Announcing OpenTelemetry Metrics are Now Available as Release Candidates

By Morgan McLean May 18, 2022

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! 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 APIs for every GA-declared language, 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.
  - People who develop 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, JS, .Net, and Python (all other languages are still working towards metrics release candidates), which capture metrics from the APIs and perform some amount of processing.
  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, which includes the Collector's ability to capture metrics from receivers for sources like host metrics or pre-packaged applications (these were already present in the Collector), the ability to receive metrics from protocols like OTLP and Prometheus, configuration-driven metric processing, and export these metrics to any supported destination.
  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 Java, JS, .Net, and Python SDKs have issued release candidates for OpenTelemetry's metric capabilities, and more languages will be issuing metrics release candidates soon. 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, or Collector, then you can access GA metrics functionality by updating your OpenTelemetry artifacts to their latest versions. You can find documentation and getting started guides for each artifact's metrics capabilities within the official OpenTelemetry documentation and examples and supplementary documentation is often available within 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.