• /
  • ログイン
  • 無料アカウント

Advanced configuration for network performance monitoring

If you want to explore all the options you can use when configuring the monitoring of your network performance, 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.

devices:
# Sample of SNMP v2c device
ups_snmpv2c__10.10.0.201:
device_name: ups_snmpv2c
device_ip: 10.10.0.201
snmp_comm: public
oid: .1.3.6.1.4.1.318.1.3.27
description: "APC Web/SNMP Management Card (MB:v4.1.0 PF:v6.2.1 PN:apc_hw05_aos_621.bin AF1:v6.2.1 AN1:apc_hw05_sumx_621.bin MN:AP9537SUM HR:05 SN: ABC123DEF456 MD:05/21/2016) (Embedded PowerNet SNMP Agent SW v2.2 compatible)"
last_checked: 2021-11-09T18:14:59.907821489Z
mib_profile: apc_ups.yml
provider: kentik-ups
poll_time_sec: 300
retries: 1
timeout_ms: 5000
user_tags:
owning_team: dc_ops
discovered_mibs:
- PowerNet-MIB_UPS
- TCP-MIB
- UDP-MIB
# Sample of SNMP v3 device
router_snmpv3__10.10.0.202:
device_name: router_snmpv3
device_ip: 10.10.0.202
snmp_v3:
user_name: userNamev3
authentication_protocol: MD5
authentication_passphrase: authPassPrivacy
privacy_protocol: AES256
privacy_passphrase: passPrivacy
oid: .1.3.6.1.4.1.9.1.544
description: "Cisco IOS Software, 3800 Software (C3845-ADVENTERPRISEK9-M), Version
15.1(3)T4, RELEASE SOFTWARE (fc1)\r\nTechnical Support: http://www.cisco.com/techsupport\r\nCopyright
(c) 1986-2012 by Cisco Systems, Inc.\r\nCompiled Thu 24-May-12 04:27 by prod_rel_team"
last_checked: 2021-11-09T18:14:59.907821489Z
mib_profile: cisco-asr.yml
provider: kentik-router
user_tags:
owning_team: core-networking
discovered_mibs:
- BGP4-MIB
- CISCO-MEMORY-POOL-MIB
- CISCO-PROCESS-MIB
- IF-MIB
- OSPF-MIB
engine_id: "80:00:01:01:0a:14:1e:28"
match_attributes:
if_interface_name: "^Ten.*|^Gig.*"
"!if_Alias": "[Uu]plink"
# Sample of SNMP v1 device
netbotz_snmpv1__10.10.0.203:
device_name: netbotz_snmpv1
device_ip: 10.10.0.201
snmp_comm: public
use_snmp_v1: true
oid: .1.3.6.1.4.1.5528.100.20.10.2013
description: "Linux netbotz930A7A 2.6.12 #307 Wed Dec 29 15:25:32 EST 2010 ppc"
last_checked: 2021-11-09T18:14:59.907821489Z
mib_profile: apc-netbotz.yml
provider: kentik-netbotz
user_tags:
owning_team: sys_ops
discovered_mibs:
- IF-MIB
- IP-MIB
- TCP-MIB
- UDP-MIB
no_use_bulkwalkall: true
# Sample of "flow only" device
flow_only__10.10.0.210:
device_name: flow_only
device_ip: 10.10.0.210
user_tags:
owning_team: net_eng
flow_only: true
# Sample of "ping only" device
ping_only__10.10.0.220:
device_name: ping_only
device_ip: 10.10.0.220
user_tags:
owning_team: load_balancing
ping_only: true
trap:
listen: 127.0.0.1:1162
community: public
version: ""
transport: ""
v3_config: null
discovery:
cidrs:
- 10.0.0.0/24
- 10.0.0.202/32
debug: false
ports:
- 161
- 1161
default_communities:
- public
- public123
- Publ!cABC
use_snmp_v1: false
default_v3: null
add_mibs: true
threads: 4
add_devices: true
replace_devices: true
no_dedupe_engine_id: false
global:
poll_time_sec: 60
drop_if_outside_poll: false
mib_profile_dir: /etc/ktranslate/profiles
mibs_db: /etc/ktranslate/mibs.db
mibs_enabled:
- BGP4-MIB
- CISCO-MEMORY-POOL-MIB
- CISCO-PROCESS-MIB
- IF-MIB
- IP-MIB
- OSPF-MIB
- PowerNet-MIB_UPS
- TCP-MIB
- UDP-MIB
timeout_ms: 3000
retries: 0
global_v3: null
response_time: false
user_tags:
environment: production
match_attributes:
if_Description: ".*WAN.*"

