Monitor metrics and logs with Grafana Alloy on Grafana Labs

Monitor Docker containers with Grafana Alloy

Mon, 30 Mar 2026 15:47:22 +0000

Monitor Docker containers with Grafana Alloy

Docker containers provide statistics and logs. The docker stats and docker logs commands display metrics and logs in a terminal as a fixed snapshot. With Alloy, you can collect your metrics and logs, forward them to a Grafana stack, and create dashboards to monitor your Docker containers.

The alloy-scenarios repository contains complete examples of Alloy deployments. Clone the repository and use the examples to understand how Alloy collects, processes, and exports telemetry signals.

In this example scenario, Alloy collects Docker container metrics and logs and forwards them to a Loki destination.

Before you begin

Ensure you have the following:

Docker
Git

Note
You need administrator privileges to run docker commands.

Clone and deploy the example

Follow these steps to clone the repository and deploy the monitoring example:

Clone the Alloy scenarios repository:

git clone https://github.com/grafana/alloy-scenarios.git

Start Docker to deploy the Grafana stack:
shell
```
cd alloy-scenarios/docker-monitoring
docker compose up -d
```
Verify the status of the Docker containers:
shell
```
docker ps
```
(Optional) Stop Docker to shut down the Grafana stack when you finish exploring this example:
shell
```
docker compose down
```

Monitor and visualize your data

Use Grafana to monitor deployment health and visualize data.

Monitor Alloy

To monitor the health of your Alloy deployment, open your browser and go to http://localhost:12345.

For more information about the Alloy UI, refer to Debug Grafana Alloy.

Visualize your data

To explore metrics, open your browser and go to http://localhost:3000/explore/metrics.

To use the Grafana Logs Drilldown, open your browser and go to http://localhost:3000/a/grafana-lokiexplore-app.

To create a dashboard for visualizing metrics and logs, open your browser and go to http://localhost:3000/dashboards.

Understand the Alloy configuration

This example uses a config.alloy file to configure Alloy components for metrics and logging. You can find this file in the cloned repository at alloy-scenarios/docker-monitoring/.

Configure metrics

The metrics configuration in this example requires three components:

prometheus.exporter.cadvisor
prometheus.scrape
prometheus.remote_write

`prometheus.exporter.cadvisor`

The prometheus.exporter.cadvisor component exposes Docker container metrics. In this example, the component requires the following arguments:

docker_host: Defines the Docker endpoint.
storage_duration: Sets the time data is stored in memory.

This component provides the prometheus.exporter.cadvisor.example.targets target for prometheus.scrape.

prometheus.exporter.cadvisor "example" {
  docker_host = "unix:///var/run/docker.sock"

  storage_duration = "5m"
}

`prometheus.scrape`

The prometheus.scrape component scrapes cAdvisor metrics and forwards them to a receiver. In this example, the component requires the following arguments:

targets: The target to scrape metrics from.
forward_to: The destination to forward metrics to.
scrape_interval: The frequency of scraping the target.

prometheus.scrape "scraper" {
  targets    = prometheus.exporter.cadvisor.example.targets
  forward_to = [ prometheus.remote_write.demo.receiver ]

  scrape_interval = "10s"
}

`prometheus.remote_write`

The prometheus.remote_write component sends metrics to a Prometheus server. In this example, the component requires the following argument:

url: Defines the full URL endpoint to send metrics to.

This component provides the prometheus.remote_write.demo.receiver destination for prometheus.scrape.

prometheus.remote_write "demo" {
  endpoint {
    url = "http://prometheus:9090/api/v1/write"
  }
}

Configure logging

The logging configuration in this example requires four components:

discovery.docker
discovery.relabel
loki.source.docker
loki.write

`discovery.docker`

The discovery.docker component discovers Docker containers and extracts metadata. In this example, the component requires the following argument:

host: Defines the address of the Docker daemon.

discovery.docker "linux" {
  host = "unix:///var/run/docker.sock"
}

`discovery.relabel`

The discovery.relabel component defines a relabeling rule to create a service name from the container name. In this example, the component requires the following arguments:

targets: The targets to relabel. In this example, the discovery.relabel component is used only for its exported relabel_rules in the loki.source.docker component. No targets are modified, so the targets argument is an empty array.
source_labels: The list of labels to select for relabeling.
regex: A regular expression that matches any string after /. Docker container names often appear with a leading slash (/) in Prometheus automatic discovery labels. This expression keeps the container name.
target_label: The label written to the target.

discovery.relabel "logs_integrations_docker" {
  targets = []

  rule {
    source_labels = ["__meta_docker_container_name"]
    regex = "/(.*)"
    target_label = "service_name"
  }
}

`loki.source.docker`

The loki.source.docker component collects logs from Docker containers. In this example, the component requires the following arguments:

host: The address of the Docker daemon.
targets: The list of containers to read logs from.
labels: The default set of labels to apply to entries.
relabel_rules: The relabeling rules to apply to log entries.
forward_to: The list of receivers to send log entries to.

loki.source.docker "default" {
  host       = "unix:///var/run/docker.sock"
  targets    = discovery.docker.linux.targets
  labels     = {"platform" = "docker"}
  relabel_rules = discovery.relabel.logs_integrations_docker.rules
  forward_to = [loki.write.local.receiver]
}

`loki.write`

The loki.write component writes logs to a Loki destination. In this example, the component requires the following argument:

url: Defines the full URL endpoint in Loki to send logs to.

loki.write "local" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }
}

Monitor Linux servers with Grafana Alloy

Mon, 30 Mar 2026 15:47:22 +0000

Monitor Linux servers with Grafana Alloy

The Linux operating system generates a wide range of metrics and logs that you can use to monitor the health and performance of your hardware and operating system. With Alloy, you can collect your metrics and logs, forward them to a Grafana stack, and create dashboards to monitor your Linux servers.

This scenario demonstrates how to use Alloy to monitor Linux system metrics and logs using a complete example configuration. You’ll deploy a containerized monitoring stack that includes Alloy, Prometheus, Loki, and Grafana.

