An Overview of Network Telemetry

Network monitoring has relied historically on SNMP as a primary means of gathering granular statistics. SNMP works on a pull model. The network monitoring station reaches out and pulls value from OIDs, and then reacts to that data. There are also monitoring options where a network device pushes statistics to data collectors such as network management stations, flow collectors, or syslog engines.


In researching Ethernet switches, I've run across the term telemetry that describes datasets coming from these devices. Vendors are positioning telemetry as if it is some new feature that you need to be on the lookout for.


So, is telemetry something new? In digging through vendor literature, watching presentations, and talking to one of my vendor contacts specifically, I’ve concluded network telemetry represents both old and new forms of network statistics, and new ways of gathering and exposing data.


First, in presentations, it's clear that some networking vendors use the term “telemetry” generically. As they work through their demo, they display, for example, sFlow and syslog data. Those are not new data formats to network engineers. We know flow data in its various formats, including sFlow. We also know syslog well. And we also know that those formats typically contain information pushed to our data collectors in real-time or near real-time.


However, I do think that for some vendors, telemetry is more than a fancy way to describe the same old data. For instance, Juniper Networks shared several facts with me about their Junos Telemetry Interface that are a bit different than what network engineers might be used to. Here are the more relevant points:


  • Junos telemetry is streamed in a push model, like syslog or flow data.
  • Juniper uses Google's Protobuf message format to stream the data. Protobuf is interesting. The big idea according to Google is to define your message format and fields, and then compile code optimized to read that data stream. This means that Juniper doesn't have to shoehorn telemetry into a format that might be ill-suited to the data. They can build their structured message format and optimize it however they like, and extend as they go.
  • Juniper is not exposing every conceivable value via their telemetry interface (which proprietary SNMP vendor MIBs tend to do). Rather, they’ve focused on performance management data: I/O & error counters, queue statistics, and so on.
  • The Junos telemetry interface is open to anyone that wants to parse the data. Therefore, any vendor that wishes to create a custom application for end users could work with Juniper, get the data format details, and go to town.


Other vendors that come up when talking about telemetry include Cisco with their ACI data center fabric, and Arista with the telemetry interface in their EOS operating system. While I don't have specific details on how Cisco and Arista telemetry interfaces might differ from the Junos telemetry interface, they all seem to emphasize the near real-time pushing of descriptive network data to a collector that can aggregate the data and present it to a network operator.


So whether the term telemetry is being used generically to mean "data from the network" or specifically to mean "pushing specific network metrics to a data collector," I believe it's a term we're going to see used more and more.


While the data gathered via telemetry might be familiar, I believe the method used to gather the data, as well as what's being done with that data, is where the magic lies.


This begs another question. Could network telemetry be the end of SNMP? While my crystal ball remains murky, I believe SNMP has a long run still ahead of it. To supplant the familiar and ubiquitous SNMP, vendors will need to get their heads together on just exactly what this new telemetry format should be.


From what I can tell looking at just three vendors — Cisco, Juniper, and Arista — network telemetry is implemented differently for each of them. Differences slow technology adoption, as the variant solutions place monitoring vendors in the unenviable position of having to pick and choose which telemetry solutions to align themselves with.


Whatever SNMP's shortcomings might be, all you have to do is sort out the OIDs. The industry has already agreed upon the rest.


  • Is telemetry just a fancy name for log messages emoticons_grin.png

  • cahunt​ said it a lot more eloquently than I did...

  • The moment a vendor uses an industry standard rather than the proprietary model they have developed the door is open to competition. No more do you need 'their specific solution' and now any tool works... very bad for future sales, but very good for market competition and other smaller 'market forces' to enter the game and offer solutions. When a vendor develops a new tech watch the time frame - usually it gets close to or just after the end of their patent and once other developers can get their hands on it and customize the market begins to see advancement. Before that point you've got to pay the $$$ for that new tech.  As in SSD and other new tech, just wait for everyone to get their hands on it and then things get good.

  • Because that will limit the amount of money they can continue to get.

    If you have to buy another tool of theirs to use their metrics the better for them...then you focus on one vendor...them.

    We the consumers want consistent standards and interoperability, but the vendors business is to sell software...consistent standards and interoperability doesn't always make them money.

    That is why you see suites of products...you'll have it at a vendor level but not always at an industry level.

  • Lets face it, the more tools at our disposal, the better. we can then implement the ones that suit our individual environment. My concern is and always is, why can't manufacturers get together to ensure consistent standards and interoperability.

Thwack - Symbolize TM, R, and C