@risinamit - please see responses to your queries below:
1. What will be definition of docker host?
Can you be more descriptive? I’m not sure what you’re asking about here. The docker host is the Linux server running docker that you host your ktranslate container(s) on. The container image for SNMP traps will be the same image used for SNMP polling and on-premises flow collection (kentik/ktranslate:v2
).
2. Is docker host capable to send traps to NewRelic?
Yes, by default ktranslate sets up a passive listener for SNMP traps on UDP port 1620. This port can be edited in the trap section of your container configuration file.
3. Which component will process all the incoming traps on the docker host?
The ktranslate container will process all traps, setup a payload compatible with our Event API; and then forward the traps into the New Relic Event API using the KSnmpTrap
namespace.
4. Where will I do configuration on docker host to send traps to New Relic?
Configuration of the ktranslate listener is in the trap section of the configuration file. By design, the container will use the host network, meaning that you will setup your devices to send traps to the IP address of the linux server running docker.
5. Is there any other component required to be installed on docker host?
It is helpful to have the tcpdump utility on the host in order to create packet capture (.pcap
) files, which we use during profile generation and troubleshooting.
6. How can ensure that only relevant data is forwarded to New Relic?
The easiest way is to create a GitHub issue for a new SNMP Traps profile and provide a sample .pcap
file that we can use to create a profile (like this one) in order to create friendly display names for the various trap varbinds. Note this is not required and ktranslate will forward all traps even without a profile; but the results in New Relic will be attributes with OIDs as the key names instead of a friendly name.
e.g.; looking at the profile example above:
- name: vmwVpxdOldStatus
OID: 1.3.6.1.4.1.6876.4.3.304.0
tag: old_status
With a profile; the results of a received trap in New Relic could be queried like this:
FROM KSnmpTrap SELECT latest(old_status) FACET device_name
Without a profile, it would look like this:
FROM KSnmpTrap SELECT latest(`1.3.6.1.4.1.6876.4.3.304.0`) FACET device_name
As far as restricting which particular traps are collected; that is handled either on the device configuration where the traps are generated, or you can create drop rules that will drop data on our ingest pipeline before writing to disk.
7. Data flow for traps from NW to New Relic is not available anywhere.
There is a high-level architectural diagram in our docs site. Is this what you’re looking for?
Hope this helps to clear up some confusion, please don’t hesitate to ask any other questions that you may need clarification on.