Grafana Alloy is an open source OpenTelemetry Collector distribution with programmable pipelines that collects metrics, logs, traces, and profiles, and it is built for teams that run observability infrastructure and want a single agent in place of several separate collectors and exporters.

What it is

Grafana Alloy is a distribution of the OpenTelemetry Collector, written in Go and released under the Apache-2.0 licence. It ships dozens of upstream OpenTelemetry Collector components alongside its own components, all configured through an expression-based configuration syntax rather than the static pipeline YAML that the upstream collector uses. The project is maintained in the Grafana organisation and lists components for OpenTelemetry Collector, Prometheus, Grafana Loki, and Grafana Pyroscope, following what the README calls Grafana's "big tent" philosophy of working with other vendors and open source databases rather than only Grafana's own backends.

The concrete problem it solves is agent sprawl. Rather than running a plain upstream OpenTelemetry Collector for traces, a Prometheus scraping setup for metrics, and separate shippers for logs and profiles, an operator runs Alloy and wires receivers, processors, and exporters together in one configuration language. Pipeline stages are referenced directly by each other, as in the README example where otelcol.receiver.otlp fans metrics, logs, and traces into otelcol.processor.batch, which forwards to otelcol.exporter.otlp. It replaces the hand-assembled multi-agent stack with one binary, one config, and one debugging surface.

Key capabilities

• Programmable pipelines expressed in an expression-based syntax, with components such as otelcol.receiver.otlp, otelcol.processor.batch, and otelcol.exporter.otlp chained through output references.
• OpenTelemetry Collector distribution: supports dozens of upstream collector components plus new components that use Alloy's own pipeline model.
• Big tent integrations with OpenTelemetry Collector, Prometheus, Grafana Loki, and Grafana Pyroscope, so pipelines are not locked to a single backend.
• Kubernetes-native components that interact with native and custom Kubernetes resources, with no separate Kubernetes operator required.
• Shareable pipelines published as modules, so a pipeline can be reused by other teams.
• Automatic workload distribution by forming a cluster of Alloy instances, instead of manually sharding work per instance.
• Centralized configuration retrieval from a server through the remotecfg block, plus a built-in UI for visualizing and debugging pipelines.

Who uses it and how

• Kubernetes platform teams that want one agent handling cluster telemetry without deploying and learning a separate Kubernetes operator.
• Large fleets that configure multiple Alloy instances into a cluster for automatic workload distribution, rather than assigning scrapes by hand.
• Organisations that keep configuration out of the instances themselves and pull it from a server via remotecfg, centralising change control.
• Multi-signal environments exporting metrics, logs, traces, and profiles to more than one destination, where the big tent integrations matter more than single-vendor depth.
• Pipeline authors who package and share configurations as modules across teams.

Getting started

The README does not name a package, container image, or compose file; it points to Grafana's documentation for installation instructions, a getting-started guide, and the full list of components. Start at the install page under grafana.com/docs/alloy/latest/get-started/ and follow the getting-started steps.

How it compares

Alloy sits between the upstream OpenTelemetry Collector and the backends it feeds: it is a distribution of the collector, so it competes with a plain collector deployment, but it also bundles Prometheus, Loki, and Pyroscope integration that a vanilla collector leaves to separate tooling. Teams already standardised on the OpenTelemetry Collector's YAML configuration are the closest adjacent audience, since Alloy reuses the collector's component vocabulary but not its configuration format.

When to use it — and when not to

Alloy is a good fit for self-hosters already running Kubernetes and several telemetry backends, and for teams willing to adopt its expression-based syntax and keep pace with a rapid release cadence of a minor release roughly every three weeks. Teams that need their existing OpenTelemetry Collector YAML to run unchanged should not pick it, because the configuration language is Alloy's own and must be translated. The honest caveats are that a large open issue count sits against the project, and the README defers most operational detail to Grafana's documentation, so the repository alone is a thin starting point.

otelcol.receiver.otlp "example" {
  grpc {
    endpoint = "127.0.0.1:4317"
  }

  output {
    metrics = [otelcol.processor.batch.example.input]
    logs    = [otelcol.processor.batch.example.input]
    traces  = [otelcol.processor.batch.example.input]
  }
}

otelcol.processor.batch "example" {
  output {
    metrics = [otelcol.exporter.otlp.default.input]
    logs    = [otelcol.exporter.otlp.default.input]
    traces  = [otelcol.exporter.otlp.default.input]
  }
}

otelcol.exporter.otlp "default" {
  client {
    endpoint = "my-otlp-grpc-server:4317"
  }
}