Observing telecom and network elements with OpenTelemetry means collecting SNMP metrics through the OpenTelemetry Collector's SNMP receiver and exporting them over OTLP, so network devices join the same pipeline as everything else..
Observing telecom and network elements with OpenTelemetry means collecting SNMP metrics through the OpenTelemetry Collector's SNMP receiver and exporting them over OTLP, so network devices join the same pipeline as everything else.
Much of telecom and enterprise network infrastructure, routers, switches, base stations, firewalls, exposes its health over SNMP, so the signals are per-interface errors and discards, throughput and utilization per link, device CPU and memory, and interface and device up/down state. In a network, a saturated link or a flapping interface is a service-affecting incident, and at telecom scale it needs fast, often automated, response.
The readings that matter most are link utilization and interface error rate, because a link approaching saturation and an interface accumulating errors are the two conditions that most directly degrade service across a network.
The Collector's snmp receiver polls device OIDs on an interval, interface counters, error and discard counters, throughput, and device CPU and memory, and maps them into OpenTelemetry metrics exported over OTLP. Device syslog is collected with the syslog receiver, so device events and metrics arrive together in one pipeline instead of a separate legacy silo.
The setup work is in the OID mapping and credentials: you configure which OIDs map to which metrics (interface counters via the standard IF-MIB, plus vendor-specific OIDs for CPU and memory) and use SNMPv3 with proper credentials rather than v2c community strings where you can.
The signals that explain most network-element incidents:
| Signal | Source | What it tells you / watch for |
|---|---|---|
ifHCInOctets / ifHCOutOctets | snmp (IF-MIB) | High-capacity byte counters; divided by link speed, give per-link utilization. |
ifInErrors / ifOutErrors | snmp (IF-MIB) | Interface error counters; a rising rate points to a physical or configuration fault. |
ifInDiscards / ifOutDiscards | snmp (IF-MIB) | Discarded packets, often from congestion or buffer exhaustion on a link. |
ifOperStatus | snmp (IF-MIB) | Interface up/down; flapping (repeated transitions) is a service-affecting fault. |
device CPU utilization | snmp (vendor OID) | Control-plane CPU; a saturated device CPU degrades everything it routes. |
device memory utilization | snmp (vendor OID) | Device memory; exhaustion can crash or destabilise the element. |
A network dashboard should surface link and interface health at scale. Row one: per-link utilization (throughput against link speed) and the top links by utilization. Row two: interface error and discard rates, and interface up/down and flap counts. Row three: device CPU and memory across the estate, so a struggling element is visible before it fails.
# link utilization (throughput / link speed)
rate(ifHCInOctets[5m]) * 8 / ifSpeed by (device, interface)
# interface error rate (physical/config fault)
rate(ifInErrors[5m]) + rate(ifOutErrors[5m]) by (device, interface)
# interfaces that are down or flapping
ifOperStatus != 1 by (device, interface)A link approaches its capacity, so latency and discards rise and service degrades for everything traversing it. Utilization (throughput against link speed) climbing toward 100% is the warning, and discards confirm congestion. Rebalance traffic, upgrade the link, or shape the load.
An interface accumulates errors or repeatedly transitions up and down, disrupting traffic across it. Error-counter rate and up/down transitions are the tells. The cause is usually physical (cabling, optics) or a duplex/config mismatch; the pattern distinguishes a bad cable from a config error.
A network element's control-plane CPU or memory saturates, so it slows or drops routing and everything it handles degrades. The device CPU and memory OIDs are the signal. Causes include a routing-table event, an attack, or a runaway process; at telecom scale this is exactly the kind of incident to resolve automatically.
Starting thresholds to tune:
| Condition | Signal | Meaning |
|---|---|---|
| link utilization > 80% for 5m | capacity | Link approaching saturation. |
| interface error rate rising | physical | A physical or config fault developing. |
| ifOperStatus flapping | stability | An interface repeatedly transitioning. |
| device CPU > 85% for 5m | device | Control-plane saturation. |
Ops Singularity ingests SNMP-sourced telemetry over OpenTelemetry and resolves network incidents at telecom scale through governed Action Tickets, deployable on-premises or air-gapped. Explore TelemetryOps and the best NOC automation tools.
Yes. The OpenTelemetry Collector's snmp receiver polls device OIDs and maps them into OpenTelemetry metrics exported over OTLP, and the syslog receiver collects device logs.
Interface errors and discards, per-link throughput and saturation, device CPU and memory, and device up/down state.
Bring a real incident. We will show you Sentinel investigate, act and verify end to end, with every action reversible and audited.