What Is Network Telemetry? Types, Sources, and How to Use It
Reviewed for technical accuracy by: Eric Hian-Cheong, Senior Product Marketing Manager at Kentik, specializing in network monitoring, AI-assisted operations, and flow analytics.
Network telemetry is the data from and about your network — measurements of the devices that move traffic and observations of the traffic itself — collected continuously so that teams can understand performance, plan capacity, detect threats, and find the root cause of problems. It spans flow records like NetFlow and IPFIX, device metrics from SNMP and streaming telemetry, routing tables and BGP updates, synthetic test results, configuration state, and event streams like syslog.
This article explains what network telemetry is, the types and sources that matter, how telemetry is collected, why the application-world “four pillars” of observability don’t map cleanly onto networks, and how raw telemetry becomes answers.
Network Telemetry at a Glance
- What it is: Data about your network rather than the data moving through it — from device health metrics to records describing every traffic conversation.
- The major types: Traffic (flow records, packet data), device metrics, events, tables (routing and forwarding state), synthetic measurements, routing data, configuration, DNS, and business/operational context.
- Where it comes from: Routers, switches, and access points; servers, clients, and IoT endpoints; cloud VPCs and container environments; firewalls and load balancers; and dedicated test agents.
- How it’s collected: SNMP polling and traps, gNMI streaming telemetry, flow export (NetFlow, sFlow, IPFIX, cloud flow logs), syslog, device APIs, and synthetic testing.
- Why MELT falls short: The application-observability pillars (Metrics, Events, Logs, Traces) don’t describe networks well — network telemetry is better understood as metrics, traffic, events, tables, configuration, and business context.
- What it’s for: Performance troubleshooting, capacity planning, security detection (DDoS, exfiltration, C2 patterns), cloud cost control, and proving whether the network is — or isn’t — the problem.
What is network telemetry?
Network telemetry refers to the data generated from and about a network: the state and health of the equipment that makes it up, and detailed observations of the traffic that crosses it. The distinction from ordinary network data is the about. A video stream crossing a switch is network data; the flow record describing that stream — who sent it, where it went, which protocol, how many bytes, over which interface — is network telemetry.
That second category is where most of the value lives. Device-level telemetry tells you a router’s CPU is healthy and an interface is passing 1.4 Gbps. Traffic telemetry tells you what that 1.4 Gbps actually is: which applications, which sources and destinations, which countries and providers, and whether the mix looks like business as usual or something that demands attention. Combined with routing data, synthetic measurements, and configuration state, telemetry answers the questions that application-layer tools cannot — where in the path a problem lives, which hop is adding latency, whether traffic is taking the route you expect, and who or what is responsible for a change.
Network telemetry matters for four broad reasons. It is the foundation of performance troubleshooting, because most performance problems live in the network between systems rather than at either end. It drives capacity planning and cost control, from WAN circuits to cloud egress. It is a primary security signal: DDoS attacks, data exfiltration, and command-and-control beaconing all leave traffic-telemetry fingerprints. And it provides the ground truth in the oldest argument in IT — proving whether the network is the problem, or definitively showing that it isn’t.
Kentik in brief: Kentik is the network intelligence platform built on unified network telemetry. Kentik ingests traffic telemetry (NetFlow, sFlow, IPFIX, J-Flow, and cloud VPC flow logs), device telemetry (SNMP and gNMI streaming telemetry via Kentik NMS), BGP routing data, synthetic test results, and events into a single data model — enriching every record at ingest with routing, geography, application, and business context. That unified, enriched foundation is what lets engineers (and Kentik AI Advisor) correlate across telemetry types in one workflow instead of swivel-chairing between tools. For a book-length treatment of this subject, see the O’Reilly guide Practical Guide to Modern Networking Telemetry, written by Kentik co-founder Avi Freedman and Leon Adato.
Learn everything you need to know about network telemetry in this new O'Reilly guide.
What are the types of network telemetry?
Network telemetry breaks down into a manageable set of categories, each answering a different class of question.
Traffic telemetry describes how data is flowing across the network: which conversations are happening, between which endpoints, using which protocols and how much volume. Formats include NetFlow, IPFIX, and sFlow exported from routers and switches, VPC flow logs from cloud providers, eBPF-based observations from hosts and containers, and full packet capture where fidelity demands it. Traffic telemetry is typically the most voluminous and highest-cardinality type — and the one that benefits most from enrichment.
Device metrics report the state and health of physical and virtual network equipment: CPU and memory utilization, interface counters, errors and discards, temperature, and component status. These arrive via SNMP polling, gNMI streaming telemetry, and device APIs. (See Network Device Monitoring for a full treatment.)
Events are discrete, timestamped records that something happened: a login attempt, a threshold crossing, an interface going down, a configuration change. SNMP traps and syslog are the classic carriers. Events in networking map roughly to what the application world calls logs.
Tables are snapshots of the state inside network devices — routing tables, forwarding tables, ARP and MAC tables. They are less commonly collected than metrics or traffic but invaluable for understanding what a device intended to do with a packet at a moment in time.
Synthetic measurements are generated by tests rather than real users: scheduled pings, traceroutes, DNS lookups, HTTP checks, and multi-step transactions run from distributed agents. Synthetics answer questions real traffic cannot — including how a path performs at 3 a.m. when nobody is using it, and whether a problem is global or specific to certain vantage points. (See What Is Synthetic Monitoring and Network Path Analysis.)
Routing telemetry captures the paths traffic will take, primarily via BGP: route announcements and withdrawals, AS paths, and policy attributes. Routing data explains why traffic moved the way it did, and is essential for diagnosing reroutes, leaks, and hijacks.
Configuration data represents operating intent — device configs, ACLs, topology, software versions. Knowing precisely when a configuration changed is frequently the difference between a mystery outage and a five-minute fix.
Business and operational context — sometimes called “Layer 8” data — maps technical telemetry to what the organization cares about: which customer an interface serves, which application owns a prefix, which site a device lives in. This context is what turns “traffic from 10.4.2.0/24 dropped” into “the Cleveland call center just lost its SaaS path.”
DNS telemetry rounds out the picture by revealing what names traffic is actually associated with, putting IP-level observations into human-readable context.
Where does network telemetry come from?
Every category above originates somewhere, and a complete telemetry strategy starts with an inventory of sources:
- Routers, switches, and access points are the workhorses, producing flow records, interface metrics, routing tables, and events across data centers, campuses, WANs, and provider networks.
- Servers, clients, and IoT endpoints contribute host-level traffic observations (increasingly via eBPF in cloud-native environments) and the client-side perspective that network-only views lack.
- Cloud VPCs and container environments generate flow logs and cloud-provider metrics that are the only practical visibility into infrastructure you don’t physically control.
- Firewalls, load balancers, and service meshes sit in the middle of critical traffic and emit logs and metrics rich with application context.
- And TAPs, SPAN ports, and packet brokers mirror traffic for tools that need packet-level fidelity.
Each source sees something the others can’t. The recurring theme of modern network operations is that no single telemetry type or source is sufficient — the questions that matter are answered by correlation across them.
Do the four pillars of observability apply to networks?
The application observability world organizes itself around a familiar framework: Metrics, Events, Logs, and Traces (MELT), sometimes argued as three pillars, sometimes four. The framework is useful for applications, but it maps poorly onto networks. In networking, events and logs are essentially the same thing. There is no meaningful analog for distributed traces — the closest network concept, the path a packet takes, is observed through entirely different means. And MELT has no place for the network’s most valuable data type: traffic.
A network-native framing works better. Network telemetry is best understood as metrics (device and interface health), traffic (how data moves across the network), events (timestamped records that something occurred), tables (device state snapshots), configuration (operating intent), and business context (what the network activity means to the organization).
Teams that adopt this framing tend to instrument more completely, because the framework prompts the question MELT never asks: do we have visibility into the traffic itself?
A related question is whether OpenTelemetry (aka “OTel”) — the application world’s standard transport — can carry network telemetry. Today, the answer is “only partially”: OTel is metrics-centric, and the network’s richest data types (flow records, routing updates, tables) don’t have natural OTel representations. Enterprises standardizing on OpenTelemetry typically run it alongside, not instead of, native network telemetry protocols.
How is network telemetry collected?
Collection methods pair with telemetry types, and most production networks use several at once:
- SNMP remains the most widely supported method for device metrics — a poll-based protocol in which a collector requests values (or receives threshold-triggered traps) from an agent on each device. Its weaknesses are coarse polling intervals, per-vendor inconsistency in how the same metric is exposed, and load on device CPUs at scale.
- Streaming telemetry (primarily gNMI over gRPC) inverts the model: devices push metrics continuously at much finer granularity with lower device impact, which is why it has become essential for catching short-lived events like microbursts that minute-scale polling averages away.
- Flow export (NetFlow, IPFIX, sFlow, J-Flow, and cloud flow logs) is the standard for traffic telemetry, with a single well-placed exporter able to describe conversations among hundreds of systems it routes for.
- Syslog carries events and freeform device messages.
- Device APIs and CLI scraping fill the gaps — many platforms still expose certain metrics, configurations, and tables only this way.
- And synthetic testing agents generate measurements on schedule from the vantage points that matter.
For a deeper protocol-level treatment of these methods, see Network Monitoring Protocols: 6 Essential Network Technologies.
From raw telemetry to answers
Collecting telemetry is the easy half. Raw telemetry arrives in inconsistent formats, at enormous volume, missing the context that makes it meaningful — and the work between collection and insight is where most of the engineering lives.
- Enrichment adds context at ingest: BGP attributes like AS path, IP geolocation, application identification, site and customer mappings. Because the underlying mappings change constantly (the global routing table alone holds roughly a million routes that can churn by tens of thousands per second), enrichment must happen as data streams in — it cannot be bolted on at query time.
- Normalization reconciles the same measurement arriving in different forms — the same interface byte count exposed differently via SNMP, streaming telemetry, and API, or flow records whose dimensions differ by protocol generation.
- Sampling and aggregation manage volume without destroying fidelity, with sample rates tracked so counters can be correctly scaled.
- And storage must match the data’s shape: traffic telemetry, with its trillions of rows and hundreds of dimensions, lives best in columnar datastores, while lower-cardinality device metrics fit time-series databases.
This is also why “send everything everywhere” fails as a strategy. Mature telemetry architectures route data deliberately — through collectors and pipelines that filter, enrich, and replicate streams to the systems that need them — rather than pointing every device at every tool.
The payoff for getting this right is correlation. The interface is saturated — with what traffic, owned by which team? Latency spiked — did a routing change cause it? Retransmits are climbing — on which segment, and was there a config change in the window? Every one of those questions joins two or more telemetry types, and answering them in minutes instead of hours is the practical difference between a telemetry pile and a network intelligence practice.
How Kentik unifies network telemetry
Kentik is the network intelligence platform for modern infrastructure teams, and unified telemetry is its foundation. The platform ingests every major network telemetry type — flow records (NetFlow, sFlow, IPFIX, J-Flow), cloud VPC flow logs, SNMP and gNMI streaming telemetry via Kentik NMS, BGP routing data, synthetic test results from Kentik Synthetics, and device events — into the Kentik Data Engine, where records are enriched at ingest with routing, geographic, application, and business context and stored at full fidelity.
Because every telemetry type shares one data model, correlation is a query rather than a project. You can use Kentik to pivot from a device alert to the flows crossing that interface, from a path change to the BGP event behind it, from a traffic spike to the customer it belongs to.
Kentik AI Advisor works across the same unified telemetry, running multi-step, natural-language investigations with the agent’s reasoning visible at each step. And for teams managing their own telemetry plumbing, Kentik publishes ktranslate, an open source agent for collecting, transforming, and securely transporting metric and traffic telemetry.
Related Reading on Network Telemetry
- Practical Guide to Modern Networking Telemetry (O’Reilly ebook) — the free, book-length guide by Kentik co-founder Avi Freedman and Leon Adato that inspired this article.
- Network Telemetry Pipelines: Collecting, Enriching, and Routing Network Data — a guide to what telemetry pipelines do, the architectures NetOps teams use to build them, the processing stages inside them, and how to keep the pipeline itself observable.
- Network Monitoring Protocols: 6 Essential Network Technologies — the protocol-level companion: SNMP, flow, ICMP, and more in depth.
- SNMP vs. Streaming Telemetry: How They Work, How They Differ, and When to Use Each — a deep dive into the two principal methods for collecting metrics from network devices.
- NetFlow Guide: Types of Network Flow Analysis — everything about traffic telemetry’s most important family of formats, including flow enrichment.
- Network Device Monitoring — device metrics, SNMP vs. streaming telemetry, and AI-assisted device workflows.
- Microburst Detection — a case study in why telemetry resolution matters: catching the sub-second events polling can’t see.
- What Is Synthetic Monitoring — the active-measurement side of network telemetry.
- Network Performance Monitoring — how telemetry types combine into an NPM practice.
FAQs about Network Telemetry
What is network telemetry?
Network telemetry is data from and about a network — both the health and state of the devices that compose it and detailed observations of the traffic crossing it — collected continuously to support performance troubleshooting, capacity planning, security detection, and cost management. It includes flow records, device metrics, events, routing data, synthetic measurements, configuration state, and the business context that ties technical data to organizational meaning.
What are the main types of network telemetry?
The major categories are traffic telemetry (NetFlow, IPFIX, sFlow, cloud flow logs, eBPF observations), device metrics (SNMP, streaming telemetry), events (SNMP traps, syslog), tables (routing and forwarding state), synthetic measurements (scheduled tests from agents), routing data (BGP), configuration data, DNS telemetry, and business or operational context. Most real-world questions are answered by correlating two or more of these types rather than any one alone.
What is the difference between network monitoring and network telemetry?
Network telemetry is the data; network monitoring is what you do with it. Telemetry refers to the raw measurements and records collected from devices and traffic, while monitoring (and the broader practice of observability) covers the systems and workflows that collect, store, analyze, alert on, and visualize that data. Strong monitoring is impossible without broad, high-quality telemetry underneath it.
What is the difference between SNMP and streaming telemetry?
SNMP is poll-based: a collector requests metric values from each device on an interval, typically every 30–60 seconds, which limits granularity and adds CPU load on devices at scale. Streaming telemetry is push-based: devices export metrics continuously over gRPC/gNMI at much finer intervals with a more consistent data structure and lower device impact. Streaming telemetry is the practical requirement for catching short-lived events — like microbursts — that polling intervals average into invisibility, though SNMP remains far more universally supported across device fleets.
Do the four pillars of observability (MELT) apply to network telemetry?
Not cleanly. Metrics, Events, Logs, and Traces describe application observability well, but in networking, events and logs are essentially the same thing, there is no true analog for traces, and the framework omits the network’s most important data type entirely: traffic. A network-native framing — metrics, traffic, events, tables, configuration, and business context — describes what network teams actually need to collect and correlate.
How can I centralize flow logs, NetFlow, sFlow, and IPFIX for analytics?
Centralizing flow telemetry means exporting all flow formats to a unified collection and analytics layer that normalizes the differing dimensions across protocol generations, scales the counters by sample rate, enriches records with routing and application context, and stores them at full fidelity for querying. Kentik serves as this unified layer: NetFlow, sFlow, IPFIX, J-Flow, and cloud VPC flow logs are ingested into one data model, enriched at ingest, and made immediately queryable alongside device metrics, routing data, and synthetic test results.
What is telemetry enrichment and why does it matter?
Enrichment is the process of adding context — metadata — to raw telemetry at ingest: BGP attributes like AS path, IP geolocation, application identification from ports and protocols, and business mappings like customer or site. It matters because raw records answer “what happened” but enriched records answer “what it means”: traffic from one IP to another becomes a named application, serving a named customer, crossing a named provider. Because the underlying mappings change constantly, enrichment must happen as data streams in rather than at query time.
How do you collect network telemetry from cloud environments?
Cloud telemetry comes primarily from provider-native sources: VPC flow logs (AWS) and virtual network flow logs (Azure and others) for traffic, cloud provider metric APIs for infrastructure state, and host-level agents — increasingly eBPF-based — for visibility inside instances and containers. Because clouds expose no SNMP-style access to underlying network hardware, flow logs are the foundational telemetry type, and synthetic testing fills the gaps by actively measuring paths between regions, clouds, and on-prem environments.
Why is sampling used in network telemetry, and does it lose important data?
Sampling — exporting records for a statistical subset of packets, commonly at ratios like 1:1000 — exists because full-fidelity traffic telemetry from a large network would overwhelm devices, transport, and storage. For the use cases sampling serves well (capacity planning, traffic engineering, top-talker analysis), a representative sample preserves the picture. It does trade away fidelity for rare, short, or low-volume events, which is why sample rates should be tuned per link role and why high-value interfaces sometimes warrant minimal or no sampling.
What should you look for in a network telemetry platform?
Look for breadth of ingestion (all flow formats, SNMP and streaming telemetry, cloud flow logs, BGP, synthetics, and events), enrichment at ingest with routing, geographic, application, and business context, full-fidelity storage that supports ad hoc questions rather than pre-decided rollups, correlation across telemetry types in a single data model, and analytics that scale from dashboards to alerting to AI-assisted investigation. The unifying test is whether the platform can answer a question that spans telemetry types — “what traffic crossed the interface that alerted, and did routing change first?” — in one workflow. Kentik was built around exactly that test.
See all your telemetry in one place, with Kentik
Kentik is the network intelligence platform that turns every type of network telemetry — flow, device metrics, routing, synthetics, and events — into answers instead of dashboards.
- Request a demo — see unified telemetry, enrichment, and AI-assisted investigation on real network data.
- Start a free trial — point your flows and devices at Kentik and run your first cross-telemetry query.
- Get the O’Reilly ebook — the free Practical Guide to Modern Networking Telemetry, by Kentik co-founder Avi Freedman and Leon Adato.
