Grafana Loki: лёгкое централизованное логирование без Elasticsearch

Я Семёнов Евгений Сергеевич, руковожу АйТи Фреш. У нас на практике для клиентов, где логов «не очень много» (до 50–100 ГБ/день) и не нужен полнотекстовый поиск в стиле «найди всё по слову», я ставлю Loki вместо ELK. Тратится в разы меньше ресурсов, администрируется один бинарь + S3. На наших серверах Dell Xeon Platinum 8280 в дата-центре МТС Москва Loki обрабатывает логи десятка клиентских инфраструктур. Разберём установку и эксплуатацию.

Зачем Loki, если есть ELK

• Индексируются только лейблы, не содержимое — в 10 раз компактнее Elasticsearch.
• Один бинарь Go (loki) и внешнее хранилище (FS, S3, GCS).
• Нативно интегрируется с Grafana, которую многие уже используют для метрик.
• LogQL синтаксически похож на PromQL — порог входа низкий.

Минусы: медленнее полнотекстовый поиск. Для security-форензики по огромным объёмам — Elastic удобнее.

Архитектура

Для малых инсталляций (single-binary mode) всё это работает на одной машине с локальной FS. Масштабируемая схема (microservices mode) разносит distributor/ingester/querier/compactor.

Установка Loki (single-binary)

# Docker Compose
services:
  loki:
    image: grafana/loki:3.1.0
    ports: ["3100:3100"]
    restart: unless-stopped
    volumes:
      - ./loki-config.yaml:/etc/loki/local-config.yaml
      - loki-data:/loki
    command: -config.file=/etc/loki/local-config.yaml

  grafana:
    image: grafana/grafana:11.1.0
    ports: ["3000:3000"]
    restart: unless-stopped
    volumes:
      - grafana-data:/var/lib/grafana
    environment:
      GF_AUTH_ANONYMOUS_ENABLED: "false"

volumes:
  loki-data:
  grafana-data:

Минимальный loki-config.yaml:

auth_enabled: false

server:
  http_listen_port: 3100

common:
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore: { store: inmemory }

schema_config:
  configs:
    - from: 2024-01-01
      store: tsdb
      object_store: filesystem
      schema: v13
      index: { prefix: index_, period: 24h }

limits_config:
  retention_period: 720h
  max_query_length: 720h

compactor:
  working_directory: /loki/compactor
  retention_enabled: true
  delete_request_store: filesystem

Promtail: агент на Linux-сервере

server:
  http_listen_port: 9080

positions:
  filename: /tmp/positions.yaml

clients:
  - url: https://loki.company.ru/loki/api/v1/push
    basic_auth: { username: "promtail", password: "${LOKI_PASS}" }

