Introduction to Grafana Alloy on Grafana Labs

Why Grafana Alloy

Mon, 24 Aug 2026 14:24:42 +0000

Why Grafana Alloy

Grafana Alloy simplifies telemetry collection by consolidating multiple collectors into one solution.

The telemetry collection challenge

Telemetry collection in production environments can quickly become complex as different teams develop different needs over time.

Consider a common scenario. You start with infrastructure observability, using Prometheus to scrape metrics from Node Exporter. Your metrics flow to a Prometheus database, and you visualize them in Grafana dashboards. This works well for monitoring infrastructure.

Later, you want to add application observability and start analyzing distributed traces. Prometheus doesn’t support traces, so you add the OpenTelemetry Collector. Now you’re running two different collectors, each with its own configuration syntax, deployment requirements, and operational overhead.

As your observability needs grow, you might add a separate collector for logs, another tool for continuous profiling, and different agents for different environments. Before long, you’re managing multiple collectors, learning different configuration languages, troubleshooting various failure modes, and dealing with increased memory and CPU overhead.

Alloy addresses these challenges by handling all signal types in a single deployment with one configuration language. You learn one tool, deploy one collector, and maintain one system.

When to use Alloy

Alloy excels in several scenarios. The following sections help you identify whether it fits your needs.

You need multiple signal types

Alloy natively supports metrics from both Prometheus and OpenTelemetry sources, application and system logs, distributed traces using OpenTelemetry, and continuous profiling data.

If you’re running separate collectors for metrics and traces, or planning to add log collection to your metrics pipeline, Alloy lets you consolidate into a single solution.

For example, if you monitor infrastructure with Prometheus but want to add distributed tracing for your microservices, you can use Alloy to handle both with one collector instead of deploying multiple collectors.

You want to reduce collector complexity

Running multiple collectors creates operational overhead. You have to learn different configuration languages, manage separate deployments and upgrades, troubleshoot different failure modes, and monitor multiple systems—all while consuming more resources.

Alloy consolidates all of this. You learn one configuration language, manage one deployment, and use a single built-in UI for debugging. This unified approach reduces both complexity and resource consumption.

For example, if your team runs Prometheus for metrics, Fluentd for logs, and Jaeger agents for traces, Alloy can replace all three and simplify your telemetry architecture.

You need both Prometheus and OpenTelemetry

Alloy works with both ecosystems simultaneously. It includes native Prometheus remote write support, full OpenTelemetry protocol support, Prometheus service discovery mechanisms, OpenTelemetry instrumentation compatibility, and the ability to convert between formats.

You don’t have to choose between Prometheus and OpenTelemetry. If you have Prometheus deployments and instrumentation but your applications use OpenTelemetry, Alloy collects from both while you standardize on one collector.

You value vendor neutrality

Alloy supports sending data to Grafana Cloud, a self-managed Grafana stack with Loki, Mimir, Tempo, and Pyroscope, any Prometheus-compatible database, any OpenTelemetry-compatible backend, or multiple destinations simultaneously.

This flexibility means you’re not locked into a single vendor or backend. You can send data to Grafana Cloud for some telemetry and self-managed systems for others, or change backends without changing your collector.

For example, if you want to send metrics to Grafana Cloud but keep logs on-premises for compliance reasons, Alloy can send metrics to the cloud and logs to your local Loki instance from the same configuration.

Your observability needs are growing

Alloy provides features for scaling, including clustering to distribute workload across multiple instances for high availability and horizontal scaling, remote configuration to manage fleet-wide configurations from a central location, and automatic workload distribution across cluster members.

Start with a single Alloy instance and scale to clusters as your needs grow, without changing your approach.

You’re running on Kubernetes

Alloy offers Kubernetes-native features including first-class support for discovering Kubernetes resources, components that interact with Kubernetes APIs directly, native understanding of pods, services, and custom resources, and support for DaemonSet and Deployment patterns.

No separate Kubernetes operator is required. The Kubernetes discovery components automatically find and scrape pods as they start and stop, without additional configuration.

You want programmable pipelines

The Alloy configuration language lets you create conditional logic in your pipelines, reference data from one component in another, build reusable pipeline modules, transform and filter data with built-in functions, and respond dynamically to changing conditions.

If you need more than basic “collect and forward” functionality, the programmable approach provides the flexibility you need. Common scenarios include routing high-priority metrics to one backend while sampling lower-priority data, extracting useful labels from high-cardinality fields to manage storage costs, standardizing attribute names when different teams use inconsistent conventions, and redacting sensitive tokens or credentials from logs before they reach storage.