The alloy-scenarios repository contains complete examples of Alloy deployments. Clone the repository and use the examples to understand how Alloy collects, processes, and exports telemetry signals.

Before you begin

Before you begin, ensure you have the following:

Docker and Docker Compose installed
Git for cloning the repository
A Linux host or Linux running in a virtual machine
Administrator privileges to run Docker commands
Available ports: 3000 (Grafana), 9090 (Prometheus), 3100 (Loki), and 12345 (Alloy UI)

Clone and deploy the scenario

This scenario runs Alloy in a container alongside Grafana, Prometheus, and Loki, creating a self-contained monitoring stack. The Alloy container acts as a demonstration system to show monitoring capabilities.

In a production environment, you would typically install Alloy directly on each Linux server you want to monitor.

Follow these steps to clone the repository and deploy the monitoring scenario:

Clone the Alloy scenarios repository:

git clone https://github.com/grafana/alloy-scenarios.git

Start Docker to deploy the Grafana stack:
shell
```
cd alloy-scenarios/linux
docker compose up -d
```
Verify the status of the Docker containers:
shell
```
docker ps
```
(Optional) Stop Docker to shut down the Grafana stack when you finish exploring this scenario:
shell
```
docker compose down
```

Monitor and visualize your data

After deploying the monitoring stack, you can use the Alloy UI to monitor deployment health and Grafana to visualize your collected data.

Monitor Alloy

To monitor the health of your Alloy deployment, open your browser and go to http://localhost:12345.

For more information about the Alloy UI, refer to Debug Grafana Alloy.

Visualize your data

To explore metrics, open your browser and go to http://localhost:3000/explore/metrics.

To use the Grafana Logs Drilldown, open your browser and go to http://localhost:3000/a/grafana-lokiexplore-app.

To create a dashboard for visualizing metrics and logs:

Open your browser and go to http://localhost:3000/dashboards.
Download the JSON file for the preconfigured Linux node dashboard.
Go to Dashboards > Import.
Upload the JSON file.
Select the Prometheus data source and click Import.

This community dashboard provides comprehensive system metrics including CPU, memory, disk, and network usage.

Understand the Alloy configuration

This scenario uses a config.alloy file to configure Alloy components for metrics and logging. You can find this file in the cloned repository at alloy-scenarios/linux/. The configuration demonstrates how to collect Linux system metrics and logs, then forward them to Prometheus and Loki for storage and visualization.

Configure metrics

The metrics configuration in this scenario requires four components that work together to collect, process, and forward system metrics. The components are configured in this order to create a data pipeline:

prometheus.exporter.unix - collects system metrics
discovery.relabel - adds standard labels to metrics
prometheus.scrape - scrapes metrics from the exporter
prometheus.remote_write - sends metrics to Prometheus for storage

`prometheus.exporter.unix`

The prometheus.exporter.unix component exposes hardware and Linux kernel metrics. This component is the primary data source that collects system performance metrics from your Linux server.

The component configuration includes several important sections:

disable_collectors: Disables specific collectors to reduce unnecessary overhead
enable_collectors: Enables the meminfo collector for memory information
filesystem: Configures filesystem monitoring options
netclass and netdev: Configure network interface monitoring

prometheus.exporter.unix "integrations_node_exporter" {
  disable_collectors = ["ipvs", "btrfs", "infiniband", "xfs", "zfs"]
  enable_collectors = ["meminfo"]

  filesystem {
    fs_types_exclude     = "^(autofs|binfmt_misc|bpf|cgroup2?|configfs|debugfs|devpts|devtmpfs|tmpfs|fusectl|hugetlbfs|iso9660|mqueue|nsfs|overlay|proc|procfs|pstore|rpc_pipefs|securityfs|selinuxfs|squashfs|sysfs|tracefs)$"
    mount_points_exclude = "^/(dev|proc|run/credentials/.+|sys|var/lib/docker/.+)($|/)"
    mount_timeout        = "5s"
  }

  netclass {
    ignored_devices = "^(veth.*|cali.*|[a-f0-9]{15})$"
  }

  netdev {
    device_exclude = "^(veth.*|cali.*|[a-f0-9]{15})$"
  }
}

This component provides the prometheus.exporter.unix.integrations_node_exporter.targets output that feeds into the discovery.relabel component.

`discovery.relabel` instance and job labels

The first discovery.relabel component in this configuration replaces the instance and job labels from the node_exporter with standardized values. This ensures consistent labeling across all metrics for easier querying and dashboard creation.

In this example, this component requires the following arguments:

targets: The targets to relabel.
source_labels: The list of labels to select for relabeling. The rules extract the instance and job labels.
replacement: The value that replaces the source label. The rules set the target labels to constants.hostname, and integrations/node_exporter.

discovery.relabel "integrations_node_exporter" {
  targets = prometheus.exporter.unix.integrations_node_exporter.targets

  rule {
    target_label = "instance"
    replacement  = constants.hostname
  }

  rule {
    target_label = "job"
    replacement = "integrations/node_exporter"
  }
}

This component provides the discovery.relabel.integrations_node_exporter.output target list that feeds into the prometheus.scrape component.

`discovery.relabel` for systemd journal logs

This discovery.relabel component defines the relabeling rules for the systemd journal logs. In this example, this component requires the following arguments:

targets: The targets to relabel. No targets are modified, so the targets argument is an empty array.
source_labels: The list of labels to select for relabeling. The rules extract the systemd unit, ID, transport, and log priority.
target_label: The label written to the target. The rules set the target labels to unit, boot_id, transport, and level.

discovery.relabel "logs_integrations_integrations_node_exporter_journal_scrape" {
  targets = []

  rule {
    source_labels = ["__journal__systemd_unit"]
    target_label  = "unit"
  }

  rule {
    source_labels = ["__journal__boot_id"]
    target_label  = "boot_id"
  }

  rule {
    source_labels = ["__journal__transport"]
    target_label  = "transport"
  }

  rule {
    source_labels = ["__journal_priority_keyword"]
    target_label  = "level"
  }
}

This component provides the discovery.relabel.logs_integrations_integrations_node_exporter_journal_scrape.rules relabeling rules that feed into the loki.source.journal component.

