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
- Device Data
- Memory Usage
- CPU Usage
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:
receivers: snmp: collection_interval: 60s endpoint: udp://localhost:161 version: v3 security_level: auth_priv user: otel auth_type: "MD5" auth_password: $SNMP_AUTH_PASSWORD privacy_type: "DES" privacy_password: $SNMP_PRIVACY_PASSWORD resource_attributes: resource_attr.name.1: indexed_value_prefix: probe resource_attr.name.2: oid: "184.108.40.206" attributes: attr.name.1: value: a2_new_key enum: - in - out attr.name.2: indexed_value_prefix: device attr.name.3: oid: "220.127.116.11" metrics: # This metric will have multiple datapoints wil 1 attribute on each. # Each datapoint will have a (hopefully) different attribute value metric.name.1: unit: 1 sum: aggregation: cumulative monotonic: true value_type: int column_oids: - oid: "18.104.22.168" attributes: - name: attr.name.3 # This metric will have multiple datapoints with 2 attributes on each. # Each datapoint will have a guaranteed different attribute indexed value for 1 of the attributes. # Half of the datapoints will have the other attribute with a value of "in". # The other half will have the other attribute with a value of "out". metric.name.2: unit: "By" gauge: value_type: int column_oids: - oid: "22.214.171.124" attributes: - name: attr.name.2 - name: attr.name.1 value: in - oid: "2" attributes: - name: attr.name.2 - name: attr.name.1 value: out # This metric will have 2 datapoints with 1 attribute on each # One datapoints will have an attribute value of "in". # The other will have an attribute value of "out". metric.name.3: unit: "By" sum: aggregation: delta monotonic: false value_type: double scalar_oids: - oid: "126.96.36.199.0" attributes: - name: attr.name.1 value: in - oid: "188.8.131.52.0" attributes: - name: aattr.name.1 value: out # This metric will have metrics created with each attached to a different resource. # Each resource will have a resource attribute with a guaranteed unique value based on the index. metric.name.4: unit: "By" gauge: value_type: int column_oids: - oid: "184.108.40.206" resource_attributes: - resource_attr.name.1 # This metric will have metrics created with each attached to a different resource. # Each resource will have a resource attribute with a hopefully unique value. metric.name.5: unit: "By" gauge: value_type: int column_oids: - oid: "220.127.116.11" resource_attributes: - resource_attr.name.2
Viewing 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.