- OpenTelemetry Collector documentation: https://opentelemetry.io/docs/collector/
- Prometheus exposition format: https://prometheus.io/docs/instrumenting/exposition_formats/
What you will do
- Optionally enable the zpages extension for quick debugging.
- Add a metrics pipeline that includes the Prometheus receiver.
- Configure
telemetry.metrics.readersto expose the Collector’s internal metrics in Prometheus format on a chosen host:port.
Minimal example configuration
The following corrected YAML config shows the minimal settings to expose internal Collector metrics via a Prometheus reader. Place this in your Collector config file (e.g.,collector-config.yaml) and restart the Collector.
- This example exposes internal metrics on port
8888. Adjusthostandportto match your network and security requirements. - After applying the configuration, visit
http://<collector-ip>:8888/metricsto view the Prometheus-format metrics.
Exposed metrics are presented in Prometheus exposition format. Some metric names are marked
[alpha], which indicates experimental metrics that may change across Collector releases.Typical Prometheus-format metric excerpts
Below are representative metric families and sample lines you will commonly see from the Collector. The examples are cleaned up for clarity.- Instrumentation scope metadata and exporter queue capacity/size:
- Exporter send/failed counters and fileconsumer metrics:
- Process-level resource metrics (CPU, memory, heap, uptime):
- Processor counters (incoming/outgoing items) and exporter sent log counts:
Interpreting these metrics
Use the table below for a quick reference of metric types and what they typically represent.| Metric Type | Meaning | Example usage |
|---|---|---|
counter | Cumulative value that only increases (monotonic). Useful for totals and rates. | Count of log records successfully sent: otelcol_exporter_sent_log_records__records__total |
gauge | Instantaneous value that can go up or down. Useful for current resource usage or queue size. | Current retry queue size: otelcol_exporter_queue_size |
[alpha] label in HELP | Experimental metric that may change between Collector releases. | otelcol_exporter_queue_capacity marked [alpha] |
data_type— the signal type:logs,metrics, ortracesexporter— which exporter produced the metric (useful to tie metrics to a destination)otel_scope_name— the instrumentation or component scope
Scaling and collection strategies
- Manually curling each Collector’s
/metricsendpoint (e.g.,http://<collector-ip>:8888/metrics) is feasible for a few instances but does not scale for large deployments. - Recommended production pattern:
- Configure a central Prometheus server (or a centralized scraping pipeline) to scrape each Collector instance’s
/metricsendpoint. - Forward aggregated data from Prometheus (or the scraping pipeline) to a long-term backend for visualization and alerting.
- Alternatively, use the Collector’s Prometheus receiver itself to scrape other Collector instances and forward their internal metrics to a central backend.
- Configure a central Prometheus server (or a centralized scraping pipeline) to scrape each Collector instance’s
- Prometheus overview: https://prometheus.io/docs/introduction/overview/
- OpenTelemetry Collector components: https://opentelemetry.io/docs/collector/
Be cautious when exposing internal metrics publicly—ensure your network and authentication policies prevent unauthorized access to the
/metrics endpoint. Limit exposure to trusted networks and enforce firewall and authentication controls as appropriate.Summary and quick checklist
- Enable zpages (optional) for quick debugging.
- Add a metrics pipeline that includes the Prometheus receiver.
- Add a Prometheus-format reader under
telemetry.metrics.readersand sethost/port(e.g.,8888). - Confirm by visiting
http://<collector-ip>:8888/metrics. - For scale: configure a central Prometheus scrape or a centralized scraping pipeline and forward to a backend for aggregation, alerting, and storage.