Generated banner for Alloy
Generated logo for Alloy

Alloy

Grafana LabsOfficialPublished by Grafana Labs

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • Low risk

From the author

Build a unified telemetry pipeline with Grafana Alloy — one OpenTelemetry-compatible binary that collects metrics, logs, traces, and profiles and ships to Grafana Cloud / Prometheus / Loki / Tempo / Pyroscope. Covers the Alloy config language (blocks, `sys.env`, component refs), `prometheus.scrape` → `remote_write`, `loki.source.file` + `loki.process` → `loki.write`, `otelcol.receiver.otlp` → `otelcol.exporter.otlp`, `pyroscope.scrape`, K8s / Docker / EC2 discovery, relabeling, modules (`import.file/git/http`), clustering, Fleet Management `remotecfg`, the Alloy UI at `:12345`, and `alloy fmt` / `alloy validate`. Use when writing a `config.alloy`, replacing Grafana Agent / OTel Collector, scraping K8s pods, parsing logs, ingesting OTLP, or debugging "Alloy isn't sending anything" — even when the user says "set up the agent", "write me a scrape config", "drop these logs before sending", or "OTel collector config" without naming Alloy.
— the description by Grafana Labs

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Grafana Alloy is an OpenTelemetry-compatible collector that uses a unified configuration language to build telemetry pipelines. This skill provides guidance on using the Alloy CLI, configuring components for data collection and shipping, and managing pipelines for metrics, logs, traces, and profiles. It covers the Alloy configuration syntax, component discovery, relabeling, and integration with backends like Grafana Cloud, Prometheus, Loki, Tempo, and Pyroscope.

What it does

  • Provides syntax and structure for config.alloy files using blocks and component references.
  • Explains how to use discovery components for Kubernetes, Docker, and cloud infrastructure.
  • Details the configuration of exporters and receivers for metrics, logs, and traces.
  • Offers commands for validating and formatting configuration files.
  • Describes how to use the Alloy UI to monitor component health and data flow.
  • Covers advanced features like modules, clustering, and remote configuration management.

When to use it

  • When setting up a telemetry pipeline to collect and ship observability data.
  • When migrating from Grafana Agent or OpenTelemetry Collector to Alloy.
  • When configuring scrape targets for Kubernetes pods or other infrastructure.
  • When debugging issues with data ingestion or pipeline connectivity.
  • When needing to transform or drop specific logs or metrics before they are shipped.

Advantages

  • Unified binary for handling multiple telemetry signals.
  • Native support for OpenTelemetry and Prometheus protocols.
  • Built-in validation and formatting tools to ensure configuration correctness.
  • Extensive component library for service discovery and data routing.
  • Integrated web UI for inspecting component status and troubleshooting.

Usage examples

“How do I set up a basic Prometheus scrape job in Alloy?”
The agent provides a configuration block using prometheus.scrape to target an address and forward metrics to a remote_write component.
“Help me debug why my Alloy logs aren't appearing in Loki.”
The agent suggests checking the component health via the local UI at port 12345 and verifying the loki.source.file configuration.
“How do I validate my config.alloy file?”
The agent instructs to run the alloy validate command to perform a syntax check on the configuration file.
“Write a configuration to receive OTLP traces and send them to Tempo.”
The agent provides an otelcol.receiver.otlp block connected to an otelcol.exporter.otlp block with appropriate authentication.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/grafana/alloy/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip alloy.zip -d .agents/skills

Documentation by Grafana Labs

Grafana Alloy

Docs: https://grafana.com/docs/alloy/latest/

OpenTelemetry-compatible collector — one binary for metrics + logs + traces + profiles.

Prerequisites

  • alloy CLI installed (brew install grafana/grafana/alloy, apt install alloy, or grafana/alloy Docker image)

  • An endpoint to ship to (Grafana Cloud, Prometheus, Loki, Tempo, Pyroscope)

  • API key + username for that endpoint, exported as GRAFANA_API_KEY etc.