`prometheus.scrape`

The prometheus.scrape component scrapes node_exporter metrics and forwards them to a receiver. This component consumes the labeled targets from the discovery.relabel.integrations_node_exporter.output.

In this example, the component requires the following arguments:

targets: The target to scrape metrics from. Use the targets with labels from the discovery.relabel component.
forward_to: The destination to forward metrics to. Send the scraped metrics to the relabeling component.
scrape_interval: The frequency of scraping the target.

prometheus.scrape "integrations_node_exporter" {
  scrape_interval = "15s"
  targets    = discovery.relabel.integrations_node_exporter.output
  forward_to = [prometheus.remote_write.local.receiver]
}

This component provides scraped metrics that feed into the prometheus.remote_write.local.receiver for storage in Prometheus.

`prometheus.remote_write`

The prometheus.remote_write component sends metrics to a Prometheus server. In this example, the component requires the following argument:

url: Defines the full URL endpoint to send metrics to.

prometheus.remote_write "local" {
  endpoint {
    url = "http://prometheus:9090/api/v1/write"
  }
}

This component provides the prometheus.remote_write.local.receiver destination that receives metrics from the prometheus.scrape component.

Configure logging

The logging configuration in this scenario collects logs from both systemd journal and standard log files. This dual approach ensures comprehensive log coverage for most Linux systems. The configuration requires four main components that work together to discover, collect, and forward logs to Loki:

loki.source.journal - collects logs from systemd journal
local.file_match - discovers standard log files using glob patterns
loki.source.file - reads logs from discovered files
loki.write - sends all collected logs to Loki for storage

`loki.source.journal`

The loki.source.journal component collects logs from the systemd journal and forwards them to a Loki receiver. This component consumes the relabeling rules from discovery.relabel.logs_integrations_integrations_node_exporter_journal_scrape.rules.

In this example, the component requires the following arguments:

max_age: Only collect logs from the last 24 hours.
relabel_rules: Relabeling rules to apply on log entries.
forward_to: Send logs to the local Loki instance.

loki.source.journal "logs_integrations_integrations_node_exporter_journal_scrape" {
  max_age       = "24h0m0s"
  relabel_rules = discovery.relabel.logs_integrations_integrations_node_exporter_journal_scrape.rules
  forward_to    = [loki.write.local.receiver]
}

This component provides systemd journal log entries that feed into the loki.write.local.receiver for storage in Loki.

`local.file_match`

The local.file_match component discovers files on the local filesystem using glob patterns. In this example, the component requires the following arguments:

path_targets: Targets to expand:
- __address__: Targets the localhost for log collection.
- __path__: Collect standard system logs.
- instance: Add an instance label with hostname.
- job: Add a job label for logs.

local.file_match "logs_integrations_integrations_node_exporter_direct_scrape" {
  path_targets = [{
    __address__ = "localhost",
    __path__    = "/var/log/{syslog,messages,*.log}",
    instance    = constants.hostname,
    job         = "integrations/node_exporter",
  }]
}

This component provides the local.file_match.logs_integrations_integrations_node_exporter_direct_scrape.targets file list that feeds into the loki.source.file component.

`loki.source.file`

The loki.source.file component reads log entries from files and forwards them to other Loki components. This component consumes the file targets from local.file_match.logs_integrations_integrations_node_exporter_direct_scrape.targets.

In this example, the component requires the following arguments:

targets: The list of files to read logs from.
forward_to: The list of receivers to send log entries to.

loki.source.file "logs_integrations_integrations_node_exporter_direct_scrape" {
  targets    = local.file_match.logs_integrations_integrations_node_exporter_direct_scrape.targets
  forward_to = [loki.write.local.receiver]
}

This component provides file-based log entries that feed into the loki.write.local.receiver for storage in Loki.

`loki.write`

The loki.write component writes logs to a Loki destination. In this example, the component requires the following argument:

url: Defines the full URL endpoint in Loki to send logs to.

loki.write "local" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }
}

This component provides the loki.write.local.receiver destination that receives log entries from both loki.source.journal and loki.source.file components.

Configure `livedebugging`

The livedebugging feature streams real-time data from your components directly to the Alloy UI. This capability helps you troubleshoot configuration issues and monitor component behavior in real-time.

`livedebugging`

livedebugging is disabled by default. Enable it explicitly through the livedebugging configuration block to make debugging data visible in the Alloy UI. You can use an empty configuration for this block and Alloy uses the default values.

livedebugging{}

For more information about using this feature for troubleshooting, refer to the Troubleshooting documentation.

Next steps

Now that you’ve successfully deployed and configured Alloy to monitor Linux systems, you can:

For additional examples and configurations, refer to the alloy-scenarios repository.

Monitor Microsoft Windows servers and desktops with Grafana Alloy

Mon, 30 Mar 2026 15:47:22 +0000

Monitor Microsoft Windows servers and desktops with Grafana Alloy

Microsoft Windows provides tools like Performance Monitor and Event Viewer to track system performance metrics and event logs. With Alloy, you can collect your performance metrics and event logs, forward them to a Grafana stack, and create dashboards to monitor your Windows performance and events.

The alloy-scenarios repository contains complete examples of Alloy deployments. Clone the repository and use the examples to understand how Alloy collects, processes, and exports telemetry signals.

In this example scenario, Alloy collects Windows performance metrics and event logs and forwards them to a Loki destination.

Before you begin

Ensure you have the following:

Docker
Git
A Windows Server or Desktop. This scenario monitors a computer running Windows.
Windows administrator access. You need administrator access to install Alloy and configure it to collect metrics and logs.

Note
You need administrator privileges to run docker commands.

Clone and deploy the example

Follow these steps to clone the scenarios repository and deploy the monitoring example:

Clone the Alloy scenarios repository.

git clone https://github.com/grafana/alloy-scenarios.git

