This page outlines the options for management of the ktranslate container used by New Relic's network monitoring.
Container requirements
We recommend the following resources for the ktranslate container image:
Disk
- 100MB available disk space
CPU
- SNMP Polling/Trap Collection: 1 CPU core dedicated for every ~1,000 devices
- Device Flow Collection: 1 CPU core dedicated for every ~2,000 flows per second (fps)
- Syslog Message Collection: 1 CPU core dedicated for every ~2,000 messages per second
Memory
- ktranslate is not generally constrained by memory resources. The amount of memory on your host should be driven by the types of applications/containers you plan to run. For a general idea, we commonly see success with image sizes as small as the AWS t2.micro which has 1 vCPU and 1.0 GB of available RAM.
ヒント
The KTranslate container image runs a single "job type" at a time. For instance, a container deployed for SNMP polling and trap collection will not be used for flow collection. Furthermore, containers deployed for flow collection are limited to a single -nf.source
type per container. This means that it is common to have multiple containers deployed to a single Docker host at any given time. They can also share a common configuration file, but do not have to.
Updating the container
Keeping the ktranslate container image up to date is good practice to both receive the latest updates and resolve common problems through various bug fixes applied during the development lifecycle. It is recommended to always pull the latest available image when redeploying your containers.
Pull the latest container image available by running one of the following:
- Docker Hubbash$docker pull kentik/ktranslate:v2
- Quay.iobash$docker pull quay.io/kentik/ktranslate:v2
- Docker Hub
Collect the IDs and names of any existing containers:
bash$docker ps -a --filter ancestor=kentik/ktranslate:v2 --format "{{.ID}} - {{.Names}}"Output Example:
3297b134a352 - ktranslate-snmp4962a854b386 - ktranslate-sflowRemove any pre-existing containers
bash$docker rm -f $CONTAINER_IDRedeploy your ktranslate container using the original settings you deployed with from either SNMP, flow data, or syslog collection.
重要
The configuration file used by ktranslate is applied to the container at runtime. Changes to this file require you to remove and restart your running container(s) to apply the edits, with the exception of using integrated discovery jobs.
Container runtime options
Below are the various options available during Docker runtime for the ktranslate container image:
Option name | Type | Required | Description |
---|---|---|---|
| Flag | ✓ | Sets the path to the |
| Flag | ✓ | The New Relic account ID that ktranslate will ship data to. |
| Flag | Overrides the default info log level for ktranslate. The available options are | |
| Flag | Used to setup the container in SNMP discovery mode to run a single discovery job, update the provided YAML configuration file, and exit. | |
| Flag | Used to setup integrated discovery jobs within the SNMP polling container scheduled to run at a fixed interval. This setting will execute the discovery job, update the provided YAML configuration file, and then restart the SNMP collection threads on the SNMP polling container to remove the need to destroy/restart your entire container for discovered devices. | |
| Flag | When combined with the | |
| Flag | Used to setup the container to poll a target device on-demand. | |
| Flag | Forwards Docker logs from ktranslate into New Relic Logs. | |
| Flag | Forwards health metrics from ktranslate into New Relic. | |
| Flag | Appended to the container name in Docker logs to help isolate logs from various containers in New Relic Logs. | |
| Flag | Sets the regional API endpoints for ktranslate to forward telemetry to New Relic. Options are | |
| Flag | Lets you process higher volumes of data. We recommend one CPU core available for every 2,000 flows per second (fps) of network flow data sent, or every 1,000 SNMP devices being monitored, or every 2,000 syslog messages per second collected by a container. The default is | |
| Flag | Changes the default sample rate value at which flows are passed to New Relic events. This does not speed up the local configuration of flow sample rate on a device, but it can slow it down. Setting this to | |
| Flag | Overrides the number of workers used in processing network packets. Use one worker for every 4,000 of flows per second (fps) of network flow data sent. The default is | |
| Flag | Overrides the listening port for incoming flow packets. The default is | |
| Flag | Sets up the type of flow this container will process. Options are | |
| Flag | Sets the path to an application map file on the Docker container, based on a volume mount from the Docker host passed as an option during runtime. | |
| Flag | Sets the | |
| Argument | ✓ (For flow containers) | This argument statically sets the following flags: |
| Argument | ✓ (For SNMP containers) | This argument statically sets the following options: |
| Argument | ✓ (For syslog containers) | This argument statically sets the following flags: |
| Flag | Format to parse syslog messages with. Options are
| |
| Flag | IP:Port tuple to run the Syslog server on. Default: | |
| Environment Variable | ✓ | Environment variable that must be used during Docker runtime to hold the New Relic for ktranslate to send data to the New Relic APIs. Ex: |
| Environment Variable | Environment variable that can be used during Docker runtime to setup ktranslate to ship data to New Relic via proxy. Ex: | |
| Environment Variable | Environment variable that can be used during Docker runtime to setup ktranslate's | |
| Environment Variable | Environment variable that can be used during Docker runtime to pass the Meraki Dashboard API key into ktranslate. Ex: | |
Environment Variable | Environment variables that can be used during Docker runtime to retrieve secrets from AWS, Azure, or GCP. |