Abstract

Network observability has traditionally been a fragmented landscape: SNMP for interface counters, NetFlow or IPFIX for flow records, syslog for events, and vendor-proprietary streaming telemetry for everything more granular. OpenTelemetry (OTel), initially designed to unify application observability signals, has expanded its scope to cover network infrastructure through evolving semantic conventions and the OTel Collector’s extensible pipeline model. This article examines how OTel Collector receiver plugins, processors, and exporters can consolidate network telemetry into a single pipeline, reducing the number of per-protocol collection daemons and giving network and application teams a shared observability stack.

The OTel Collector as a Network Telemetry Hub

The OpenTelemetry Collector is a vendor-neutral agent that ingests telemetry data through receivers, processes it through a chain of processors, and exports it to one or more backends. For network infrastructure, the most relevant receivers are the SNMP receiver (contributed by the observIQ community and now in the opentelemetry-collector-contrib repository), the Netflow receiver for IPFIX and NetFlow v9 records, and the gnmi receiver for streaming gNMI telemetry from modern routers and switches.

The SNMP receiver polls OIDs on a configurable interval and converts the results to OTel metrics with consistent attribute naming. The gnmi receiver connects to devices via gRPC and subscribes to gNMI paths using the SAMPLE or ON_CHANGE subscription modes, translating the ProtoBuf-encoded updates into OTel metric data points. Having both poll-based and streaming ingestion in the same Collector process eliminates the need to run separate daemons for legacy SNMP devices and modern gNMI-capable hardware, with output flowing to the same Prometheus or Thanos backend.

Processors for Normalization and Enrichment

Raw telemetry from network devices uses inconsistent naming across vendors. A counter for inbound octets might be ifInOctets from SNMP, openconfig-interfaces:in-octets from a gNMI path, or a proprietary attribute name from a vendor SDK. OTel processors handle normalization before data reaches the backend.

The transform processor, using OTTL (OpenTelemetry Transformation Language) expressions, renames attributes and converts units inline - for example, converting byte counters to bits per second by computing deltas between samples and multiplying by eight. The resource processor attaches device-level metadata - site, role, ASN, vendor - by joining against a resource catalog, which can be a static file, a Consul KV lookup, or an HTTP endpoint. The metricstransform processor can aggregate per-interface metrics up to per-device or per-site summaries. Chaining these processors in a single pipeline produces normalized, enriched metrics ready for alerting and dashboarding without any post-processing in the backend.

Routing Telemetry to Multiple Backends

One Collector pipeline can fan out to multiple exporters simultaneously. Network operations teams often want raw interface metrics in a time-series database (Prometheus, VictoriaMetrics) while security teams want flow records shipped to a SIEM (Elastic, Splunk). The OTel routing connector and fanout exporter patterns support this: a single Collector instance can export the same stream to Prometheus remote-write, an OTLP endpoint, and a file exporter for audit archiving, all configured in one config.yaml.

This multi-backend fan-out is operationally significant because it removes the need to run separate collection agents for each consumer. Teams that previously maintained a Telegraf deployment for Prometheus, a flow collector for the SIEM, and a vendor agent for cloud dashboards can consolidate into a single Collector DaemonSet on each collector node, with all routing and transformation logic codified in version-controlled configuration.

Current Limitations

Network device coverage is the main gap. The OTel gnmi receiver works well against devices running OpenConfig models (Juniper, Arista, Nokia, recent Cisco IOS-XR builds), but older Cisco IOS-XE platforms and many campus switches only support SNMP or proprietary telemetry. The SNMP receiver’s performance at scale is also bounded by poll interval and device response latency; high-frequency counters still benefit from dedicated streaming collectors. The OTel network semantic conventions for network device metrics are still in the development stability level as of mid-2025, meaning attribute names and metric naming may change in minor releases. Teams adopting the network receivers today should pin their Collector version and plan for a normalization update when conventions stabilize.