> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Metrics SDK Lifecycle APIs and Views > Explains metrics SDK lifecycle, MetricReaders and MetricExporters, push versus pull exports, and Shutdown and ForceFlush behaviors and best practices for reliable metric delivery. 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 | Mode | Who initiates export | Typical use cases | Effect of ForceFlush | | ------------- | ------------------------------------------------- | ----------------------------------------------------- | --------------------------------------------------------- | | Push | MetricReader (periodic or on demand) | Exporters that send to collectors/backends directly | ForceFlush triggers immediate collection + export | | Pull (scrape) | External scraper (e.g., `https://prometheus.io/`) | Instrumentation that exposes an endpoint for scrapers | ForceFlush 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 * OpenTelemetry Metrics: [https://opentelemetry.io/docs/](https://opentelemetry.io/docs/) (see Metrics SDK and exporter guidelines) * Prometheus documentation: [https://prometheus.io/docs/](https://prometheus.io/docs/) 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.