How to Monitor SNMP with OpenTelemetry
With observIQ’s latest contributions to OpenTelemetry, you can now use free open source tools to easily aggregate data across your entire infrastructure to any or multiple analysis tools. The easiest way to use the latest OpenTelemetry tools is with observIQ’s distribution of the OpenTelemetry collector. You can find it here.
In this blog, we cover how to use OpenTelemetry to monitor SNMP – you can use the SNMP receiver to ship logs to many popular analysis tools, including Google Cloud, New Relic, OTLP, Grafana, and more.
What signals matter?
SNMP is a network management protocol that’s used to exchange data between network devices. There are three main versions of SNMP, all of which are supported by the SNMP OpenTelemetry receiver. The SNMP receiver is most often used to monitor local area devices on the same network, so important signals vary by what kinds of devices appear on the network. SNMP is different from other recievers because it requires more specific knowledge of the devices on the network, and specific configurations for the metrics to be collected. Some data that can be collected from SNMP includes:
- Network Data
- Processes
- Uptime
- Throughput
- Device Data
- Memory Usage
- CPU Usage
- Temperature
Installing the Receiver
If you don’t already have an OpenTelemetry collector built with the latest SNMP receiver installed, we suggest using the observIQ OpenTelemetry Collector distro that includes the SNMP receiver (and many others). Installation is simple with our one-line installer. Come back to this blog after running the install command on your source.
Configuring the Receiver
Navigate to your OpenTelemetry configuration file. If you’re using the observIQ Collector, you’ll find it in one of the following location:
- /opt/observiq-otel-collector/config.yaml (Linux)
- C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml (Windows)
Edit the configuration file to include the SNMP receiver like in the example shown below. Keep in mind that because of the considerable variety with SNMP managers, your configuration will be different (and likely not as long). Detailed instructions for configuring SNMP monitoring can be found here on GitHub. See the following for examples:
1receivers:
2 snmp:
3 collection_interval: 60s
4 endpoint: udp://localhost:161
5 version: v3
6 security_level: auth_priv
7 user: otel
8 auth_type: "MD5"
9 auth_password: $SNMP_AUTH_PASSWORD
10 privacy_type: "DES"
11 privacy_password: $SNMP_PRIVACY_PASSWORD
12
13 resource_attributes:
14 resource_attr.name.1:
15 indexed_value_prefix: probe
16 resource_attr.name.2:
17 oid: "1.1.1.1"
18
19 attributes:
20 attr.name.1:
21 value: a2_new_key
22 enum:
23 - in
24 - out
25 attr.name.2:
26 indexed_value_prefix: device
27 attr.name.3:
28 oid: "2.2.2.2"
29
30 metrics:
31 # This metric will have multiple datapoints wil 1 attribute on each.
32 # Each datapoint will have a (hopefully) different attribute value
33 metric.name.1:
34 unit: 1
35 sum:
36 aggregation: cumulative
37 monotonic: true
38 value_type: int
39 column_oids:
40 - oid: "2.2.2.1"
41 attributes:
42 - name: attr.name.3
43 # This metric will have multiple datapoints with 2 attributes on each.
44 # Each datapoint will have a guaranteed different attribute indexed value for 1 of the attributes.
45 # Half of the datapoints will have the other attribute with a value of "in".
46 # The other half will have the other attribute with a value of "out".
47 metric.name.2:
48 unit: "By"
49 gauge:
50 value_type: int
51 column_oids:
52 - oid: "3.3.3.3"
53 attributes:
54 - name: attr.name.2
55 - name: attr.name.1
56 value: in
57 - oid: "2"
58 attributes:
59 - name: attr.name.2
60 - name: attr.name.1
61 value: out
62 # This metric will have 2 datapoints with 1 attribute on each
63 # One datapoints will have an attribute value of "in".
64 # The other will have an attribute value of "out".
65 metric.name.3:
66 unit: "By"
67 sum:
68 aggregation: delta
69 monotonic: false
70 value_type: double
71 scalar_oids:
72 - oid: "4.4.4.4.0"
73 attributes:
74 - name: attr.name.1
75 value: in
76 - oid: "4.4.4.5.0"
77 attributes:
78 - name: aattr.name.1
79 value: out
80 # This metric will have metrics created with each attached to a different resource.
81 # Each resource will have a resource attribute with a guaranteed unique value based on the index.
82 metric.name.4:
83 unit: "By"
84 gauge:
85 value_type: int
86 column_oids:
87 - oid: "5.5.5.5"
88 resource_attributes:
89 - resource_attr.name.1
90 # This metric will have metrics created with each attached to a different resource.
91 # Each resource will have a resource attribute with a hopefully unique value.
92 metric.name.5:
93 unit: "By"
94 gauge:
95 value_type: int
96 column_oids:
97 - oid: "1.1.1.2"
98 resource_attributes:
99 - resource_attr.name.2Viewing the metrics collected
If you follow the steps detailed above, the following SNMP logs will now be delivered to your specified destination. If you have issues, make sure that all authentication fields are accurate and that your exporter has the intended endpoint.
observIQ’s monitoring technology is a game changer for organizations that care about performance and efficiency. If you’re using SNMP, our solutions can make a significant difference in your monitoring. Follow this space to keep up with all our future posts and simplified configurations for various sources. For questions, requests, and suggestions, reach out to our support team at support@observIQ.com. Join our open source observability community Slack Channel.
