Единого победителя в сравнении систем централизованного логирования нет. Elastic Stack, Graylog, Loki и OpenSearch решают одну задачу: собрать события с десятков и сотен хостов и дать по ним поиск. Различия лежат в модели хранения, языке запросов и эксплуатационной стоимости, и именно они определяют, во сколько обойдётся диск, сколько инженеров потребуется и за какой срок вы увидите первый лог из продакшена.
Точка отсчёта для сравнения - Elasticsearch. Это распределённая поисковая и аналитическая система на базе Apache Lucene: она индексирует документы, ищет по тексту, фильтрует события, собирает метрики и хранит журналы (разбор индексов, mapping и запросов Elasticsearch). Данные лежат в JSON-документах, документы объединяются в индексы, поля получают типы и правила обработки через mapping. Индекс распределяется по шардам, реплики хранят копии для отказоустойчивости, а поиск работает сразу по нескольким индексам.
Короткий ответ на главный вопрос: для Kubernetes и экономии диска чаще берут Loki, для аудита и полнотекстового поиска - Elastic Stack или OpenSearch, для быстрого старта без своей команды эксплуатации - Graylog. Дальше разбираем, из чего складывается этот выбор.
Как мы сравниваем системы логирования: критерии вместо маркетинга
Сравниваем для продакшена, где логи измеряются терабайтами в месяц, retention задан политикой, а поиск нужен в момент инцидента. Пет-проект с одним контейнером к таким нагрузкам отношения не имеет, и выводы для него будут другими.
Шесть критериев, которые реально влияют на выбор
| Критерий | Что определяет на практике |
|---|---|
| Модель хранения: индексы или чанки | Объём диска на год логов, стоимость retention, скорость поиска по содержимому |
| Язык запросов | Время дебага и расследований, возможность автоматизировать запросы из кода |
| Требования к ресурсам (CPU, RAM, диск, IOPS) | Бюджет на железо или облако, минимальный размер кластера |
| Сложность эксплуатации: кластер, бэкапы, обновления | Постоянная нагрузка на команду, риск деградации в момент инцидента |
| Порог входа | Время до первого лога, который можно найти поиском |
| Лицензия и стоимость владения | Юридические риски и цена владения на горизонте двух-трёх лет |
Каждый критерий проверяется вопросом к своей инфраструктуре. Модель хранения отвечает за то, сколько диска уйдёт на год логов; язык запросов - сколько минут займёт расследование; ресурсы - сколько денег нужно на ноды; эксплуатация показывает недельную нагрузку на команду; порог входа определяет, когда система начнёт приносить пользу; лицензия снимает или создаёт юридический риск при коммерческом использовании.
Набор применим ко всем четырём системам. Для Loki модель хранения отвечает за дешёвый диск, а язык запросов определяет, придётся ли сканировать содержимое чанков. У Graylog часть критериев наследуется от движка под капотом, а часть относится к самой платформе.
Кому и когда это сравнение не нужно
Если у вас меньше пяти сервисов и логи читаются через journalctl или docker logs, централизованное логирование пока избыточно: настройка и поддержка съедят больше времени, чем сэкономят. Вернитесь к вопросу, когда появятся несколько хостов и потребность искать события сразу по всем.
Второй случай - жёсткая привязка к одному стеку без планов его менять. Миграция ради миграции увеличивает риск и почти не даёт выгоды.
Elastic Stack: индексы, Query DSL и полнотекстовый поиск
Elastic Stack - это связка Elasticsearch, Logstash или Beats и Kibana. Хранение, поиск и аналитика приходятся на Elasticsearch, Kibana даёт интерфейс, Beats и Logstash отвечают за доставку и разбор событий.
Модель хранения: индексы, шарды, реплики
Индекс - логическая единица хранения, шард - физическая часть индекса, реплика - копия шарда. Число шардов и реплик задают при создании индекса, и пересмотр этого решения на живом кластере требует переиндексации данных. Для логов ориентир при планировании: один шард на 30-50 ГБ данных и одна реплика на продакшене. Шардов больше - параллельнее поиск, но выше накладные расходы на кластер и дороже retention.
Индексы проектируют через mapping, шаблоны, data streams и aliases: прежняя модель types в современных версиях не используется. Create Index API позволяет передать настройки, mapping и aliases одним запросом, а для массовой загрузки логов применяют Bulk API (индексы, шаблоны и Bulk API в Elasticsearch).
Query DSL и типовые запросы для логов
Query DSL - язык запросов в формате JSON, а не SQL. Для автоматизации это плюс: запрос удобно собирать кодом, хранить в репозитории и отправлять через REST API по HTTP или официальный клиент для Python, Java, JavaScript, Go, .NET.
GET logs-app-*/_search
{
"query": {
"bool": {
"filter": [
{ "term": { "service.keyword": "billing" } },
{ "term": { "level": "error" } },
{ "range": { "@timestamp": { "gte": "now-1h" } } }
]
}
}
}
Поиск по фразе в тексте сообщения:
GET logs-app-*/_search
{
"query": {
"match_phrase": { "message": "connection refused" }
}
}
Агрегация по сервисам за сутки, чтобы увидеть, кто генерирует больше всего событий:
GET logs-app-*/_search
{
"size": 0,
"aggs": {
"by_service": { "terms": { "field": "service.keyword", "size": 20 } }
}
}
Обратите внимание на суффикс .keyword. Elastic рекомендует не применять поле типа text для полнотекстового поиска, а выбирать keyword для фильтрации, сортировки и агрегаций. Практический вывод для логов: message держите в text, а service, level, host и namespace - в keyword, иначе агрегации будут разбирать строку на токены и терять точность.
Тот же принцип видно на примере каталога товаров: название хранят в поле типа text, чтобы искать по словам, а артикул или бренд - в keyword, чтобы фильтровать и сортировать без анализа. Логи устроены так же: сообщение ищут текстом, атрибуты группируют по keyword.
Отдельно стоит помнить о границах применимости: Elasticsearch хорошо хранит данные для поиска, но не заменяет реляционную СУБД во всех сценариях. Для транзакций, сложных связей и строгой целостности обычно используют PostgreSQL или MySQL, а поисковый слой подключают отдельно.
Когда Elastic Stack выигрывает
- Поиск по подстроке и фразам в миллионах строк, когда нужно найти редкое исключение в стектрейсе.
- Аудит и расследования: логи разносятся по индексам, а запрос идёт сразу по нескольким индексам.
- Аналитика по событиям и связка с SIEM.
- Векторный поиск: Elastic описывает Elasticsearch как поисковый и аналитический движок, масштабируемое хранилище и векторную базу данных (позиционирование Elasticsearch), что расширяет сценарии за пределы логов.
Обратная сторона: кластер на JVM требует внимания к heap, watermarks и распределению шардов. Команде нужен хотя бы один человек, который понимает, что происходит при появлении нераспределённых шардов.
OpenSearch: форк Elasticsearch и его отличия на практике
OpenSearch появился как форк Elasticsearch 7.10.2 после смены лицензии Elastic на SSPL. Модель индексов, шардов, реплик и Query DSL унаследована, но проект развивается отдельно, при поддержке AWS.
Лицензия и вендор-лок: что важно для бизнеса
Elasticsearch распространяется под Elastic License 2.0 и SSPL, OpenSearch - под Apache 2.0. Для внутреннего использования разница почти не проявляется. Для сервиса, который вы предоставляете клиентам на базе поискового движка, SSPL ограничивает такое предоставление без отдельной договорённости с вендором. Apache 2.0 подобных ограничений не содержит.
Второй фактор - вендор-лок. Один поставщик диктует темп релизов, состав плагинов и условия лицензии. Форк снижает этот риск: код доступен под Apache 2.0, совместимость с API сохраняется. Цена - расхождения в составе возможностей и другой набор плагинов.
OpenSearch vs Elasticsearch: что выбрать в 2026
| Параметр | Elasticsearch | OpenSearch |
|---|---|---|
| Лицензия | Elastic License 2.0, SSPL | Apache 2.0 |
| Происхождение | Разработка Elastic | Форк Elasticsearch 7.10.2 |
| Веб-интерфейс | Kibana | OpenSearch Dashboards |
| Язык запросов | Query DSL | Query DSL и PPL (Piped Processing Language) |
| Векторный поиск | Развивается вендором | Реализован, состав возможностей отличается |
| Поддержка | Elastic и партнёры | AWS и сообщество |
Прямая рекомендация. Уже работаете на Elasticsearch и лицензия устраивает - не мигрируйте без причины, миграция занимает недели. Строите с нуля и юридически важна Apache 2.0 - берите OpenSearch. Нужны максимальная экосистема, векторный поиск и облачные сервисы вендора - Elasticsearch.
Для логов OpenSearch ведёт себя как Elasticsearch: индексы, mapping, data streams, политики жизненного цикла. Добавляются PPL как альтернатива Query DSL и встроенные security-плагины, вместо Kibana работает OpenSearch Dashboards.
Чек-лист перед миграцией Elasticsearch в OpenSearch: версия исходного кластера, список плагинов, кастомные анализаторы, шаблоны индексов, политики жизненного цикла, дашборды, алерты, роли и права. Расхождения обычно всплывают на плагинах и анализаторах, а не на самих запросах.
Graylog: компромисс с готовым веб-интерфейсом и обработкой потоков
Graylog - платформа поверх Elasticsearch или OpenSearch. Модель хранения наследуется от движка под капотом, а ценность добавляется на уровне интерфейса, обработки сообщений и прав доступа.
Streams, pipelines и extractors: что это даёт на практике
Stream - группа сообщений по правилу, pipeline - цепочка правил обработки, extractor - извлечение полей из неструктурированного текста. Пример: лог Nginx разбирается extractor'ом, попадает в stream «nginx», в pipeline получает дополнительное поле и уходит в алерт по коду 5xx. В чистом Elastic Stack то же самое требует конфигов Logstash или ingest-пайплайнов.
rule "tag_nginx_5xx"
when
has_field("status")
then
set_field("status_class", to_string(to_long($message.status) / 100));
end
Язык запросов в Graylog похож на синтаксис Lucene, поэтому привычные фильтры вроде level:error и message:"timeout" переносятся из Kibana почти без правок. Парсинг и обогащение живут в pipeline, а не в отдельном сервисе, и это экономит один компонент в схеме.
Когда Graylog выигрывает
Сценарии: небольшая команда без выделенного инженера по логам, нужен быстрый старт, важна встроенная обработка потоков, требуются алерты и RBAC из коробки. Развёртывание через docker-compose поднимается за вечер, и это закрывает возражение «слишком сложно».
Ограничения тоже стоит учитывать: гибкость кастомных анализаторов ниже, чем в Elasticsearch, движок хранения всё равно требует ресурсов и обслуживания, а часть возможностей вроде расширенного управления пользователями и потоками относится к коммерческим редакциям.
Loki: экономия диска и нативная работа с Kubernetes
Loki создан в Grafana Labs с идеей, обратной Elasticsearch: индексируются не документы, а только метки потоков. Содержимое логов сжимается в чанки и складывается в объектное хранилище - S3, GCS или MinIO. Язык запросов - LogQL, синтаксически близкий к PromQL.
Чанки vs индексы: почему Loki экономит диск
В Elasticsearch индекс строится по каждому полю каждого документа, и размер поискового индекса может быть сопоставим с объёмом самих данных. Loki индексирует набор меток (namespace, pod, container, app), а тело лога лежит в сжатом чанке. Порядок экономии, на который ссылаются при выборе, - в 5-10 раз по диску; точную цифру даёт только замер на ваших логах, потому что она зависит от кардинальности меток и степени сжатия сообщений.
Компромисс предсказуем: поиск по содержимому требует чтения чанков за выбранный интервал, поэтому фильтр по подстроке работает медленнее, чем в Elasticsearch, и тем медленнее, чем шире временное окно. Чем больше уникальных значений меток, тем крупнее индекс и тем дороже эксплуатация.
LogQL: язык запросов для логов
{namespace="prod", app="api"} |= "error"
sum by (pod) (rate({namespace="prod"} |= "timeout" [5m]))
Селектор меток обязателен, фильтр по содержимому добавляют операторами |=, != и |~. Для тех, кто уже работает с Prometheus, синтаксис знаком: те же селекторы и функции rate, sum by, topk. Алерты в Grafana строятся по этим же выражениям, поэтому переключение между метриками и логами не требует нового мышления.
Loki или Elasticsearch для логов: прямой ответ
Kubernetes и приоритет стоимости хранения - Loki. Полнотекстовый поиск, аудит и расследования - Elasticsearch или OpenSearch. Нужны оба сценария - держите Loki для оперативных логов и Elasticsearch для аудита, но учитывайте удвоение инфраструктуры и двойную отправку событий.
Сравнительная таблица: Elastic Stack, Graylog, Loki и OpenSearch
| Критерий | Elastic Stack | OpenSearch | Graylog | Loki |
|---|---|---|---|---|
| Модель хранения | Индексы, шарды, реплики | Индексы, шарды, реплики | Индексы движка под капотом | Метки плюс сжатые чанки в объектном хранилище |
| Язык запросов | Query DSL (JSON) | Query DSL, PPL | Lucene-подобный синтаксис, pipeline-правила | LogQL, близок к PromQL |
| Ресурсы, ориентир | 3 и более нод, 8-16 ГБ RAM, JVM heap около половины RAM, SSD с высоким IOPS | Те же, что у Elasticsearch | Ноды Graylog, MongoDB и кластер движка | 1-2 ноды, 4-8 ГБ RAM, объектное хранилище |
| Эксплуатация | Снапшоты, rolling upgrade, контроль шардов | То же плюс свои плагины | Бэкап MongoDB и движка, обновление пакетами | Бэкап объектного хранилища, обновление через Helm |
| Порог входа | 1-2 дня до первого лога | 1-2 дня | Около дня, интерфейс из коробки | Часы, особенно в Kubernetes |
| Лицензия | Elastic License 2.0, SSPL | Apache 2.0 | Graylog Open и коммерческие редакции | AGPLv3 |
Проверенная фактура в этом материале покрывает внутреннее устройство Elasticsearch: индексы, mapping, шарды, реплики, Query DSL, Bulk API. Детали Graylog, Loki и OpenSearch, а также конкретные условия лицензий и ориентиры по железу сверяйте с официальной документацией проектов и актуальными текстами лицензий: они меняются от версии к версии.
Требования к ресурсам: ориентиры для продакшена
Для Elasticsearch и OpenSearch планируют минимум три ноды, чтобы выдержать потерю одной, 8-16 ГБ RAM на ноду, из которых heap JVM обычно берут около половины и не выше 31 ГБ, и SSD с высоким IOPS. Для логов диск и IOPS важнее CPU: запись идёт потоком, а тяжёлые агрегации по большим окнам упираются в чтение с диска.
Graylog требует ресурсов под движок хранения плюс ноды под сам сервер и MongoDB. Loki обходится дешевле: 1-2 ноды под компоненты и объектное хранилище под чанки, запас RAM нужен для кэша запросов, а не для индекса.
Все цифры - ориентиры для планирования, а не гарантия. Реальные значения зависят от объёма, размера сообщений, кардинальности меток и глубины запросов. Прогоните свой профиль нагрузки на тестовом стенде перед закупкой железа.
Сложность эксплуатации: бэкапы, обновления, мониторинг
Elasticsearch и OpenSearch: снапшоты индексов в S3 или совместимое хранилище, rolling upgrade по нодам, мониторинг через экспортёры метрик. Основная сложность - состояние кластера: распределение шардов, пороги по диску, ребалансировка после сбоя ноды.
Graylog: бэкап MongoDB плюс бэкап кластера движка, обновление пакетами, меньше ручных операций с шардами. Loki: бэкап сводится к политикам объектного хранилища, обновление идёт через Helm-чарт, компонентов меньше, и это снижает недельную нагрузку на команду.
Сравнить готовые схемы развёртывания и конфигурации можно в материале о выборе стека логирования от Elastic Stack до Grafana Loki.
Сценарии выбора: что брать под вашу инфраструктуру
- Kubernetes-кластер, важна стоимость хранения: Loki. Метки снимаются автоматически, чанки лежат в дешёвом объектном хранилище.
- Аудит и расследования, нужен полнотекстовый поиск: Elastic Stack или OpenSearch.
- Небольшая команда, нужен быстрый старт и интерфейс из коробки: Graylog.
- Строите с нуля, критична лицензия Apache 2.0: OpenSearch.
- Уже используете Prometheus и Grafana: Loki, потому что LogQL не потребует нового языка.
- Аналитика событий, SIEM, векторный поиск: Elastic Stack.
Система сбора логов для Kubernetes: почему чаще выбирают Loki
Promtail работает как DaemonSet, читает stdout контейнеров и обогащает записи метками namespace, pod, container, node. Метки ускоряют фильтрацию, чанки в объектном хранилище держат стоимость низкой, а Grafana становится единым окном для метрик и логов. Границы решения: если нужен поиск по содержимому в глубину нескольких суток, Loki будет сканировать чанки, и запрос может не уложиться в разумное время. Альтернатива для полнотекстового поиска - Fluent Bit плюс Elasticsearch или OpenSearch.
Чек-лист для Kubernetes: нужен ли полнотекстовый поиск или хватит фильтра по меткам, какой объём логов в сутки, где разместите объектное хранилище, какой retention нужен, кто отвечает за алерты и как проверить, что агент не потерял поток.
Готовые конфигурации для Kubernetes, включая схемы отказоустойчивых пайплайнов, собраны в статье ELK vs Loki vs Graylog в 2026: сравнение, архитектура, конфиги для Kubernetes.
Когда Elastic Stack или OpenSearch выигрывают
Аудит безопасности, расследование инцидентов, поиск по подстроке в миллионах строк, аналитика по событиям, связка с SIEM. Разделение по индексам даёт ещё один плюс: логи billing и frontend можно держать отдельно, а запрос выполнять сразу по обоим индексам.
Миграция между системами логирования: что учесть
Основные маршруты: Elasticsearch в OpenSearch, Elasticsearch в Loki, Graylog в Elastic Stack. Каждый требует своей подготовки и своего плана отката.
Elasticsearch в OpenSearch: совместимость версий, плагины, кастомные анализаторы, шаблоны и политики жизненного цикла. Elasticsearch в Loki: пересмотр модели меток и отказ от полнотекстового поиска, фильтры придётся переписать в селекторы LogQL. Graylog в Elastic Stack: pipeline-правила переносятся в Logstash или ingest-пайплайны, часть логики обогащения придётся собирать заново.
Самый безопасный способ - двойная запись: агенты шлют события в старую и новую систему параллельно, вы сверяете полноту и только затем отключаете старую. Цена - удвоенная нагрузка на диск и сеть на время миграции.
Чек-лист перед миграцией
- Инвентаризация источников логов и их форматов.
- Проверка парсеров, extractors и pipeline-правил.
- Оценка суточного объёма и требуемого retention.
- Тестовый стенд с реальными логами, а не с синтетикой.
- Двойная запись и сверка полноты событий.
- Проверка типовых запросов, дашбордов и алертов.
- План отката и критерий, при котором вы его включаете.
- Обучение команды новому языку запросов.
Без плана отката миграцию начинать нельзя. Это проект на недели, а не на вечер. Архитектуру конвейера и типовые ошибки при переносе разбираем в статье о централизованном сборе и анализе логов в 2026 году.
Итог: как выбрать систему логирования под свою инфраструктуру
- Определите, нужен ли полнотекстовый поиск по содержимому или хватит фильтра по меткам и полям.
- Оцените суточный объём логов, требуемый retention и бюджет на диск.
- Проверьте, есть ли у вас Kubernetes: там Loki даёт максимальную отдачу.
- Оцените ресурсы команды: кто будет обслуживать кластер, бэкапы и обновления.
- Проверьте лицензионные ограничения под ваш способ использования.
Финальные рекомендации: для Kubernetes и экономии диска - Loki; для аудита и полнотекстового поиска - Elastic Stack или OpenSearch; для быстрого старта со встроенной обработкой потоков - Graylog. Универсально лучшей системы нет, есть подходящая под вашу инфраструктуру.
Разверните тестовый стенд на docker-compose или через Helm на своих логах и сравните двух финалистов по трём метрикам: объём диска на 1 ТБ принятых событий, медиана времени ответа на типовой запрос и время от запуска до первого найденного события. Решение принимайте по этим цифрам. Практические приёмы для подготовки логгеров и ротации описаны в руководстве об эффективном логировании для DevOps.