LGTM-стек #4: Grafana Alloy — один коллектор вместо трёх агентов

До Alloy в стеке приходилось держать отдельно Grafana Agent для метрик, Promtail для логов и, если нужны трейсы, ещё OpenTelemetry Collector. Grafana Alloy — один процесс, который собирает и метрики, и логи, и трейсы, и профили одновременно.

Конфиг — не YAML, а свой декларативный язык (файлы .alloy), построенный из компонентов: каждый компонент выполняет одну задачу и описывается блоком с аргументами внутри:

COMPONENT_NAME "label" {
  attribute = "value"
}

Основная идея — компоненты соединяются друг с другом через экспорты: один компонент публикует значение, другой на него ссылается напрямую в конфиге, без промежуточных переменных окружения.

Минимальный рабочий пример — сбор Prometheus-метрик и отправка их в удалённое хранилище:

prometheus.remote_write "default" {
  endpoint {
    url = "http://localhost:9009/api/v1/push"
  }
}

prometheus.scrape "example" {
  targets = [{
    __address__ = "127.0.0.1:9100",
  }]

  forward_to = [prometheus.remote_write.default.receiver]
}

prometheus.scrape собирает метрики с node_exporter на 9100-м порту и передаёт их (forward_to) на вход компонента prometheus.remote_write.default — обращение идёт через component_type.label.export_name, а не через ID или имя файла.

Порт 9009 в примере — это порт по умолчанию у Grafana Mimir, /api/v1/push — эндпоинт remote_write, совместимый с обычным Prometheus.

Практическая выгода — не философская “всё в одном”, а конкретная: одна точка обновления версии, один процесс в systemd вместо трёх, и общие для всех типов телеметрии механизмы service discovery (discovery.kubernetes и подобные компоненты можно переиспользовать между сбором метрик и логов, а не настраивать discovery отдельно в Prometheus и отдельно в Promtail).

#prometheus #grafana #lgtm