Common Workflows

1. Write + validate a config locally
// config.alloy — metrics → Grafana Cloud
prometheus.scrape "app" {
  targets = [{"__address__" = "localhost:9090"}]
  forward_to = [prometheus.remote_write.cloud.receiver]
  scrape_interval = "30s"
}

prometheus.remote_write "cloud" {
  endpoint {
    url = sys.env("PROMETHEUS_URL")
    basic_auth {
      username = sys.env("PROM_USER")
      password = sys.env("GRAFANA_API_KEY")
    }
  }
}
# 1. Format + syntax-check (catches typos before run)
alloy fmt config.alloy
alloy validate config.alloy

# 2. Run it
alloy run config.alloy
# or as a service: systemctl restart alloy

# 3. Verify all components are healthy via the UI on port 12345
curl -s http://localhost:12345/api/v0/web/components \
  | jq '.[] | select(.health.state != "healthy") | {id, state:.health.state, msg:.health.message}'
# Expect: empty (nothing unhealthy). Otherwise the row shows the failing component + reason.

# 4. Verify samples are flowing
curl -s http://localhost:12345/metrics \
  | grep -E '^prometheus_remote_storage_(samples_total|enqueue_retries_total)' | head
# samples_total should be > 0 and rising; retries should be 0.
2. Add log shipping (file → Loki)
loki.source.file "app_logs" {
  targets    = [{ __path__ = "/var/log/app/*.log", job = "app" }]
  forward_to = [loki.write.cloud.receiver]
}

loki.write "cloud" {
  endpoint {
    url = sys.env("LOKI_URL")
    basic_auth {
      username = sys.env("LOKI_USER")
      password = sys.env("GRAFANA_API_KEY")
    }
  }
}
# Verify in Grafana → Explore → Loki:
#   {job="app"}
# Expect lines streaming. If empty:
#   - check /var/log/app/*.log actually exists + readable by the alloy user
#   - http://localhost:12345 → loki.source.file.app_logs → "Targets" tab
3. Receive OTLP traces and ship to Tempo
otelcol.receiver.otlp "default" {
  grpc { endpoint = "0.0.0.0:4317" }
  http { endpoint = "0.0.0.0:4318" }
  output { traces = [otelcol.exporter.otlp.tempo.input] }
}

otelcol.exporter.otlp "tempo" {
  client {
    endpoint = "tempo-xxx.grafana.net/tempo:443"
    auth     = otelcol.auth.basic.grafana_cloud.handler
  }
}

otelcol.auth.basic "grafana_cloud" {
  username = sys.env("TEMPO_USER")
  password = sys.env("GRAFANA_API_KEY")
}
# Verify in Grafana → Explore → Tempo → service.name = your-service
# At the Alloy level, watch the receiver:
curl -s http://localhost:12345/metrics | grep otelcol_receiver_accepted_spans

Full pattern set (Kubernetes discovery + relabel, complete Cloud pipeline for all 4 signals): references/collection-patterns.md.

Reference

Troubleshooting

  • alloy validate → "component not found" → version too old; alloy --version and upgrade

  • UI shows component unhealthy → click into it on http://localhost:12345 for the live error

  • prometheus_remote_storage_samples_dropped_total rising → check enqueue_retries_total and the remote_write endpoint URL + creds

  • No spans landing in Tempo → check otelcol_receiver_refused_spans and the exporter's otelcol_exporter_sent_spans / otelcol_exporter_send_failed_spans

Resources

Files

references/config-syntax.md

Alloy Configuration Language Syntax

Reference for Alloy's configuration syntax (.alloy files). For the canonical docs, see https://grafana.com/docs/alloy/latest/get-started/configuration-syntax/.

File format

  • Extension: .alloy

  • Encoding: UTF-8

  • Whitespace-insensitive; one or more components per file

  • Comments: // line comment, /* ... */ block comment

