Grafana Alloy: Metrics Collection (Prometheus & Ecosystem)

Publié le : 10/05/2026 à 10:00

1. Discovery

Auto-detection of targets via Kubernetes, Consul, or static files.

Dynamically finding targets

In modern environments, service IP addresses and ports change constantly. Alloy integrates discovery components (Service Discovery) from Prometheus. Whether via discovery.kubernetes, discovery.consul, or simple static files, Alloy automatically identifies targets to query, along with all their associated labels.

2. Scraping

Configuration of the prometheus.scrape component.

Collecting metrics

Once the targets are identified, the prometheus.scrape component comes into play. It periodically connects to the targets' /metrics endpoints, retrieves the data in Prometheus format, applies any relabeling rules (to filter or modify labels before ingestion), and forwards the time series to the export component.

3. Remote Write

Forwarding data to Grafana Cloud or a local instance.

Metrics forwarding

The prometheus.remote_write component takes the scraped metrics and pushes them to a compatible time series database, such as Grafana Mimir, Prometheus (with remote_write enabled), or Grafana Cloud. It handles authentication (Basic Auth, Bearer Token), buffering (WAL) to prevent data loss in case of a network outage, and compression.

Best Practice: Always configure the wal (Write-Ahead Log) component for your forwarders. This ensures that in the event of a database outage, Alloy caches the metrics on disk and automatically resends them once the connection is restored.

Common Mistake: Scraping metrics with high cardinality (e.g., including a user_id or a session_id in the labels of a Prometheus metric) without using relabel components to filter them. This will lead to a cardinality explosion and saturate your backend.

prometheus.remote_write "default" {
  endpoint {
    url = "https://prometheus-prod.grafana.net/api/prom/push"
  }
  wal {
    truncate_frequency = "2h"
    max_keepalive_time = "5m"
  }
}

4. OTLP Interoperability

Receiving and transforming OpenTelemetry metrics.

The bridge between Prometheus and OTLP

Alloy shines in its ability to unify ecosystems. With the otelcol components, Alloy can act as an OpenTelemetry collector, receiving metrics in OTLP format sent directly by your instrumented applications, converting them on the fly, and integrating them into your existing Prometheus export pipeline.