Announcing OpenTelemetry Metrics are Now Available as Release Candidates

Splunk is all-in on OpenTelemetry, as exemplified by our native support for it in Observability Cloud, Splunk Enterprise and Enterprise Cloud’s usage of the OpenTelemetry Collector with Splunk Connect for OpenTelemetry Kubernetes, our long-term ambition to use OpenTelemetry as the main way that all Splunk Products capture data from customers’ infrastructure and applications for analysis, and our massive level of contribution to the project.

OpenTelemetry has achieved a major milestone today, by issuing the first wave of metrics GA release candidates across its APIs, SDKs, and language agents. This fulfills the project’s original promise of unified distributed tracing and metric collection, and will allow the community to focus their efforts on logging support, integrations with more data sources, and additional signal types. You can learn more about this from the official OpenTelemetry blog post, which I’ve also copied below.

OpenTelemetry’s metrics capabilities are now available as release candidates, starting with Java, .Net, and Python! This means that the specification, APIs, SDKs, and other components that author, capture, process, and otherwise interact with metrics now have the full set of OpenTelemetry metrics functionality and are ready for use. These release candidates will be promoted to general availability throughout the next few weeks.

The 1.0 Metrics Release Includes the Following:
 

• Metrics functionality included in the OpenTelemetry language-specific APIs, which provide language-specific interfaces that can create and manipulate metrics, and associate metadata and attributes to each.
  These are useful for:
  - Developers of shared libraries that are distributed to end-users, so that these end users can natively use OpenTelemetry to capture metrics from these. For example, gRPC uses these APIs to produce latency, throughput, and error rate metrics for each RPC method on a given service.
  - Developers who create and maintain web services or client applications, so that they can produce custom metrics or interact with existing metrics. For example, an e-commerce company could use the API to track how many purchases are made over time.
  
  
• Metrics functionality included in the OpenTelemetry SDKs for Java, .Net, Python, and JS (coming next week) SDKs, which capture metrics from the APIs and perform some amount of processing. Metrics support for other languages is still in development.
  These are useful for:
  - Developers of applications that are used by other organizations, like databases, message queues, etc., who will expose metrics over OTLP (or Prometheus) so that their own end users are able to monitor the performance of these apps. These applications could be open or closed source.
  - Developers of applications within a technology organization, who want to capture metrics generated by OpenTelemetry APIs within their applications, either by their own developers or from shared libraries that their applications depend on. These metrics can be exported through OTLP or exported through any other OpenTelemetry exporter.
  
  
• Collector support for metrics includes the Collector’s capability to capture metrics from a rich variety of data sources like host metrics or pre-packaged applications. The Collector also provides the ability to receive metrics from data sources using multiple data protocols such as the native OpenTelemetry protocol (OTLP) and OpenMetrics compliant protocols such as Prometheus. Also supported is configuration-driven metric processing and native OTLP, Prometheus and custom exporters to send observability metrics to on-cloud and on-premises monitoring systems of your choice.
  This is useful for:
  - Anyone who wants to capture metrics from their hosts (Linux VMs, Windows, VMs, Kubernetes, etc.) or pre-packaged applications (databases, message queues, etc.).
  - Anyone who wants to capture metrics from existing sources like OTLP (from OpenTelemetry SDKs, pre-packaged applications, etc.), Prometheus, or others.
  - Anyone who wants to process / modify metrics and metric metadata captured from these sources.
  - Anyone who wants to convert metrics from one format to another. For example, the Collector can capture metrics from a mix of OTLP and Prometheus sources, and then send all of these to a single destination using OTLP (with the standard OpenTelemetry semantic conventions), Prometheus, or any other exporter.
  
  
• Full OpenTelemetry Protocol (OTLP) support for efficiently serializing and transmitting metrics between systems.
  
  
• A metrics section of the specification, which defines different types of metrics, their shapes, how to process them, and semantic conventions. This is primarily used by OpenTelemetry contributors but also provides guidance to OpenTelemetry users who are authoring metrics or metadata.
   

All of this functionality is additive to OpenTelemetry’s existing tracing support, and both signal types share the same metadata and semantic conventions. As of this announcement, the following languages have issued metrics release candidates:

• Java
• .Net
• Python

The RC release for JS is planned for next week, and more languages will be issuing metrics release candidates throughout the coming months. Each of these releases will be followed by general availability after we receive feedback from users.

Getting Started

If you’re already using a mix of the OpenTelemetry APIs, SDKs, language agents, and Collector, then you can access the release candidate metrics functionality by updating your OpenTelemetry artifacts to their latest versions. We’re currently updating the official OpenTelemetry documentation for each artifact’s metrics capabilities. Examples and supplementary documentation are also being added to each artifact’s corresponding GitHub repository.

What’s Next for OpenTelemetry

Distributed traces and logs were the two halves of OpenTelemetry’s core promise when we announced it at Kubecon EU in 2019. With the general availability of metrics, we have produced the capabilities that we originally set out to create, meaning that we can shift our focus to further investing into the robustness and ease of use of each component, the number of data sources that OpenTelemetry can capture telemetry from (either through the OpenTelemetry APIs, OTLP, or otherwise), and new capabilities and signal types.

Logging is the most visible release on the horizon, and we’re running full speed ahead on this effort. Expect to hear a lot more about our progress on logging throughout the year (logs already have a stable data model and OTLP support), and anyone interested in this area is welcome to join the weekly logging SIG calls. Beyond logging, major new projects include formalizing and implementing client instrumentation and investigations into eBPF. With metrics complete, we may also turn our attention to more signal types.