Skip to main content
You now understand the high-level metrics pipeline. This article examines the lifecycle of key metrics components — MetricExporters and MetricReaders — and explains how metrics are delivered (pushed or pulled), how shutdowns are handled, and when to use ForceFlush. Metric exporters are lightweight plugins whose sole responsibility is to transmit metrics to a destination (a backend, collector, or monitoring system). They always work in tandem with a MetricReader: the reader handles aggregation and temporality, while the exporter packages and sends already-summarized metrics. Keep exporters simple — if an exporter receives a format or timing it cannot support, it should log a clear error so users know why data was not exported.
Exporters should not perform aggregation or alter temporality. If a destination requires a custom metric format that the SDK does not natively support, the exporter must surface this clearly in logs and documentation.
The image is an infographic about "Metric Exporter," explaining its role as a plug-in for sending metrics, its collaboration with a MetricReader, and its operation principles like simplicity, error logging, and scheduling.
Why separate MetricReaders and MetricExporters?
  • MetricReaders decide when and how to collect metrics (periodic, on-demand) and perform aggregation and temporality.
  • MetricExporters remain agnostic of aggregation logic; they receive the reader’s summarized metrics and transmit them.
  • This separation makes SDKs flexible: you can attach multiple exporters (push and/or pull) to a MeterProvider, each with its own reader configuration.
Key export modes at a glance
ModeWho initiates exportTypical use casesEffect of ForceFlush
PushMetricReader (periodic or on demand)Exporters that send to collectors/backends directlyForceFlush triggers immediate collection + export
Pull (scrape)External scraper (e.g., https://prometheus.io/)Instrumentation that exposes an endpoint for scrapersForceFlush has no effect — scrapes happen only on request
Push-based exporters In push workflows, a MetricReader controls collection cadence (for example, periodic polling). The reader collects and aggregates the in-memory metrics, then calls the exporter to transmit that summarized data to its destination. Push exporters can also be triggered by immediate requests such as ForceFlush or direct application signals (for example, when an application logs a critical incident and requests an immediate export). Typical push flow:
  • Instrument data is recorded in in-memory state.
  • MetricReader collects and summarizes those metrics from the SDK.
  • MetricExporter packages and sends the summarized metrics to an external process (collector or backend).
The image explains a push-based metric exporter system, detailing how it sends metrics autonomously and works with a paired MetricReader to send data, with periodic or immediate options during errors. The diagram shows the flow from in-memory state to metric exportation and another process.
Pull-based exporters Pull-based exporters (commonly called “scrape” exporters) expose an HTTP endpoint that an external scraper requests to retrieve metrics. The exporter is passive and only responds to scrape requests; it does not push data autonomously. Because the scraper controls timing, operations such as ForceFlush do not trigger an immediate push — scrapes occur only when the external system requests them. Typical pull flow:
  • Instrument data remains in in-memory state.
  • The pull exporter exposes summarized data on an endpoint.
  • An external scraper periodically requests (scrapes) the endpoint and forwards metrics to the backend.
The image is a diagram explaining a Pull Metric Exporter, highlighting its passive nature of waiting to be scraped by a process like Prometheus. It shows an in-memory state providing metrics to a PrometheusExporter, which is then accessed by another scraping process.
Shutdown and ForceFlush — lifecycle control APIs Two lifecycle APIs are critical for reliable metric delivery: Shutdown and ForceFlush. Understand their responsibilities and limitations so you can ensure final metrics are delivered during application termination. Shutdown (MeterProvider)
  • Shutdown is the termination API on the MeterProvider. It should be called exactly once to perform cleanup and to stop metric processing.
  • On shutdown the provider should cascade the shutdown call to all registered MetricReaders and MetricExporters.
  • SDKs may block synchronously up to a timeout and should report whether shutdown succeeded, failed, or timed out.
  • After shutdown, the provider should refuse to create functional meters. Returning no-op meters is preferred so the application can keep running while preventing new metrics from being recorded.
The image is a flow diagram comparing processes before and after a "Shutdown" event, with "ForceFlush" and "Metric creation" involved. It is sourced from KodeKloud.
ForceFlush
  • ForceFlush asks push-based MetricReaders (and, transitively, their exporters) to immediately collect and export any buffered metrics.
  • It is intended for push-based workflows where you want to ensure buffered metrics are delivered before shutdown or at critical moments.
  • Pull exporters (scrape-based) are unaffected by ForceFlush; they only expose metrics in response to scrapes. For scrape-based setups, ensure the external scraper performs a final scrape if you need the last metrics exported.
ForceFlush is intended for push-based workflows (e.g., ensuring buffered metrics are sent before shutdown). For scrape-based setups (Prometheus), ensure the scraper scrapes the endpoint at least once before shutdown if you need the final data exported.
Lifecycle summary and best practices
  • Call Shutdown on the MeterProvider once to terminate metric processing cleanly and cascade cleanup to all MetricReaders and MetricExporters.
  • After shutdown, the provider should return no-op meters to prevent further metric creation while allowing the app to continue running.
  • Push exporters:
    • Attempt to ForceFlush any pending data during shutdown.
    • Stop timers/background threads, clear buffers, and release resources.
  • Pull exporters:
    • Stop exposing the scrape endpoint so subsequent scrapes return no data.
    • Document how consumers should perform a final scrape if they require last-minute metrics.
  • Provide explicit feedback about shutdown outcome (success, failure, timeout) to orchestration or monitoring systems.
The image is a summary of instructions related to shutting down a MeterProvider, including its effects on MetricReaders and MetricExporters, as well as guidance for push and pull exporters.
References and further reading This article covered metrics SDK lifecycle topics: MetricExporters (push and pull), MetricReaders, ForceFlush, and Shutdown semantics, including best practices for ensuring final metrics are reliably exported.

Watch Video