This is documentation for the next version of Grafana Alloy Documentation. For the latest stable release, go to the latest version.

Documentationbreadcrumb arrow Grafana Alloybreadcrumb arrow Referencebreadcrumb arrow Componentsbreadcrumb arrow otelcolbreadcrumb arrow otelcol.receiver.prometheus
General availability (GA) Open source

otelcol.receiver.prometheus

otelcol.receiver.prometheus receives Prometheus metrics, converts them to the OpenTelemetry metrics format, and forwards them to other otelcol.* components. This is a custom component built on a fork of the upstream OpenTelemetry Collector receiver.

You can specify multiple otelcol.receiver.prometheus components by giving them different labels.

Note

Support for translating Prometheus native histograms into OTLP exponential histograms is a public preview feature. To enable native histogram translation, run Alloy with the --stability.level=public-preview configuration flag.

Note

In Alloy v1.14.0, otelcol.receiver.prometheus no longer sets OTLP metric start times for Prometheus metrics. The receiver forwards metrics without adding start times when the Prometheus input doesn’t have a created time.

Start time indicates 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_time to set it. The OTLP endpoint for Grafana Mimir and the OTLP Gateway for Grafana Cloud both support OTLP metric start time.

To add the start time in the same way that otelcol.receiver.prometheus did prior to Alloy v1.14.0, configure otelcol.processor.metric_start_time with strategy set to true_reset_point.

It’s only necessary to use true_reset_point if your Mimir or Grafana Cloud instance is explicitly configured with a -distributor.otel-created-timestamp-zero-ingestion-enabled=true flag, since true_reset_point sends a sample with the same start and end time, and Mimir by default doesn’t create a zero sample for it. For most Mimir and Grafana Cloud use cases, there’s no change in behavior even if you don’t add otelcol.processor.metric_start_time.

Usage

Alloy 
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 blocks with otelcol.receiver.prometheus:

BlockDescriptionRequired
outputConfigures where to send received telemetry data.yes
debug_metricsConfigures the metrics that this component generates to monitor its state.no

output

Required

The output block configures a set of components to forward resulting telemetry data to.

The following arguments are supported:

NameTypeDescriptionDefaultRequired
logslist(otelcol.Consumer)List of consumers to send logs to.[]no
metricslist(otelcol.Consumer)List of consumers to send metrics to.[]no
traceslist(otelcol.Consumer)List of consumers to send traces to.[]no

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.

debug_metrics

The debug_metrics block configures the metrics that this component generates to monitor its state.

The following arguments are supported:

NameTypeDescriptionDefaultRequired
disable_high_cardinality_metricsbooleanWhether to disable certain high cardinality metrics.trueno

disable_high_cardinality_metrics is the Alloy equivalent to the telemetry.disableHighCardinalityMetrics feature gate in the OpenTelemetry Collector. It removes attributes that could cause high cardinality metrics. For example, attributes with IP addresses and port numbers in metrics about HTTP and gRPC connections are removed.

Note

If configured, disable_high_cardinality_metrics only applies to otelcol.exporter.* and otelcol.receiver.* components.

Exported fields

This component exports the following fields that other components can reference:

NameTypeDescription
receiverMetricsReceiverA value that other components can use to send Prometheus metrics to.

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 receiver converts the metrics to OTLP format and forwards them to the otelcol.exporter.otlphttp component, which sends them to an OTLP-capable endpoint:

Alloy 
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.otlphttp.default.input]
  }
}

otelcol.exporter.otlphttp "default" {
  client {
    endpoint = sys.env("OTLP_ENDPOINT")
  }
}

Compatible components

otelcol.receiver.prometheus can accept arguments from the following components:

otelcol.receiver.prometheus has exports that can be consumed by the following components:

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.