Optional 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.

The syntax for these files is "@fileName.extension", including the double quotes.

Discovery CIDRs

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

Devices

Example:

devices:
- "@neteng-devices.yaml"
- "@dc-ops.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: public
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

SNMPv3 - AWS Secrets

ktranslate has built-in support for retrieving keys from AWS Secrets Manager to use in your SNMPv3 configuration.

To use this feature, you will need to set the following 3 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.

AWS_REGION

Specifies the AWS Region to send requests to for commands requested using this profile.

Example for Docker runtime:

bash
$
docker run -d --name ktranslate-snmp --restart unless-stopped --net=host \
>
-v `pwd`/snmp-base.yaml:/snmp-base.yaml \
>
-e NEW_RELIC_API_KEY=$YOUR_NR_LICENSE_KEY \
>
-e AWS_ACCESS_KEY_ID=$YOUR_AWS_ACCESS_KEY_ID \
>
-e AWS_SECRET_ACCESS_KEY=$YOUR_AWS_SECRET_ACCESS_KEY \
>
-e AWS_REGION=$YOUR_AWS_REGION \
>
kentik/ktranslate:v2 \
>
-snmp /snmp-base.yaml \
>
-nr_account_id=$YOUR_NR_ACCOUNT_ID \
>
-log_level=info \
>
-metrics=jchf \
>
-tee_logs=true \
>
nr1.snmp

In your associated configuration file (snmp-base.yaml); you would update your SNMPv3 config snippet as follows, prefixing the secret name with aws.sm.:

default_v3:
user_name: aws.sm.SECRET_NAME_1
authentication_protocol: MD5
authentication_passphrase: aws.sm.SECRET_NAME_2
privacy_protocol: AES256
privacy_passphrase: aws.sm.SECRET_NAME_3

ヒント

You need to create dedicated secrets per value. Note in the example above there are three distinct secret names in use.

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.<deviceName>.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.

The flow_only attribute

To support monitoring of devices where performance statistics are nor accessible, available, or desired, you can set the devices.<deviceName>.flow_only attribute to true.

This will generate a Flow Device entity in New Relic One 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 One, you can see the results of this polling by investigating the following events:

FROM KFlow SELECT count(*) FACET device_name WHERE instrumentation.name = 'netflow-events' TIMESERIES

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.<deviceName>.ping_only attributes to true.

This feature uses the go-ping package to send unprivileged UDP packets to devices in order to collect the average, min, and max RTT for the endpoint based on sending 1 packet/sec from ktranslate to the device IP address.

Setting the global.response_time attribute to true will add RTT monitoring on top of existing SNMP polling. devices.<deviceName>.ping_only: true will allow you to monitor devices with only the UDP packets for RTT and no SNMP polling.

In New Relic One, 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' FACET device_name TIMESERIES

ヒント

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.

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.

Example Filters

  • Only collect flow data from source addresses in the 10.0.0.0/24 CIDR range
-nf.source sflow --filters addr,src_addr,%,10.10.0.0/24
  • Only collect flow data where the destination port is not equal to 8531
-nf.source netflow5 --filters int,l4_dst_port,!=,8531

You can also add multiple filters together with an inherited AND operator

  • Only collect flow data from source addresses in the 10.0.0.0/24 CIDR range AND where the destination port is not equal to 8531
--filters addr,src_addr,%,10.0.0.0/24 --filters int,l4_dst_port,!=,8531
問題を作成する
Copyright © 2022 New Relic Inc.