The module system allows you to create custom components that combine multiple steps, package and share pipelines with your team, use community-contributed modules, and maintain consistent collection patterns across services.

Your platform team can create a standard monitoring module that application teams import and configure with their specific settings, without understanding the underlying complexity.

What Alloy replaces

Alloy can consolidate multiple collectors. Replace Prometheus Agent to gain the same functionality plus support for logs, traces, and profiles. Replace the OpenTelemetry Collector to add native Prometheus support alongside OTLP. Replace specialized log collectors like Promtail, Fluentd, or Filebeat with a unified collection approach.

You can also run Alloy alongside collectors during migration to transition gradually without disrupting your observability. Refer to the migration guides for step-by-step instructions.

When Alloy might not be the right choice

Alloy is powerful and flexible, but it’s not always the best fit.

Consider alternatives if you only need basic Prometheus metrics scraping with no additional features, as Prometheus Agent might be simpler. If you’re deeply integrated with a specific collector’s ecosystem and don’t need multi-signal support, staying with your current solution may make more sense. If you have very specific requirements that available components don’t address, evaluate whether the benefits outweigh the effort of migration.

Next steps

Learn how Alloy works to understand the architecture
Review requirements and expectations to understand deployment considerations
Install Alloy to get started
Follow a tutorial for hands-on experience

How Grafana Alloy works

Mon, 24 Aug 2026 14:24:42 +0000

How Grafana Alloy works

Understanding the architecture and design of Alloy helps you use it effectively.

Where Alloy fits

A typical observability setup has three layers: data sources that generate telemetry, collection tools that gather and process it, and storage backends with visualization frontends for querying and exploring data.

Alloy operates in the collection layer, sitting between your data sources and your storage backends. It acts as the bridge between them, performing three main functions in your telemetry pipeline.

Collect telemetry data

Alloy gathers telemetry from any source in your infrastructure. You can configure it to scrape Prometheus endpoints for metrics or set up receivers to accept data pushed via the OpenTelemetry protocol. It tails log files and reads from system outputs to capture application and infrastructure logs. Service discovery automatically finds resources in Kubernetes, Docker, or cloud environments without requiring static configuration. You can also integrate with databases, message queues, and other systems to capture telemetry from specialized sources.

Transform and process data

Processing telemetry before sending it to backends optimizes costs and improves data quality. Create filters to drop unwanted data or redact sensitive information like tokens and credentials from logs before they reach storage. Add labels, metadata, or contextual information to enrich your data—for example, extract a cloud provider name from instance IDs to create useful aggregation labels. Standardize attribute names across services when different teams use inconsistent naming conventions. Implement sampling strategies to reduce high-volume data while preserving the signal you need for troubleshooting. Convert between formats, such as transforming Prometheus metrics to OpenTelemetry format, to ensure compatibility with your backends. Define routing rules to send different types of data to different destinations based on your operational requirements.

Send to backends

Alloy delivers processed telemetry to any storage system you choose. Send data to Grafana Cloud for managed observability, or export to your self-managed Grafana stack components. Connect to any Prometheus-compatible database for metrics and any OpenTelemetry-compatible backend for all signal types. Write to multiple destinations simultaneously, sending the same data to different systems or routing different data types to specialized backends.

Component-based architecture

Alloy uses modular components that work like building blocks. Each component performs a specific task, such as collecting metrics from Prometheus endpoints, receiving OpenTelemetry data, transforming and filtering telemetry, or sending data to backends.

You connect these components together to build pipelines that match your exact requirements. This modular approach makes configurations easier to understand, test, and maintain.

Programmable pipelines

Alloy uses a rich, expression-based configuration language that lets you reference data from one component in another, create dynamic configurations that respond to changing conditions, build reusable pipelines you can share across teams, and use built-in functions to transform and filter data.

Custom and shareable pipelines

You can create custom components that combine multiple components into a single, reusable unit. Share these custom components with your team or the community through the module system. Use pre-built modules from the community or create your own.

Enterprise-ready features

As your systems grow more complex, Alloy scales with you. Clustering lets you configure instances to form a cluster for automatic workload distribution and high availability. Centralized configuration retrieves settings from remote servers for fleet management. Kubernetes-native capabilities let you interact with Kubernetes resources directly without learning separate operators.

Built-in debugging tools