A config file is a sequence of top-level blocks (components and configuration blocks) and attributes.

Blocks

Blocks declare either a configuration block (logging, http, tracing, remotecfg, clustering, ...) or a component instance.

BLOCK_TYPE "LABEL" {
  attribute = value

  nested_block {
    attribute = value
  }
}
  • BLOCK_TYPE is dotted (e.g. prometheus.scrape, otelcol.receiver.otlp).

  • "LABEL" is the user-chosen instance name. The BLOCK_TYPE.LABEL pair must be unique.

  • Some top-level blocks have no label (logging, http, tracing, remotecfg, clustering).

// Two instances of the same component type, distinguished by label
prometheus.scrape "api" {
  targets    = [{__address__ = "api.example.com:8080"}]
  forward_to = [prometheus.remote_write.cloud.receiver]
}

prometheus.scrape "db" {
  targets    = [{__address__ = "db.example.com:9090"}]
  forward_to = [prometheus.remote_write.cloud.receiver]
}

Attributes

Attributes are NAME = VALUE pairs inside a block.

scrape_interval = "30s"
enabled         = true
targets         = [{__address__ = "localhost:9090"}]

Attribute names are unquoted identifiers. Values can be literals, references, function calls, or arbitrary expressions.

Component model

Every component has two halves:

  1. Arguments — the attributes and nested blocks you write.

  2. Exports — values the component publishes for other components to consume.

Reference an export with BLOCK_TYPE.LABEL.export_name:

local.file "api_key" {
  filename = "/etc/secrets/api.key"
}

prometheus.remote_write "cloud" {
  endpoint {
    url = "https://prometheus.example.com/api/v1/write"
    basic_auth {
      username = "metrics"
      password = local.file.api_key.content   // <- export reference
    }
  }
}

When a referenced export changes, Alloy re-evaluates and restarts dependent components automatically — you do not manually wire updates.

Data types

TypeExample
number42, 3.14, -7
string"hello", multi-line """\nfoo\nbar\n""" (raw)
booltrue, false
nullnull
array[1, 2, 3], [{__address__ = "host:9090"}]
object{ key = "value", other = 1 }
functionvalues returned by stdlib (sys.env, etc.)
capsuleopaque internal type (e.g. component receivers/handlers)

Object keys can be unquoted identifiers (key = "v") or quoted strings ("key" = "v"). Quoted keys are required when the key isn't a valid identifier — e.g. it contains a hyphen ("node-name" = "...") or starts with a digit. Identifiers built only from letters, digits, and underscores (including leading underscores like __address__) are valid unquoted; quoting them is purely a convention borrowed from Prometheus-style metadata labels.

Expressions

Expressions appear on the right-hand side of any attribute. Supported forms:

// Literals
x = 1
y = "string"
z = true

// Arithmetic, comparison, logical operators
a = 1 + 2 * 3            // 7
b = (1 + 2) * 3          // 9
c = 10 > 5 && !false     // true
d = "https://" + host    // string concatenation

// Component reference
e = prometheus.remote_write.cloud.receiver

// Function call
f = sys.env("HOME")
g = encoding.from_json(local.file.config.content)

// Indexing and field access
h = my_array[0]
i = my_object.field
j = my_object["field-with-dash"]

Operator precedence (highest to lowest, standard):

  1. Unary !, -

  2. *, /, %

  3. +, -

  4. <, <=, >, >=

  5. ==, !=

  6. &&

  7. ||

Use parentheses to override precedence.

References to other components

Format: <block_type>.<label>.<export>.

// Targets export from discovery, consumed by scrape
prometheus.scrape "k8s" {
  targets    = discovery.kubernetes.pods.targets
  forward_to = [prometheus.remote_write.cloud.receiver]
}

