Graylog или Grafana Loki: что выгоднее и когда

MAATRIX

Логи копятся быстро: через месяц-два после запуска проекта в journalctl и файлах под /var/log уже невозможно найти нужную строку руками. Нужен централизованный сбор — и тут встаёт выбор между Graylog (тяжёлый, но мощный SIEM-комбайн) и Grafana Loki (лёгкий стек в духе Prometheus). Оба решают задачу «собрать логи со всех серверов в одно место», но требуют разного железа, разного времени на настройку и годятся для разных сценариев. Разберём честно, без маркетинга.

Архитектурная разница: индексация против компрессии

Graylog — это надстройка над полнотекстовым поисковым движком (Elasticsearch или OpenSearch) плюс MongoDB для метаданных (пользователи, стримы, правила). Каждое сообщение лога при записи разбирается на поля и индексируется целиком — как в Elasticsearch под Kibana. За это платите ресурсами: индекс с полнотекстовым поиском по каждому полю занимает в разы больше места, чем сырой текст, и требует много RAM под кэши и Java heap.

Grafana Loki устроен принципиально иначе — «индексируется только метаданные (labels), а не содержимое строки». Loki хранит логи блоками, сжатыми gzip/snappy, и индексирует не текст сообщения, а небольшой набор меток вида {job="nginx", host="web-1"}. Поиск по содержимому — это grep по сжатым чанкам в момент запроса, а не мгновенный ответ из готового индекса. Отсюда и разница: Loki на порядок дешевле по хранению и памяти, но полнотекстовый поиск по большим объёмам логов работает медленнее, чем в Graylog/Elasticsearch.

Из этой архитектурной развилки вытекают все остальные различия — ресурсы, retention, скорость поиска, сложность эксплуатации.

Ресурсы: сколько RAM, CPU и диска нужно каждому

Минимальный стек Graylog — это три компонента: сам Graylog, Elasticsearch/OpenSearch, MongoDB. Даже для небольшого объёма логов (условно — несколько ГБ в сутки) закладывайте отдельный Java heap под Elasticsearch (обычно рекомендуют не менее половины доступной RAM, но не больше ~31 ГБ из-за особенностей адресации указателей в JVM) плюс память под сам Graylog и MongoDB сверху. На практике комфортный старт — от 8 ГБ RAM и 4 vCPU, и это без запаса под пиковую нагрузку. Точные цифры под ваш объём логов лучше прикинуть отдельно — подход к расчёту разобран в статье сколько RAM нужно для Graylog.

Loki заметно легче на старте, потому что не тянет за собой Elasticsearch — минимальная связка это Loki + Promtail (или новый агент Grafana Alloy) + Grafana для визуализации, и вместо MongoDB — обычная файловая система или S3-совместимое хранилище под чанки. Для небольшого проекта Loki реально поднять на 2-4 ГБ RAM и 2 vCPU, и это будет работать стабильно — экономия ресурсов ощутима именно на старте и на среднем объёме.

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

Установка и запуск: сложность разворачивания

Graylog разворачивается через готовый docker-compose.yml с тремя сервисами и парой переменных окружения (GRAYLOG_PASSWORD_SECRET, GRAYLOG_ROOT_PASSWORD_SHA2), но реальная настройка начинается после старта: нужно завести Input (например, GELF UDP на 12201), настроить Index Set с retention-политикой, прописать Extractors или Pipeline Rules под формат ваших логов, поднять Streams с правилами маршрутизации. Это не пять минут — рассчитывайте на день-два на нормальную настройку под конкретный проект. Пошаговый разбор есть в статье установка Graylog на Ubuntu 24.04, включая типовые проблемы при эксплуатации.

Loki проще запустить, но легко ошибиться в конфиге на старте — часто спотыкаются на schema_config (версия схемы хранения) и лимитах приёма (ingestion_rate_mb, max_streams_per_user), которые по умолчанию рассчитаны на небольшую нагрузку и режут запись при росте числа меток. Минимальный docker-compose.yml:

services:
  loki:
    image: grafana/loki:3.0.0
    ports:
      - "3100:3100"
    volumes:
      - ./loki-config.yaml:/etc/loki/local-config.yaml
      - loki-data:/loki
    command: -config.file=/etc/loki/local-config.yaml

  promtail:
    image: grafana/promtail:3.0.0
    volumes:
      - /var/log:/var/log:ro
      - ./promtail-config.yaml:/etc/promtail/config.yml
    command: -config.file=/etc/promtail/config.yml

  grafana:
    image: grafana/grafana:11.0.0
    ports:
      - "3000:3000"

volumes:
  loki-data:

Подробный разбор конфигурации, включая типовые грабли, — в статье логи в Grafana Loki на VPS. Если у вас уже стоит связка Grafana и Prometheus для метрик, добавление Loki как ещё одного datasource — минимальный шаг: логи и метрики оказываются в одном интерфейсе, с одной системой алертов.