Alloy includes a built-in user interface that helps you visualize your component pipelines, inspect component states and outputs, troubleshoot configuration issues, and monitor performance.

Deployment patterns

Choose the deployment pattern that fits your architecture.

Edge deployment: Deploy Alloy close to your data sources for minimal latency. Run it as a DaemonSet in Kubernetes to collect from every node, install it on each host for infrastructure monitoring, or deploy it alongside applications for local processing.

Gateway deployment: Deploy Alloy as a centralized gateway. Configure your applications to send telemetry to Alloy gateways, which process and forward data to backends. Applications only need to know about the gateway endpoints.

Hybrid deployment: Combine edge and gateway approaches. Deploy edge instances to handle initial collection and filtering close to sources, then forward to gateway instances for aggregation and final processing. This pattern reduces bandwidth usage and enables centralized policy enforcement while maintaining local processing capabilities.

Integrations

Alloy integrates with Grafana Cloud and self-managed Grafana stacks, routing metrics to Mimir, logs to Loki, traces to Tempo, and profiles to Pyroscope. It also works with the broader Prometheus ecosystem through full compatibility with the Prometheus exposition format and service discovery mechanisms, and with any OpenTelemetry-compatible backend through OTLP support.

You can also connect to other ecosystems, including InfluxDB, Elasticsearch, and cloud platforms like AWS, Google Cloud Platform, and Azure.

Next steps

Review requirements and expectations to understand deployment considerations
Install Alloy to get started
Learn core concepts including components, expressions, and pipelines
Follow tutorials for hands-on experience
Explore the component reference to see available components

How telemetry flows through Grafana Alloy

Mon, 24 Aug 2026 14:24:42 +0000

How telemetry flows through Grafana Alloy

Alloy moves telemetry through connected components, from sources to backends. Your configuration defines those components and the connections between them. Follow those connections to see where data enters the pipeline and where it ends up.

Define every connection explicitly

Alloy doesn’t transform, route, or process telemetry unless your configuration tells it to. You define every connection between components, and telemetry moves only along the paths you create.

A changed component alters the telemetry it handles. A missing connection means data doesn’t reach the next stage.

Components connect through exports, receiver references, and attributes such as forward_to. Build data pipelines explains how these connections form pipelines.

Follow the pipeline stages

Connected components form pipelines. Most telemetry pipelines use some combination of four functions: discovery, ingestion, transformation, and output. Discovery and transformation are optional, and you can chain multiple components in the same function or branch to multiple outputs.

flowchart LR

  Discovery[Discovery]
  Ingestion[Ingestion]
  Transformation[Transformation]
  Output[Output]

  Discovery -.->|targets| Ingestion
  Ingestion -->|telemetry| Transformation
  Transformation -->|telemetry| Output

  %% Grafana styling
  classDef grafana fill:#ffffff,stroke:#F05A28,stroke-width:2px,rx:8,ry:8,color:#1f2937,font-weight:600;

  class Discovery,Ingestion,Transformation,Output grafana

In pull-based pipelines, discovery components pass scrape targets to ingestion components such as prometheus.scrape. OpenTelemetry pipelines start at otelcol.receiver.* and skip discovery.

Ingestion collects or receives telemetry and converts it to an internal format. Transformation components modify, filter, route, or sample that data. You can also connect ingestion directly to output and skip transformation.

Output components send telemetry to backends.

When a component supports multiple signal types, connect each type separately through the pipeline.

Build data pipelines has multi-stage examples and pipeline patterns. Choose a component helps you pick components by signal type.

See how telemetry moves in a configuration

When you read a configuration, follow the data path from source to destination:

Start at ingestion components and note what signal type each one handles.
If the pipeline uses discovery, follow targets from discovery components into ingestion.
Follow each component’s output to the next component in the chain.
Note any transformation components and what they change.
Identify where each path ends at an output component.

Connection order determines execution order, not the textual order of components in the file. Pipelines can branch to multiple outputs or share components across paths. Pipeline patterns covers fan-out and chain processing.

The Alloy UI visualizes these connections. Use Debug to inspect component pipelines in a running instance.

Next steps

Start with Get started for configuration syntax and component basics.
Use Build data pipelines to connect components and apply pipeline patterns.
Use Choose a component to pick components for metrics, logs, traces, and profiles.
Follow Collect and forward data for end-to-end collection examples.
Read How Alloy works for architecture and capabilities.
Look up behavior in the Component reference.

OpenTelemetry in Alloy

Mon, 24 Aug 2026 14:24:42 +0000

