If you want to explore all the options you can use when configuring the monitoring of your network, see the following sections.
snmp-base.yaml sample file
Here's an example of the various configuration options available in the snmp-base.yaml file used by the ktranslate Docker image to poll for SNMP and flow data devices. You can also see a heavily-commented sample in the KTranslate repository on GitHub.
# Configuration of every device monitored by this container
Indicates whether to enable debug level logging during SNMP polling. By default, it's set to false.
port
Port to send SNMP queries to. By default, it's set to port 161.
oid
✓ (Required for SNMP polling)
The discovered systemObjectID | sysObjectID | sysOID for the device. This is used to match the device to a known SNMP profile and set the provider attribute. If no match is found, this sets the provider as a kentik-default device.
description
The discovered sysDescr of the device. This field is informational.
last_checked
Timestamp when this device was last discovered by the ktranslate Docker image. This field is informational.
mib_profile
✓ (Required for SNMP polling)
SNMP Profile file that was associated with this device during the discovery run based on its sysOID. If this starts with a bang (!) token, it will override the automatic matching from the sysOID and use a manual override. Ex: "!cisco-asa.yml" (quotes are required).
provider
✓ (Required for New Relic)
Value used during entity synthesis for New Relic. This is automatically created based on the matched mib_profile and must match one of the rules in the entity-definitions repository in order for an entity to be created. If you are manually adding devices, you will need to take caution to make sure this value is valid.
poll_time_sec
Indicates the SNMP polling frequency in seconds. This setting is used to override the global.poll_time_sec attribute.
retries
Indicates the number of attempts to retry polling SNMP OIDs. This setting is used to override the global.retries attribute.
timeout_ms
Indicates the SNMP polling timeout in milliseconds. This setting is used to override the global.timeout_ms attribute.
user_tags
key:value pair attributes to give more context to the device. Tags at this level will be appended to any tags applied in the global.user_tags attribute.
discovered_mibs
List of MIBs pulled from matched mib_profile that this device can respond to. This field is informational.
engine_id
The unique engine ID discovered for this device's SNMP agent. Generally found during SNMP v3 discovery. This field is informational.
match_attributes
attribute:regex pairs to add metrics to allowlist. Pairs at this level will be appended to any pairs applied in the global.match_attributes attribute. Uses the RE2 syntax and has a default OR operator. Prefix key with ! to force to AND operators.
monitor_admin_shut
Indicates whether to monitor interfaces in Administratively Shutdown status. By default, it's set to false.
no_use_bulkwalkall
Disables the SNMP GETBULK request action when true. By default, it's set to false.
response_time
Indicates whether response time polling is enabled for this device. By default, it's set to false.
ping_only
Disables all SNMP polling and enables response time polling for this device when true. This setting will override the global.response_time attribute. By default, it's set to false. You will want to make sure you have included the line provider: kentik_ping for each ping_only device.
ping_interval_sec
This setting is used to override the default rate of 1 packet/sec used during ping_only | response_time polling.
flow_only
Disables all SNMP polling when true. By default, it's set to false.
purge_after_num
Removes device from config file after X scheduled discovery jobs have failed. This setting overrides the global purge_devices_after_num setting. Set this to -1 to keep device forever, or any integer >= 1 to set up a purge threshold. (Default: 0)
Disables all SNMP polling for this device_name config. Default: false.
Key name
Required
Description
listen
✓
Listening IP port for receiving SNMP traps. By default it's set to 0.0.0.0:1620 and we use a redirect in your docker run ... command to redirect the more common UDP 162 on the host to UDP 1620 in the container. The redirect is done with this flag -p 162:1620/udp
community
SNMPv1/v2c community string for receiving SNMP traps. By default we still process incoming traps even if they do not match this community.
version
SNMP version to use. Options are v1, v2c, and v3. By default, it's set to v2c.
transport
SNMP transport protocol to use. Options are TCP and UDP. By default, it's set to UDP
Setting this to true will prevent the container from attempting any SNMP or ICMP polling, used in cases where you want a container that only listens for incoming traps.
drop_undefined
Setting this to true will prevent the container from forwarding any SNMP trap messages that are not explicitly defined in an existing SNMP profile. (Default: false)
Multiple SNMPv3 configurations to scan during SNMP polling. Use this option OR default_v3, not both
add_devices
✓
Indicates whether to add discovered devices to the devices section of the snmp-base.yaml file. By default, it's set to true.
add_mibs
✓
Indicates whether to add discovered MIBs to the global.mibs_enabled section of the snmp-base.yaml file. By default, it's set to true.
threads
✓
Integer limit of threads to use during discovery. It should be less than the number of cores available to the container. By default it's set to 4.
replace_devices
✓
Indicates whether to replace discovered devices if they already exist in the devices section of the snmp-base.yaml file. By default, it's set to true.
no_dedup_engine_id
When set to true, disables deduplication of discovered devices if it appears that they are the same device, based on their reported SNMP engine ID. By default, it's set to false
check_all_ips
When set to true, forces the discovery job to attempt SNMP connectivity against every target IP address from the cidrs array, without checking for liveliness first via TCP port scan. This setting will slow down discovery jobs, but can help bypass issues where discovery is failing against devices that are not listed in your cidrs array with /32 overrides. By default, it's set to false
Key name
Required
Description
poll_time_sec
✓
Time in seconds to poll devices. This can be overridden per device using the devices.<deviceName>.poll_time_sec attribute. By default, it's set to 60.
drop_if_outside_poll
Indicates whether to drop all values from this cycle if polling takes longer than the value set in poll_time_sec. By default, it's set to false.
mib_profile_dir
Directory to find curated MIB profiles. These are pulled into the ktranslate image automatically from Kentik's snmp-profiles repository and can be overridden at Docker runtime by creating a volume mount of your own local directory of profiles.
mibs_db
mibs_enabled
✓
Array of all active MIBs the ktranslate Docker image will poll. This list is automatically generated during discovery if the discovery_add_mibs attribute is true. MIBs not listed here will not be polled on any device in the configuration file. You can specify a SNMP table directly in a MIB file using MIB-NAME.tableName syntax. Ex: HOST-RESOURCES-MIB.hrProcessorTable.
timeout_ms
✓
Time in milliseconds SNMP queries timeout. This can be overridden per device using the devices.<deviceName>.timeout_ms attribute. By default, it's set to 3000.
retries
✓
Number of attempts to retry failed SNMP polls. This can be overridden per device using the devices.<deviceName>.retries attribute. By default, it's set to 0.
user_tags
key:value pair attributes to give more context to the device. Tags at this level will be applied to all devices in the configuration file.
match_attributes
attribute:regex pairs to add metrics to allowlist. Pairs at this level will matched against all devices in the configuration file. Uses the RE2 syntax and has a default OR operator. Prefix key with ! to force to AND operators.
response_time
Indicates whether response time polling is enabled for all devices in the configuration file. By default, it's set to false.
purge_devices_after_num
Removes devices from config file after X scheduled discovery jobs have failed. Set this to -1 to keep devices forever, or any integer >= 1 to set up a purge threshold. By default, it's set to 0.
SNMPv1 and SNMPv2c do not support the use of cloud secrets as the protocols themselves send their community strings via plain text by default. If you are concerned about the security of your SNMP authentication, please update to use SNMPv3.
To use AWS Secrets Manager, you will need to set the following three environmental variables and provide them to Docker at runtime:
Name
Description
AWS_ACCESS_KEY_ID
Specifies the AWS access key used as part of the credentials to authenticate the user.
AWS_SECRET_ACCESS_KEY
Specifies the AWS secret key used as part of the credentials to authenticate the user.
To use Azure Key Vault, you will need to set the following five environmental variables and provide them to Docker at runtime:
Dica
You need to set KT_AZURE_KEY_VAULT_NAME or KT_AZURE_KEY_VAULT_URL, not both. The default is to use KT_AZURE_KEY_VAULT_NAME and the agent will use a common URL pattern: https://$KT_AZURE_KEY_VAULT_NAME.vault.azure.net/
This is the client secret (password) that is used for the service principal during authentication. Note this ID is for the client secret's value, not the ID of the secret itself.
To use GCP Secret Manager, you will need to set the following volume mount for a credential JSON file along with two environmental variables and provide them to Docker at runtime:
Specifies the local file path for the service account key used to authenticate the user. This file is volume mounted into the Docker container and then referenced in the GOOGLE_APPLICATION_CREDENTIALS environment variable.
SNMPv3 authentication protocol. The possible values are NoAuth, MD5, or SHA
authentication_passphrase
SNMPv3 authentication passphrase
privacy_protocol
✓
SNMPv3 privacy protocol. The possible values are NoPriv, DES, AES, AES192, AES256, AES192C, or AES256C
privacy_passphrase
SNMPv3 privacy passphrase
context_engine_id
SNMPv3 context engine ID
context_name
SNMPv3 context name
Examples:
Dica
Using secrets from AWS, Azure, of GCP will also require that you provide the proper environment variables and any other authentication information needed for the agent to query the target API.
To support running discovery jobs with multiple SNMP v3 profiles, you can replace the discovery.default_v3 key with the discovery.other_v3s key, which holds an array of SNMPv3 configurations.
This can also work using a cloud provider secrets manager. An example for AWS:
discovery:
other_v3s:
- aws.sm.$YOUR_SECRET_NAME_1
- aws.sm.$YOUR_SECRET_NAME_2
API polling configurations
Dica
You can also use cloud provider secrets in your API authentication configuration.
The Arista eAPI integration collects additional BGP and MLAG telemetry that isn't typically available via SNMP polling.
BGP details are collected from this command: show ip bgp summary vrf all
NRQL to find BGP telemetry:
FROM Metric SELECT
max(kentik.eapi.bgp.InMsgQueue)AS'InQ',// Messages Queued from the Neighbor
max(kentik.eapi.bgp.MsgReceived)AS'MsgSent',// Messages Received from the Neighbor
max(kentik.eapi.bgp.MsgSent)AS'MsgRcvd',// Messages Sent to the Neighbor
latest(peer_state)AS'State',// State of the BGP session
latest(kentik.eapi.bgp.UpDownTime)AS'Up/Down',// Period the BGP session has been in current state
latest(kentik.eapi.bgp.Version)AS'V'// BGP version number
FACET
entity.name AS'Device',
router_id AS'Device IP',
peer AS'BGP Peer',
peer_asn AS'BGP Peer ASN',
vrf AS'VRF Name'
MLAG details are collected from this command: show mlag detail
NRQL to find MLAG telemetry:
FROM Metric SELECT
latest(kentik.eapi.mlag.PortsConfigured)AS'Ports Configured',// Count of MLAG ports currently configured
latest(kentik.eapi.mlag.PortsDisabled)AS'Ports Disabled',// Count of MLAG ports in 'Disabled' state
latest(kentik.eapi.mlag.PortsActivePartial)AS'Ports Active-partial',// Count of MLAG ports in 'Active-partial' state
latest(kentik.eapi.mlag.PortsInactive)AS'Ports Inactive',// Count of MLAG ports in 'Inactive' state
latest(kentik.eapi.mlag.PortsActiveFull)AS'Ports Active-full',// Count of MLAG ports in 'Active-full' state
latest(kentik.eapi.mlag.PortsErrdisabled)AS'Ports Err-disabled',// Count of MLAG ports in 'Err-disabled' state
latest(config_sanity)AS'Config-Sanity',// Current result of 'config-sanity' check
latest(state)AS'State',// Current MLAG state
latest(neg_status)AS'Negotiation Status',// Current negotiation status between switches
latest(peer_address)AS'Peer Address',// Address of MLAG peer
latest(peer_link)AS'Peer Link',// Link name for MLAG peer
latest(peer_link_status)AS'Peer Link Status',// Status of MLAG peer
latest(local_interface)AS'Local Interface',// Local interface used for MLAG configuration
latest(local_intf_status)AS'Local Interface Status'// Status of local interface used for MLAG configuration
FACET
entity.name AS'Device',
domain_id AS'MLAG Domain ID'
Configuration options
Key name
Required
Description
eapi_config.username
✓
The username to pass to the device to authenticate the eAPI authentication.
eapi_config.password
✓
The password to pass to the device to authenticate the eAPI authentication.
eapi_config.transport
Specifies the type of connection transport to use. The possible values are https and http. Default: https.
eapi_config.port
✓
The TCP port of the endpoint for the eAPI connection.
The Meraki Dashboard API integration pulls various metrics related to the health of your Meraki environment. The combination of configuration options allows you to set up different monitoring scenarios for your needs and creates entities in your New Relic account.
Organization metrics are collected by default under the kentik.meraki.organization.Count metric which is exclusively used to generate the Meraki Organization entity. This is mainly to enable visualization of the Meraki hierarchy to align networks and devices to their parent organization.
NRQL to find organization configuration change telemetry:
FROM KExtEvent SELECT*
meraki_config.preferences.show_network_attr: true
Network metrics are collected under the kentik.meraki.network.Count metric which is exclusively used to generate the Meraki Network entity. This is mainly to enable visualization of the Meraki hierarchy and align the devices to the network they are members of.
meraki_config.monitor_devices: true && meraki_config.preferences.device_status_only: true: Uses the Get Organization Device Statuses endpoint to list the status of every Meraki device in the organization.
NRQL to find device status telemetry:
FROM Metric SELECT
latest(status)AS'Device Status'// Current status of this device
FACET
org_id AS'Organization ID',
org_name AS'Organization Name',
network_id AS'Network ID',
network AS'Network Name',
device_name AS'Device Name',
src_addr AS'Device Public IP',
mac AS'Device MAC',
model AS'Device Model',
serialAS'Device Serial',
address AS'Device Address',
lat AS'Device Latitude',
lng AS'Device Longitude',
notes AS'Device Notes'
WHERE instrumentation.name ='meraki.device_status'
max(kentik.meraki.uplinks.LatencyMS)AS'Uplink Latency',// Uplink measured latency in milliseconds
max(kentik.meraki.uplinks.LossPct)AS'Uplink Loss %',// Uplink measured loss percentage
max(kentik.meraki.uplinks.Recv)AS'Uplink Receive Bytes',// Uplink bytes received
max(kentik.meraki.uplinks.Sent)AS'Uplink Transmit Bytes',// Uplink bytes sent
latest(status)AS'Uplink Status'// Latest status of the uplink
FACET
org_id AS'Organization ID',
org_name AS'Organization Name',
network_id AS'Network ID',
network AS'Network Name',
device_name AS'Device Name',
interface AS'Device Uplink Interface',
model AS'Device Model',
serialAS'Device Serial'
WHERE org_id ISNOTNULL
meraki_config.monitor_uplinks: true && meraki_config.preferences.hide_uplink_usage: true: Uses the Get Organization Uplinks Statuses endpoint to list only the uplink status of every Meraki MX, MG and Z series device in the organization.
NRQL to find device uplink status telemetry:
FROM Metric SELECT
latest(status)AS'Uplink Status'// Latest status of the uplink
FACET
org_id AS'Organization ID',
org_name AS'Organization Name',
network_id AS'Network ID',
network AS'Network Name',
device_name AS'Device Name',
interface AS'Device Uplink Interface',
model AS'Device Model',
serialAS'Device Serial'
WHERE org_id ISNOTNULL
meraki_config.monitor_vpn_status: true && meraki_config.preferences.show_vpn_peers: false: Uses the Get Organization Appliance VPN Statuses endpoint the show VPN statuses across the networks in the organization.
NRQL to find VPN status telemetry:
FROM Metric SELECT
latest(status)AS'VPN Status'// Latest status of this VPN
FACET
org_id AS'Organization ID',
org_name AS'Organization Name',
network_id AS'Network ID',
network AS'Network Name',
device_name AS'Device Name',
serialAS'Device Serial',
vpn_mode AS'VPN Mode',
wan1 OR wan2 AS'WAN Interface IP'
WHERE instrumentation.name ='meraki.vpn_status'
AND org_id ISNOTNULL
meraki_config.monitor_vpn_status: true && meraki_config.preferences.show_vpn_peers: true: Uses the Get Organization Appliance VPN Statuses endpoint to add information about VPN peers across the networks in the organization.
NRQL to find VPN peers telemetry:
FROM Metric SELECT
latest(status)AS'Peer Status'// Current status of this VPN peer
FACET
network_id AS'Network ID',
network AS'Network Name',
device_name AS'Device Name',
serialAS'Device Serial',
vpn_mode AS'VPN Mode',
wan1 AS'WAN 1 IP',
wan2 AS'WAN 2 IP',
peer_name AS'Peer Name',// Name of this peer
peer_reachability AS'Peer Reachability',// Latest results of reachability test for this peer
peer_network_id AS'Peer Network ID',// Network ID for this peer
peer_type AS'Peer Type'// Type of Peer (Meraki vs Third-party)
WHERE metricName ='kentik.meraki.vpn_status.PeerStatus'
Dica
You can use the KENTIK_MERAKI_API_KEY environment variable to pass your API key into the Meraki integration without storing it in plain text on your configuration file.
Filters all monitoring to a specific list of networks.
meraki_config.product_types
Valid types are wireless, appliance, switch, systemsManager, camera, cellularGateway, sensor, and cloudGateway. (Default: null)
Adds parameters to the monitor_devices API request to filter on specific types of devices.
These options allow you to further define the data collected from the main configuration options. Various combinations are described in the examples section above.
Key name
Required
Input
Description
meraki_config.preferences.device_status_only
true | false (Default: false)
Required when using monitor_devices: true to restrict polling to only status information. (This is used to prevent timeout issues.)
meraki_config.preferences.hide_uplink_usage
true | false (Default: false)
Used in combination with monitor_uplinks to remove performance metrics and only return status information for uplinks.
meraki_config.preferences.show_vpn_peers
true | false (Default: false)
Used in combination with monitor_vpn_status to add telemetry on VPN peers.
meraki_config.preferences.show_network_attr
true | false (Default: false)
Used to add telemetry on networks. Required to create Meraki Network entities.
Minimum configuration example
# This represents the minimal configuration required for a container that only performs Meraki API polling.
# By default we only monitor uplinks. All other items are optional.
---
devices:
meraki_cloud_controller:
device_name: meraki_cloud_controller
device_ip: snmp.meraki.com
provider: meraki-cloud-controller
ext:
ext_only:true
meraki_config:
api_key:"$YOUR_API_KEY"
trap:{}
discovery:{}
global:
poll_time_sec:300
timeout_ms:30000
Full configuration examples [#meraki-full-config]
All options required to create the Meraki Organization, Meraki Network, and Meraki Device entities.
devices:
meraki_dashboard_api:
device_name: meraki_controller
device_ip: snmp.meraki.com
provider: meraki-cloud-controller
ext:
ext_only:true
meraki_config:
api_key: $YOUR_MERAKI_API_KEY
monitor_devices:true
monitor_org_changes:true
monitor_uplinks:true
monitor_vpn_status:true
preferences:
device_status_only:true
hide_uplink_usage:false
show_vpn_peers:true
show_network_attr:true
trap:{}
discovery:{}
global:
poll_time_sec:300
timeout_ms:30000
Targeting multiple Meraki Dashboard API keys
devices:
# Entity 1 - monitor everything this API key has access to
meraki_all:
device_name: meraki_all
device_ip: snmp.meraki.com
provider: meraki-cloud-controller
ext:
ext_only:true
meraki_config:
api_key:"$YOUR_API_KEY_1"
max_http_retry:8
monitor_devices:true
monitor_org_changes:true
monitor_uplinks:true
monitor_vpn_status:true
preferences:
device_status_only:true
show_vpn_peers:true
hide_uplink_usage:false
# Entity 2 - Monitor these specific organizations under this API key
meraki_single_org:
device_name: meraki_single_org
device_ip: snmp.meraki.com
provider: meraki-cloud-controller
ext:
ext_only:true
meraki_config:
api_key:"$YOUR_API_KEY_2"
monitor_devices:true
monitor_org_changes:true
monitor_uplinks:true
monitor_vpn_status:true
preferences:
device_status_only:true
show_vpn_peers:true
hide_uplink_usage:false
organizations:
-"Org 1 - Prod.*"
-"Org 2 - Staging"
# Entity 3 - Monitor specific devices filtered by organization, network, and product types; using the same API key from Entity 2
meraki_filtered:
device_name: meraki_filtered
device_ip: snmp.meraki.com
provider: meraki-cloud-controller
ext:
ext_only:true
meraki_config:
api_key:"$YOUR_API_KEY_2"
monitor_devices:true
monitor_uplinks:false
preferences:
device_status_only:true
organizations:
-"Org 3 - Remote Sites"
networks:
-"Corp.*99"
-"Retail.*"
product_types:
- wireless
- appliance
trap:{}
discovery:{}
global:
poll_time_sec:300
timeout_ms:30000
External config files
To support a wide variety of configuration and automation needs, you can use external files that you volume mount into your Docker container to decouple certain elements of the standard configuration file. You will need to include the mount argument below in your docker run command, with one argument per external configuration file.
-v `pwd`/fileName.yaml:/fileName.yaml \
The syntax for these files is "@fileName.yaml", including the double quotes.
Example:
discovery:
cidrs:"@cidrs.yaml"
The CIDRs file should use a YAML list syntax like this:
- 10.10.0.0/24
- 10.20.0.0/24
- 192.168.0.21/32
Example:
devices:
"@neteng-devices.yaml"
The device files should use the same syntax as the standard devices section of the main config file, omitting the optional fields that are generated during discovery:
devices:
# Sample of SNMP v2c device
ups_snmpv2c__10.10.0.201:
device_name: ups_snmpv2c
device_ip: 10.10.0.201
snmp_comm: $YOUR_COMMUNITY_STRING
oid: .1.3.6.1.4.1.318.1.3.27
mib_profile: apc_ups.yml
provider: kentik-ups
poll_time_sec:300
retries:1
timeout_ms:5000
user_tags:
owning_team: dc_ops
The match_attributes attribute
To support filtering of data that does not create value for your observability needs, you can set the global.match_attributes.{} and/or devices.[].match_attributes.{} attribute map.
This will provide filtering at the ktranslate level, before shipping data to New Relic, giving you granular control over monitoring of things like interfaces.
The default behavior of this map is an OR condition, but you can override this and force an AND operator by prefixing your key name with !. This is also useful to return only matched items and omit all null and "" (empty) results.
Match when if_Alias begins with UplinkOR when if_interface_name begins with Gig, keep all null and "" values:
devices:
deviceName:
...
match_attributes:
if_Alias:"^Uplink.*"
if_interface_name:"^Gig.*"
Match when if_Alias begins with UplinkAND when if_interface_name begins with Gig, drop all null and "" values:
devices:
deviceName:
...
match_attributes:
if_Alias:"^Uplink.*"
"!if_interface_name":"^Gig.*"
Match when if_Alias begins with Uplink, drop all null and "" values:
devices:
deviceName:
...
match_attributes:
"!if_Alias":"^Uplink.*"
Golang's regex package does not support negative lookahead patterns (q(?!u)) by default. As a workaround, you can add the DOES_NOT_MATCH token to your attribute map to effectively give you the inverse results of your matching pattern.
For example, to match on every interface that does not include the string Uplink; you can use a configuration like this:
devices:
deviceName:
...
match_attributes:
"!if_Alias":"^Uplink.*"
DOES_NOT_MATCH:true
The response_time and ping_only attributes
To support monitoring of devices where performance statistics are not accessible or available, or in simple cases where basic round-trip time (RTT) monitoring is required, you can either set the global.response_time or devices.[].ping_only attributes to true.
This feature uses the go-ping package to send either ICMP (default) or unprivileged UDP packets to devices in order to collect the average, min, max, and stddev round-trip time (RTT). This package also shows packet loss percentage for the endpoint based on sending one packet/sec from ktranslate to the device IP address, which can be overridden by setting the devices.[].ping_interval_sec attribute. You can switch from the default use of privileged ICMP packets to UDP by setting the KENTIK_PING_PRIV=false environment variable during Docker runtime.
Setting the global.response_time attribute to true will add RTT monitoring on top of existing SNMP polling. To monitor devices with only the UDP|ICMP packets for RTT and no SNMP polling, use devices.[].ping_only: true.
In New Relic, you can see the results of this polling by investigating the following metrics:
FROM Metric SELECT
average(kentik.ping.AvgRttMs)AS'Average',
max(kentik.ping.MaxRttMs)AS'Max',
min(kentik.ping.MinRttMs)AS'Min',
average(kentik.ping.StdDevRtt)AS'StdDev',
latest(kentik.ping.PacketLossPct)AS'Packet Loss %'
FACET device_name
Dica
You can use the ping_only attribute in replacement of the flow_only attribute if you would like to collect RTT metrics from a flow device. If both ping_only and flow_only are true, the device will be treated as a flow_only device.
The flow_only attribute
To support monitoring of devices where you only want to collect flow data, you can set the devices.<deviceName>.flow_only attribute to true.
This will generate a Flow Device entity which will only have telemetry in the KFlow event namespace. Alternatively, collecting flow telemetry from a device that is in your configuration file as an SNMP device will add decoration of the KFlow data to the pre-existing entity, such as a Router or Firewall.
In New Relic, you can see the results of this polling by investigating the following events:
FROM KFlow SELECT*
WHERE instrumentation.name ='netflow-events'
Flow data application mapping
By default, flow telemetry is mapped to known applications based on evaluation of the layer 4 port in use on a specific flow conversation. If needed, you can override the default mapping by providing a YAML file during Docker runtime to the -application_map flag. This will allow you to specify application names based on ports you identify.
Example syntax:
applications:
-ports:[9092,9093]
name: kafka
-ports:[80,8080]
name: http
-ports:[443,8443]
name: https
Flow data input filtering
By default, flow data containers will collect and process every flow packet they receive. If needed, you can add an inclusion filter to the -nf.source flag that will ignore all traffic not matching the filter you provide.
Syntax: --filters $TYPE,$FIELD,$FUNCTION,$MATCH
Argument Name
Required
Description
$TYPE
✓
The type of filter to apply. Possible values are string, int, and addr.
$FIELD
✓
The name of the field to evaluate the match pattern against.
$FUNCTION
✓
The type of function to use during evaluation. Possible values are Equal: ==, NotEqual: !=, LessThan: <, GreaterThan: >, Contains: %
$MATCH
✓
The value to be used as a match pattern.
Only collect flow data from source addresses in the 10.0.0.0/24 CIDR range
By default, the ktranslate Docker container must be manually destroyed and rebuilt to incorporate changes to the SNMP profiles in the mib_profile_dir path. This is normal behavior in most deployments as the Docker image pulls in the latest profiles available from the public snmp-profiles repository. In situations where you provide custom profiles, you can use the watch_profile_changes setting to enable the container to automatically refresh the underlying configurations and SNMP profiles for the container.
Importante
This is not recursive because of a limitation in the watcher library. So, if a profile changes in a subdirectory, you must also edit a top-level file to trigger the change.
Assuming this directory structure:
.
└── /snmp-profiles/
└── profiles/
└── kentik-snmp/
├── 3com
├── _general
├── a10networks
└── ...
You will need to place a new file at the root of the directory and manually change it to trigger this refresh cycle. An easy way to implement this is to simply write a timestamp to a file such as last_updated.txt when your change is submitted.