Forwarding arrays are common: forward_to = [<recipient>.input] or [<recipient>.receiver]. The exact export name (input, receiver, handler, ...) depends on the recipient component.

Standard library

The stdlib mixes two shapes: most functions live under a namespace and are called as namespace.function(...) (e.g. sys.env, string.replace); a handful are top-level functions called by their bare name (e.g. coalesce, json_path). The most-used:

NameShapeUseful members
sysnamespacesys.env("VAR") — read environment variable
constantsnamespaceconstants.hostname, constants.os, constants.arch
arraynamespacearray.concat(a, b), array.combine_maps(...)
convertnamespaceconvert.nonsensitive(...), type casts
encodingnamespaceencoding.from_json(...), encoding.from_yaml(...)
filenamespacefile.path_join(...)
stringnamespacestring.to_upper, string.to_lower, string.replace, string.split
coalesce(a, b, c)top-levelFirst non-null/non-empty argument
json_path(doc, "$.field")top-levelExtract values from a JSON document

Full reference: https://grafana.com/docs/alloy/latest/reference/stdlib/.

// Typical patterns
password = sys.env("GRAFANA_API_KEY")
field    = "spec.nodeName=" + coalesce(sys.env("HOSTNAME"), constants.hostname)
url      = "https://" + sys.env("HOST") + "/api"
config   = encoding.from_json(local.file.json_config.content)

Top-level configuration blocks

Unlike component blocks, these are unlabeled and appear at most once.

logging {
  level  = "info"     // debug | info | warn | error
  format = "logfmt"   // logfmt | json
}

http {
  listen_addr = "0.0.0.0:12345"   // Alloy UI + /metrics endpoint
}

tracing {
  sampling_fraction = 0.1
  write_to          = [otelcol.exporter.otlp.default.input]
}

remotecfg {
  url = "https://fleet-management.grafana.net"
  basic_auth {
    username = sys.env("FM_USERNAME")
    password = sys.env("FM_TOKEN")
  }
  poll_interval = "1m"
}

clustering {
  enabled = true
}

Imports and modules

Imported namespaces let you call user-defined components like stdlib functions.

// Local file
import.file "utils" {
  filename = "./modules/utils.alloy"
}

// Git
import.git "k8s" {
  repository = "https://github.com/grafana/alloy-modules"
  revision   = "main"
  path       = "modules/kubernetes/"
}

// HTTP
import.http "shared" {
  url            = "https://config-server/alloy/shared.alloy"
  poll_frequency = "5m"
}

// Invoke an imported declare block
utils.my_component "example" {
  arg = "value"
}

declare defines a reusable component locally:

declare "wrapped_scrape" {
  argument "target" { optional = false }
  argument "receiver" { optional = false }

  prometheus.scrape "inner" {
    targets    = [{__address__ = argument.target.value}]
    forward_to = [argument.receiver.value]
  }
}

Durations and sizes

  • Durations are Go-style strings: "30s", "1m", "500ms", "2h30m".

  • Byte sizes use IEC/SI suffixes where accepted: "512MiB", "1GB".

Common pitfalls

  • Quoting object keys is required only when the key isn't a valid identifier (hyphens, dots, leading digits): {"node-name" = "..."}. Quoting Prometheus-style keys like __address__ is conventional but not required.

  • Trailing commas are allowed and recommended in multi-line arrays/objects.

  • Component labels must match references exactly — prometheus.scrape "api" is referenced as prometheus.scrape.api.<export>, not api.<export>.

  • Forwarding uses the recipient's input export — usually .receiver (Prometheus/Loki/Pyroscope) or .input (otelcol).

  • Reloads: edit and SIGHUP the process, or POST /-/reload on the HTTP endpoint.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs network access, Needs an API key

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Grafana Labs
Publisher
Grafana Labs (Official)
Source
grafana/skills · skills/grafana-core/alloy · commit 8fb72a5
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Grafana Labs or Grafana Labs.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download alloy.zip