Skip to main content
The SNMP integration requires CXDOT Collector 1.6.0 or greater. Simple Network Management Protocol (SNMP) is a protocol for monitoring network devices. Use the SNMP integration with the CXDOT Collector to collect availability and performance metrics from SNMP devices. The SNMP integration supports SNMP v1, v2c, and v3. The integration polls individual devices with its built-in generic-device metrics. It doesn’t scan network address ranges, use vendor-specific metric profiles, receive traps, build network topology or device inventories, collect network flow records, or run ping checks.

Supported telemetry types

The SNMP integration supports these telemetry types:

Prerequisites

The SNMP integration has the following prerequisites:
  • Enable SNMP v1, v2c, or v3 on each device.
  • Obtain a community string for SNMP v1 or v2c. For SNMP v3, obtain a user name and the authentication and privacy credentials required by the selected security level.
  • Allow the Collector to reach each device over User Datagram Protocol (UDP). Include the port in every endpoint, such as router.example.com:161 for the standard SNMP port.

Configure

To configure the SNMP integration, follow these steps:
  1. Choose how each integration instance finds SNMP targets:
    • To poll known devices directly, add a static device list to the Helm values file for your CXDOT Collector. For example:
      Use your deployment’s secret management to set SNMP_COMMUNITY in the Collector environment. The integration polls exactly the devices in this list and doesn’t process autodiscovery annotations for this integration instance.
    • To use Kubernetes annotation-based autodiscovery, annotate pods or Services with the target’s SNMP connection settings and explicitly select the generic-device profile. The CXDOT Collector ignores other profile selections. Because the integration is enabled by default, annotation-based targets don’t require an integration configuration block. Annotation-based autodiscovery creates targets only from these Kubernetes annotations. It doesn’t scan address ranges or discover unannotated network devices. For more information, see autodiscovery.
  2. Optional: Configure a second integration instance to use static targets and compatible annotations together. For example, add the following to the values.yaml file for your CXDOT Collector Helm chart:
    The bare snmp key defines the static target instance. The snmp/discovered key defines a named instance that processes compatible annotations.

Validate

To validate the SNMP integration, follow these steps:
  1. In the Live Telemetry Analyzer, add the following filters:
    • __name__=cxdot.integration.target.health
    • cxdot.integration.name=snmp
    Confirm that one time series appears for each device, identified by the server.address and server.port labels. A reachable device reports 1, and an unreachable device reports 0.
  2. In Metrics Explorer, run the following query:
    Confirm that the query reports each reachable device’s interface count.

Configuration reference

Configure one SNMP integration instance with the following settings. In Helm values, place these settings under config.integrations.snmp. In a Collector configuration file, place them under cxdot.integrations.snmp.

Optional settings

  • enabled Type: boolean. Optional. Default: true. Whether to enable this configuration block. If true, the Collector runs the integration or capability. If false, the Collector doesn’t run it.
  • devices Type: array of object. Optional. Default: []. Network devices to poll. Each endpoint is host:port; include port 161 explicitly for the standard SNMP UDP endpoint. Every device uses the built-in generic-device metric profile. A nonempty list disables autodiscovery for this integration instance. To use both target methods, configure a separate named integration instance.
  • devices[].auth_password Type: string. Optional. Authentication password for authenticated SNMP v3.
  • devices[].auth_type Type: string. Optional. Authentication protocol for authenticated SNMP v3. Allowed values: MD5, SHA, SHA224, SHA256, SHA384, SHA512.
  • devices[].community Type: string. Optional. Community string for SNMP v1 or v2c.
  • devices[].context_name Type: string. Optional. SNMP context name for an SNMP v3 device.
  • devices[].endpoint Type: string. Required. Device address as host:port, normally router.example.com:161.
  • devices[].privacy_password Type: string. Optional. Privacy password for private SNMP v3.
  • devices[].privacy_type Type: string. Optional. Privacy protocol for private SNMP v3. Allowed values: DES, AES, AES192, AES192C, AES256, AES256C.
  • devices[].security_level Type: string. Optional. Authentication and privacy level for SNMP v3. Allowed values: no_auth_no_priv, auth_no_priv, auth_priv.
  • devices[].user Type: string. Optional. User name for SNMP v3.
  • devices[].version Type: string. Required. SNMP protocol version used by the device. Allowed values: v1, v2c, v3.
  • collection_interval Type: duration. Optional. Default: 15s. Time between SNMP polls of each device.
  • timeout Type: duration. Optional. Default: 15s. How long a single scrape may run before it is abandoned. Defaults to collection_interval and must not exceed it: a scrape that outlives its own tick holds up the scrape that should have started next, and the backlog delays the collector’s shutdown by as many intervals as it takes to drain. Scrapes against an endpoint that has gone away — a deleted pod’s address, a removed static target — are the usual way to hit that, since a freed address often swallows the connection instead of refusing it, so the scrape runs out the full deadline.
  • request_timeout Type: duration. Optional. Default: 2s. Time to wait for one SNMP request before retrying or abandoning it.