What is Telemetry
Telemetry, in networking, is technology for high-speed remote data collection from network devices. Instead of a management system repeatedly asking each device for updates, monitored devices proactively and in real time push their own metrics — CPU, memory, traffic statistics — along with logs and events, directly to a collector or analytics platform. That push model is what makes telemetry fundamentally different from traditional pull-based monitoring like SNMP polling: data arrives as it happens, rather than waiting for the next poll cycle to catch it.
Telemetry typically runs over gRPC, Google's high-performance, open-source RPC framework built on HTTP/2, using Protocol Buffers to define interfaces and binary encoding for transmission. gRPC handles the transport, security, and encoding work, so both sides of the connection can focus purely on defining what data to exchange rather than how to move it. Telemetry data itself is commonly encoded as JSON_IETF — the YANG JSON encoding defined in IETF RFC 7951 — giving it a structured, standards-based format the collector can parse reliably.
How Telemetry Works
Telemetry supports two fundamentally different subscription modes, distinguished by which side initiates the connection. In Dial-in mode, the network device acts as the server and the collector acts as the client — the collector connects to the device and listens for data, which keeps device-side configuration minimal and suits short-term, ad hoc monitoring. In Dial-out mode, the roles flip: the device acts as the client and proactively connects to the collector, pushing data outward. This is the better fit for long-term monitoring across large-scale networks, since the collector doesn't need to maintain (or re-establish) a connection to every device individually.
Each mode supports its own reporting modes. Dial-in supports both stream (with on-change reporting for data only when something actually changes, or sampled reporting at a fixed interval) and poll (data retrieved only when the collector explicitly asks). Dial-out supports periodic reporting (data sent at a regular interval) and stream reporting (triggered by change) — the same on-change/interval-based distinction, just initiated from the device side instead.
What gets collected is defined by collection targets and collection paths. Targets fall into DB types — structured internal databases like COUNTERS_DB (per-interface counters), STATE_DB (operational state), APPL_DB, ASIC_DB, and others — and a non-DB type called OTHERS, covering system-level data like CPU and memory statistics that don't live in a structured database. Collection paths for DB-type data can be as specific as <TABLE>/<KEY>/<Field>, or use predefined "virtual paths" the platform ships with — for example, a path that collects egress packet-loss counters across every Ethernet interface at once using a wildcard, rather than requiring one subscription per port.
Why Telemetry is Beneficial
Real-time visibility, not polling delay: Push-based delivery means a collector learns about a change or event as it happens, rather than waiting up to a full poll interval to notice.
Scales to large networks without polling overhead: Dial-out mode lets thousands of devices push data outward on their own schedule, avoiding the linear scaling problem of a collector having to individually poll every device in a growing fabric.
Granular, purpose-built data paths: Structured collection paths — down to a specific table, key, and field — mean operators subscribe to exactly the data they need, instead of parsing through broad, general-purpose MIB-style responses.
Faster fault isolation: Because metrics like packet loss, PFC counters, and queue drops can be streamed continuously rather than sampled periodically, operators can correlate a network event with the moment it actually occurred.
Standards-based and interoperable: Built on gRPC and JSON_IETF/YANG encoding, telemetry data integrates cleanly with modern observability stacks like OpenTelemetry, rather than requiring a proprietary collector.