ELK vs Loki vs Graylog: что выбрать для логов на VDS

Если у вас на облачном VDS крутится несколько сервисов — от веб-сайта до фоновых воркеров — момент, когда «хватает tail -f», проходит быстро. Нужны центральное хранение, поиск, алерты, дашборды и внятная ретеншн‑политика. На рынке три самых частых варианта: ELK (Elasticsearch + Logstash + Kibana), Loki (Grafana Loki) и Graylog. Разберёмся, какой стек выбирать под разные нагрузки, бюджеты и сценарии эксплуатации на одном или нескольких VDS.

Коротко: что есть что

ELK: полнотекстовый поиск, мощные агрегации, зрелая экосистема. Главный минус на VDS — прожорливость по RAM/CPU и диску из‑за индексации. Отлично для расследований, аналитики, сложных дашбордов, безопасности и аудита.

Loki: индексируются только метки (labels), сами логи хранятся как сжатые чанки; запросы сканируют нужные чанки и фильтруют содержимое. Минимальные требования к ресурсам, дешёвое долгое хранение, идеальная связка с Grafana и Prometheus. Минус — не «поисковик документов», а система логов: сложные полнотекстовые кейсы делать труднее.

Graylog: удобная веб‑админка «из коробки», маршрутизация по потокам (streams), конвейеры парсинга (pipelines), встроенные приёмы Syslog/GELF, Sidecar‑агент для управления коллекторами. Хранилищем обычно служит Elasticsearch или совместимый движок, поэтому по ресурсам ближе к ELK, но в эксплуатации проще для команд, которым важен централизованный UI и ролевые права.

Критерии выбора для VDS

• Ресурсы: RAM/CPU/диск, поведение под пиками, предсказуемость.
• Хранение: формат, сжатие, ретеншн, «холодные» данные, резервное копирование.
• Запросы: язык, скорость поиска, сложность агрегаций, ад‑hoc аналитика.
• Интеграции: агенты и протоколы (Syslog, GELF, JSON, journald, Docker).
• Эксплуатация: развёртывание, обновления, мониторинг, алерты, мульти‑тенантность.

Ресурсы и ёмкость: насколько дружелюбны к VDS

ELK: мощь за цену ресурсов

Elasticsearch требует ощутимую память под heap и файловый кэш. На небольшой VDS (например, 4 vCPU / 8 GB RAM / быстрый SSD) можно уверенно держать небольшой объём логов и короткий ретеншн. С ростом cardinality по полям, сложных агрегаций и количества шардов потребности в RAM растут. Плюс Logstash сам по себе ресурсоёмок, хотя его можно заменить на Filebeat/Fluent Bit с парсингом на edge. Для стабильности: отключайте swap, следите за gc, подбирайте размер сегментов и политику ILM, ограничивайте поля, избегайте взрывного роста уникальных значений. Если только выбираете мощности — оцените, как выбрать конфигурацию VDS по CPU/RAM.

Loki: экономный хранитель

В Loki индексируются только labels. Это радикально снижает требования к CPU и RAM в сравнении с полнотекстовым индексатором. На VDS уровня 2 vCPU / 4 GB RAM Loki обычно чувствует себя уверенно для малых и средних проектов, а при аккуратной работе с лейблами выдерживает весьма бодрые потоки. Основные риски — «взрыв кардинальности» labels (например, вынесли user_id в label) и медленные запросы, если фильтровать приходится большие незакрытые интервалы времени. Решение — продуманная схема labels, строгие лимиты на размер/время чанков и здравый ретеншн.

Graylog: удобство плюс накладные от поискового бэкенда

Сам Graylog‑сервер относительно лёгкий, но основная нагрузка уходит в Elasticsearch/совместимый движок. На VDS по потреблению получается близко к ELK, зато выигрыш — в управляемости: потоки, pipelines, дешёвый вход через Syslog/GELF, гибкие роли. Для экономии ресурсов переносите как можно больше парсинга на агенты и не плодите поля без необходимости.

Если цель — самый дешёвый по ресурсам централизованный лог на VDS, чаще всего выигрывает Loki. Если нужен мощный полнотекстовый поиск с аналитикой и корреляцией — ELK. Если важна управляемость, роли и удобные конвейеры с простым UI — Graylog.

Хранение и ретеншн

ELK хранит документы с индексами. Это удобно для поиска и агрегаций, но индекс стоит места. В реальности суточный объём на диске зачастую в 1.5–3 раза больше исходного, в зависимости от количества полей, маппинга и компрессии. Ретеншн обычно реализуется через ILM: горячие индексы — частые запросы, холодные — дешёвое хранение, затем удаление. Бэкапы — snapshots. При проектировании закладывайте быстрые SSD и свободное место под сегментацию и слияния сегментов.

