Metrics (2024)

A measurement captured at runtime.

A metric is a measurement of a service captured at runtime. The momentof capturing a measurements is known as a metric event, which consists notonly of the measurement itself, but also the time at which it was captured andassociated metadata.

Application and request metrics are important indicators of availability andperformance. Custom metrics can provide insights into how availabilityindicators impact user experience or the business. Collected data can be used toalert of an outage or trigger scheduling decisions to scale up a deploymentautomatically upon high demand.

To understand how metrics in OpenTelemetry works, let’s look at a list ofcomponents that will play a part in instrumenting our code.

Meter Provider

A Meter Provider (sometimes called MeterProvider) is a factory for Meters.In most applications, a Meter Provider is initialized once and its lifecyclematches the application’s lifecycle. Meter Provider initialization also includesResource and Exporter initialization. It is typically the first step in meteringwith OpenTelemetry. In some language SDKs, a global Meter Provider is alreadyinitialized for you.

Meter

A Meter creates metric instruments, capturingmeasurements about a service at runtime. Meters are created from MeterProviders.

Metric Exporter

Metric Exporters send metric data to a consumer. This consumer can be standardoutput for debugging during development, the OpenTelemetry Collector, or anyopen source or vendor backend of your choice.

Metric Instruments

In OpenTelemetry measurements are captured by metric instruments. A metricinstrument is defined by:

• Name
• Kind
• Unit (optional)
• Description (optional)

The name, unit, and description are chosen by the developer or defined viasemantic conventions for common oneslike request and process metrics.

The instrument kind is one of the following:

• Counter: A value that accumulates over time – you can think of this likean odometer on a car; it only ever goes up.
• Asynchronous Counter: Same as the Counter, but is collected once foreach export. Could be used if you don’t have access to the continuousincrements, but only to the aggregated value.
• UpDownCounter: A value that accumulates over time, but can also go downagain. An example could be a queue length, it will increase and decrease withthe number of work items in the queue.
• Asynchronous UpDownCounter: Same as the UpDownCounter, but iscollected once for each export. Could be used if you don’t have access to thecontinuous changes, but only to the aggregated value (e.g., current queuesize).
• Gauge: Measures a current value at the time it is read. An example wouldbe the fuel gauge in a vehicle. Gauges are asynchronous.
• Histogram: A client-side aggregation of values, such as request latencies.A histogram is a good choice if you are interested in value statistics. Forexample: How many requests take fewer than 1s?

For more on synchronous and asynchronous instruments, and which kind is bestsuited for your use case, seeSupplementary Guidelines.

Aggregation

In addition to the metric instruments, the concept of aggregations is animportant one to understand. An aggregation is a technique whereby a largenumber of measurements are combined into either exact or estimated statisticsabout metric events that took place during a time window. The OTLP protocoltransports such aggregated metrics. The OpenTelemetry API provides a defaultaggregation for each instrument which can be overridden using the Views. TheOpenTelemetry project aims to provide default aggregations that are supported byvisualizers and telemetry backends.

Unlike request tracing, which is intended tocapture request lifecycles and provide context to the individual pieces of arequest, metrics are intended to provide statistical information in aggregate.Some examples of use cases for metrics include:

• Reporting the total number of bytes read by a service, per protocol type.
• Reporting the total number of bytes read and the bytes per request.
• Reporting the duration of a system call.
• Reporting request sizes in order to determine a trend.
• Reporting CPU or memory usage of a process.
• Reporting average balance values from an account.
• Reporting current active requests being handled.

Views

A view provides SDK users with the flexibility to customize the metrics outputby the SDK. You can customize which metric instruments are to be processed orignored. You can also customize aggregation and what attributes you want toreport on metrics.

Language Support

Metrics are a stable signalin the OpenTelemetry specification. For the individual language specificimplementations of the Metrics API & SDK, the status is as follows:

Specification

To learn more about metrics in OpenTelemetry, see themetrics specification.