Start Docker to deploy the Grafana stack.
shell
```
cd alloy-scenarios/windows
docker compose up -d
```
Verify the status of the Docker containers:
shell
```
docker ps
```
Install Alloy on Windows.
Replace the default config.alloy file with the preconfigured config.alloy file included in the alloy-scenarios/windows directory. For detailed steps explaining how to stop and start the Alloy service, refer to Configure Alloy on Windows.
1. Stop the Alloy service.
2. Replace the config.alloy file in C:\Program Files\GrafanaLabs\Alloy with the config.alloy file from the alloy-scenarios/windows directory.
3. Start the Alloy service.
(Optional) To access the Alloy UI from a remote computer, add --server.http.listen-addr=0.0.0.0:12345 to the Alloy runtime arguments. For detailed steps explaining how to update this command-line argument, refer to Expose the UI to other machines. This step makes the Alloy UI available at http://<WINDOWS_IP_ADDRESS>:12345.
(Optional) Stop Docker to shut down the Grafana stack when you finish exploring this example.
shell
```
docker compose down
```

Monitor and visualize your data

Use Grafana to monitor your deployment’s health and visualize your data.

Monitor Alloy

To monitor the health of your Alloy deployment, open your browser and go to http://localhost:12345.

For more information about the Alloy UI, refer to Debug Grafana Alloy.

Visualize your data

To explore metrics, open your browser and go to http://localhost:3000/explore/metrics.

To use the Grafana Logs Drilldown, open your browser and go to http://localhost:3000/a/grafana-lokiexplore-app.

To create a dashboard to visualize metrics and logs, open your browser and go to http://localhost:3000/dashboards.

Understand the Alloy configuration

This example uses a config.alloy file to configure the Alloy components for metrics and logging. You can find the config.alloy file in the cloned repository at alloy-scenarios/windows/.

The configuration includes livedebugging to stream real-time data to the Alloy UI.

Configure metrics

The metrics configuration in this example requires three components:

prometheus.exporter.windows
prometheus.scrape
prometheus.remote_write

`prometheus.exporter.windows`

The prometheus.exporter.windows component exposes hardware and OS metrics for Windows-based systems. In this example, the component requires the following arguments:

enabled_collectors: The list of collectors to enable.

prometheus.exporter.windows "default" {
  enabled_collectors = ["cpu","cs","logical_disk","net","os","service","system", "memory", "scheduled_task", "tcp"]
}

`prometheus.scrape`

The prometheus.scrape component scrapes Windows metrics and forwards them to a receiver. In this example, the component requires the following arguments:

targets: The target to scrape metrics from.
forward_to: The destination to forward metrics to.

prometheus.scrape "example" {
  targets    = prometheus.exporter.windows.default.targets
  forward_to = [prometheus.remote_write.demo.receiver]
}

`prometheus.remote_write`

The prometheus.remote_write component sends metrics to a Prometheus server. In this example, the component requires the following argument:

url: Defines the full URL endpoint to send metrics to.

prometheus.remote_write "demo" {
  endpoint {
    url = "http://localhost:9090/api/v1/write"
  }
}

Configure logging

The logging configuration in this example requires three components:

loki.source.windowsevent
loki.process
loki.write

`loki.source.windowsevent`

The loki.source.windowsevent component reads events from Windows Event Logs and forwards them to other Loki components. In this example, the component requires the following arguments:

eventlog_name: The event log to read from.
use_incoming_timestamp: Assigns the current timestamp to the log.
forward_to: The list of receivers to send log entries to.

loki.source.windowsevent "application"  {
    eventlog_name = "Application"
    use_incoming_timestamp = true
    forward_to = [loki.process.endpoint.receiver]
}

loki.source.windowsevent "System"  {
    eventlog_name = "System"
    use_incoming_timestamp = true
    forward_to = [loki.process.endpoint.receiver]
}

`loki.process`

The loki.process component receives log entries from other Loki components, applies one or more processing stages, and forwards the results to the list of receivers. In this example, the component requires the following arguments:

forward_to: The list of receivers to send log entries to.
expressions: The key-value pairs that define the name of the data extracted and the value that it’s populated with.
values: The key-value pairs that define the label to set and how to look them up.
source: Name from extracted values map to use for the timestamp.
overwrite_existing: Overwrite the existing extracted data fields.

loki.process "endpoint" {
  forward_to = [loki.write.endpoint.receiver]
  stage.json {
      expressions = {
          message = "",
          Overwritten = "",
          source = "",
          computer = "",
          eventRecordID = "",
          channel = "",
          component_id = "",
          execution_processId = "",
          execution_processName = "",
      }
  }

  stage.structured_metadata {
      values = {
          "eventRecordID" = "",
          "channel" = "",
          "component_id" = "",
          "execution_processId" = "",
          "execution_processName" = "",
      }
  }

  stage.eventlogmessage {
      source = "message"
      overwrite_existing = true
  }

  stage.labels {
      values = {
          "service_name" = "source",
      }
  }

  stage.output {
    source = "message"
  }

}

`loki.write`

The loki.write component writes the logs out to a Loki destination. In this example, the component requires the following argument:

url: Defines the full URL endpoint in Loki to send logs to.

loki.write "endpoint" {
    endpoint {
        url ="http://localhost:3100/loki/api/v1/push"
    }
}

Configure `livedebugging`

Livedebugging streams real-time data from components directly to the Alloy UI. Refer to the Troubleshooting documentation for more details about this feature.

`livedebugging`

livedebugging is disabled by default. Enable it explicitly through the livedebugging configuration block to make debugging data visible in the Alloy UI.

livedebugging {
  enabled = true
}

Monitor logs from a local file with Grafana Alloy

Mon, 30 Mar 2026 15:47:22 +0000

Monitor logs from a local file with Grafana Alloy

Log files record events, activities, and usage patterns within a system, application, or network. These files are essential for monitoring, troubleshooting, and understanding system behavior. With Alloy, you can collect your logs, forward them to a Grafana stack, and create dashboards to monitor your system behavior.

The alloy-scenarios repository contains complete examples of Alloy deployments. Clone the repository and use the examples to understand how Alloy collects, processes, and exports telemetry signals.

In this example scenario, Alloy collects logs from a local file and forwards them to a Loki destination.

Before you begin

Ensure you have the following:

Docker
Git

Note
You need administrator privileges to run docker commands.