OpenTelemetry in Alloy

Grafana Alloy combines the Prometheus-native, production-grade collection features of Alloy with the broad ecosystem and standards of OpenTelemetry. The Alloy OpenTelemetry Engine is an OpenTelemetry Collector distribution embedded within Alloy. It lets you run Alloy with the OpenTelemetry Collector while retaining access to Alloy features and integrations through the Alloy Engine extension.

EXPERIMENTAL: OTel Engine is an experimental feature. Experimental features are subject to frequent breaking changes, and may be removed with no equivalent replacement.

To maintain full compatibility of the OTel Engine with the upstream OpenTelemetry Collector and expose a compatible command line interface, the OTel Engine isn’t hidden behind a stability flag.

Make sure that you understand the risks involved before using an experimental feature in your production environments.

Why the OTel Engine exists

Standard OpenTelemetry Collector pipelines use YAML configuration, but Alloy components require translating that configuration into Alloy syntax. The OTel Engine runs the Collector runtime directly, so you can use Collector YAML configurations without translation.

The OTel Engine addresses this by running the upstream Collector runtime directly from the Alloy executable. You can bring existing Collector configurations to Alloy, use familiar Collector tooling, and choose from the components bundled with the otel command.

The OTel Engine also gives Grafana a standards-native foundation for extending Alloy. Grafana is committed to providing a first-class OpenTelemetry collection experience as this experimental engine matures.

How the engines fit together

Both engines are built into the same Alloy binary: alloy run starts the Default Engine, and alloy otel starts the OTel Engine. The optional Alloy Engine extension lets you run a Default Engine pipeline inside the OTel Engine, in the same process.

The following diagram shows how the engines and the extension fit inside the Alloy executable:

---
config:
  flowchart:
    subGraphTitleMargin:
      top: 10
      bottom: 10
    rankSpacing: 10
---

