Grafana Alloy вместо Promtail и Grafana Agent: миграция, relabeling и troubleshooting

Зачем вообще переходить на Grafana Alloy

Если у вас уже настроены promtail для Loki и grafana-agent (или Agent Flow) для метрик/трейсов, миграция выглядит как «лишняя работа». На практике Alloy упрощает жизнь в трёх местах: единый бинарник для логов/метрик/трейсов, единый подход к маршрутизации и фильтрации данных, более прозрачная отладка пайплайнов.

Дальше — не обзор, а практичная инструкция: как воспроизвести поведение Promtail и Grafana Agent, как не сломать relabel_configs, как перенести обработку логов и что проверять, если после переезда «логи пропали» или «remote_write молчит».

Короткий словарь, чтобы дальше не путаться:

• Loki logs — отправка логов в Loki (push).
• Prometheus remote_write — отправка метрик в удалённый приёмник/хранилище.
• relabel_configs — правила переименования/фильтрации таргетов и лейблов (Prometheus-стиль).
• pipeline stages — обработка логов (парсинг, drop/keep, labels, timestamp).
• journald/systemd — чтение логов из systemd-journald.

Главная идея миграции: не «переписать всё», а воспроизвести потоки данных

Самый надёжный путь в promtail migration и grafana agent migration — начать с минимального рабочего конфига Alloy и постепенно добавлять преобразования, сверяя результат по данным и по поведению (таргеты живые, очереди не растут, дропов нет).

Рабочая стратегия почти всегда такая:

1. Запустите Alloy так, чтобы он отправлял «сырые» логи и «сырые» метрики (без сложного relabeling и без богатых пайплайнов).
2. Переносите relabel_configs отдельно от лог-обработки: сначала метрики (где relabeling чаще критичен), затем логи.
3. В конце добавляйте «косметику»: нормализацию label’ов, выравнивание job/instance, выделение app/env и т.д.

Подготовка: что собрать до миграции

Перед тем как трогать прод, соберите «контракт» текущей системы — это сильно ускоряет поиск расхождений после переезда:

• Текущий promtail.yaml (особенно scrape_configs, pipeline_stages, relabel_configs).
• Текущий конфиг Grafana Agent (static mode) или Flow (HCL/River).
• Список источников логов: файлы (/var/log, docker json logs), journald, syslog и т.п.
• Список «обязательных» лейблов в Loki (обычно job, host/instance, app, env).
• Куда пишете метрики через remote_write и какие заголовки/тенант нужны (если multi-tenant).

Практика: до миграции сделайте пару контрольных запросов в Loki по ключевым label’ам и зафиксируйте ожидаемый объём/частоту логов. После переезда вы быстро поймёте, что сломалось: сбор, фильтрация или relabeling.

Если вы ещё не фиксировали правила «какие label’ы считаем нормой для Loki», полезно заранее договориться о них. В помощь — разбор типовых ошибок с кардинальностью и пайплайнами: лейблы и пайплайны Loki: как не убить индекс.

Минимальный пример Alloy: Loki + Prometheus remote_write

Ниже — минимальный каркас Alloy (River/HCL): отдельно writer в Loki и отдельно remote_write для метрик. Дальше вы будете «подцеплять» источники и обработки и форвардить их в эти выходы.

logging {
  level = "info"
}

loki.write "to_loki" {
  endpoint {
    url = "LOKI_PUSH_ENDPOINT"
  }
}

prometheus.remote_write "to_remote" {
  endpoint {
    url = "REMOTE_WRITE_ENDPOINT"
  }
}

Важно: сначала добейтесь, чтобы этот скелет стабильно стартовал и не падал из-за TLS/доступности endpoint’ов. Потом добавляйте источники.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Promtail migration: перенос file scrape и обработок

1) File tailing: базовая схема

В Promtail вы привыкли к scrape_configs с static_configs и меткой __path__. В Alloy идея такая же: задаёте набор файлов как «targets», проставляете начальные label’ы и отправляете поток в loki.write.

Минимальный эквивалент «читать N файлов и пушить в Loki»:

local.file_match "varlog" {
  path_targets = [
    { __path__ = "/var/log/nginx/access.log", job = "nginx" },
    { __path__ = "/var/log/nginx/error.log",  job = "nginx" },
    { __path__ = "/var/log/syslog",           job = "syslog" }
  ]
}

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

Практическое правило: лейблы, которые «точно нужны всем» (например, job, env, instance), лучше задавать как можно раньше. Так вы уменьшаете риск потерять их на relabel-этапах и упрощаете корреляцию.

2) Перенос pipeline_stages: что переносится 1:1, а где лучше передумать

