otelcol.receiver.prometheus
Public preview: This is a public preview component. Public preview components are subject to breaking changes, and may be replaced with equivalent functionality that cover the same use case. To enable and use a public preview component, you must set the
stability.levelflag topublic-previewor below.
otelcol.receiver.prometheus receives Prometheus metrics, converts them to the OpenTelemetry metrics format, and forwards them to other otelcol.* components.
You can specify multiple otelcol.receiver.prometheus components by giving them different labels.
Note
otelcol.receiver.prometheusis a custom component built on a fork of the upstream OpenTelemetry receiver.
Note
In Alloy v1.14.0,
otelcol.receiver.prometheusno longer sets OTLP metric start times for Prometheus metrics. The receiver forwards metrics without adding start times when the Prometheus input does not have a created time.Start time is a way to tell when a cumulative metric such as an OTLP “sum” or a Prometheus “counter” was last reset. If your database uses start times for OTLP metrics, you can use
otelcol.processor.metric_start_timeto set it. Grafana Mimir’s OTLP endpoint and Grafana Cloud’s OTLP Gateway both support OTLP metric start time.To add the start time in the same way that
otelcol.receiver.prometheusdid it prior to Alloy v1.14.0, configureotelcol.processor.metric_start_timewithstrategyset totrue_reset_point.In practice it is only necessary to use
true_reset_pointif your Mimir/Grafana Cloud instance is explicitly configured with a-distributor.otel-created-timestamp-zero-ingestion-enabled=trueflag, sincetrue_reset_pointwill send a sample with the same start and end time and Mimir by default won’t create a zero sample for it. For most Mimir and Grafana Cloud use cases there would be no change in behaviour even if nootelcol.processor.metric_start_timeis added.
Usage
otelcol.receiver.prometheus "<LABEL>" {
output {
metrics = [...]
}
}Arguments
The otelcol.receiver.prometheus component doesn’t support any arguments. You can configure this component with blocks.
Blocks
You can use the following block with otelcol.receiver.prometheus:
output
RequiredThe output block configures a set of components to forward resulting telemetry data to.
The following arguments are supported:
You must specify the output block, but all its arguments are optional.
By default, telemetry data is dropped.
Configure the metrics, logs, and traces arguments accordingly to send telemetry data to other components.
Exported fields
The following fields are exported and can be referenced by other components:
Component health
otelcol.receiver.prometheus is only reported as unhealthy if given an invalid configuration.
Debug information
otelcol.receiver.prometheus doesn’t expose any component-specific debug information.
Example
This example uses the otelcol.receiver.prometheus component as a bridge between the Prometheus and OpenTelemetry ecosystems.
The component exposes a receiver which the prometheus.scrape component uses to send Prometheus metric data to.
The metrics are converted to the OTLP format before they’re forwarded to the otelcol.exporter.otlp component to be sent to an OTLP-capable endpoint:
prometheus.scrape "default" {
// Collect metrics from the default HTTP listen address.
targets = [{"__address__" = "127.0.0.1:12345"}]
forward_to = [otelcol.receiver.prometheus.default.receiver]
}
otelcol.receiver.prometheus "default" {
output {
metrics = [otelcol.exporter.otlp.default.input]
}
}
otelcol.exporter.otlp "default" {
client {
endpoint = sys.env("OTLP_ENDPOINT")
}
}Compatible components
otelcol.receiver.prometheus can accept arguments from the following components:
- Components that export OpenTelemetry
otelcol.Consumer
otelcol.receiver.prometheus has exports that can be consumed by the following components:
- Components that consume Prometheus
MetricsReceiver
Note
Connecting some components may not be sensible or components may require further configuration to make the connection work correctly. Refer to the linked documentation for more details.