At the IETF 104 meeting last week, telemetry was mentioned many times. In those discussions, I had to repeatedly clarify what we mean by “telemetry”. Taking a formal definition, I would say:
Telemetry is an automated communications process by which measurements and other data are collected at remote or inaccessible points and transmitted to receiving equipment for monitoring.”
Source: http://adsabs.harvard.edu/abs/1987STIN…8913455
In verbal communication, I simply explain:
Telemetry is the collection process of any useful operational data
When I want to specifically address the YANG-based telemetry, I use the term model-driven telemetry, as explained in this Why Data Model-driven Telemetry is the only useful Telemetry? blog. For model-driven telemetry, the more formal definition comes from the Cisco documentation:
Telemetry is an automated communications process by which measurements and other data are collected at remote or inaccessible points and transmitted to receiving equipment for monitoring. Model-driven telemetry provides a mechanism to stream data from a model-driven telemetry-capable device to a destination.
Telemetry uses a subscription model to identify information sources and destinations. Model-driven telemetry replaces the need for the periodic polling of network elements; instead, a continuous request for information to be delivered to a subscriber is established upon the network element. Then, either periodically, or as objects change, a subscribed set of YANG objects are streamed to that subscriber.
The data to be streamed is driven through subscription. Subscriptions allow applications to subscribe to updates (automatic and continuous updates) from a YANG datastore, and this enables the publisher to push and in effect stream those updates.
Going one step further, depending on the audience, I would adapt my language, in other words, the telemetry definition.
For most operations engineers, telemetry refers to the streaming of monitoring data, helping network monitoring, troubleshooting, and service assurance. Therefore, it could be flagged as operational telemetry.
In practice, nobody in the industry speaks of operational telemetry as the operational aspects are implicit. Network and operations engineers speak of telemetry and they mean operational telemetry. This telemetry might also contain information about the applied configuration, especially when used with non-fully transactional protocols, such as RESTCONF and gRPC, as this is a key component of the service assurance. Indeed, the first step is service assurance is to validate that the (service) configuration is correctly applied.
Business telemetry, as opposed to (operational) telemetry, is a clarifying term we made up: It specifies the use of telemetry to stream information to help business developments. For example, how is the network inventory in terms of hardware, software, and licenses related to each customer? Knowing this inventory certainly helps the vendor account teams, on top of knowing how customers use your specific functionality and service (what is enabled and how?). There is also a great advantage for the support teams, who could proactively warn of potential defects, thus reducing in parallel the support costs. Business developers, (senior) Vice Presidents, and top execs speak of telemetry, but they actually mean business telemetry.
Some could argue that any telemetry fulfills a business purpose in the end; hence the “business” prefix in “business telemetry” is not necessary and even confusing. However, the term business telemetry helps to make a clear distinction of the audience in telemetry discussions.
The good news is that the business and operational telemetry meet somewhere, as both use the same information. They are just different flavors of eventually the same set of data – but consumed by different persona. So, it’s just a question of packaging the information: one time to solve a technical problem and a second time to answer a business question.
In conclusion, maybe we’re over-engineering the telemetry definition. Could we just agree on an generic definition for telemetry, i.e. the collection process of any useful operational data. Regardless of where the data is coming from: data plane, control plane, or management plane. Regardless of the measurement mechanism: packet-based, flow-based, or a simple counter. Indeed, in the end, the data source and the measurement mechanism should be orthogonal to the way to stream the data. “should” as the industry is not there yet! However we’re on the right track with model-driven telemetry.
If you want to know more about telemetry, my colleague Frank Brockners and I presented the IETF 104 Host Speaker Series on “Telemetry – Industry Status, Challenges, and IETF Opportunities”. In this talk, we discussed (the interaction of) telemetry at different levels: networking, application, and business.