Clone and deploy the example

Follow these steps to clone the scenarios repository and deploy the monitoring example:

Clone the Alloy scenarios repository.

git clone https://github.com/grafana/alloy-scenarios.git

Start Docker to deploy the Grafana stack.
shell
```
cd alloy-scenarios/logs-file
docker compose up -d
```
Verify the status of the Docker containers:
shell
```
docker ps
```
(Optional) Stop Docker to shut down the Grafana stack when you finish exploring this example.
shell
```
docker compose down
```

Monitor and visualize your data

Use Grafana to monitor your deployment’s health and visualize your data.

Monitor Alloy

To monitor the health of your Alloy deployment, open your browser and go to http://localhost:12345.

For more information about the Alloy UI, refer to Debug Grafana Alloy.

Visualize your data

To use the Grafana Logs Drilldown, open your browser and go to http://localhost:3000/a/grafana-lokiexplore-app.

To create a dashboard for visualizing metrics and logs, open your browser and go to http://localhost:3000/dashboards.

Understand the Alloy configuration

This example uses a config.alloy file to configure the Alloy components for logging. You can find this file in the cloned repository at alloy-scenarios/logs-file/.

The configuration includes livedebugging to stream real-time data to the Alloy UI.

Configure `livedebugging`

livedebugging streams real-time data from your components directly to the Alloy UI. Refer to the Troubleshooting documentation for more details about this feature.

`livedebugging`

By default, livedebugging is disabled. Enable it explicitly through the livedebugging configuration block to make debugging data visible in the Alloy UI.

livedebugging {
  enabled = true
}

Configure logging

The logging configuration in this example requires three components:

local.file_match
loki.source.file
loki.write

`local.file_match`

The local.file_match component discovers files on the local filesystem using glob patterns. In this example, the component requires the following arguments:

path_targets: Targets to expand. Looks for glob patterns on the __path__ key.
sync_period: How often to sync the filesystem and targets. When files are added or removed, the list of targets is automatically updated based on this configuration. When files are removed, the stored position is removed in the next filesystem sync.

local.file_match "local_files" {
    path_targets = [{"__path__" = "/temp/logs/*.log", "job" = "python", "hostname" = constants.hostname}]
    sync_period  = "5s"
}

`loki.source.file`

The loki.source.file component reads log entries from files and forwards them to other Loki components. In this example, the component requires the following arguments:

targets: The list of files to read logs from.
forward_to: The list of receivers to send log entries to.
tail_from_end: Whether a log file is tailed from the end if a stored position isn’t found.

loki.source.file "log_scrape" {
    targets    = local.file_match.local_files.targets
    forward_to = [loki.write.local.receiver]
    tail_from_end = true
}

`loki.write`

The loki.write component writes logs to a Loki destination. In this example, the component requires the following argument:

url: Defines the full URL endpoint in Loki to send logs to.

loki.write "local" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }
}

Monitor TCP logs with Grafana Alloy

Mon, 30 Mar 2026 15:47:22 +0000

Monitor TCP logs with Grafana Alloy

Writing logs over a network using raw TCP is a widely used method for transmitting log data between systems. This method provides a direct, connection-oriented way to send logs from a client, such as an application or logging agent, to a remote server, such as a log aggregator or central logging system. With Alloy, you can collect your logs, forward them to a Grafana stack, and create dashboards to monitor your system behavior.

The alloy-scenarios repository contains complete working examples of Alloy deployments. Clone the repository and use the example deployments to understand how Alloy collects, processes, and exports telemetry signals.

In this example scenario, Alloy uses a TCP endpoint to collect logs written by an application as a JSON payload and forwards them to a Loki destination.

Before you begin

Ensure you have the following:

Docker
Git

Note
You need administrator privileges to run docker commands.

Clone and deploy the example

Follow these steps to clone the scenarios repository and deploy the monitoring example:

Clone the Alloy scenarios repository:

git clone https://github.com/grafana/alloy-scenarios.git

Start Docker to deploy the Grafana stack:
shell
```
cd alloy-scenarios/logs-tcp
docker compose up -d
```
Verify the status of the Docker containers:
shell
```
docker ps
```
(Optional) Stop Docker to shut down the Grafana stack when you finish exploring this example:
shell
```
docker compose down
```

Monitor and visualize your data

Use Grafana to monitor your deployment’s health and visualize your data.

Monitor Alloy

To monitor the health of your Alloy deployment, open your browser and go to http://localhost:12345.

For more information about the Alloy UI, refer to Debug Grafana Alloy.

Visualize your data

To use the Grafana Logs Drilldown, open your browser and go to http://localhost:3000/a/grafana-lokiexplore-app.

To create a dashboard to visualize your metrics and logs, open your browser and go to http://localhost:3000/dashboards.

Understand the Alloy configuration

This example uses a config.alloy file to configure the Alloy components for logging. You can find the config.alloy file in the cloned repository at alloy-scenarios/logs-tcp/.

The configuration includes livedebugging to stream real-time data to the Alloy UI.

Configure `livedebugging`

livedebugging streams real-time data from your components directly to the Alloy UI. Refer to the Troubleshooting documentation for more details about this feature.

`livedebugging`

livedebugging is disabled by default. Enable it explicitly through the livedebugging configuration block to make debugging data visible in the Alloy UI.

livedebugging {
  enabled = true
}

Configure logging

The logging configuration in this example requires three components:

loki.source.api
loki.process
loki-write

`loki.source.api`

The loki.source.api component receives log entries over HTTP and forwards them to other Loki components. In this example, the component requires the following arguments:

listen_address: The network address the server listens to for new connections. Setting this argument to 0.0.0.0 tells the server to listen on all IP addresses.
listen_port: The port the server listens to for new connections.
forward_to: The list of receivers to send log entries to.

loki.source.api "loki_push_api" {
    http {
        listen_address = "0.0.0.0"
        listen_port = 9999
    }
    forward_to = [
        loki.process.labels.receiver,
    ]
}

`loki.process`

The loki.process component receives log entries from other Loki components, applies processing stages, and forwards the results to the list of receivers. In this example, the component requires the following arguments:

