Metrics in OpenTelemetry for beginners: easily explained
This document is an introduction to Metrics in OpenTelemetry for beginners. It briefly explains what metrics are in the context of OpenTelemetry, describes the types of metrics in OpenTelemetry, and outlines their lifecycle from generation to export to a metric storage, such as Prometheus, InfluxDB, and many others.
What is OpenTelemetry
OpenTelemetry is an observability framework for generating and delivering telemetry data, such as metrics, logs, and traces, to an Observability storage.
Benefits of using OpenTelemetry for metrics
When you build an OpenTelemetry infrastructure for metrics, you can enjoy the following benefits:
Support of multiple programming languages
Easy integration with different metric backends (storages)
Flexibility across environments — Kubernetes, clouds, and bare metal
Unified infrastructure for metrics, logs, and traces
What is a metric?
A metric is a time-series measure of a process or a state within software. Engineers use metrics to monitor software health, performance, and business efficiency.
What kind of metrics exist in OpenTelemetry?
Gauge
A Gauge is an instantaneous snapshot of data at each point in time.
For example, it can be the number of processes on the machine or the CPU temperature.
Sum
Sum is a numeric metric that represents the cumulative total of all reported measurements over a time interval or a cumulative value from the beginning of time. For example, it can be the total amount of requests served by a service in a minute (1), or a cumulative value of requests from the start (2).
Histogram
A histogram describes a distribution of metric values grouped into buckets, where each bucket represents a range of values and the count of measurements that fell into that range. For example, buckets can represent server request latency intervals, and values - the count of requests that fall in the bucket.
Each metric in OpenTelemetry contains the following information:
Metric name
Attributes - these can be a name of the application that produced a metric, an availability zone, the name of the server, the instrumentation name, and many others
Value type of the point (integer, floating point, etc.)
Unit of measurement
Points at each time interval
Read more about the Metrics data model in OpenTelemetry in the official documentation.
How the OpenTelemetry metrics pipeline works
Let’s look at the metrics lifecycle within the Observability framework.
Metrics generation
Typically, your application needs to generate metrics. To do that, you can use a corresponding OpenTelemetry SDK – a set of tools for generating telemetry data and sending it to the OpenTelemetry Collector.
Metrics collection
The next step is exporting metrics to the OpenTelemetry collector. OpenTelemetry Collector can collect telemetry data from multiple applications and process it all together. This step is not necessary - the application can send metrics directly to the Metrics Backend, especially if you are just trying it out.
Processing in the collector
OpenTelemetry Collector can transform metrics before sending them to the Metrics backend. Transformation involves filtering, adding, or deleting attributes, as well as renaming metrics. You can write your own processor if you have a specific need.
Export to the Backend
Finally, OpenTelemetry Collector exports your metrics to the Metrics Backend.
Note
How OpenTelemetry instrumentation generates Metrics
For the server application
The exact options for generating metrics depend on the chosen programming language, but the OpenTelemetry community maintains a unified approach. Opentelemetry instrumentation is a set of libraries, SDKs, and API for generating metrics and other telemetry data.
Two kinds of instrumentation are generally available:
Code instrumentation. Check the development status and availability for your language here.
Zero-code instrumentation. For some programming languages, you can instrument your application without touching the code. Check the availability of zero-code instrumentation for your language here. It means that once Zero-code instrumentation is configured, some common use-case metrics work out of the box, and it can also mean that you can use a metric-generation library integrated with OpenTelemetry to produce OpenTelemetry metrics. An example of such a library is Java Micrometers.
In a generic scenario, instrumentation generates metrics and other telemetry data and sends them to the OpenTelemetry collector using the OpenTelemetry (OTLP) protocol. At this stage, metrics contain information, defined in the OpenTelemetry data model.
OpenTelemetry instrumentation has flexible configuration options; in most cases, it utilizes environment variables that follow the same naming specifications across multiple programming languages. Check the OpenTelemetry Exporter Configuration and Environment variable specification to find out more.
Other platforms
OpenTelemetry also has a set of instrumentations for specific platforms, which don’t run as a server application, such as:
How OpenTelemetry collector collects Metrics
OpenTelemetry Collector collects metrics from multiple applications. The canonical approach is to collect telemetry data using otlpreceiver via the OTLP protocol, mentioned earlier; however, in principle, it can collect metrics in any format if a corresponding receiver exists.
An example of such a receiver is Prometheus-Receiver. Instead of instrumenting your application, you can implement the exposure of Prometheus metrics in it, and configure the OpenTelemetry collector to collect these Prometheus metrics via the Prometheus protocol. Several receivers exist in the opentelemetry-collector-contrib repository, and you can also implement your own receiver if needed.
How OpenTelemetry collector processes Metrics
The OpenTelemetry collector can transform metrics using processors.
Some useful processors include:
k8sattributesprocessor: enrich telemetry data with Kubernetes information, such as cluster name, region, deployment name, etc.
filterprocessor: filter out incorrect data
attributeprocessor: add, rename, and delete metric attributes
You can also write a custom processor if you have specific needs.
Destinations where metrics can be exported
An OpenTelemetry collector can write metrics into any metric storage that supports OTLP format, such as. But, as always, it is not limited to that. It can export data in any format if a corresponding processor exists.
Example of metric exporters:
prometheusremotewriteexporter: can write metrics to a storage that supports the Prometheus Remote Write protocol, such as Uptrace, VictoriaMetrics, Thanos, and others
influxdbexporter: write metrics to InfluxDb
clickhoseexporter: write metrics to clickhouse
Conclusion
This is a brief overview of how metrics work in OpenTelemetry, and you are now ready to try it out in real- world scenarios. Do you plan to set up OpenTelemetry Collector in production? Learn how to choose the OpenTelemetry collector distribution
