# OpenTelemetry Metrics Release Candidates

LLMS index: [llms.txt](/llms.txt)

---

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 feature-set 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](/docs/) 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 metrics 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.