Пайплайны Promtail часто со временем превращаются в «комбайн». При миграции удобно разделить задачи на три типа:

• Парсинг: regex/json/logfmt, выделение полей.
• Нормализация: переименование, приведение уровней, timestamp.
• Фильтрация: drop/keep по содержимому и/или по label’ам.

Пример типичного фрагмента promtail-конфига (показываю именно Promtail, чтобы было проще сравнивать):

scrape_configs:
- job_name: nginx
  static_configs:
  - targets: [localhost]
    labels:
      job: nginx
      __path__: /var/log/nginx/access.log
  pipeline_stages:
  - regex:
      expression: '^(?P<remote_addr>\S+) - - \[(?P<time>[^\]]+)\] "(?P<method>\S+) (?P<uri>\S+) (?P<proto>\S+)" (?P<status>\d+) (?P<bytes>\d+)'
  - labels:
      status:
      method:
  - drop:
      expression: '"GET /health"'

В Alloy вы решаете ту же задачу: распарсить строку и часть полей превратить в label’ы. Для Loki держите в голове ограничение: в label’ы выносите только то, по чему вы реально фильтруете и агрегируете. Например, status и method иногда ок, а вот uri обычно создаёт кардинальность и делает Loki медленнее и дороже.

3) Где делать фильтрацию: pipeline или relabel

Частая ошибка при миграции — пытаться весь drop/keep перенести в relabeling. Упростим:

• Relabel — про лейблы и таргеты (метаданные), обычно «до» обработки содержимого.
• Pipeline — про содержимое логов (сообщение и извлечённые поля), «во время» обработки.

То есть «не собирать логи с пути» — это настройка источника/targets, а «не отправлять строки, содержащие healthcheck» — это лог-пайплайн.

Journald/systemd: миграция на Alloy без сюрпризов

Если вы читаете логи из systemd-journald, важны два практических момента: права доступа и контроль кардинальности (какие поля превращаются в label’ы).

Чек-лист перед включением journald-источника:

• Пользователь Alloy должен иметь доступ к журналу (часто это членство в группе systemd-journal).
• Проверьте, что журнал действительно persistent там, где вы ожидаете историю (иначе после перезагрузки данные «исчезают»).
• Определите набор journald-полей, которые вы мапите в label’ы. Обычно хватает _SYSTEMD_UNIT, SYSLOG_IDENTIFIER, PRIORITY, _HOSTNAME.

Каркас в Alloy выглядит как «source journald → обработка → loki.write»:

loki.source.journal "journald" {
  forward_to = [loki.write.to_loki.receiver]
  labels = {
    job = "journald"
  }
}

Дальше обычно добавляют relabeling, чтобы привести _SYSTEMD_UNIT к label’у unit или построить app из SYSLOG_IDENTIFIER. Если вы хотите более «боевую» схему с выносом журнала и централизованной доставкой, пригодится: настройка systemd-journal-remote для сбора journald.

Grafana Agent migration: метрики и remote_write в Alloy

Для метрик Alloy чаще всего заменяет Agent в режиме «сам скрейпит цели как Prometheus и пишет через remote_write». Это самый частый сценарий для серверов и VM.

1) Скрейп + relabel_configs: перенос без потери таргетов

relabel_configs — место, где чаще всего «теряются» таргеты. Симптом простой: Alloy работает, но метрик нет.

Практический подход: сначала запускайте скрейп без relabeling, убедитесь, что таргеты живые, затем включайте правила по одному.

Типичный prom-подобный relabeling, который встречается в Agent/Prometheus:

relabel_configs:
- source_labels: [__address__]
  target_label: instance
- source_labels: [__meta_consul_service]
  target_label: job
- action: drop
  source_labels: [__meta_kubernetes_pod_name]
  regex: ".*test.*"

На что смотреть при переносе в Alloy:

• Какие __meta_* лейблы реально доступны в вашем service discovery (static, file_sd, consul, kubernetes). Нельзя «перенести regex», если мета-лейбла больше нет.
• Порядок правил важен. drop по незаполненному source_labels может неожиданно «вырезать всё» или «не вырезать ничего».
• Если вы формируете job из нескольких полей, проверяйте результат: ошибка часто в разделителях или replace.

2) remote_write: типовые грабли

Когда prometheus remote_write «не работает», причины обычно банальные, но диагностируются не всегда быстро:

• Неверный endpoint (часто отличается путь).
• Нужна аутентификация или tenant-заголовки, но они не заданы.
• TLS: недоверенный CA, SNI, неполная цепочка сертификатов.
• Слишком большой поток: очередь растёт, включается backpressure, появляются дропы.
• Сильная кардинальность label’ов после неудачного relabeling.