expressions: Key-value pairs defining the name of the data extracted and the value it’s populated with.
values: Key-value pairs defining the label to set and how to look them up.
forward_to: The list of receivers to send log entries to.

loki.process "labels" {
    stage.json {
      expressions = { "extracted_service" = "service_name", 
                      "extracted_code_line" = "code_line", 
                      "extracted_server" = "server_id", 
                    }
    }

  stage.labels {
    values = {
      "service_name" = "extracted_service",
    }
  }

  stage.structured_metadata {
    values = {
      "code_line" = "extracted_code_line",
      "server" = "extracted_server",
      }
    }

  forward_to = [loki.write.local.receiver]
}

`loki-write`

The loki.write component writes the logs to a Loki destination. In this example, the component requires the following argument:

url: Defines the full URL endpoint in Loki to send logs to.

loki.write "local" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }
}

Monitor RFC5424-compliant syslog messages with Grafana Alloy

Mon, 30 Mar 2026 15:47:22 +0000

Monitor RFC5424-compliant syslog messages with Grafana Alloy

RFC5424-compliant syslog messages follow a well-defined, standardized structure for logging. These logs include fields such as priority, timestamp, hostname, application name, process ID, message ID, structured data, and the actual message. With Alloy, you can collect your logs, forward them to a Grafana stack, and create dashboards to monitor your system behavior.

The alloy-scenarios repository contains complete examples of Alloy deployments. Clone the repository and use the examples to understand how Alloy collects, processes, and exports telemetry signals.

In this example scenario, Alloy listens for syslog messages over TCP or UDP connections and forwards them to a Loki destination.

Before you begin

Ensure you have the following:

Docker
Git

Note
You need administrator privileges to run docker commands.

Clone and deploy the example

Follow these steps to clone the scenarios repository and deploy the monitoring example:

Clone the Alloy scenarios repository.

git clone https://github.com/grafana/alloy-scenarios.git

Start Docker to deploy the Grafana stack.
shell
```
cd alloy-scenarios/syslog
docker compose up -d
```
Verify the status of the Docker containers:
shell
```
docker ps
```
(Optional) Stop Docker to shut down the Grafana stack when you finish exploring this example.
shell
```
docker compose down
```

Monitor and visualize your data

Use Grafana to monitor your deployment’s health and visualize your data.

Monitor Alloy

To monitor the health of your Alloy deployment, open your browser and go to http://localhost:12345.

For more information about the Alloy UI, refer to Debug Grafana Alloy.

Visualize your data

To use the Grafana Logs Drilldown, open your browser and go to http://localhost:3000/a/grafana-lokiexplore-app.

To create a dashboard to visualize metrics and logs, open your browser and go to http://localhost:3000/dashboards.

Understand the Alloy configuration

This example uses a config.alloy file to configure Alloy components for logging. You can find the config.alloy file in the cloned repository at alloy-scenarios/syslog/.

The configuration includes livedebugging to stream real-time data to the Alloy UI.

Configure `livedebugging`

Livedebugging streams real-time data from components directly to the Alloy UI. Refer to the Troubleshooting documentation for more details about this feature.

`livedebugging`

livedebugging is disabled by default. Enable it explicitly through the livedebugging configuration block to make debugging data visible in the Alloy UI.

livedebugging {
  enabled = true
}

Configure logging

The logging configuration in this example requires two components:

loki.source.syslog
loki.write

`loki.source.syslog`

The loki.source.syslog component listens for syslog messages over TCP or UDP connections and forwards them to other Loki components. In this example, the component requires the following arguments:

address: The host and port address to listen to for syslog messages.
protocol: The protocol to listen to for syslog messages. The default is TCP.
labels: The labels to associate with each received syslog record.
forward_to: The list of receivers to send log entries to.

loki.source.syslog "local" {
  listener {
    address  = "0.0.0.0:51893"
    labels   = { component = "loki.source.syslog", protocol = "tcp" }
  }

  listener {
    address  = "0.0.0.0:51898"
    protocol = "udp"
    labels   = { component = "loki.source.syslog", protocol = "udp" }
  }

  forward_to = [loki.write.local.receiver]
}

`loki.write`

The loki.write component writes logs to a Loki destination. In this example, the component requires the following arguments:

url: Defines the full URL endpoint in Loki to send logs to.

loki.write "local" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }
}

Monitor structured logs with Grafana Alloy

Mon, 30 Mar 2026 15:47:22 +0000

Monitor structured logs with Grafana Alloy

Structured logs use a consistent format, such as JSON, to organize data into key-value pairs. This format makes it easier to search, filter, and analyze log data. With Alloy, you can collect your logs, forward them to a Grafana stack, and create dashboards to monitor your system behavior.

The alloy-scenarios repository contains complete examples of Alloy deployments. Clone the repository and use the examples to understand how Alloy collects, processes, and exports telemetry signals.

In this example scenario, Alloy collects log entries over HTTP, parses them into labels and structured metadata, and forwards the results to a Loki destination.

Before you begin

Ensure you have the following:

Docker
Git

Note
You need administrator privileges to run docker commands.

Clone and deploy the example

Follow these steps to clone the scenarios repository and deploy the monitoring example:

Clone the Alloy scenarios repository:

git clone https://github.com/grafana/alloy-scenarios.git

Start Docker to deploy the Grafana stack:
shell
```
cd alloy-scenarios/mail-house
docker compose up -d
```
Verify the status of the Docker containers:
shell
```
docker ps
```
(Optional) Stop Docker to shut down the Grafana stack when you finish exploring this example:
shell
```
docker compose down
```

Monitor and visualize your data

Use Grafana to monitor your deployment’s health and visualize your data.

Monitor Alloy

To monitor the health of your Alloy deployment, open your browser and go to http://localhost:12345.

For more information about the Alloy UI, refer to Debug Grafana Alloy.

Visualize your data

To use the Grafana Logs Drilldown, open your browser and go to http://localhost:3000/a/grafana-lokiexplore-app.

To create a dashboard to visualize your metrics and logs, open your browser and go to http://localhost:3000/dashboards.