Loki хранит логи в сжатых чанках, индекс — миниатюрный. В среднем диск занимает меньше исходного за счёт эффективной компрессии; длительное хранение обходится заметно дешевле. Ретеншн гибко задаётся по tenant/stream, доступна сегрегация «горячего» и «холодного» хранения. Для бэкапов можно копировать объектное хранилище/каталоги чанков или использовать снапшоты блочного уровня. Главное — не допускать гигантской кардинальности по меткам: хранение будет дешёвым, а запросы быстрыми только при аккуратных labels.

Graylog использует индексные наборы (index sets) с ротацией по времени или размеру. Это упрощает ретеншн, но по диску и индексу наследует особенности Elasticsearch. Бэкапы — через снапшоты поискового бэкенда и резерв MongoDB (если используется).

Поисковые возможности и язык запросов

ELK (Lucene/KQL) — мастер сложных запросов, полнотекста, агрегатов, пайплайнов и визуализаций. Идеален, когда вам важны быстрые ответы на сложные «кто/что/когда/как часто» и корреляция событий по множеству полей.

Loki (LogQL) — фильтрация по labels и по содержимому строк. Сильная сторона — исследование временных серий логов и совместная работа с метриками. Подходит для SRE/DevOps‑паттернов «сначала метрика, затем прыжок в логи». Для тяжёлой текстовой аналитики по произвольным полям Loki не претендует на роль поисковой СУБД.

Graylog (собственный синтаксис на базе поискового бэкенда) — быстрые интерактивные запросы через UI, сохранённые поиски, алерты по потокам, трассировка по полям. Компромисс между мощью запроса и простотой использования.

Интеграции и агенты

• ELK: Beats (Filebeat, Metricbeat и т. д.), Logstash, Fluent Bit, natively JSON, journald, syslog. Широкая экосистема парсеров и поддержка форматов.
• Loki: Promtail, Fluent Bit с плагином, драйверы для Docker. Удобен сбор из journald, файлов, Kubernetes, Docker; лейблинг «с коробки».
• Graylog: Sidecar для централизованного управления агентами (например, Filebeat/Winlogbeat), приём Syslog и GELF, UDP/TCP, агрегация из разных источников с роутингом по потокам.

Практика показывает: максимально ранняя нормализация и фильтрация логов на источнике экономит и CPU, и RAM, и диск центральной системы, какой бы стек вы ни выбрали.

Типовые схемы на одном или нескольких VDS

Минимум для малого проекта

• Loki на одном VDS (2 vCPU / 4 GB RAM / SSD): Promtail на тех же узлах, ретеншн 7–14 дней. Отлично для веб‑сайта, пары приложений и nginx. Дешёво, просто, предсказуемо.
• ELK на одном VDS (4 vCPU / 8 GB RAM / быстрый SSD): Filebeat на источниках, краткий ретеншн (3–7 дней, зависит от потока), агрегации без тяжёлых join‑подобных сценариев. Для расследований и поиска по полям.
• Graylog на одном VDS (4 vCPU / 8 GB RAM), плюс бэкенд поиска: быстрое внедрение, простой UI, потоки и pipeline‑правила. Подходит командам с требованием ролевых доступов и централизованного управления.

Средний трафик

• Loki на двух VDS: один под ingester/querier/index‑gateway, второй под хранилище/кэш; или один узел под Loki, второй — под Grafana и вспомогательные сервисы. Ретеншн 14–30 дней, лейблы строго нормированы.
• ELK на двух VDS: разделить ingest‑нагрузку (Filebeat/Logstash) и Elasticsearch. Применить ILM, limit на поля, шаблоны индексов, снапшоты на отдельный диск.
• Graylog на двух VDS: Graylog‑сервер отдельно, бэкенд поиска отдельно. MongoDB — либо рядом, либо управляемый сервис. Index sets с ротацией по времени/размеру.

Когда узкое место — диск

Для VDS с ограниченными SSD чаще выигрывает Loki: высокий коэффициент сжатия, минимальный индекс. В ELK/Graylog в этом случае спасают агрессивная фильтрация на источниках, отказ от лишних полей, короткий ретеншн и вынос «холодных» индексов. Отдельно проверьте настройки TRIM и монтирования: поможет гайд по fstrim/discard для SSD.

О рисках и предсказуемости

• ELK: следите за cardinality полей, количеством шардов, heap size, gc‑паузами; ограничивайте глубину вложенных структур; включайте лимиты на поля.
• Loki: не поднимайте labels с высокой кардинальностью (user_id, request_id на уровне label). Нормализуйте: такие значения оставляйте в строке логов, а в labels — только стабильные ключи (service, instance, env, status). Подробнее о дизайне меток — в статье как спроектировать labels и пайплайны в Loki.
• Graylog: индексные наборы под потоки с разным профилем; следите за нагрузкой на бэкенд поиска; используйте Sidecar для единых конфигов агентов.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Алертинг и наблюдаемость

В ELK алерты гибкие и «данные‑центричные»: можно реагировать на сложные условия и аномалии. В Loki алерты органично встраиваются в мир Prometheus/Grafana: часто строится метрика из логов и уже по ней ставится правило. В Graylog удобно триггерить по потокам/запросам, рассылать уведомления и вести расследования через сохранённые поиски.

