Profiles define what SNMP OIDs we want to collect and send to your New Relic account. This document explains how to modify an existing profile or create a new profile.
If you've decided to build a custom profile or modify one of our open source profiles, you need a few essential tools:
- A GitHub account: This enables you to raise issues and contribute changes to Kentik's open source profiles.
- An SNMP walk from a network device where you want to work on a profile. For more information, see our documentation on setting up SNMP and using
- Permissions to perform Docker pull on the server that hosts your
This document covers:
- Making requests for new or modified profiles through GitHub to be worked on by the maintainers
- Contributing your own profiles and modifications publicly
- Using custom profiles privately
Support for all things relating to kentik/snmp-profiles is handled through GitHub issues. New Relic technical support is not able to provide any additional help beyond redirecting you back to raise an issue there.
This is the most common and simple scenario, for cases where you don't have the time or expertise with SNMP to do these yourself. After you provide the relevant data, our team will build the profile for you.
- Log into GitHub and go to the snmp-profiles repo.
- Click the Issues tab near the top.
- Click New issue.
- To request a new profile, look for the SNMP Profile Request section, and click Get started. Provide all requested information in the template, such as the device vendor, model, snmp object identifier, and a sanitized SNMP walk.
- For all other requests, use Open a blank issue.
Providing an SNMP walk is critical as we cannot do any work on the profile without these. This is not the same as an MIB file.
The maintainers of the repo will review the information you provided and, if there is anything missing, they will follow up with you. Once all the necessary data is provided, they will add it to the queue of profiles to be built. After it is added to the repo, the issue will be closed, and all you have to do is update the ktranslate docker container on your end, and the newest profiles will automatically be loaded.
We gladly accept contributions from anyone who wants to help out to either create new profiles or improve the existing profiles.
To familiarize yourself with the structure of a profile, review this highly commented template.yml on GitHub.
Log into GitHub and go to the snmp-profiles repo.
To create a copy of the same information in your account, click the fork button near the top.
Within your fork,make necessary changes to the files, or create new vendor directories and profiles as needed.
Be sure to pass your profile through a YAML validator, such as codebeautify, before submitting a pull request.
When you are done with your changes, submit a pull request to the upstream repo.
The maintainers will review the change, and discuss any necessary feedback. When everyone is aligned, it will be merged.
Shortly after a merge, new SNMP profiles are automatically available by pulling the new version of the Docker image and launching a new container in your environment. For more information, see our documentation about SNMP manual setup.
Be sure to sync your fork regularly to keep it up to date with changes in the upstream repo.
In many cases SNMP offers a lot of data, but much of that data does not provide actionable information. Or, the data provides value that is so uncommon and low impact, it might not be worth bringing into your New Relic account.
You want to 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 on 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 example of data that is available but provides very poor value is an OID table that lists all the running processes on a network appliance. Coming from a server admin perspective, that 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.
For cases where you want to make a change to a profile, but you know that it is a scenario that is very unique and would not apply to other customers you can locally edit the profiles.
The value of
devices.[deviceName].provider is critical to entity synthesis in New Relic. More details can be found in the documentation on device configuration.
The way this is done is by using Docker's volume mount to pass in your customized files to the ktranslate container inside the
There are other ways you could accomplish this but in this example we will demonstrate using a git fork and clone.
- Ensure you are in the directory you want to keep the files in, then clone your fork of the GitHub repo to your Docker host:
git clone https://github.com/<YourGitUser>/snmp-profiles.git
- Get the command you would normally use to launch the SNMP container, and add a second volume mount argument after the one where we passed in the
-v `pwd`/snmp-profiles/profiles:/etc/ktranslate/profiles \
mount command replaces the built-in profiles directory with your customized data.
The end result will be be similar to this:
docker run -ti --name ktranslate-discovery --rm --net=host \--user `id -u`:`id -g` \-v `pwd`/snmp-base.yaml:/snmp-base.yaml \-v `pwd`/snmp-profiles/profiles:/etc/ktranslate/profiles \kentik/ktranslate:v2 \-snmp /snmp-base.yaml \-log_level info \-snmp_discovery=true
Be sure to pass your custom version of the profiles in every time you launch a discovery container or SNMP polling container. If you don't use it consistently for all SNMP instances sets, this can cause unreliable behavior.