Централизованные логи давно перестали быть «приятным бонусом». Как только появляется несколько серверов, контейнеров и окружений, задача превращается в инженерную: собирать nginx logs, system logs и логи приложений, держать разумный log retention, быстро искать инциденты и не разориться на хранении.
На практике чаще всего спорят два подхода:
- Grafana Loki + Promtail + Grafana: индекс «по-минимуму», упор на дешёвое хранение и быстрый доступ к потокам.
- OpenSearch: «поиск и аналитика по всему», мощные агрегации и произвольные запросы, но дороже по ресурсам и сложнее в эксплуатации.
Ниже — практичное сравнение без религии: когда Loki действительно удобнее, когда без OpenSearch будет больно, и как не ошибиться с архитектурой.
Модель данных и индекс: главная разница
Ключевой вопрос — что именно вы индексируете. От этого зависит стоимость хранения, скорость запросов и то, насколько «свободно» можно расследовать инциденты.
Loki: индекс по меткам, текст — в чанках
Loki хранит строки логов как данные в чанках, а индекс строит в основном по labels (меткам). На практике это означает:
- дёшево и быстро фильтровать потоки по метаданным:
job,host,app,namespace,env; - поиск по тексту возможен, но это сканирование чанков внутри выбранного набора меток;
- если «раздуть» метки (например, сделать меткой
request_idилиuser_id), индекс вырастет лавинообразно и Loki станет тяжелее, чем ожидалось.
Вывод: Loki выигрывает, когда вы заранее описываете лог-потоки «крупными» метками и чаще ищете в рамках понятного среза (сервис, хост, окружение).
OpenSearch: индексирует поля и текст, платите ресурсами
OpenSearch рассчитан на индексацию документов (обычно JSON) и быструю работу «по любому полю». Это даёт:
- мощный полнотекстовый поиск по сообщению;
- агрегации/аналитику по множеству полей (status code, upstream, latency и т.д.);
- контроль схемы через маппинги, но ценой RAM/CPU/IO и большей операционной сложности.
Вывод: OpenSearch выигрывает, когда логи — это «данные для расследований и аналитики», а не просто поток сообщений.
Вопрос, который обычно решает спор: вам нужно быстро «смотреть логи сервиса» или строить «поисковую базу событий» с тяжёлой аналитикой и произвольными запросами?
Сбор логов: Promtail и реальность на серверах
В связке с Loki чаще всего используют Promtail: агент читает файлы логов, добавляет метки и отправляет строки в Loki. Для OpenSearch-стека в реальной жизни чаще встречаются Fluent Bit, Vector или Logstash — с более гибкими трансформациями, но и с большей сложностью настройки.
Promtail: сильные стороны
- Быстрый старт: прочитал файл, добавил метки, отправил.
- Пайплайны: можно распарсить строку и аккуратно извлечь пару значимых меток.
- Хорошо ложится на типовые случаи: access/error логи Nginx, логи приложений, сервисы, пишущие в файлы.
Слабые места, о которых забывают
- Кардинальность меток: хочется пометить всё (IP, URI, request id), но это частая архитектурная ошибка. Метка должна быть «грубым» измерением, а не уникальным значением почти на каждую строку.
- journald/systemd: можно читать напрямую или через экспорт в файл, но важно понять, где у вас «истина», как устроены перезапуски и что будет при потере буфера.
- Ротации: многие проблемы начинаются не от нагрузки, а от нестандартных ротаций/симлинков/переименований. Тестируйте именно ваш сценарий logrotate и поведение агента.
Если вы планируете собирать логи с нескольких хостов и хотите предсказуемые ресурсы под хранение и приём, часто удобнее разнести роли (приём/хранение/визуализация) на отдельные узлы или хотя бы на отдельную машину. Для таких задач обычно выбирают VDS, чтобы не конкурировать за диск и CPU с приложением.
Поиск и запросы: LogQL против OpenSearch DSL
Loki и LogQL: быстро, если правильно размечено
Типичный запрос в Loki начинается с выбора потока по меткам, затем идёт фильтрация по содержимому и простые агрегации. Это отлично подходит для задач:
- «покажи ошибки конкретного сервиса за последние 15 минут»;
- «в каких подах/на каких хостах сейчас сыпятся 502»;
- «топ сообщений по частоте» в рамках выбранного среза.
Если же вы хотите «гулять» по логам без предварительного ограничения метками, делать сложные выборки по десяткам полей и строить ad-hoc аналитику, Loki чаще будет упираться в необходимость сканировать большие объёмы текста.
Отдельная боль, с которой сталкиваются почти все: «сделали меткой то, что не должно быть меткой». Полезно иметь внутренние правила по labels и пайплайнам — иначе через месяц в системе тяжело работать. В тему: как проектировать labels и пайплайны Loki без взрыва кардинальности.
OpenSearch: когда нужен «настоящий поиск»
OpenSearch хорош там, где расследование похоже на работу с базой событий:
- много структурированных полей (JSON-логи, единая схема);
- сложные агрегации, группировки, фильтры, сортировки;
- запросы вида «дай события, где A и B, но не C»;
- длинные расследования и ретроспектива на больших объёмах.
Цена — ресурсы и дисциплина: индексы, шардирование, маппинги, контроль размеров, жизненный цикл индексов и регулярные снапшоты.
Log retention: хранение, стоимость и «сколько дней держать»
В логах retention почти всегда про два разных решения:
- Сколько дней хранить (регламент, безопасность, аудит).
- Сколько это стоит и насколько быстро должны выполняться запросы к «истории».
Loki: сильный сценарий — дешёвое хранение
Loki хорошо чувствует себя, когда вы стремитесь к дешёвому хранению и заранее ограничиваете область поиска метками. Типичный рабочий сценарий: держать 14–30 дней «горячих» логов, и при необходимости расширять retention, понимая, что поиск по тексту будет тем медленнее, чем шире выбранный срез.
Практическая рекомендация: если ваш основной запрос — «сервис/хост/окружение, покажи ошибки», а retention нужен «подлиннее», Loki часто заметно экономичнее.
OpenSearch: retention как управление индексами
В OpenSearch retention обычно делается политиками жизненного цикла: ежедневные индексы, перевод в read-only, перенос на более дешёвые ноды, удаление. Это мощно, но требует:
- планирования числа шардов и целевого размера индекса;
- контроля маппингов (иначе индекс раздувается неожиданно быстро);
- достаточной RAM для кэшей и стабильного диска/IO.
Если вы обязаны держать большие объёмы логов в режиме «быстро искать по любому полю», OpenSearch справится, но вы будете платить железом и временем администрирования.
Nginx logs и system logs: что удобнее в типовых задачах
Nginx access/error: чаще выигрывает Loki для ежедневного просмотра
Для большинства веб-проектов запросы к nginx logs обычно такие: «почему 502», «какой upstream падает», «кто долбит», «где выросла латентность». Если формат логов стабилен и вы размечаете потоки метками (host, vhost, env, service), Loki + Grafana дают очень удобный ежедневный UX: быстро отфильтровать, посмотреть хвост, построить простую статистику.
Но если вам нужна полноценная аналитика по access-логам как по событийной базе (сложные разрезы, произвольные агрегации, регулярные отчёты) — OpenSearch логичнее, особенно если вы пишете access-логи в JSON и поддерживаете единую схему.
Если Nginx стоит за CDN/балансировщиком, сначала убедитесь, что корректно восстанавливаете IP клиента, иначе аналитика по источникам будет мусорной. В тему: как правильно настроить real IP за прокси и CDN для логов.
System logs: зависит от того, «смотреть» или «расследовать»
System logs (journald/syslog) чаще нужны, чтобы быстро ответить «что случилось на хосте» и «что менялось». Для таких сценариев Loki удобен при условии хороших меток (host, unit, severity) и понятного retention.
OpenSearch становится интереснее, когда вы превращаете системные события в «аудитные записи» и хотите глубоко коррелировать их с приложениями и пользователями: то есть когда лог — это документ с полями, и расследование требует сложных запросов.
Ресурсы и эксплуатация: где меньше сюрпризов на VDS
На ограниченных ресурсах чаще «выживает» Loki — если не злоупотреблять метками и не пытаться сделать из него поисковик. OpenSearch же требует дисциплины по ресурсам и данным с первого дня, иначе проблемы почти гарантированы.
Loki: типовые узкие места
- взрыв кардинальности из-за неправильных labels;
- слишком большой объём логов без лимитов и без фильтрации на агенте;
- рост нагрузки при широких запросах без предварительного среза метками.
OpenSearch: что обычно «болит»
- память: кэши, стабильность под нагрузкой;
- диски: индекс раздувается быстрее ожидаемого;
- операционка: шардирование, ребаланс, маппинги, обновления, снапшоты.
Если у вас 1–3 сервера и задача «просто centralized logging для веб-проектов», OpenSearch часто оказывается избыточным по сложности. Если же логи — критичный источник аналитики/аудита, много команд и сложные расследования — сложность оправдана.
Для небольших проектов, где нужен «включил и работает» без отдельного администрирования кластера, проще стартовать на виртуальном хостинге с выносом логов на отдельный узел только по мере роста. Так вы не переплачиваете за инфраструктуру до тех пор, пока объёмы и требования не заставят масштабироваться.
Надёжность, бэкапы и восстановление
Логи кажутся «необязательными» ровно до первого серьёзного инцидента. Поэтому заранее решите, как переживать сбои и как восстанавливаться.
Loki
- Если хранение вынесено в объектное хранилище, потеря одной ноды обычно менее критична.
- Важна консистентность индекса: понимайте, где лежат индекс и чанки, как обеспечивается репликация и что будет при частичном падении.
- Агент должен переживать перезапуски и временную недоступность приёмника (очередь, повторы, контроль потерь).
OpenSearch
- Обычно опираются на репликацию шардов плюс регулярные снапшоты.
- Восстановление зависит от размеров индексов и пропускной способности дисков/сети.
- Без регулярных снапшотов вы в какой-то момент обнаружите, что «бэкапа нет», даже если кластер был «зелёным».
Практическая матрица выбора
Ниже — прикладные критерии. Это не «истина», а рабочий ориентир, который помогает принять решение.
Выбирайте Grafana Loki + Promtail + Grafana, если
- нужен centralized logging для инфраструктуры и веб-проектов, а не «поисковая система событий»;
- основные источники — nginx и system логи, плюс логи приложений;
- вы готовы дисциплинированно проектировать labels и избегать высокой кардинальности;
- важен предсказуемый бюджет на хранение и простой retention;
- команде нужен быстрый ежедневный UX в Grafana.
Выбирайте OpenSearch, если
- нужен полнотекстовый поиск и сложные запросы по большим массивам;
- логи структурированы (JSON) и вы активно используете поля для аналитики;
- нужны сложные агрегации, отчёты, корреляции, расследования «задним числом»;
- есть ресурсы и компетенции поддерживать кластер и его жизненный цикл;
- скорость поиска в больших исторических объёмах важнее стоимости.
Компромиссные схемы, которые реально работают
1) Loki для «оперативных» логов, OpenSearch для выборочных событий
Большой поток (например, nginx access, debug) уходит в Loki на 7–14 дней. В OpenSearch отправляются только важные события: audit, security, бизнес-события, ошибки уровня error/fatal или обогащённые записи с полями. Так вы снижаете стоимость OpenSearch и оставляете его там, где он действительно нужен.
2) Loki как основной, но строгие правила разметки и фильтрации
Если вы выбираете Loki, вводите правила сразу: какие labels разрешены, как именуются job/app/env, какие поля никогда не становятся метками, где происходит нормализация формата. Это превращает Loki из «помойки строк» в управляемую систему.
Частые ошибки при внедрении
- Пытаться сделать из Loki Elasticsearch: добавлять в labels всё подряд и ожидать мгновенного поиска «по любому слову» на год истории.
- Пытаться сделать из OpenSearch дешёвый архив: грузить туда всё и держать долго без управления индексами и маппингами.
- Не договориться о формате nginx logs: разные форматы на серверах ломают парсинг и делают аналитику бессмысленной.
- Отсутствие политики retention: «храним всегда» обычно заканчивается заполнением дисков и аварийным удалением данных.
Итог
Grafana Loki + Promtail + Grafana — сильный выбор для практичного centralized logging в инфраструктуре, где важны скорость просмотра, понятные срезы по меткам и экономичный retention. OpenSearch оправдан, когда логи становятся базой событий: нужен мощный поиск, сложные агрегации и богатая работа с полями.
Если сомневаетесь, начните с двух списков: (1) какие запросы к логам вы реально делаете каждую неделю, (2) сколько дней retention нужно и что должно быть «быстро», а что может быть «медленно, но дёшево». От этого зависит всё остальное — от формата nginx логов до бюджета на диск и память.
