Practical Guide to Modern Networking Telemetry (Avi Freedman, Leon Adato)（Z-Library）

Kentik

Practical Guide To Modern Networking Telemetry How to Use Telemetry to See Into Your Network’s Performance and Usage Patterns Avi Freedman and Leon Adato

Practical Guide to Modern Networking Telemetry by Avi Freedman and Leon Adato Copyright © 2026 O’Reilly Media, Inc. All rights reserved. Published by O’Reilly Media, Inc., 141 Stony Circle, Suite 195, Santa Rosa, CA 95401. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (https://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: Megan Laddusaw Development Editor: Gary O’Brien Production Editor: Katherine Tozer Copyeditor: Stephanie English Proofreader: Heather Walley Cover Designer: Ellie Volckhausen Cover Illustrator: Ellie Volckhausen Interior Designer: David Futato Interior Illustrator: Kate Dullea April 2026: First Edition Revision History for the First Edition 2026-04-07: First Release

See https://oreilly.com/catalog/errata.csp?isbn=9798341608900 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Practical Guide to Modern Networking Telemetry, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the authors and do not represent the publisher’s views. While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights. This work is part of a collaboration between O’Reilly and Kentik. See our statement of editorial independence. 979-8-341-60887-0 [LSI]

Introduction You’re probably interested in this book because you want to learn about collecting, measuring, and analyzing data from network devices and traffic to gain insights into network performance–network telemetry. Before diving into the tools, techniques, and technologies of modern network telemetry, let’s take a minute to talk about “the network” and the benefits and return on investment (ROI) that building robust observability options into your infrastructure can bring. What IS “the Network,” Exactly? In “The Ultimate Guide to Network Observability”, Avi wrote the following: People often refer to “the network” in their organizations, but in most cases the network isn’t one entity. It’s a complex, diverse, fragmented, and loosely interconnected set of physical and virtual links and equipment, and it’s housed in a variety of places, including data centers, corporate wide area networks (WANs), private and public clouds, the internet, container environments, and even inside hosts. Organizations own and control some of those resources but simply pay to use others. The environment remains largely the same today. Sure, the cloud has gotten cloudier (meaning opaque to users) even as it has become more ubiquitous within organizations of every size and scale. And at the same time, corporate LANs, WANs, data centers, and cloud environments have not become less complex (or sprawling, or expensive). In fact, investments in on-premises networking have increased alongside cloud-related ones. What IS “Network Telemetry,” Exactly? Network telemetry refers to the data from and about your network, both from your network elements and from watching data moving through your network, which makes it important (and valuable) for several reasons:

Infrastructure performance and health: uptime, health, planning For user and application traffic to flow well across the network, the devices themselves need to be functioning well, with enough CPU and RAM capacity, healthy hardware, and sufficient bandwidth. Network and application traffic and performance Traffic generated by users and applications becomes packets flowing across the network, and that data is a source of truth for network performance and even application performance. Cost Network costs can be enormous for many companies, and optimizing the network infrastructure is often a full-time job. Combining network telemetry with business data about cost can drive huge savings that often fund the entire network observability stack. Security Network telemetry remains a fast and great way to identify many cybersecurity issues, including distributed denial-of- service (DDoS) attempts, data exfiltration, lateral movement, and the impact of malicious botnets. Metadata To make the rest of the telemetry useful, it helps to add metadata such as user, customer, application, and physical locations so that you can ask intelligent questions.

About You (“Is This Book for Me?”) This book is for you if any of the following are (or might be) true: You’d describe yourself as a “learn and do” kind of person. You’re comfortable with application monitoring and observability but not networking, and you’d like to find out how network monitoring and observability are different (and beneficial!). You’re comfortable with networking but not monitoring and observability, and you’d like to find out how network monitoring and observability are different (and beneficial!). You build, maintain, support, or are simply curious about “the network” and the ways in which network performance affects everything that rides on top of it, from the data to the application to the overall UX. You know how to look at a dashboard and interpret data presented in charts and graphs, but you want to understand how monitoring and observability data are represented in those forms. On the flip side, what does this book presume you already know? To be honest, there aren’t a lot of requirements. Throughout this guide, we’ll provide detailed information on terms and technologies and point you to external content when we think you might appreciate a deeper dive than we have pages to cover. That said, you will be most comfortable with the information we’re sharing if the following are generally true about you: You’re familiar with the basic network devices—routers, switches, and firewalls—and what they do. You have a general understanding of cloud infrastructure concepts like virtual machines and cloud providers.

You’re aware of typical network security issues and threats, such as DDoS attacks. Even if you aren’t rock-solid on those topics, do not panic. Throughout this guide we’ll offer information, instruction, and examples. If you need more, we’ll also provide links to background and deeper dives on these and other topics as we cover them. About This Book: What Will I Learn? We know that a book of this nature is an investment of time and attention. As such, we want to suggest the return you may enjoy for spending some of your precious time with it. By the end of this book, you’ll gain a better understanding of the following: Types of network telemetry This includes traffic data, device metrics, events, synthetic measurements, routing information, configuration data, and business/operational data. Network telemetry sources This includes physical and virtual network equipment, servers, clients, cloud environments, and more. The different planes of network telemetry Management, control, and data planes serve as points of contact where network telemetry can be gathered. Ways to wrangle telemetry data Collect monitoring information from devices, replicate data to analytics systems, feed broader observability systems, and understand data system requirements and trade-offs. Ways to use network telemetry in situ

Navigate, display, and use network telemetry within the tool(s) you use to collect it. Using network telemetry as part of your larger observability ecosystem network data extends, enhances, and informs the telemetry you get from application and infrastructure monitoring. We’ll show you how to integrate and correlate the information so you have a better sense of what is happening from the top to the very bottom of the application stack and the Open Systems Interconnection (OSI) model. This guide isn’t just geared to increasing your awareness; we’d also like to believe that we’ll provide you with skills you can actively apply. After reading this book, you’ll be able to do the following: Justify the business case for implementing and using a network observability solution in the workplace. Apply the knowledge about the different types of network telemetry, along with the strengths and weaknesses of each type, to select the best mix of options when displaying data about a particular network, application, issue, or architecture. Design better monitoring and observability solutions by combining data and telemetry from various tools (Be honest—we know you’ve got more than a couple!) in ways that provide clarity and uncover issues. Build, adapt, and improve monitoring and observability outputs— everything from dashboards and reports to alerts and automated workflows—based on your (perhaps newfound) understanding of how network telemetry works. Lead the charge for better network observability by educating teammates, departments, and even business leaders. NOT About This Book: What WON’T I Learn?

Well-organized technologists don’t just focus on the list of things they want to do; they also maintain healthy boundaries by keeping in mind the things that are not part of the roadmap. We’d like to show the same discipline and organizational rigor here by listing some of what this book is not going to teach you. We hope this will both set your mind at ease and let you know whether the book you’re holding has the answers you’re looking for. This book isn’t going to teach you about topics such as: Basic networking. We won’t explain the OSI model, networking protocols, or how to configure a routing protocol on a Layer 3 device in detail (but will provide links to background on routers). How to evaluate, select, install, configure, or use a specific observability solution. How to evaluate, select, install, configure, or use a specific type of networking gear, networking protocols, or standard networking architectures. How to evaluate, select, install, configure, or use a specific cloud provider or how to migrate a particular application to (or from, or between) the cloud. With all that said, let’s get started!

Chapter 1. Network and Telemetry Introduction To talk clearly, coherently, and concisely about network monitoring and observability, we need to lay the groundwork. Now, maybe you already know everything there is to know about networks, from the very first ARPANET packet all the way to the 1.02 petabits-per-second multicore fiber marvel running in a research lab in Japan. But do you? Too many mistakes in tech come not from misconfigurations but from misunderstandings. In this chapter, we’ll explain our context for concepts as far-ranging as “What is a network?” to the devices that make up that network, and on to the data types we’ll focus on for the rest of this book. What IS Network Telemetry, Redux In the Introduction, we offered a high-level description of network telemetry, but now it’s time to really dig in with a detailed explanation. Network telemetry refers to data about your network rather than the data that’s moving around your network. Network telemetry includes everything from the relatively simple device information (think: what are the make, model, and subcomponents in the gear that make up my network) to the more relevant (and important) performance and state information about the devices themselves (e.g., metrics related to resource consumption and device state). Network telemetry really hits hard when it gives you detailed information about the network traffic itself. Where are those packets coming from or going to, which might include everything from IP addresses to URLs to countries? How much of the data is one protocol versus another? How many of the intermediate hops from source to destination are remaining static and how many are changing? Are those intermediate hops the most

efficient hops or is some of the traffic getting hung up in suboptimal routes? What is the performance users are seeing from those packetized communications? Those questions are (or should be) deeply interesting to IT practitioners because they speak to aspects of application performance that can’t be figured out using higher-level tracing options found in non-network-centric observability solutions. This makes network telemetry important (and valuable) for several reasons. Security First Saying “security first” is easy; actually performing security is a whole galaxy away. Saying “security is everyone’s responsibility” doesn’t help much either. Sure, it is everyone’s responsibility, but no one’s ever gotten a bonus for it. Still, if you could spot security issues, understand their root causes, and fix them, you probably wouldn’t say no. Network telemetry allows you to do exactly that with specific types of security issues—for example, DDoS and botnet attacks. Not only does network telemetry tell you an attack is happening to (or on) your network, the right platforms can show you when those events are happening “near” your network—meaning they’re happening to someone else who is also using your ISP’s infrastructure, using the same routes your data is traversing, or hitting intermediate network gear your traffic is also using. But network telemetry goes further than that. Because it can tell you both source and destination, as well as the volume, protocol breakdown, and applications involved, network telemetry can quickly identify when data is being exfiltrated. Having a network observability solution will allow you to put alerts in place that tell you when unexpected or unwanted protocols, ports, or destinations appear in the mix or appear above a certain baseline. Understand Your Network Top to Bottom and End to End

Network telemetry gives you a view of your internal network (LAN, whether in the cloud or on premises) and it also tells you how your network traffic performs once it exits the edge router and hits the WAN and then often the internet. That means you can make informed decisions about traffic and capacity management at the edge of your network. Network telemetry is also the best way to understand the performance of your ISP, cloud architecture, software-defined (SD)-WAN, and other network investments. Network telemetry provides a unique view of your infrastructure, allowing you to pinpoint the area that’s actually experiencing a problem (versus just knowing that “the application is slow” or “we can’t get to the database”), and thus speed resolution. All of this allows you to confidently understand your current use (including new and unexpected services and traffic patterns), plan for future growth, and thus control costs. Make Your Cloud Environment Less…Foggy? You can smooth the transition of applications from on premises to cloud by first baselining the current performance, load, traffic direction, etc. After the application has been transitioned to the cloud, you’ll understand when performance differs, where the breakdown is occurring, and why. Network telemetry empowers you to gain a deeper understanding of your network’s health, performance, and usage patterns. This knowledge allows you to proactively manage your network, optimize its performance, and ensure a smooth digital experience for users. Anatomy of a Network Let’s be honest: networks are composed of simple base components but, at scale, they are anything but simple. Yes, most of the network diagrams you see in class are three routers, connected to a switch, which is connected to the cloud or the internet. Yet in the real world (such as the one shown in

Figure 1-1), networks are composed of many different device types in multiple configurations and use cases. Figure 1-1. A real-world (albeit complex) network design We want to take a moment to identify and define the most common devices and functions you might see because these are going to be the sources of network telemetry that we discuss later in the book. Broadly categorized, these devices and functions include the following: Routers, switches, and access points

Physical and virtual equipment responsible for moving traffic in your data centers and clouds, across your campuses and WANs, and over the internet, broadband, and mobile networks. Servers, clients, and Internet of Things (IoT) endpoints Physical and virtual equipment that connects to your network, such as servers; clients such as PCs, laptops, and mobile devices; and even IoT endpoints. Cloud virtual private clouds (VPCs) VPCs in your public cloud infrastructure. This includes subnets and the container environments where you deploy your microservices-enabled applications. Controllers, service meshes, load balancers, and firewalls Physical and virtual devices that control, orchestrate, load balance, program network configuration, and filter inbound and outbound network and application traffic based on policies and threat intelligence across data centers, cloud, WANs, and the internet. Transport devices Many modern transport devices (Layers 1 through 2) in fiber, broadband, and mobile networks now support active and passive telemetry. Test access point (TAP)/switch port analyzer (SPAN)/network packet broker (NPB) devices Physical and virtual TAPs, SPANs, and NPB devices that provide port mirroring, testing, and monitoring.

A few of those deserve a more detailed description. Remember, the purpose of this guide is not to teach you every aspect of network design, architecture, implementation, or management. Instead, we want to describe the following devices in terms of the telemetry they emit and the insights that telemetry provides. However, if you want a more in-depth look into specific explanations of device and telemetry types, see the Chapter 1 notes in our GitHub repository. At the outset, it’s also important to note that each of these devices has its own hardware metrics that shed light on the network—everything from: Up/down status of individual components CPU and RAM to fan, temperature, and power supply data Disk activity and configuration changes Dynamic status of internal software and hardware components To a greater or lesser extent, combining that insight with the other details can tell you where problems are occurring or, conversely, when a problem is downstream of a device that seems to be complaining, but is in actuality simply unable to communicate with the next hop in the chain. The final caveat before getting into the specifics of each device type is that even something as seemingly innocuous as inventory (especially when visualized as a map) can have a profound impact on your ability to understand how a network is performing and where the root cause of a problem may lie. Network Routing/Switching Primitives There are four foundational primitives that most elements use in various combinations for IP networking: Link-layer forwarding (usually Ethernet) Most of this guide will focus on IP networking—watching IPv4 and IPv6 traffic. But underneath the IP layer, there are

link layers that think in frames, not packets. Those frames are usually forwarded by dynamically learning what addresses (called MAC addresses for Ethernet) are where. There used to be more link-layer protocols for wired networking, but Ethernet has dominated for decades, perhaps with a smattering of InfiniBand for supercomputing and AI data centers. IP forwarding (also called routing) Directing packets from one interface (physical or logical) to another. Routing tables are populated and describe how packets get from one place to another. Most routing is done by looking at the destination IP address of the packet, but it can get more complex and look at the source IP address or other parts of the packet. Access control lists/firewall rules Another core routing primitive allows filtering and rate- limiting traffic according to specified policies. These policies are often called access control lists (ACLs) in routers and switches, firewall rules in security elements, and sometimes just policy in more cloud-y networking layers. Tunnels/virtual private networks (VPNs) Originally used for more exotic configurations, tunnels are now commonplace and are protocol-based wormholes that connect different parts of a network. Common tunneling protocols include GRE, IP (in) IP, and WireGuard. When these are exposed to users, often they’re just called VPNs, but people raised in networking often think of them as tunnels. While it’s important—for the purposes of this book—to clarify that the monitoring, logging, and tracing are primarily focused on the application

(meaning Layers 5 through 7), there are still important and valuable insights to be gained from a network telemetry standpoint. Types of Telemetry Now that we understand the definition and the value of network telemetry, as well as the devices that make up a typical network, we need to take a moment to list out the various data types available for monitoring and observability. This section will go into both the protocols themselves and, in some cases, the techniques used to extract the data from systems and into monitoring and observability solutions. It should be noted that this list is limited to network-centric telemetry types. For a more complete list, see the expanded section on our GitHub repository. Network telemetry boils down to the following subset: Traffic This describes any data element (metric, web log, etc.) that shows how your traffic is flowing across networks. Sample formats include NetFlow, sFlow, IPFIX, VPC flow logs, traffic data in JSON, and packet data via PCAP and eBPF for connections, process, and container context in cloud native environments. Device metrics These tell you the state or health of your physical and logical network equipment. Sample formats include SNMP, syslog, and streaming telemetry.  Events This indicates events like an attempted login, a threshold has been met, or a configuration has been changed. Sample formats include SNMP trap and syslog.  Tables