Тактика миграции: сначала отправьте базовые метрики (например, up и метрики node_exporter), и только потом включайте enrich/дополнительные labels.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Relabeling в Alloy: как не сломать лейблы для Loki и Prometheus

Полезно разделять два мира:

• Prometheus relabel_configs — влияет на таргеты и лейблы метрик.
• Loki relabeling — влияет на label’ы лог-стримов (а значит, на индексацию, скорость запросов и стоимость).

Советы, которые чаще всего экономят часы:

• Не делайте label’ом то, что имеет много уникальных значений: uri, request_id, user_id. Для Loki это почти гарантированная боль.
• Стабилизируйте host: выберите один канонический label (instance или host) и держите его одинаковым в логах и метриках.
• Одинаковые имена job для логов и метрик упрощают корреляцию в Grafana.

Если после миграции запросы в Loki стали заметно медленнее, чаще всего вы случайно вынесли высококардинальное поле в label. Верните поле в контент и фильтруйте через LogQL по содержимому.

Troubleshooting: когда после миграции «ничего не видно»

1) Проверяем, что Alloy вообще читает источники

Для file tailing проверьте:

• Пути к файлам существуют и доступны пользователю Alloy.
• Логи реально дописываются (нет ротации в «новый» файл, который не матчится).
• Если используете glob-паттерны — убедитесь, что они действительно матчятся.

Для journald проверьте:

• Права: доступ к журналу, группа systemd-journal.
• Журнал не «volatile» там, где вы ожидаете persistent.

2) Проверяем, что данные доходят до Loki

Типовые симптомы и что они обычно означают:

• Alloy читает файлы, но в Loki пусто: проблема с endpoint, auth/TLS или блокирующим drop в пайплайне.
• В Loki данные есть, но «не находятся по label»: проблема с relabeling/labels (например, поменялось имя job или host).

Быстрый приём: временно добавьте фиксированный label (например, migrated="true") и ищите по нему. Если он не появляется — поток не доходит или дропается.

3) Проверяем remote_write

Если удалённое хранилище метрик не видит поток:

• Проверьте DNS/маршрутизацию с сервера: endpoint может быть недоступен из вашей сети.
• Проверьте TLS-ошибки в логах Alloy: цепочка сертификатов — частый кейс.
• Сведите конфиг к одному scrape (например, localhost exporter) и одному remote_write endpoint — так проще исключить relabeling.

4) «Всё было нормально, потом перестало»: ротация, positions и дубли

При замене Promtail на Alloy помните про state: promtail хранит позиции чтения (offset) для файлов; Alloy тоже ведёт своё состояние. Если запустить новый агент «с нуля», возможны два сценария:

• Дубли: новый агент перечитал файлы с начала.
• Пропуски: новый агент стартовал «с конца», а вы ожидали догрузку истории.

Это не «баг», а вопрос ожиданий. Для продового перехода обычно выбирают один из подходов:

• Переключиться на Alloy и принять небольшой дубль, отфильтровав его временем в запросах.
• Переключиться в момент, когда лог-файлы небольшие (например, после ротации).
• Сделать короткий параллельный прогон и сравнить потоки.

Практический чек-лист миграции (Promtail/Agent → Grafana Alloy)

1. Поднять Alloy с минимальными источниками логов и минимальным remote_write для метрик.
2. Проверить, что логи появляются в Loki по простому запросу, без опоры на старые label’ы.
3. Проверить, что метрики доходят через remote_write (хотя бы up).
4. Перенести relabeling по одному правилу и следить, что таргеты не пропали.
5. Перенести лог-обработки: сначала парсинг, потом labels, потом drop/keep.
6. Убедиться, что journald/systemd источники читаются и не плодят кардинальность.
7. Зафиксировать итоговый набор label’ов как «контракт» для команд devops/разработка/аналитика.

Финальные замечания по производительности и кардинальности

Alloy не «магически быстрее», но даёт удобные рычаги контроля потока. На практике производительность чаще упирается в:

• кардинальность label’ов в Loki и метриках;
• агрессивный regex-парсинг на шумных логах;
• неудачный выбор label’ов для индекса (слишком много уникальных значений);
• сетевые проблемы до приёмников (Loki/remote_write) и очередь на отправку.

Если хотите максимум эффекта от миграции, начните с простого: минимальные label’ы, простой пайплайн, понятный job/instance, а затем добавляйте только то, что реально используется в запросах и алертах.

Для проектов на своём сервере или в облаке удобно держать мониторинг-стек рядом с приложениями на VDS: проще управлять доступами, сетью и дисками под Loki/Prometheus, а при необходимости масштабировать ресурсы без смены архитектуры.