Skip to main content
Great work exploring the Metrics API and SDK. This lesson explains how metric data points flow through the OpenTelemetry (OTel) metrics pipeline used by APIs and SDKs. Core components in the OpenTelemetry metrics pipeline:
  • MeterProvider: the entry point that provisions meters and configures the pipeline.
  • Meter: represents an instrumentation scope (a library or component) and creates instruments.
  • Instrument: counters, histograms, and up-down counters that record measurements.
  • Measurement: a single recorded data point emitted by an instrument.
  • View: an optional transformation layer to configure aggregation, filtering, renaming, or attribute changes without changing application code.
  • MetricReader: controls collection and aggregation intervals and triggers exports.
  • MetricExporter: encodes aggregated metric data (e.g., in OTLP) and sends it to a backend.
  • Exemplars: sampled metric measurements that include trace/context information linking the metric to the exact trace/span that produced it.
The image is a table describing the OpenTelemetry (OTel) metrics pipeline components and their roles. It includes components like MeterProvider, Meter, Instrument, Measurement, View, MetricReader, and MetricExporter, each with a specific function in the pipeline.
Exemplars are sampled measurement points that include trace/span identifiers or other context. They let you jump from an interesting metric value to the trace(s) that generated it—great for root-cause analysis and drill-down.

​
MeterProvider and how it ties the pipeline together

The MeterProvider is the root of the Metrics SDK pipeline. It:
  • Owns one or more Meters (each represents an instrumentation scope such as a library or component).
  • Configures pipeline behavior (views, readers, exporters, and resource attribution).
  • Applies any meter configurator logic that can enable/disable meters by scope.
Meters create Instruments (counters, histograms, up-down counters) which produce Measurements. Views can transform measurements at collection time—renaming metrics, changing aggregation, filtering attributes, or remapping labels—without touching instrumentation code. MetricReaders schedule collection and trigger exports. MetricExporters serialize aggregated metric data (often OTLP) and send it to a backend or collector. Best practice: use descriptive meter names (for example, library name + version) so metrics are properly attributed and easier to query in backends.
Avoid empty or vague meter names. The SDK may return a functional meter for an empty name (sometimes with a warning), but you’ll lose important attribution metadata.
Example: creating meters with clear names

​
A full lifecycle example

The example below illustrates a typical end-to-end setup: initialize a MeterProvider with a Resource and meter configurator, attach a periodic MetricReader with a Console exporter, create a Meter and instrument, record measurements, and register a runtime View to filter attributes.
Sequence explained
  • Initialize MeterProvider with a Resource (for example, service.name and env) and optionally supply a meter_configurator to enable/disable meters by scope.
  • Attach a PeriodicExportingMetricReader and a MetricExporter (Console in this demo) to control export timing and serialization.
  • Create a Meter with a descriptive name and version, then create Instruments and record Measurements with attributes.
  • Register an optional View at runtime to transform or filter attributes before export (this keeps instrumentation code untouched while applying policy).

​
Pipeline summary

Think of the MeterProvider as your metrics factory and central configurator. The main pipeline stages are:
StageRole
Provider (MeterProvider)Orchestrates Meters, resources, Views, Readers, and Exporters
MeterInstrumentation scope that creates Instruments
InstrumentCounters, Histograms, UpDownCounters used to emit Measurements
View (optional)Transformation layer: aggregation, attribute filtering, renaming
Reader (MetricReader)Controls collection timing and triggers aggregation/export
Exporter (MetricExporter)Serializes and sends aggregated metrics to a backend
Mnemonic: “Please Make Insight Via Reliable Exports”
(P = Provider, M = Meter, I = Instrument, V = View, R = Reader, E = Exporter) Links and references

​
Summary

This should give you a clear understanding of how metric data moves from your application to a collector or backend, the role of each component in the pipeline, and practical tips for configuring MeterProvider, Meter names, Views, Readers, and Exporters. That’s it for the Metrics pipeline section.

Watch Video