Menu

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

Open source

otelcol.exporter.prometheus

otelcol.exporter.prometheus accepts OTLP-formatted metrics from other otelcol components, converts metrics to Prometheus-formatted metrics, and forwards the resulting metrics to prometheus components.

Note

otelcol.exporter.prometheus is a custom component unrelated to the prometheus exporter from OpenTelemetry Collector.

Conversion of metrics are done according to the OpenTelemetry Metrics Data Model specification.

Multiple otelcol.exporter.prometheus components can be specified by giving them different labels.

Usage

alloy
otelcol.exporter.prometheus "LABEL" {
  forward_to = [...]
}

Arguments

otelcol.exporter.prometheus supports the following arguments:

NameTypeDescriptionDefaultRequired
include_target_infobooleanWhether to include target_info metrics.trueno
include_scope_infobooleanWhether to include otel_scope_info metrics.falseno
include_scope_labelsbooleanWhether to include additional OTLP labels in all metrics.trueno
add_metric_suffixesbooleanWhether to add type and unit suffixes to metrics names.trueno
gc_frequencydurationHow often to clean up stale metrics from memory."5m"no
forward_tolist(MetricsReceiver)Where to forward converted Prometheus metrics.yes
resource_to_telemetry_conversionbooleanWhether to convert OTel resource attributes to Prometheus labels.falseno

By default, OpenTelemetry resources are converted into target_info metrics. OpenTelemetry instrumentation scopes are converted into otel_scope_info metrics. Set the include_scope_info and include_target_info arguments to false, respectively, to disable the custom metrics.

When include_scope_labels is true the otel_scope_name and otel_scope_version labels are added to every converted metric sample.

When include_target_info is true, OpenTelemetry Collector resources are converted into target_info metrics.

Note

OTLP metrics can have a lot of resource attributes. Setting resource_to_telemetry_conversion to true would convert all of them to Prometheus labels, which may not be what you want. Instead of using resource_to_telemetry_conversion, most users need to use otelcol.processor.transform to convert OTLP resource attributes to OTLP metric datapoint attributes before using otelcol.exporter.prometheus. See Creating Prometheus labels from OTLP resource attributes for an example.

Blocks

The following blocks are supported inside the definition of otelcol.exporter.prometheus:

HierarchyBlockDescriptionRequired
debug_metricsdebug_metricsConfigures the metrics that this component generates to monitor its state.no

debug_metrics block

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
levelstringControls the level of detail for metrics emitted by the wrapped collector."detailed"no

disable_high_cardinality_metrics is the Grafana 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.

level is the Alloy equivalent to the telemetry.metrics.level feature gate in the OpenTelemetry Collector. Possible values are "none", "basic", "normal" and "detailed".

Exported fields

The following fields are exported and can be referenced by other components:

NameTypeDescription
inputotelcol.ConsumerA value that other components can use to send telemetry data to.

input accepts otelcol.Consumer data for metrics. Other telemetry signals are ignored.

Metrics sent to the input are converted to Prometheus-compatible metrics and are forwarded to the forward_to argument.

The following are dropped during the conversion process:

  • Metrics that use the delta aggregation temporality

Component health

otelcol.exporter.prometheus is only reported as unhealthy if given an invalid configuration.

Debug information

otelcol.exporter.prometheus does not expose any component-specific debug information.

Example

Basic usage

This example accepts metrics over OTLP and forwards it using prometheus.remote_write:

alloy
otelcol.receiver.otlp "default" {
  grpc {}

  output {
    metrics = [otelcol.exporter.prometheus.default.input]
  }
}

otelcol.exporter.prometheus "default" {
  forward_to = [prometheus.remote_write.mimir.receiver]
}

prometheus.remote_write "mimir" {
  endpoint {
    url = "http://mimir:9009/api/v1/push"
  }
}

Create Prometheus labels from OTLP resource attributes

This example uses otelcol.processor.transform to add extra key1 and key2 OTLP metric datapoint attributes from the key1 and key2 OTLP resource attributes.

otelcol.exporter.prometheus then converts key1 and key2 to Prometheus labels along with any other OTLP metric datapoint attributes.

This avoids the need to set resource_to_telemetry_conversion to true, which could have created too many unnecessary metric labels.

alloy
otelcol.receiver.otlp "default" {
  grpc {}

  output {
    metrics = [otelcol.processor.transform.default.input]
  }
}

otelcol.processor.transform "default" {
  error_mode = "ignore"

  metric_statements {
    context = "datapoint"

    statements = [
      `set(attributes["key1"], resource.attributes["key1"])`,
      `set(attributes["key2"], resource.attributes["key2"])`,
    ]
  }

  output {
    metrics = [otelcol.exporter.prometheus.default.input]
  }
}

otelcol.exporter.prometheus "default" {
  forward_to = [prometheus.remote_write.mimir.receiver]
}

prometheus.remote_write "mimir" {
  endpoint {
    url = "http://mimir:9009/api/v1/push"
  }
}

Compatible components

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

otelcol.exporter.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.