Understand the Alloy configuration

This example uses a config.alloy file to configure the Alloy components for logging. You can find the config.alloy file in the cloned repository at alloy-scenarios/mail-house/.

The configuration includes livedebugging to stream real-time data to the Alloy UI.

Configure `livedebugging`

livedebugging streams real-time data from your components directly to the Alloy UI. Refer to the Troubleshooting documentation for more details about this feature.

`livedebugging`

livedebugging is disabled by default. Enable it explicitly through the livedebugging configuration block to make debugging data visible in the Alloy UI.

livedebugging {
  enabled = true
}

Configure logging

The logging configuration in this example requires three components:

loki.source.api
loki.process
loki.write

`loki.source.api`

The loki.source.api component receives log entries over HTTP and forwards them to other Loki components. In this example, the component requires the following arguments:

listen_address: The network address the server listens to for new connections. Setting this argument to 0.0.0.0 tells the server to listen on all IP addresses.
listen_port: The port the server listens to for new connections.
forward_to: The list of receivers to send log entries to.

loki.source.api "loki_push_api" {
    http {
        listen_address = "0.0.0.0"
        listen_port = 9999
    }
    forward_to = [
        loki.process.labels.receiver,
    ]
}

`loki.process`

expressions: Key-value pairs defining the name of the data extracted and the value it’s populated with.
source: Name from extracted values map to use for the timestamp.
format: Determines how to parse the source string.
values: Key-value pairs defining the label to set and how to look them up.
forward_to: The list of receivers to send log entries to.

loki.process "labels" {
    stage.json {
      expressions = { 
                      "timestamp" = "",
                      "state" = "", 
                      "package_size" = "", 
                      "package_status" = "", 
                      "package_id" = "",
                    }
    }

  stage.timestamp {
    source = "timestamp"
    format = "RFC3339"
  }

  stage.labels {
    values = {
      "state" = "",
      "package_size" = "",
    }
  }

  stage.structured_metadata {
    values = {
      "package_status" = "",
      "package_id" = "",
    }
  }

  stage.static_labels {
    values = {
      "service_name" = "Delivery World",
    }
  }

  stage.output {
    source = "message"
  }

  forward_to = [loki.write.local.receiver]
}

`loki.write`

The loki.write component writes logs to a Loki destination. In this example, the component requires the following argument:

url: Defines the full URL endpoint in Loki to send logs to.

loki.write "local" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }
}

Monitor Kubernetes logs with Grafana Alloy

Mon, 30 Mar 2026 15:47:22 +0000

Monitor Kubernetes logs with Grafana Alloy

Kubernetes captures logs from each container in a running Pod.
With Alloy, you can collect Kubernetes logs, forward them to a Grafana stack, and create dashboards to monitor your Kubernetes Deployment.

The alloy-scenarios repository contains complete examples of Alloy deployments.
Clone the repository and use the examples to understand how Alloy collects, processes, and exports telemetry signals.

This example scenario uses a Kubernetes Monitoring Helm chart to deploy and monitor Kubernetes logs.
It installs three Helm charts: Loki, Grafana, and Alloy.
The Helm chart simplifies configuration and deploys best practices for monitoring Kubernetes clusters.

Alloy, installed with k8s-monitoring-helm, collects two log sources: Pod Logs and Kubernetes Events.

Before you begin

Ensure you have the following:

Clone and deploy the example

Follow these steps to clone the scenarios repository and deploy the monitoring example:

Clone the Alloy scenarios repository:

git clone https://github.com/grafana/alloy-scenarios.git

Set up the example Kubernetes environment:
1. Navigate to the alloy-scenarios/k8s/logs directory:
  shell
```
cd alloy-scenarios/k8s/logs
```
2. Create a local Kubernetes cluster using kind.
  The kind.yml file provides the cluster configuration:
  shell
```
kind create cluster --config kind.yml
```
3. Add the Grafana Helm repository:
  shell
```
helm repo add grafana https://grafana.github.io/helm-charts
```
4. Create the meta and prod namespaces:
  shell
```
kubectl create namespace meta && \
kubectl create namespace prod
```
Deploy Loki in the meta namespace.
Loki stores the collected logs.
The loki-values.yml file contains the Loki Helm chart configuration:
shell
```
helm install --values loki-values.yml loki grafana/loki -n meta
```
This Helm chart installs Loki in monolithic mode.
For more details, refer to the Loki documentation.
Deploy Grafana in the meta namespace.
You can use Grafana to visualize the logs stored in Loki.
The grafana-values.yml file contains the Grafana Helm chart configuration:
shell
```
helm install --values grafana-values.yml grafana grafana/grafana --namespace meta
```
This Helm chart installs Grafana and sets the datasources.datasources.yaml field to the Loki data source configuration.
Deploy Alloy in the meta namespace.
The k8s-monitoring-values.yml file contains the Kubernetes monitoring Helm chart configuration:
shell
```
helm install --values ./k8s-monitoring-values.yml k8s grafana/k8s-monitoring -n meta --create-namespace
```
This Helm chart installs Alloy and specifies the Pod logs and Kubernetes Events sources that Alloy collects logs from.

Port-forward the Grafana Pod to your local machine:

Get the name of the Grafana Pod:

export POD_NAME=$(kubectl get pods --namespace meta -l "app.kubernetes.io/name=grafana,app.kubernetes.io/instance=grafana" -o jsonpath="{.items[0].metadata.name}")

Set up port-forwarding:

kubectl --namespace meta port-forward $POD_NAME 3000

Port-forward the Alloy Pod to your local machine:

Get the name of the Alloy Pod:

export POD_NAME=$(kubectl get pods --namespace meta -l "app.kubernetes.io/name=alloy-logs,app.kubernetes.io/instance=k8s-alloy-logs" -o jsonpath="{.items[0].metadata.name}")

Set up port-forwarding:

kubectl --namespace meta port-forward $POD_NAME 12345

Deploy Grafana Tempo to the prod namespace.
Tempo generates logs for this example:
shell
```
helm install tempo grafana/tempo-distributed -n prod
```

Monitor and visualize your data

