Grafana Alloy

Last reviewed Sep 13, 2026 · 778 words

One Alloy process replaces three: node_exporter for host metrics, Promtail for logs, and whatever OpenTelemetry Collector you were about to add for traces. Grafana Agent, its predecessor, is already end-of-life, so if you run Agent this move is not optional. If you are starting a Grafana stack fresh, Alloy is the collector I would put on every host, with one honest caveat: it is a 2024 project with its own configuration syntax, and you will spend the first hour learning that syntax rather than collecting anything.

What it is, and the two things it is not

Alloy is a distribution of the OpenTelemetry Collector, which means it is a pipeline: components discover targets, scrape or tail them, transform the data, and forward it. It stores nothing. Metrics go to Prometheus or Mimir over remote write, logs to Loki, traces to Tempo, profiles to Pyroscope, and then Grafana reads from those. It is also not a vendor lock: it speaks OTLP in and out, so an Alloy pipeline can ship to any OpenTelemetry-compatible backend. The Grafana integration is where it is most comfortable, not where it is limited to.

The config syntax, in one file that does something useful

Alloy's configuration is a block language (originally called River) where every block is a component and components wire together by referencing each other's exports. Here is a complete config that scrapes the local host and tails Docker container logs:

prometheus.exporter.unix "host" { }

prometheus.scrape "host" {
  targets    = prometheus.exporter.unix.host.targets
  forward_to = [prometheus.remote_write.default.receiver]
}

prometheus.remote_write "default" {
  endpoint {
    url = "http://prometheus:9090/api/v1/write"
  }
}

discovery.docker "containers" {
  host = "unix:///var/run/docker.sock"
}

loki.source.docker "containers" {
  host       = "unix:///var/run/docker.sock"
  targets    = discovery.docker.containers.targets
  forward_to = [loki.write.default.receiver]
}

loki.write "default" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }
}

Read it bottom-up if it looks strange: forward_to is the wire. Once that clicks, adding a prometheus.scrape for a new exporter is 4 lines. Alloy exposes a debugging UI on port 12345 showing every component, its health, and live data flowing through it, which is the single best troubleshooting tool in this whole category and a real advantage over the plain OTel Collector.

The 128 MB claim holds at idle, not under load

An Alloy container doing host metrics and nothing else sits around 100 to 150 MB, which matches the minimum listed here. Add Docker log tailing for 30 containers and a few hundred scrape targets and I have seen it settle between 300 and 500 MB, with spikes during remote-write retries when the backend is down, because Alloy buffers on disk and in memory until the endpoint returns. Treat those as estimates from homelab-scale use, not benchmarks. On a Raspberry Pi, the plain node_exporter at 20 MB is still the lighter choice if all you need is host metrics.

Migrating from Grafana Agent is a one-line convert

The alloy convert subcommand reads an existing config and emits Alloy syntax:

alloy convert --source-format=static --output=config.alloy agent.yaml
alloy convert --source-format=promtail --output=logs.alloy promtail.yaml

It also accepts prometheus and otelcol source formats, which is how you migrate a bare Prometheus scrape config or an OTel Collector YAML. The converted output is verbose and worth tidying, but it runs. Check the diagnostics it prints, since a few Agent integrations have no exact equivalent.

Alloy or the plain OpenTelemetry Collector

If Grafana is your dashboard and Loki or Tempo is your backend, Alloy. It bundles the Prometheus-native components (the prometheus.exporter.* family wraps the standard exporters) and the OTel ones in one binary, with better debugging. If you are shipping to a non-Grafana backend, or your organisation standardises on upstream OTel, the OpenTelemetry Collector itself avoids a Grafana-shaped dependency. If your world is InfluxDB, Telegraf remains the natural agent.

What I'd do

One Alloy container per Docker host in host network mode, the config above plus a prometheus.scrape block for each service exporter, shipping to a single Prometheus and Loki on the monitoring box. Pin the image tag, because the config syntax still gets additions between minor versions and a surprise upgrade can reject a block. Convert any Agent or Promtail config with the CLI rather than by hand. Keep node_exporter only on hosts where 100 MB matters. It is a young project at 3,506 stars, but it is the one Grafana Labs is investing in, and betting against that in a Grafana stack has a poor track record.