Documentation Grafana Alloy Reference Configuration blocks logging

logging

logging is an optional configuration block used to customize how Alloy produces log messages. logging is specified without a label and can only be provided once per configuration file.

Usage

Alloy Copy

logging {

}

Arguments

You can use the following arguments with logging:

level

The following strings are recognized as valid log levels:

• "error": Only write logs at the error level.
• "warn": Only write logs at the warn level or above.
• "info": Only write logs at info level or above.
• "debug": Write all logs, including debug level logs.

format

The following strings are recognized as valid log line formats:

• "json": Write logs as JSON objects.
• "logfmt": Write logs as logfmt lines.

write_to

The write_to argument allows Alloy to tee its log entries to one or more loki.* component log receivers in addition to the default location. This, for example can be the export of a loki.write component to send log entries directly to Loki, or a loki.relabel component to add a certain label first.

destination

The following strings are recognized as valid log destinations:

• "stderr": Write logs to stderr.
• "windows_event_log": Windows only. Write logs to the Windows Event Log under the “Alloy” source.

The default value of destination is set to "windows_event_log" when Alloy runs as a Windows service. Otherwise, destination defaults to "stderr".

Alloy fails to start if destination is set to "windows_event_log" and Alloy is not running on Windows.

Blocks

You can use the following blocks with logging:

rate_limiting

The rate_limiting block enables per-message rate limiting and sampling of repeated log lines.

Rate limiting keys on the component, the log level, and the log message text (not attributes/fields). Only identical repeated lines from the same component at the same level are throttled; distinct components/messages are independent (LRU-bounded by max_signatures).

Log lines that share a constant message but differ only in attributes are treated as the same signature and throttled together.

Log lines with an empty message, such as some go-kit-style logs emitted without a msg or message field, bypass rate limiting entirely and are always written.

After suppression begins, the first admitted line of each new window carries a slog_sampling.dropped_count attribute.

Dropped lines are counted by the alloy_logging_suppressed_lines_total metric (labeled by level and component_id).

Set enabled = false to disable. Omitting the rate_limiting block leaves limiting enabled with defaults.

Retrieve logs

You can retrieve the logs in different ways depending on your platform and installation method:

Linux:

• If you’re running Alloy with systemd, use journalctl -u alloy.

Docker:

• If you’re running Alloy in a Docker container, use docker logs CONTAINER_ID.

macOS:

• If you’re running Alloy with Homebrew as a service, use brew services info grafana/grafana/alloy to check status and tail -f $(brew --prefix)/var/log/alloy.log for logs.
• If you’re running Alloy with launchd, use log show --predicate 'process == "alloy"' --info or check /usr/local/var/log/alloy.log.
• If you’re running Alloy in a Docker container, use docker logs CONTAINER_ID.

Windows:

• If you’re running Alloy as a Windows service, check the Windows Event Viewer under Windows Logs > Application for Alloy-related events.
• If you’re running Alloy that is manually installed, check the log files in %PROGRAMDATA%\Grafana\Alloy\logs\ or the directory specified in your configuration.
• If you’re running Alloy in a Docker container, use docker logs CONTAINER_ID.

All platforms:

• Alloy writes logs to stderr if started directly without a service manager. Redirect stderr of the Alloy process to a file for logs to persist on disk.

Example

Alloy Copy

logging {
  level  = "info"
  format = "logfmt"
}