A networking protocol that has been under development for four years got a boost from both F5 Inc. and ServiceNow Inc. this week.

Called OpenTelemetry — OTel or OTLP for short — the protocol has been endorsed by dozens of vendors and has a curious mixture of open- and closed-source code to help advance the cause of observability, as it is now called. If refers to the broad collection of log analyzers, metrics and network traces that are used to figure out what’s happening inside a digital infrastructure.

OTLP was designed to be extensible, efficient and useful in a number of situations. For example, it can help analyze server log collections and share network trace data between different providers’ products.

It’s housed under the Cloud Native Computing Foundation, which supports a wide collection of other protocol and standards efforts to handle application programming interfaces, cross-cloud communications and other infrastructure-related tasks. The foundation is the keeper of the Kubernetes standards, for example.

OTLP’s role is central to many tasks, as shown in this architecture diagram:

OTLP is supported on a wide variety of commercial and open-source analytical tools, including the top three cloud platforms. It’s also used in products from Datadog, Dynatrace, Elastic, SolarWinds, Splunk and Uptrace, just to name a few.

The protocol involves more than just the commercial tools from these supporters. There is also a standard collection of APIs and software development kits available in numerous programming languages, including Java, Go and PHP. The protocol is designed to work well in containers.

This week’s news involves a more parsimonious use of network bandwidth that doubles the data compression power of the protocol stack that was developed jointly by F5 and ServiceNow. Engineers from both companies have contributed thousands of lines of code towards the standard, which is intended to make telemetry more meaningful and support a wider set of future circumstances in troubleshooting all kinds of networking problems.

“Strong telemetry is the foundation for application health and safety,” Kara Sprague wote on F5’s blog Tuesday. “And to use telemetry effectively, we need a common way to collect and transport high volumes of data across multiple systems and applications so it can be turned into actionable insights.”

Her blog post also mentions other benefits, such as the ability to support more automated decision-making, cheaper training costs for large language AI models, better real-time event analysis and faster breach response times.

A blog post by Vijay Samuel of eBay Inc. last year explains why the auction platform has moved to OTLP. Its users generate 1.5 million events every minute, and the company needed a more efficient way to observe and track down network problems. Its existing proprietary methods didn’t scale well and were costly to maintain, something the new protocols solved. EBay also wanted to support more open-source efforts as part of its corporate culture.

Collecting telemetry data certainly isn’t new. What is innovative is making its collection consistent across the variety of methods and data formats so that different tools can work together, especially in today’s world of cloud-native applications. “This means companies can spend less time developing a mechanism for collecting critical application data and can spend more time delivering new features instead,” Wayne Segar said in a DynaTrace blog post in February.

Images: Kate Ter Haar/Flickr, OpenTelemetry