Skip to content

Connect over SNMP

SNMP is how CORE-M ingests from gear that will never run a CORE-M agent — switches, routers, UPSes, PDUs, and industrial controllers. Unlike the other protocols, the device does not push to CORE-M. Instead CORE-M polls the device for OID values on a schedule, and optionally receives traps the device emits. Both are normalized: polls become telemetry, traps become device events.

ModelDirectionPortBecomes
PollingCORE-M → device (GET)161Telemetry (TelemetryPoint)
TrapsDevice → CORE-M162Device events
  • Polling is the primary path. The adapter runs one polling goroutine per enabled target, issues SNMP GETs for the configured OIDs on the target’s interval, and publishes the results as telemetry. Each cycle records poll latency and status.
  • Traps are the asynchronous path. When the device raises an event (link down, threshold breach), it sends a trap to the receiver on 162, which normalizes it into a device event.

Both SNMP v2c and v3 are supported per target.

v2c authenticates with a community string. Set it on the target:

FieldValue
versionv2c
communityyour read community (kept secret, never logged)

v2c has no encryption — use it only on trusted management networks.

The device profile maps each polled OID to a CORE-M metric name. Numeric OID values land in numeric_values; everything else lands in string_values. The OID response is used only for the value — the device and tenant identity always come from the target configuration, never from the wire.

OIDMeaningCORE-M metric
.1.3.6.1.2.1.1.3.0sysUpTimesys_uptime
.1.3.6.1.2.1.2.2.1.10.1ifInOctets (if 1)if1_in_octets
.1.3.6.1.2.1.2.2.1.16.1ifOutOctets (if 1)if1_out_octets
.1.3.6.1.4.1.318.1.1.1.2.2.1.0UPS battery capacityups_battery_pct

For example, polling .1.3.6.1.2.1.1.3.0 on a 60-second interval and mapping it to sys_uptime publishes a TelemetryPoint with numeric_values.sys_uptime every minute.

sequenceDiagram
    participant DL as device-link SNMP poller
    participant Dev as Network device :161
    participant RP as Redpanda telemetry.raw.{tenant}

    loop every poll interval
        DL->>Dev: SNMP GET (configured OIDs)
        Dev-->>DL: OID values
        DL->>DL: Map OIDs → metrics (identity from target)
        DL->>RP: Publish TelemetryPoint
        DL->>DL: Record poll latency + status
    end

When a trap arrives from a known device, the trap receiver normalizes it into a device event and publishes device.event.{tenant_id}.{device_id}. This is how asynchronous conditions (a port going down, a power event) surface in CORE-M without waiting for the next poll cycle.

A trap from a source that matches no target credential or gateway mapping is rejected — it is not turned into an event. The auth-failure metric corem_protocol_auth_failures_total{protocol="snmp"} is incremented. This keeps unsolicited or spoofed traps from injecting events for devices CORE-M does not recognize.

Reach for SNMP when…

  • The device is network or industrial gear that already speaks SNMP and cannot run a custom agent.
  • You want centralized, scheduled polling rather than device-initiated pushes.
  • You need asynchronous fault notification via traps alongside metric polling.
  • The MIBs you care about are standard and stable (interfaces, system, UPS).

For devices you control end to end, an agent-push protocol — MQTT, HTTP, or CoAP — gives finer control and lower latency.