Безопасность и доступы

Все три стека поддерживают TLS на входе и внутри, аутентификацию и ролевую модель. На VDS стоит включать mTLS для агент‑>инжестер, закрывать внешним фаерволом внутренние порты, ограничивать доступ к дашбордам и писать политику логирования персональных данных (маскирование чувствительных полей на входе).

Эксплуатация, бэкапы, обновления

• Бэкапы: для ELK/Graylog — snapshots поисковой составляющей; для Loki — копирование чанков/объектного хранилища или блочные снапшоты дисков.
• Обновления: держите совместимость компонентов (агенты/сервер); тестируйте на стейджинге с реплеем небольшой выборки логов.
• Мониторинг: экспортируйте метрики работы индексатора, очередей, ошибок парсинга, скоростей записи/чтения, времени ответа запросов и процентиля.

Небольшие примеры конфигураций

Promtail: базовый сбор nginx‑логов в Loki

server:
  http_listen_port: 9080
  grpc_listen_port: 0

clients:
  - url: http://127.0.0.1:3100/loki/api/v1/push

positions:
  filename: /var/lib/promtail/positions.yaml

scrape_configs:
  - job_name: nginx
    static_configs:
      - targets: [localhost]
        labels:
          job: nginx
          service: web
          env: prod
          __path__: /var/log/nginx/access.log
    pipeline_stages:
      - regex:
          expression: '^(?P<ip>\S+) \S+ \S+ \[(?P<ts>[^\]]+)\] "(?P<method>\S+) (?P<path>\S+) \S+" (?P<status>\d+) (?P<bytes>\d+).*$'
      - labels:
          status:
          method:

ELK: зачаточная политика ILM

{
  "policy": {
    "phases": {
      "hot": {"actions": {"rollover": {"max_size": "20gb", "max_age": "2d"}}},
      "warm": {"min_age": "3d", "actions": {"shrink": {"number_of_shards": 1}}},
      "delete": {"min_age": "14d", "actions": {"delete": {}}}
    }
  }
}

Стоимость владения на VDS: что съедает бюджет

В реальности платите не только за CPU/RAM, но и за диск и трафик. ELK дороже по диску и памяти; Loki выигрывает в длительном хранении и компактности; Graylog добавляет удобство администрирования, но несёт стоимость бэкенда поиска. При одинаковом потоке логов Loki чаще позволяет держать более длительный ретеншн на том же объёме SSD.

Кому что

• Берите ELK, если вам критичны полнотекст, богатые агрегации, расследования инцидентов, аналитика по множеству полей и сложные дашборды.
• Берите Loki, если ключевое — дешёвый по ресурсам централизованный сбор, быстрая навигация по labels, связка с метриками и длительный ретеншн на VDS.
• Берите Graylog, если нужна дружелюбная панель с потоками, pipelines, ролями, быстрым стартом под Syslog/GELF и централизованным управлением агентами.

Мини‑чек‑лист внедрения на VDS

1. Опишите цели: поиск по полям, алерты, ретеншн, RPO/RTO, роли, аудит.
2. Считайте бюджет логов: строки в секунду, средняя длина, пик, доля шума.
3. Фильтруйте на источнике: отбрасывайте шум, нормализуйте поля, маскируйте чувствительное.
4. Планируйте ретеншн: горячие/тёплые/холодные данные, сроки хранения, политика удаления.
5. Выберите стек: исходя из требований к поиску, ресурсу VDS и бюджету диска.
6. Настройте мониторинг: метрики ingest, задержек, ошибок парсинга, времени ответов.
7. Регулярные бэкапы и тест восстановления; планы обновлений компонентов.
8. Безопасность: TLS везде, rbac, сегментация сети, минимизация открытых портов.

Типичные ошибки и как их избежать

• Слишком много полей в ELK/Graylog: ограничивайте списком разрешённых, используйте шаблоны маппинга.
• Кардинальность labels в Loki: не тащите динамические идентификаторы в labels.
• Отсутствие ретеншна: внезапно кончается диск. Всегда задавайте срок хранения и лимиты размера.
• Нулевая фильтрация: вы платите за каждый байт. Сокращайте шум DEBUG/TRACE на источнике.
• Нет бэкапов: особенно опасно при одиночном VDS. Делайте снапшоты регулярно.

Итог

На одном или нескольких VDS можно комфортно жить с любым из трёх стеков — вопрос в приоритетах. ELK — когда нужна аналитика и мощный поиск. Loki — когда важны экономия ресурсов, связка с метриками и длительное хранение. Graylog — когда первичны централизованный UI, удобные pipelines и роли. Начните с формулировки целей, прикиньте бюджет логов и ретеншн, затем сопоставьте с ресурсами VDS — и вы быстро придёте к решению, которое будет надёжно работать и предсказуемо масштабироваться.