scrape_configs:
  - job_name: system
    static_configs:
      - targets: [localhost]
        labels:
          job: varlogs
          host: web-01
          __path__: /var/log/*.log

  - job_name: nginx
    static_configs:
      - targets: [localhost]
        labels:
          job: nginx
          env: prod
          __path__: /var/log/nginx/*.log
    pipeline_stages:
      - regex:
          expression: '^(?P[^ ]+) .*? "(?PGET|POST|PUT|DELETE) (?P[^ ]+) HTTP/\d\.\d" (?P\d+)'
      - labels:
          method:
          status:

LogQL: поиск и агрегация

Синтаксис напоминает PromQL. Примеры:

{job="nginx"} |= "500"

# Только GET с кодом 5xx за последний час
{job="nginx", method="GET"} |~ " 5\\d\\d "

# Счётчик ошибок по сервисам
sum by (service) (
  count_over_time({env="prod"} |= "ERROR" [5m])
)

# Топ-5 URL с 4xx
topk(5,
  sum by (path) (count_over_time({job="nginx"} |~ " 4\\d\\d " [1h]))
)

Оператор |= — содержит подстроку, |~ — регулярка, != — не содержит, !~ — не матчит regex. | json — парсит JSON-поля на лету.

Дашборды и алерты в Grafana

Подключение Loki как источника — Configuration → Data Sources → Loki → URL http://loki:3100. В дашбордах используем LogQL-запросы, визуализация — Logs, Stat, Time series (с sum_over_time).

Алерты создаются через Grafana Alerting:

# Пример правила — более 10 ошибок за 5 минут
expr: |
  sum(count_over_time({service="api", env="prod"} |= "ERROR" [5m])) > 10
for: 2m
labels:
  severity: warning
annotations:
  summary: "Много ошибок в API"

Масштабирование: когда single-node мало

Single-node тянет до ~100 ГБ/день и ~1 ТБ хранилища. Если больше — переходим на microservices mode:

• Distributor — принимает пуш от Promtail, валидирует, отправляет в ingester.
• Ingester — буферизует в памяти, сбрасывает чанки в S3.
• Querier — выполняет запросы, читает S3 и ingester.
• Query Frontend — разбивает большие запросы на подзапросы.
• Compactor — объединяет чанки, применяет ретенцию.

Для microservices нужен S3/MinIO. На наших серверах Dell Xeon Platinum 8280 мы держим MinIO на NVMe, получаем 40 Гбит/с пропускной способности.

Реальный кейс: логирование для интернет-магазина

Однажды в 2024 году к нам пришёл клиент — магазин детских товаров, 18 серверов (10 веб-бэкендов, 3 БД, DNS, почта, CDN-kесспулы). ELK им настраивали подрядчики дважды — 3 ноды ES не справлялись, пришлось перетряхивать конфиги каждый месяц. Мы заменили на Loki single-node на виртуалке 8 vCPU / 16 ГБ с 1 ТБ NVMe.

За 4 рабочих дня: установка Loki + Promtail на 18 источниках, парсинг nginx access/error, docker-контейнеры через docker driver, импорт дашбордов. Стоимость — 58 000 руб. Клиент получил поиск по логам за 90 дней, алерты в Telegram, экономию ресурсов в 5 раз против ELK.

Грабли Loki

• Высокая кардинальность лейблов. Лейбл request_id с миллионом значений = миллион стримов = смерть производительности.
• Неудачные regex в pipeline_stages. Каждая строка обрабатывается — плохая regex тормозит Promtail.
• Compactor отключен. Без него ретенция не работает, старые данные не удаляются.
• Нет лимитов запросов. Один «жирный» запрос кладёт querier. Настройте max_query_length, max_entries_limit_per_query.
• Promtail не читает после рестарта. Проверьте positions.yaml — там последний offset. Если файл потерян, всё читается заново.

FAQ — Grafana Loki

Чем Loki лучше ELK?

Loki индексирует только лейблы, а не содержимое логов — это раз в 10 экономит место и CPU. Проще в эксплуатации: один бинарь + S3 хранилище. Но полнотекстовый поиск медленнее, чем в Elasticsearch.

Сколько ресурсов нужно Loki для 50 ГБ логов в день?

Single-node: 4 vCPU, 8 ГБ ОЗУ, 500 ГБ диск (или S3). Масштабируемая схема (distributor/ingester/querier) оправдана от 500 ГБ/день. На NVMe ingester работает быстрее.

Можно ли собирать Windows Event Logs в Loki?

Да, через Grafana Agent или Promtail с виндовым экспортером wevtutil/windows_exporter. Поля Event Log преобразуются в лейблы и сообщение. Поиск по EventID удобен через LogQL.

Как ограничить ретенцию в Loki?

В config.yaml: limits_config.retention_period = 720h (30 дней), плюс compactor с retention_enabled=true. Можно задавать ретенцию по лейблам: разные длительности для security/app/debug.

Что такое высокая кардинальность в Loki?

Loki хранит индекс по уникальным комбинациям лейблов. Лейбл с высокой кардинальностью (user_id, request_id) создаёт миллионы стримов и убивает производительность. Такие значения должны быть в сообщении, а не в лейблах.