flowchart TD
    subgraph EXEC["Grafana Alloy executable"]
        direction TB
        run(["'alloy run' command"])
        otel(["'alloy otel' command"])
        DE["Default Engine
Traditional Alloy pipeline"]
        run --> DE

        subgraph OE["OTel Engine"]
            direction TB
            subgraph EXT["alloyengine extension (optional)"]
                DEP["Default Engine
Traditional Alloy pipeline"]
            end
        end
        otel --> OE
    end

    style EXEC fill:#fdefe5,stroke:#000000,color:#000000,rx:10,ry:10
    style OE fill:#cce5ff,stroke:#000000,color:#000000,rx:10,ry:10
    style EXT fill:#cce5ff,stroke:#000000,color:#000000,stroke-dasharray: 4 3,rx:10,ry:10
    style DE fill:#ff8833,stroke:#000000,color:#000000,rx:10,ry:10
    style DEP fill:#ff8833,stroke:#000000,color:#000000,rx:10,ry:10
    style run fill:#ffffff,stroke:#000000,color:#000000,rx:10,ry:10
    style otel fill:#ffffff,stroke:#000000,color:#000000,rx:10,ry:10

Choose an engine

Alloy supports two runtime engines and an extension. Choose the engine that best matches your existing configuration and collection workload.

Default Engine: The standard way to run Alloy. It uses Alloy configuration syntax and Alloy components. It remains the stable, most polished experience for getting the most from Grafana Cloud, with backward compatibility guarantees, a built-in UI, live debugging, support bundles, clustering, and broad Grafana integrations.
OTel Engine: The upstream OpenTelemetry Collector runtime embedded in Alloy. It uses Collector YAML configuration and standard Collector command-line arguments. It provides a direct path for OpenTelemetry-native pipelines and existing Collector configurations.
Alloy Engine extension: An OpenTelemetry Collector extension that starts a Default Engine pipeline alongside the OTel Engine. The two pipelines run in the same process, but they don’t interact directly.

Use the OTel Engine for OpenTelemetry-native pipelines

The OTel Engine is a good fit when you:

Already run an OpenTelemetry Collector and want to reuse its YAML configuration and operational model.
Prefer to use standard Collector configuration and command-line arguments.
Collect push-based, OpenTelemetry-native signals through OTLP.
Use Grafana Application Observability and don’t need Default Engine components in the same pipeline.

Grafana Application Observability uses OpenTelemetry-native telemetry. To build a compatible Collector pipeline, refer to Set up OpenTelemetry Collector for Application Observability.

Use the Default Engine for the full Alloy experience

The Default Engine is the recommended choice when you:

Want the stable and most complete Alloy experience.
Collect infrastructure telemetry with Prometheus exporters and pull-based scrapes.
Need Alloy features such as clustering, the built-in UI, live debugging, support bundles, or configuration reloads.
Use Grafana integrations for Kubernetes monitoring, Database Observability, eBPF, logs, or profiles.

The Default Engine is optimized for Prometheus pipelines and label semantics. It also provides Grafana-specific collection features that don’t yet have OpenTelemetry-native equivalents.

Run both engines when you need both component sets

Use the alloyengine extension when one process needs both standard Collector components and Default Engine components. This approach can simplify small deployments.

For large workloads, run the engines in separate processes so you can scale and troubleshoot them independently. Push-based OTLP gateways and pull-based Prometheus scrapers have different load and scaling characteristics.

Manage the OTel Engine with Fleet Management

The OTel Engine works with the OpenTelemetry Collector support in Grafana Fleet Management. The Alloy container provides an otelcol-compatible entry point, and the engine includes the components needed to run with the Open Agent Management Protocol (OpAMP) Supervisor. To monitor and remotely configure an OTel Engine deployment, follow the Fleet Management setup for the OpenTelemetry Collector.

How the engines evolve

Grafana continues to improve the OTel Engine and its integration with Grafana products. The goal is a first-class collection experience for users who choose standard OpenTelemetry Collector workflows.

Default Engine continues to be in active development. It remains the default, stable engine, and Grafana continues to add features to it. The two engines can evolve toward the same outcomes without requiring every feature to have an identical implementation.

Next steps

Requirements and expectations

Mon, 24 Aug 2026 14:24:42 +0000

Requirements and expectations

Before you put Grafana Alloy into production, it helps to have a clear picture of where it runs well, how it’s usually deployed, and where people most often get surprised.

Before a first deployment, people usually want answers to a few basic questions:

Will Alloy run in my environment?
How should I deploy it the first time?
What kinds of constraints or trade-offs should I expect?

The guidance here focuses on the common, supported paths that work well for most users, without diving into every possible edge case.

Design expectations

Grafana Alloy makes telemetry collection explicit and predictable, even when that means exposing trade-offs that other tools try to hide.

A few design choices are worth keeping in mind:

Alloy favors explicit configuration over implicit behavior. You define pipelines, routing, and scaling decisions in configuration rather than relying on automatic inference.
Alloy exposes deployment and scaling choices instead of masking them. Changes in topology—such as switching from a DaemonSet to a centralized deployment—can affect behavior, and those effects are intentional and visible.
Alloy consolidates multiple collectors, but it doesn’t replicate every default or assumption from these other collectors. Similar concepts may behave differently when the underlying goals differ.
Alloy prioritizes predictability over “magic” defaults. Understanding how components connect and how work distributes is part of operating Alloy successfully.

Keeping these expectations in mind makes it easier to reason about configuration changes, scaling decisions, and observed behavior in production.

Supported platforms

Alloy runs on the following platforms:

Linux
Windows
macOS
FreeBSD

For supported architectures and version requirements, refer to Supported platforms.

For setup instructions, refer to Set up Alloy.

Network requirements

Alloy requires network access for its HTTP server and for sending data to backends.

HTTP server

Alloy runs an HTTP server for its UI, API, and metrics endpoints. By default, it listens on 127.0.0.1:12345.

For more information, refer to HTTP endpoints.

Outbound connectivity

Alloy needs outbound network access to send telemetry to your backends. Ensure firewall rules and egress rules allow connections to:

Remote write or OTLP endpoints for metrics, such as Mimir, Prometheus, or Thanos
Log ingestion endpoints, such as Loki, Elasticsearch, or OTLP-compatible backends
Trace ingestion endpoints, such as Tempo, Jaeger, or OTLP-compatible backends
Profile ingestion endpoints, such as Pyroscope

Cluster communication

When you enable clustering, Alloy nodes communicate over HTTP/2 using the same HTTP server port. Each node must be reachable by other cluster members on the configured listen address.

Permissions and access

Some Alloy components interact closely with the host, container runtime, or Kubernetes APIs. When that happens, Alloy needs enough access to complete the work.

This requirement most often comes up when collecting:

Host-level metrics, logs, traces, or profiles
Container or runtime information
Data that lives outside the application sandbox

Not every component can run in a fully locked-down environment. When Alloy runs with restricted permissions, certain components might fail or behave unexpectedly.

For access and permissions on Kubernetes, refer to Access and permissions for Alloy on Kubernetes.

When you enable a component, check its documented requirements first. Refer to the component reference for component-specific constraints and limitations.

Security

Alloy supports TLS for secure communication. Configure TLS in component tls blocks for backend connections, or use the --cluster.enable-tls flag for clustered mode. Authentication methods such as basic auth, OAuth2, and bearer tokens are configured per component.

Secrets management

Store sensitive values like API keys and passwords outside your configuration files. Alloy supports environment variable references and integrations such as HashiCorp Vault, Kubernetes Secrets, AWS S3, and local files.

Refer to the component documentation for specific options.

Deployment patterns

Alloy supports edge, gateway, and hybrid deployment patterns. Refer to How Alloy works for guidance on choosing the right pattern for your architecture.

For detailed setup instructions, refer to Deploy Alloy.

Clustering and scaling behavior

Some Alloy behavior depends on how you deploy it, not just on configuration.

Alloy supports clustering to distribute work across multiple instances. Clustering uses a gossip protocol and consistent hashing to distribute scrape targets automatically.

Note
Target auto-distribution requires enabling clustering at both the instance level and the component level. Refer to Clustering for configuration details.

A few things that often surprise users:

More Alloy instances means more meta-monitoring metrics.
A switch between DaemonSet and centralized deployments can change observed series counts.
Scaling clustered collectors changes how targets distribute, even when the target list stays the same.

For resource planning guidance, refer to Estimate resource usage.

Data durability

Alloy uses a Write-Ahead Log (WAL) for metrics to handle temporary backend outages. The WAL buffers data locally and retries sending when the backend becomes available.

For the WAL to persist across restarts, configure persistent storage using the --storage.path flag.

Note
Without persistent storage, Alloy loses buffered data on restart. By default, Alloy stores data in a temporary directory.

Push-based pipelines for logs, traces, and profiles have different durability characteristics. Refer to component documentation for more information.

Monitor Alloy

Alloy exposes metrics about its own health and performance at the /metrics endpoint.

Key monitoring capabilities:

Internal metrics: Controller and component metrics in Prometheus format
Health endpoints: /-/ready and /-/healthy for load balancer checks
Debugging UI: Visual component graph and live debugging at /

Refer to Set up meta-monitoring for configuration examples.

Component capabilities

Each Alloy component has its own capabilities and limits. Before you rely on a component in production, check:

Which signal types it accepts and emits: metrics, logs, traces, and profiles
Whether the component is stable or still evolving
Whether it’s a native Alloy component or wraps upstream OpenTelemetry Collector functionality

Refer to the component reference for this information.

Troubleshoot issues

If something doesn’t behave as expected after deployment:

Review Troubleshooting and debugging.
Check the component documentation.
Revisit deployment patterns and clustering assumptions.

Introduction to Grafana Alloy on Grafana Labs

Why Grafana Alloy

Why Grafana Alloy

The telemetry collection challenge

When to use Alloy

You need multiple signal types

You want to reduce collector complexity

You need both Prometheus and OpenTelemetry

You value vendor neutrality

Your observability needs are growing

You’re running on Kubernetes

You want programmable pipelines

You want to share pipelines across teams

What Alloy replaces

When Alloy might not be the right choice

Next steps

How Grafana Alloy works

How Grafana Alloy works

Where Alloy fits

Collect telemetry data

Transform and process data

Send to backends

Component-based architecture

Programmable pipelines

Custom and shareable pipelines

Enterprise-ready features

Built-in debugging tools

Deployment patterns

Integrations

Next steps

How telemetry flows through Grafana Alloy

How telemetry flows through Grafana Alloy

Define every connection explicitly

Follow the pipeline stages

See how telemetry moves in a configuration

Next steps

OpenTelemetry in Alloy

OpenTelemetry in Alloy

Why the OTel Engine exists

How the engines fit together

Choose an engine

Use the OTel Engine for OpenTelemetry-native pipelines

Use the Default Engine for the full Alloy experience

Run both engines when you need both component sets

Manage the OTel Engine with Fleet Management

How the engines evolve

Next steps

Requirements and expectations

Requirements and expectations

Design expectations

Supported platforms

Network requirements

HTTP server

Outbound connectivity

Cluster communication

Permissions and access

Security

Secrets management

Deployment patterns

Clustering and scaling behavior

Data durability

Monitor Alloy

Component capabilities

Troubleshoot issues

Next steps