Хранение логов и retention

В Graylog retention настраивается через Index Sets: задаёте ротацию (по размеру индекса или по времени) и число хранимых индексов — например, ротация каждые сутки и хранение 30 индексов даёт примерно месяц логов. Индексы, вышедшие за пределы retention, автоматически удаляются или архивируются (в платной версии Graylog Enterprise есть архивация в S3, в открытой — только удаление или ручной экспорт). Дисковое пространство нужно закладывать с запасом: индекс живёт, пока не истечёт retention, и растёт нелинейно от объёма входящих логов.

В Loki retention настраивается проще — через limits_config.retention_period и (в микросервисном/simple-scalable режиме) через compactor, который сам вычищает устаревшие чанки. Ключевое отличие — Loki изначально проектировался под дешёвое долгосрочное хранение в объектном хранилище (S3, MinIO, GCS): чанки можно хранить месяцами при относительно скромном бюджете, потому что вы платите за сжатые данные, а не за раздутый полнотекстовый индекс. Если совмещаете с бэкапами — общие принципы ротации и хранения на диске одинаковы для любой системы логирования.

Поиск, алерты и работа в интерфейсе

Здесь начинается практическая разница, которую чувствуешь на реальном инциденте. В Graylog вы ищете как в Kibana — по любому полю, с полнотекстовым поиском по содержимому сообщения, с автодополнением значений, гистограммой по времени, сохранёнными поисками и dashboard-виджетами. Если нужно найти «все сообщения, где встречается конкретный ID транзакции, независимо от сервиса» — Graylog находит это за секунды.

В Loki философия другая: сначала фильтруете по labels (сервис, под, уровень, окружение) в LogQL — {job="nginx"} |= "500" — и только внутри уже отфильтрованного потока идёт построчный grep по тексту. Если labels подобраны с умом (не слишком много уникальных комбинаций — это «кардинальность», от которой Loki деградирует сильнее всего), поиск быстрый. Но если нужно искать конкретную строку по всей базе логов без привязки к меткам — это будет медленнее, чем в Graylog, особенно на больших объёмах.

По алертам: у Graylog есть встроенные Alert Conditions на уровне Streams (например, «более N ошибок за 5 минут») с уведомлениями в Slack/email/webhook из коробки. У Loki алерты строятся через LogQL-метрические запросы (rate({job="app"} |= "error" [5m])) и стандартный Alertmanager — то есть, если вы уже настроили алерты для Prometheus, добавить алерты по логам — вопрос ещё нескольких правил в том же формате, без изучения нового интерфейса.

Когда выбрать Graylog, а когда Loki

Graylog оправдан, когда:

• Нужен полнотекстовый поиск «по всему» без привязки к заранее продуманным меткам — например, разбор инцидентов безопасности, где ищут произвольные строки (IP, токены, сообщения об ошибках) по всей истории.
• Логи используются для комплаенса и аудита — есть готовые роли, права доступа на уровне Streams, экспорт в SIEM-формате.
• В команде есть опыт с Elasticsearch/OpenSearch и ресурсы на его обслуживание (мониторинг heap, реиндексация при росте).
• Нужны сложные Pipeline Rules — обогащение, парсинг, маршрутизация сообщений прямо на лету, без отдельного ETL.

Loki оправдан, когда:

• В стеке уже есть Grafana и Prometheus — хочется видеть логи и метрики рядом, в одном интерфейсе, с общими дашбордами.
• Бюджет на сервер ограничен, а объём логов растёт — Loki ощутимо экономит RAM и диск на том же потоке данных.
• Поиск в основном идёт по структурированным меткам (сервис, инстанс, уровень), а не по произвольному полнотекстовому запросу.
• Команда работает с Kubernetes — там Loki + Promtail (или Grafana Alloy) — де-факто стандартная связка для логов подов, естественно ложится поверх меток namespace/pod/container.

Если сомневаетесь, честный ориентир такой: если вы уже думаете «нам бы ELK, но подешевле» — скорее всего, вам нужен Loki. Если вы думаете «нам нужен полноценный SIEM с ролями и полнотекстовым поиском» — берите Graylog и закладывайте под него отдельный сервер с запасом по RAM. Альтернативный вариант между ними — Elasticsearch напрямую с Kibana, разница с Graylog разобрана в статье Grafana или Kibana: что выбрать для сервера.

Для обоих вариантов имеет смысл держать сбор логов на отдельном сервере, а не на том же, где крутится продакшен-приложение — так пиковая нагрузка на индексацию не влияет на отзывчивость основного сервиса, и удобнее контролировать доступ к логам отдельно от доступа к продакшену.

Частые вопросы