Централизованное логирование: Часть 5 — Loki и Grafana

Loki — система хранения логов от Grafana Labs. Её главное отличие от ELK, OpenSearch и Graylog — Loki не строит полнотекстовый индекс. Индексируются только метки (labels) — короткий набор пар «ключ — значение», описывающих источник: сервер, сервис, окружение. Сами строки логов хранятся сжатыми блоками, в том числе в S3-совместимом хранилище. За счёт этого Loki требует заметно меньше ресурсов, а логи просматриваются в Grafana рядом с метриками Prometheus.

Лицензия

С апреля 2021 года Loki, как и Grafana, распространяется под AGPLv3 — открытой лицензией, одобренной OSI. Агенты и ряд библиотек остались под Apache 2.0. Для компании, которая запускает Loki для собственных логов, AGPLv3 ограничений не создаёт; условие о раскрытии изменений касается тех, кто модифицирует Loki и предоставляет его как сетевой сервис.

Компоненты

• Loki — принимает, хранит и отдаёт логи. Для небольших установок запускается одним процессом, для больших — как набор отдельных служб.
• Grafana — интерфейс для поиска (раздел Explore), дашбордов и оповещений.
• Агент на серверах — читает логи, добавляет метки и отправляет в Loki. Сейчас это Grafana Alloy.

Promtail больше не поддерживается

Долгое время агентом для Loki был Promtail, и в большинстве старых инструкций описан именно он. С 13 февраля 2025 года Promtail получал только исправления, а 2 марта 2026 года его поддержка полностью прекратилась. Grafana рекомендует переходить на Grafana Alloy. Для перевода существующей конфигурации есть команда:

alloy convert --source-format=promtail --output=config.alloy promtail.yaml

Она преобразует конфигурацию Promtail в формат Alloy; результат стоит проверить вручную.

Пример конфигурации Alloy

Конфигурация Alloy состоит из компонентов, соединённых между собой. Чтобы читать файлы из /var/log и отправлять их в Loki, нужны три компонента: поиск файлов, чтение и отправка.

local.file_match "system" {
  path_targets = [{
    __address__ = "localhost",
    __path__    = "/var/log/*.log",
    job         = "system",
  }]
}

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

loki.write "default" {
  endpoint {
    url = "http://loki.internal:3100/loki/api/v1/push"
  }
  external_labels = {
    host = "web-01",
    env  = "prod",
  }
}

local.file_match находит файлы по шаблону, loki.source.file читает их и передаёт строки дальше, loki.write отправляет их в Loki и добавляет к каждой записи метки host и env. Для системного журнала есть компонент loki.source.journal, для контейнеров — loki.source.docker.

Метки и кардинальность

Метки — самая важная часть настройки Loki. Каждая уникальная комбинация значений меток образует отдельный поток (stream), и для каждого потока хранятся свой индекс и свои блоки данных. Документация Loki прямо говорит, что система рассчитана на долгоживущие потоки и небольшое число значений меток.

Хорошие метки — с малым и стабильным набором значений: env, cluster, namespace, app, job, host.

Плохие метки — с неограниченным числом значений: идентификаторы запросов, трассировок, пользователей и заказов, IP-адреса, время. Даже уровень лога и код ответа HTTP документация советует не выносить в метки, а искать фильтром по строке. Высокая кардинальность приводит к огромному индексу и тысячам мелких блоков в хранилище, и Loki начинает работать медленно.

Для часто искомых полей с большим числом значений, например идентификатора клиента, в Loki есть структурированные метаданные: они хранятся рядом с записью и не попадают в индекс.

LogQL

Запросы пишутся на LogQL. Запрос начинается с выбора потоков по меткам, дальше идёт цепочка фильтров и обработчиков.

Строки с ошибками в логах nginx на рабочих серверах:

{job="nginx", env="prod"} |= "error"

Разбор JSON и фильтр по полю:

{app="payments"} | json | level="error" | order_id != ""

Число ошибок в секунду по серверам за пятиминутные окна — такой запрос можно вывести на график и использовать в оповещении:

sum by (host) (rate({job="nginx"} |= " 500 " [5m]))

Синтаксис похож на PromQL, поэтому тем, кто работает с Prometheus, осваивать его проще.

Достоинства

• Экономия ресурсов. Индекс по меткам в разы меньше полнотекстового; строки хранятся сжатыми, в том числе в дешёвом объектном хранилище.
• Логи рядом с метриками. В Grafana можно перейти от графика метрики к логам того же сервиса за тот же интервал.
• Простой старт. Для небольшой инфраструктуры достаточно одного процесса Loki и агента на серверах.
• Открытая лицензия AGPLv3.

Ограничения

• Поиск по содержимому медленнее. Без полнотекстового индекса запрос по тексту перебирает строки выбранных потоков. Чем точнее выбор меток и короче интервал, тем быстрее запрос.
• Обработка скромнее, чем в Logstash или конвейерах Graylog: основную работу по разбору выполняют агент и запросы LogQL.
• Дисциплина с метками. Одна неудачная метка с большим числом значений может перегрузить систему.

Типичные ошибки

• Новая установка на Promtail. Агент не поддерживается; для новых серверов сразу используйте Alloy.
• Идентификатор запроса или IP-адрес в метке. Число потоков растёт лавинообразно.
• Нет срока хранения. В Loki он задаётся параметром retention_period и включается в компактаторе; без этого данные хранятся бессрочно.
• Loki открыт наружу без аутентификации. В однопользовательском режиме Loki сам не проверяет, кто отправляет и читает логи. Доступ ограничивают межсетевым экраном или обратным прокси с аутентификацией.

Когда выбирать Loki

Loki подходит, если метрики уже собирает Prometheus, а дашборды строятся в Grafana, и нужно недорого добавить к ним логи. Он хорошо работает в Kubernetes и при большом объёме логов, по которым ищут в основном по источнику и времени. Если нужен полнотекстовый поиск и сложная аналитика по содержимому, лучше подойдут OpenSearch или ELK.