Prometheus Receiver
core, contrib, k8s
Maintainers: @Aneurysm9, @dashpole, @ArthurSens, @krajorama
Source: opentelemetry-collector-contrib
Supported Telemetry
Overview
See the Design for additional information on this receiver.⚠️ Warning
Note: This component is currently work in progress. It has several limitations and please don’t use it if the following limitations are a concern:- Collector cannot auto-scale the scraping yet when multiple replicas of the collector are run.
- When running multiple replicas of the collector with the same config, it will scrape the targets multiple times.
- Users need to configure each replica with different scraping configuration if they want to manually shard the scraping.
Unsupported features
The Prometheus receiver is meant to minimally be a drop-in replacement for Prometheus. However, there are advanced features of Prometheus that we don’t support and thus explicitly will return an error for if the receiver’s configuration YAML/code contains any of the following- alert_config.alertmanagers
- alert_config.relabel_configs
- remote_read
- remote_write
- rule_files
External Dependencies
This receiver uses the scrape manager and parser implementation fromprometheus/prometheus. Compatibility with Prometheus scrape behavior follows the version pinned in go.mod.
Supported scrape protocol and exposition formats are those accepted by the Prometheus scrape configuration:
PrometheusProtoOpenMetricsText1.0.0OpenMetricsText0.0.1PrometheusText1.0.0PrometheusText0.0.4
fallback_scrape_protocol is not set, the receiver defaults it to PrometheusText0.0.4 for compatibility with targets that do not return a proper content type.
For native histogram details and protocol requirements, see Prometheus native histograms.
Getting Started
This receiver is a drop-in replacement for getting Prometheus to scrape your services. It supports the full set of Prometheus configuration inscrape_config,
including service discovery. Just like you would write in a YAML configuration
file before starting Prometheus, such as with:
Note: Since the collector configuration supports env variable substitution
$ characters in your prometheus configuration are interpreted as environment
variables. If you want to use $ characters in your prometheus configuration,
you must escape them using $$.
config attribute:
Configuration
| Field | Default | Description |
|---|---|---|
config | Embedded Prometheus scrape configuration (global, scrape_configs, scrape_config_files, and related sections). Uses the same YAML structure as Prometheus; any field you omit picks up the default documented there for that setting. Service discovery and relabeling behave like Prometheus. | |
target_allocator | Optional Target Allocator client configuration used to fetch dynamically assigned scrape targets. See OpenTelemetry Operator. | |
trim_metric_suffixes | false | [Experimental] Trims unit and some counter type suffixes from metric names, for example singing_duration_seconds_total -> singing_duration. Useful when trying to restore metric names closer to OpenTelemetry instrumentation. |
api_server | Optional nested block for a local Prometheus agent-mode API server (debugging targets, configuration, and service discovery). See Prometheus API Server. |
config.scrape_configs, config.scrape_config_files, or target_allocator must be set.
Example configuration:
Complete Configuration Example
The following example demonstrates a complete end-to-end configuration showing how to use the Prometheus receiver with processors and exporters in a service pipeline:- Scrapes metrics from a service running on
localhost:9090every 5 seconds - Filters metrics to keep only those matching
http_request_duration_seconds.*usingmetric_relabel_configs - Adds resource attributes (
deployment.environment) to all metrics (note:service.nameis automatically set from the job name) - Uses exporter-level batching via
sending_queue.batchto improve efficiency when multiple scrapes occur - Exports metrics to both an OTLP endpoint and Prometheus remote write endpoint
Prometheus native histograms
Native histograms are a data type in Prometheus, for more information see the specification. The Prometheus receiver automatically converts native histograms to OpenTelemetry exponential histograms. To enable scraping and ingestion of native histograms, you need to configure two things in your Prometheus scrape config:- Enable native histogram scraping: Set
scrape_native_histograms: true(globally or per-job) - Use the protobuf scrape protocol: Include
PrometheusProtoinscrape_protocols(required until Prometheus supports native histograms over text formats)
always_scrape_classic_histograms.
OpenTelemetry Operator
Additional to this static job definitions this receiver allows to query a list of jobs from the OpenTelemetryOperators TargetAllocator or a compatible endpoint.target_allocator section embeds the full confighttp client configuration.
Exemplars
This receiver accepts exemplars coming in Prometheus format and converts it to OTLP format.- Value is expected to be received in
float64format - Timestamp is expected to be received in
ms - Labels with key
span_idin prometheus exemplars are set as OTLPspan idand labels with keytrace_idare set astrace id - Rest of the labels are copied as it is to OTLP format
Resource and Scope
This receiver drops thetarget_info prometheus metric, if present, and uses attributes on
that metric to populate the OpenTelemetry Resource.
It drops otel_scope_name and otel_scope_version labels, if present, from metrics, and uses them to populate
the OpenTelemetry Instrumentation Scope name and version. It drops the otel_scope_info metric,
and uses attributes (other than otel_scope_name and otel_scope_version) to populate Scope
Attributes.
Resource Attribute Mapping
In addition to attributes derived fromtarget_info, this receiver maps scrape target metadata to OpenTelemetry resource attributes. These mappings follow OpenTelemetry semantic conventions.
For the current detailed mapping list, see resource_attribute_mapping.md.
We are incrementally adding mappings for additional Prometheus service discovery labels and
welcome contributions aligned with OpenTelemetry semantic conventions.
Scrape Metadata Metrics
Scrape metadata metrics are automatically generated by Prometheus during scraping and are emitted alongside the target metrics. For the full list of scrape metadata metrics and their semantics, refer to the Prometheus documentation on automatically generated labels and time series. Whenextra_scrape_metrics is enabled in Prometheus global or scrape_config,
additional scrape metadata metrics are emitted as described in the same Prometheus
documentation.
Prometheus API Server
The Prometheus API server can be enabled to host info about the Prometheus targets, config, service discovery, and metrics. Theserver_config can be specified using the OpenTelemetry confighttp package. An example configuration would be:
- /api/v1/targets
- /api/v1/targets/metadata
- /api/v1/status/config
- /api/v1/scrape_pools
- /metrics
/api/v1/ and the data format that is returned can be found in the Prometheus documentation.
Feature gates
See documentation.md for the complete list of feature gates supported by this receiver. Feature gates can be enabled using the--feature-gates flag:
Benchmark Results
Current Prometheus receiver benchmark results are published on the Collector Benchmarks page. The table below links directly to the current Prometheus receiver charts by scenario and metric type.Configuration
config.yaml (testdata)
config.yaml (testdata)
Last generated: 2026-06-01