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

Choose a component

Open source

Choose a Grafana Alloy component

Components are the building blocks of Grafana Alloy, and there is a large number of them. The components you select and configure depend on the telemetry signals you want to collect.

Metrics for infrastructure

Use prometheus.* components to collect infrastructure metrics. This gives you the best experience with Grafana Infrastructure Observability.

For example, you can get metrics for a Linux host using prometheus.exporter.unix, and metrics for a MongoDB instance using prometheus.exporter.mongodb.

You can also scrape any Prometheus endpoint using prometheus.scrape. Use discovery.* components to find targets for prometheus.scrape.

Metrics for applications

Use otelcol.receiver.* components to collect application metrics. This gives you the best experience with Grafana Application Observability, which is OpenTelemetry-native.

For example, use otelcol.receiver.otlp to collect metrics from OpenTelemetry-instrumented applications.

If your application is already instrumented with Prometheus metrics, there is no need to use otelcol.* components. Use prometheus.* components for the entire pipeline and send the metrics using prometheus.remote_write.

Logs from infrastructure

Use loki.* components to collect infrastructure logs. The loki.* components label your logs in a way that resembles Prometheus metrics. This makes it easy to correlate infrastructure metrics collected by prometheus.* components with logs collected by loki.* components.

For example, the label that both prometheus.* and loki.* components would use for a Kubernetes namespace is called namespace. On the other hand, gathering logs using an otelcol.* component might use the OpenTelemetry semantics label called k8s.namespace.name, which wouldn’t correspond to the namespace label that’s common in the Prometheus ecosystem.

Logs from applications

Use otelcol.receiver.* components to collect application logs. This gathers the application logs in an OpenTelemetry-native way, making it easier to correlate the logs with OpenTelemetry metrics and traces coming from the application. All application telemetry must follow the OpenTelemetry semantic conventions, simplifying this correlation.

For example, if your application runs on Kubernetes, every trace, log, and metric can have a k8s.namespace.name resource attribute.