This is documentation for the next version of Alloy. For the latest stable release, go to the latest version.
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 will give 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 will give 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 is common in the Prometheus ecosystem.
Logs from applications
Use otelcol.receiver.*
components to collect application logs.
This will gather 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.
Traces
Use otelcol.receiver.*
components to collect traces.
If your application is not yet instrumented for tracing, use beyla.ebpf
to generate traces for it automatically.
Profiles
Use pyroscope.*
components to collect profiles.