Grafana Alloy: the collector, what it replaces and how to migrate

Grafana Alloy is an open source telemetry collector, presented by Grafana Labs as a distribution of the OpenTelemetry Collector with built-in Prometheus pipelines and native support for Loki and Pyroscope. For an SRE or platform team, the practical question is simple: what does Grafana Alloy replace in your estate, and what is left to do alongside it?

This article answers it from the official documentation: what Alloy replaces (Grafana Agent, Promtail, sometimes an OpenTelemetry Collector or a Prometheus agent), how a configuration is built, how to migrate and how to send OTLP data to Dynatrace. It complements the Dynatrace and Grafana comparison, which compares platforms, whereas Alloy is a collection component.

The examples for sending to Dynatrace apply to Dynatrace SaaS: the pages read describe the live.dynatrace.com URL. Dynatrace Managed was not verified here.

In brief

• Grafana Alloy is released under the Apache-2.0 licence (GitHub repository grafana/alloy) and covers metrics, logs, traces and profiles.
• According to the Loki documentation, Grafana Agent Static, Flow and Operator reached end of life on 1 November 2025; according to the Alloy documentation, Promtail did so on 2 March 2026.
• Alloy does not replace a back end: it collects, transforms and forwards.
• It speaks OTLP, so it can feed Dynatrace, though this is not a dedicated integration.

Grafana Alloy: what this collector is

The repository describes Alloy as an OpenTelemetry Collector distribution with programmable pipelines. The README adds that it supports dozens of Collector components, plus components specific to Alloy. The documentation says a single tool can replace a separate collector per signal type, which reduces operational overhead, and that it sends to any compatible back end.

The model is built on components. Each component does one job: receive, transform or send. A configuration file wires them together, the output of one becoming the input of the next. Alloy then runs the whole as a continuous pipeline. Three families come up again and again:

• prometheus.*: collecting and forwarding Prometheus-format metrics;
• loki.*: reading and forwarding logs;
• otelcol.*: receivers, processors and exporters from the OpenTelemetry ecosystem.

Alloy also ships a web UI. According to the troubleshooting page, it listens by default on http://localhost:12345 and lists components with their health, evaluated arguments and exports. On a non-containerised install, only the local machine can reach it by default.

What Grafana Alloy replaces, and what it does not

The documentation offers migration guides from Grafana Agent (Static and Flow modes, plus the Operator), Promtail, Prometheus and the OpenTelemetry Collector. Here is the most useful summary.

Two caveats. First, the Alloy documentation home page does not say outright that « Alloy replaces Agent »; the migration guides and the Loki page establish it. Second, Alloy is a distribution: if you only need OTLP to a third-party back end, a standard OpenTelemetry Collector, such as the one in our article on the OpenTelemetry Collector on Kubernetes, remains a legitimate choice. Alloy becomes attractive when your estate mixes Prometheus metrics, Loki logs and OTLP.

Write a first Alloy configuration for Dynatrace

To send OTLP telemetry to Dynatrace SaaS, the Dynatrace documentation gives a base URL of https://{your-environment-id}.live.dynatrace.com/api/v2/otlp, to which /v1/traces, /v1/metrics or /v1/logs is appended. Authentication uses a platform token in the Authorization header with the Bearer scheme. The scopes listed are openpipeline:logs:ingest, openpipeline:metrics:ingest and openpipeline:traces:ingest.

The point to remember for Alloy: the same page states that gRPC is not supported and that binary protobuf is required. The suitable exporter is therefore otelcol.exporter.otlphttp, whose client block accepts endpoint and headers. The receiver can accept both gRPC and HTTP from applications (ports 4317 and 4318 by default): Alloy handles the conversion to HTTP.

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

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

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

otelcol.exporter.otlphttp "dynatrace" {
  client {
    endpoint = sys.env("DT_ENDPOINT")
    headers  = { "Authorization" = "Bearer " + sys.env("DT_PLATFORM_TOKEN") }
  }
}

This configuration combines three examples from the Alloy documentation (receiver, batch, exporter) with the header described by Dynatrace. It was not run against a Dynatrace environment for this article: test it on a non-critical environment first.

The critical lines

