network telemetry
Imagine the difference between a doctor who only checks on you when you phone for an appointment, and a fitness band that quietly streams your heart rate every second whether you ask or not. Older network monitoring, like SNMP, mostly works the first way: the manager keeps phoning each device to ask "how are you?" Network telemetry flips this around — devices continuously push a steady stream of their own measurements to a collector, without waiting to be polled.
Concretely, with streaming telemetry you subscribe a device to a set of metrics — interface counters, queue depths, CPU load, error rates — and the device then sends updates on its own schedule, perhaps several times a second, in a compact, structured encoding rather than one query-and-answer exchange per value. Because the device pushes instead of being asked, you avoid the round trips and the gaps between polls, and you can collect far more detail from far more devices at far higher frequency. The most modern form goes deeper still: in-band telemetry can have each packet pick up tiny measurements as it crosses each switch, so you can see exactly where in the network a given flow met its queuing delay.
It is worth being clear about why this matters and what it does not solve on its own. Polling thousands of devices every few seconds simply does not scale, and second-by-second push gives the fine-grained, near-real-time visibility that fast automated reactions need. But telemetry is the data firehose, not the understanding — pushing more numbers faster only helps if something downstream stores, correlates, and makes sense of them. That downstream job, of turning streams of data into answers about whether the system is healthy and why, is what observability is about.
Instead of an SNMP poll every 30 seconds, a router streams interface and queue statistics to a collector every second over a structured channel (such as gNMI). When a microburst fills a queue for 200 ms, the telemetry stream captures it; the old 30-second poll would have missed the spike entirely between samples.
Telemetry has devices push their own metrics continuously, catching short-lived events that periodic polling samples right past.
Telemetry is the data stream, not the understanding: pushing more numbers faster helps only if something downstream stores and correlates them. Turning those streams into answers about why the system behaves as it does is the job of observability.