Loki GA: развернули рядом с Prometheus и убрали Kibana из дежурного арсенала

На одном из managed-проектов у нас исторически сложился стандартный набор для observability: Prometheus для метрик, Grafana для дашбордов, ELK-стек для логов. Всё работало, но работало в параллельных мирах. Дежурный инженер при алерте открывал Grafana, смотрел что происходит с метриками, потом открывал Kibana, пытался сопоставить временные метки и найти нужные логи. Два инструмента, два разных query language, два разных интерфейса - и в два часа ночи это утомляет.

Grafana Labs выпустила Loki в GA - и мы решили проверить, реально ли убрать Kibana из этой цепочки.

Что такое Loki и чем он отличается от ELK

Основная идея Loki - не индексировать содержимое логов, а индексировать только метаданные: лейблы вроде namespace, pod, app. Сам текст лога хранится в сжатых чанках как есть. Это резко снижает потребление памяти по сравнению с Elasticsearch, который индексирует каждое поле каждой строки.

Платишь за это ограниченными возможностями поиска: нельзя сделать быструю агрегацию по произвольному полю, если этот field не вынесен в лейбл явно. Elasticsearch здесь гибче. Но для большинства сценариев дежурного инженера - «найди логи этого пода за последние 15 минут с ошибкой» - Loki справляется без проблем.

Архитектурно Loki состоит из трёх компонентов:

• Promtail - агент на каждой ноде, читает логи из /var/log/ и через Kubernetes-аннотации цепляет лейблы из Pod metadata. Конфигурируется похоже на Prometheus scrape config - если уже разбирался с Prometheus, Promtail не вызывает удивления.
• Loki - сам сервер: принимает потоки логов, пишет их в хранилище. В нашем случае - локальный filesystem на PV, для крупного кластера сюда просится S3-совместимое объектное хранилище.
• Grafana - визуализация через datasource типа Loki, запросы на языке LogQL.

Как разворачивали

Использовали Helm chart из официального репозитория grafana/loki-stack. Chart поднимает Loki, Promtail как DaemonSet и при желании Grafana - но Grafana у нас уже была, поэтому подключили как отдельный datasource.

Promtail настраивается на чтение журналов через tail из /var/log/pods/ с автодискавери через Kubernetes API - всё стандартно, без ничего экзотического. Главный вопрос с лейблами: что выносить в индекс, а что оставлять в тексте. Мы взяли namespace, pod, container, node и app из аннотаций. Этого хватает для большинства запросов.

LogQL по синтаксису действительно похож на PromQL. Базовый запрос - stream selector в фигурных скобках, плюс фильтры:

{namespace="production", app="api-gateway"} |= "error"

Операторы |= (содержит), != (не содержит), |~ (regex) - этого покрывает 90% нужного. Плюс есть парсинг: если логи в JSON, | json разбирает их и позволяет фильтровать по полям. Если logfmt - аналогично.

Метрические запросы через rate() и count_over_time() дают возможность строить счётчики ошибок прямо из логов - без отдельного exporter. Это неожиданно удобно для сервисов, которые пишут ошибки в лог, но не отдают метрику по ним.

Что получили в Grafana

Вот это оказалось главной ценностью - не сам Loki как таковой, а то что всё сошлось в одном месте.

В Grafana 6.x появились Explore панели с поддержкой нескольких datasource одновременно. Настроили дашборд для дежурного: верхняя половина - метрики из Prometheus (error rate, latency, pod restarts), нижняя половина - логи из Loki за тот же временной интервал, с фильтром по тому же namespace и app. Переключаешь временной диапазон - оба графика обновляются синхронно.

Дополнительно настроили panel links: кликаешь на всплеск error rate на графике Prometheus - открывается Explore с предзаполненным LogQL-запросом для того же сервиса в том же временном окне. Это не магия, это просто URL-параметры в Grafana, но в 2 часа ночи разница между «один клик» и «открой второй браузер, введи временные метки вручную» - очень ощутима.

Что пока не так гладко

ELK мы не удалили. Там живёт часть инфраструктурных логов, которые мы пока не переключили, плюс Kibana используется для нескольких специфичных аналитических задач где нужна полнотекстовая агрегация. Loki для этого не подходит.

Хранение логов в Loki на filesystem без репликации - это не для продакшна без резервного копирования. Вопрос с S3-бэкендом или Ceph Object Storage открыт, пока присматриваемся к ruler, который только появился в последних версиях.

LogQL пока беднее чем Kibana Query Language для сложных сценариев разбора структурированных логов. | json работает, но если лог-формат нестандартный - нужен pipeline через regex, а это уже менее удобно.

Общее наблюдение

Идея Loki подкупает простотой операционной модели - он не пытается быть Elasticsearch. Потребление ресурсов заметно ниже, деплой проще, интеграция с уже существующим Prometheus/Grafana стеком - без лишних усилий.

Основной выигрыш для нас - не в возможностях поиска по логам (тут ELK богаче), а в том что дежурный инженер работает в одном окне. Корреляция метрик с логами перестала требовать ручного переключения контекста. Это небольшое изменение в UX, но когда оно применяется к процессу разбора инцидентов в три часа ночи - ценность ощущается быстро.

Стек пока не полностью переведён - скорее параллельный режим. Но направление понятно.