1. The output block is required on the receiver. According to the documentation, if the metrics, logs and traces lists stay empty, telemetry is dropped.
2. Secrets come from the environment through sys.env. The + operator concatenates strings, which lets you build the Bearer … value without writing the token in the file.
3. No gRPC towards Dynatrace: do not confuse the otlp exporter (gRPC) with otlphttp.

Migrate from Grafana Agent or Promtail with alloy convert

Alloy provides a conversion command. According to the migration guides, --source-format is promtail or static, --output names the generated Alloy file, and --report writes a diagnostic report. Without a report, conversion errors go to stderr.

The guide also flags two options to handle with care. --bypass-errors produces a best-effort conversion whose behaviour may differ from the original. And run --config.format=… with --config.bypass-conversion-errors starts Alloy despite non-critical errors, which the documentation advises against in production.

1. Back up the original configuration and list what it collects (log files, Prometheus targets).
2. Run alloy convert with --report and read every warning.
3. Start Alloy alongside the old agent on a test node, without stopping the old one.
4. Compare the volumes received on both sides before switching the old agent off.

Metrics and logs: two examples from the documentation

For metrics, prometheus.scrape requires two arguments, targets (each target carries at least the __address__ label) and forward_to. The default interval is 60 seconds. For logs, loki.source.file reads files whose path is given in the __path__ label, then forwards to loki.write.

These blocks show the appeal of a single tool: one process, one configuration file and a local UI showing which components are healthy. However, sending Prometheus metrics or Loki logs on to Dynatrace requires conversion components that this article has not verified; do not rely on that without reading them in the documentation.

Check that Grafana Alloy works

1. Open http://localhost:12345: every component should appear healthy.
2. Open the detail page of otelcol.exporter.otlphttp to check its evaluated arguments.
3. Send a test trace from an application instrumented with OpenTelemetry to port 4318.
4. Look for that trace in Dynatrace; if it is missing, recheck token scope, URL and protocol.

Best practices

• An SLI for the collector itself: a collector that drops data puts your error budget at risk. Monitor it like a service. See observability versus monitoring.
• Migrate in stages and keep the old agent until volumes match.
• Never write a token in the configuration: use environment variables.
• Read the component page before adding it: arguments, defaults and stability.
• Keep OTLP as the contract with your applications, which limits lock-in, as explained in OpenTelemetry and Prometheus.

Frequently asked questions

Does Grafana Alloy replace Grafana Agent?

In practice, yes: the Loki documentation states that Grafana Agent Static, Flow and Operator reached end of life on 1 November 2025, and the migration guides name Alloy as the target.

Is Grafana Alloy an OpenTelemetry Collector?

It is a distribution of the OpenTelemetry Collector, with built-in Prometheus pipelines and support for Loki and Pyroscope. The otelcol.* components reuse the Collector’s receivers, processors and exporters.

Can Alloy send its data to Dynatrace?

Alloy exports over OTLP/HTTP, and the Dynatrace SaaS OTLP API accepts HTTP with a platform token, not gRPC. The pairing therefore works on paper; test it before adopting it. The Managed case is not covered here.

Conclusion

Grafana Alloy first replaces the Grafana agents that have reached end of life, and can merge several collectors into one. It replaces neither a back end nor careful thought about what you collect. To choose between Alloy and a standard OpenTelemetry Collector, start from your sources: the more mixed they are (Prometheus, Loki, OTLP), the stronger the case for Alloy. For trace volume reduction, see also tail sampling.

Sources

• Introduction, Grafana Alloy documentation
• grafana/alloy repository
• Migrate from Promtail, Alloy documentation
• Migrate from Grafana Agent Static, Alloy documentation
• Migrate to Alloy, Loki documentation
• otelcol.receiver.otlp, otelcol.exporter.otlphttp, prometheus.scrape, loki.source.file
• Alloy UI, Grafana Alloy documentation
• OTLP API, Dynatrace documentation (SaaS)

span.observer is an independent blog, not affiliated with Dynatrace LLC or Grafana Labs. Product names belong to their respective owners; configurations are examples to adapt and test.

Originally published on span.observer. French version: https://span.observer/fr/grafana-alloy-collecteur-remplace/.