• EnglishEspañol日本語한국어Português
  • Log inStart now

SNMP device profiles

Profiles define both the SNMP OIDs that ktranslate collects and how it processes received SNMP trap messages. Follow the instructions here if you want to modify an existing profile or create a new one.

Requirements

Whether you're creating or modifying a profile, make sure you have the following:

Important

New Relic does not provide support directly for the contents of the kentik/snmp-profiles. If an existing SNMP profile is returning incorrect data or another breaking behavior, open an issue on the kentik/snmp-profiles repository. We are unable to provide timelines for modification or creation of SNMP profiles in the third party for ktranslate.

Depending on the service level associated with your New Relic account, you may be eligible for help from New Relic Global Technical Support. In accordance with our Global Technical Support Offerings, we will do our best to determine whether an issue is with New Relic's products or caused by something outside our control and purview. For issues with third party tools that are outside our control, we will use commercially reasonable efforts to contribute enhancements, patches, or other functional developments to the upstream open source project.

Profile creation

Use custom profiles privately

The contents of the kentik/snmp-profiles repository are loaded to ktranslate by default when you build the container or service and are therefore globally applied to all instances.

To support full customization options so you can maintain your own collection settings and patterns, do the following:

  1. Clone the repository.
  2. Make changes as you see fit.
  3. Load your custom profile directory into your Docker container or Linux service on startup.

The way this is done is by mapping your customized files to the KTranslate instance inside the etc/ktranslate/profiles/ directory.

Assuming you are in a directory just above snmp-profiles, the command to add looks like this:

bash
$
`pwd`/snmp-profiles/profiles:/etc/ktranslate/profiles

For Docker, you would add this as a volume mount, which would look similar to this:

bash
$
docker run -d --name ktranslate-$CONTAINER_SERVICE --restart unless-stopped --pull=always -p 162:1620/udp \
>
-v `pwd`/snmp-base.yaml:/snmp-base.yaml \
>
-v `pwd`/snmp-profiles/profiles:/etc/ktranslate/profiles
>
-e NEW_RELIC_API_KEY=$NR_LICENSE_KEY \
>
kentik/ktranslate:v2 \
>
-snmp /snmp-base.yaml \
>
-nr_account_id=$NR_ACCOUNT_ID \
>
-metrics=jchf \
>
-tee_logs=true \
>
-service_name=$CONTAINER_SERVICE \
>
-snmp_discovery_on_start=true \
>
-snmp_discovery_min=180 \
>
nr1.snmp

For a Linux service, you will edit the contents of /etc/ktranslate/profiles on the local host.

Tip

To remove the risk of inconsistent behavior in your environment, be sure to pass in your custom version of the profiles every time you launch a container or service.

Contribute to the public repository

As an open source repo, contributions are welcome from anyone to create new profiles or improve the existing profiles that will enhance the monitoring capabilities for all users.

New Relic isn't involved in the process of reviewing profiles on the third-party repo. All requests for changes and updates must be addressed with Kentik's maintainers via Github issues.

Shortly after a profile is merged, CI/CD automation makes the new SNMP profiles available in a new version of the Docker image.

What kinds of OIDs should I include?

In many cases SNMP offers a lot of data, but little provides actionable information. The sample SNMP walk above has 2,022 rows of results from OIDs, and the resulting profile collects about 50 total OIDs. Following the basic patterns of "Golden Signals" defined by the Site Reliability Engineering (SRE) discipline; focus on collecting data that lets you know if there is anything that would stop the device from being able to perform whatever functions you expect it to perform. Building from that, you should collect measurements that tell you how well it is performing those functions.

Example 1:

For a device operating as a VPN concentrator, we would collect high-level system metrics like:

  • CPU and memory utilization
  • Hardware sensor information to make sure that the device isn't going to shut itself down due to things like fan failures
  • OIDs that tell us about the aggregated connections and throughput

Example 2:

An OID table that lists all the running processes on a network appliance is an example of data that is available but not helpful.

Collecting all running processes might sound useful, but since this is an appliance, you normally do not have the capability or the need to do anything with the processes that run inside it. Polling and storing tables with hundreds of items that you can't actually do anything with would not be efficient.

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.