Use Grafana to monitor your deployment’s health and visualize your data.

Monitor the health of your Alloy deployment

To monitor the health of your Alloy deployment, open your browser and go to http://localhost:12345.

For more information about the Alloy UI, refer to Debug Grafana Alloy.

Visualize your data

To use the Grafana Logs Drilldown, open your browser and go to http://localhost:3000/a/grafana-lokiexplore-app.

To create a dashboard to visualize your metrics and logs, open your browser and go to http://localhost:3000/dashboards.

Understand the Kubernetes Monitoring Helm chart

The Kubernetes Monitoring Helm chart, k8s-monitoring-helm, collects, scrapes, and forwards Kubernetes telemetry data to a Grafana stack.
This includes metrics, logs, traces, and continuous profiling data.

`cluster`

Define the cluster name as meta-monitoring-tutorial.
This is a static label attached to all logs collected by the Kubernetes Monitoring Helm chart.

cluster:
  name: meta-monitoring-tutorial

`destinations`

Define a destination named loki to forward logs to Loki.
The url attribute specifies the URL of the Loki gateway.

destinations:
  - name: loki
    type: loki
    url: http://loki-gateway.meta.svc.cluster.local/loki/api/v1/push

`clusterEvents`

Enable the collection of cluster events.

collector: Use the alloy-logs collector to collect logs.
namespaces: Specify the meta and prod namespaces to collect logs from.

clusterEvents:
  enabled: true
  collector: alloy-logs
  namespaces:
    - meta
    - prod

`nodeLogs`

Disable the collection of node logs.
Collecting node logs requires mounting /var/log/journal, which is out of scope for this example.

nodeLogs:
  enabled: false

`podLogs`

Enable the collection of Pod logs.

labelsToKeep: Specify labels to keep when collecting logs.
This configuration removes pod from the labels to keep.
structuredMetadata: Specify structured metadata to collect.
This configuration sets the structured metadata pod to keep the Pod name for querying.

podLogs:
  enabled: true
  gatherMethod: kubernetesApi
  collector: alloy-logs
  labelsToKeep: ["app_kubernetes_io_name","container","instance","job","level","namespace","service_name","service_namespace","deployment_environment","deployment_environment_name"]
  structuredMetadata:
    pod: pod  # Set structured metadata "pod" from label "pod"
  namespaces:
    - meta
    - prod

Define the Alloy role

The Kubernetes Monitoring Helm chart deploys only what you need.
In this case, the configuration deploys Alloy with the capability to collect logs.
Metrics, traces, and continuous profiling are disabled.

alloy-singleton:
  enabled: false

alloy-metrics:
  enabled: false

alloy-logs:
  enabled: true
  alloy:
    mounts:
      varlog: false
    clustering:
      enabled: true

alloy-profiles:
  enabled: false

alloy-receiver:
  enabled: false

Monitor metrics and logs with Grafana Alloy on Grafana Labs

Monitor Docker containers with Grafana Alloy

Monitor Docker containers with Grafana Alloy

Before you begin

Clone and deploy the example

Monitor and visualize your data

Monitor Alloy

Visualize your data

Understand the Alloy configuration

Configure metrics

prometheus.exporter.cadvisor

prometheus.scrape

prometheus.remote_write

Configure logging

discovery.docker

discovery.relabel

loki.source.docker

loki.write

Monitor Linux servers with Grafana Alloy

Monitor Linux servers with Grafana Alloy

Before you begin

Clone and deploy the scenario

Monitor and visualize your data

Monitor Alloy

Visualize your data

Understand the Alloy configuration

Configure metrics

prometheus.exporter.unix

discovery.relabel instance and job labels

discovery.relabel for systemd journal logs

prometheus.scrape

prometheus.remote_write

Configure logging

loki.source.journal

local.file_match

loki.source.file

loki.write

Configure livedebugging

livedebugging

Next steps

Monitor Microsoft Windows servers and desktops with Grafana Alloy

Monitor Microsoft Windows servers and desktops with Grafana Alloy

Before you begin

Clone and deploy the example

Monitor and visualize your data

Monitor Alloy

Visualize your data

Understand the Alloy configuration

Configure metrics

prometheus.exporter.windows

prometheus.scrape

prometheus.remote_write

Configure logging

loki.source.windowsevent

loki.process

loki.write

Configure livedebugging

livedebugging

Monitor logs from a local file with Grafana Alloy

Monitor logs from a local file with Grafana Alloy

Before you begin

Clone and deploy the example

Monitor and visualize your data

Monitor Alloy

Visualize your data

Understand the Alloy configuration

Configure livedebugging

livedebugging

Configure logging

local.file_match

loki.source.file

loki.write

Monitor TCP logs with Grafana Alloy

Monitor TCP logs with Grafana Alloy

Before you begin

Clone and deploy the example

Monitor and visualize your data

Monitor Alloy

Visualize your data

Understand the Alloy configuration

`prometheus.exporter.cadvisor`

`prometheus.scrape`

`prometheus.remote_write`

`discovery.docker`

`discovery.relabel`

`loki.source.docker`

`loki.write`

`prometheus.exporter.unix`

`discovery.relabel` instance and job labels

`discovery.relabel` for systemd journal logs

`prometheus.scrape`

`prometheus.remote_write`

`loki.source.journal`

`local.file_match`

`loki.source.file`

`loki.write`

Configure `livedebugging`

`livedebugging`

`prometheus.exporter.windows`

`prometheus.scrape`

`prometheus.remote_write`

`loki.source.windowsevent`

`loki.process`

`loki.write`

Configure `livedebugging`

`livedebugging`

Configure `livedebugging`

`livedebugging`

`local.file_match`

`loki.source.file`

`loki.write`

Configure `livedebugging`

`livedebugging`

`loki.source.api`

`loki.process`

`loki-write`

Configure `livedebugging`

`livedebugging`

`loki.source.syslog`

`loki.write`

Configure `livedebugging`

`livedebugging`

`loki.source.api`

`loki.process`

`loki.write`

`cluster`

`destinations`

`clusterEvents`

`nodeLogs`

`podLogs`