Grafana Loki 0.1: логи рядом с Prometheus - проще, чем мы ожидали

Несколько недель назад Grafana Labs выпустили Loki 0.1 - первый публичный релиз системы агрегации логов, которую они описывают как «Prometheus, но для логов». Мы отложили его в очередь «посмотреть когда будет время», но время нашлось быстрее обычного: на одном из managed-проектов заказчик спросил, можно ли смотреть логи и метрики в Grafana одновременно. Вопрос простой, ответ обычно - нет, но тут как раз кстати.

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

ELK (или EFK с Fluentd) - стандартный ответ на вопрос «как агрегировать логи в Kubernetes». Работает. Но весит прилично: Elasticsearch требует памяти и тюнинга, Kibana - отдельный UI с отдельной концепцией, Beats или Fluentd настраиваются через километровые конфиги. На небольших кластерах всё это стоит дороже, чем сами приложения.

Loki берёт другую идею. Он не индексирует содержимое логов - только лейблы. Сами строки хранятся как есть, в сжатых чанках. Поиск работает через grep по отфильтрованному набору: сначала по лейблам находишь нужные потоки, потом regexp-ом ищешь внутри. Это медленнее чем полнотекстовый индекс Elasticsearch для сложных запросов, но для типичных случаев - «покажи логи этого пода за последние 10 минут» - вполне быстро.

Главное: Loki разделяет ту же концепцию лейблов, что и Prometheus. {namespace="production", app="api", pod="api-xyz-123"} - это одновременно и selector для метрик в Prometheus, и selector для логов в Loki. Grafana 6.0 умеет работать с обоими datasource на одном дашборде.

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

Установка через официальные Helm-чарты - Loki и Promtail отдельными чартами. Loki разворачивается как StatefulSet с PVC, Promtail - как DaemonSet на всех нодах.

Promtail - это агент сбора логов, аналог Filebeat. Он читает логи из /var/log/pods/ и /var/log/containers/, автоматически обнаруживает поды через Kubernetes API и добавляет лейблы из метаданных: namespace, pod name, container name. Конфигурация по умолчанию покрывает большинство случаев - нам не пришлось писать кастомные pipeline stages для базовой задачи.

Для сравнения: последний раз мы настраивали Filebeat для Kubernetes, там ушло несколько часов на то, чтобы правильно спарсить JSON-логи приложения, добавить нужные поля, настроить мультистрочные стектрейсы. С Promtail базовый сбор заработал за 20 минут. Кастомные parser-ы всё равно нужны если хочешь парсить поля из строк лога, но для «хранить и искать по тексту» этот шаг можно пропустить.

Корреляция метрик и логов - ради чего всё

Вот это оказалось интереснее, чем мы ожидали. В Grafana 6.0 добавили Explore - режим для ad-hoc запросов, где можно переключаться между datasource. Выбираешь Prometheus, пишешь PromQL, видишь spike на графике. Переключаешься на Loki с теми же лейблами - видишь логи того же пода в тот же момент времени.

Это звучит тривиально, но раньше эта операция выглядела так: смотришь на Grafana с метриками, видишь аномалию, переходишь в Kibana, вспоминаешь как там устроен поиск, пытаешься восстановить какой именно pod/контейнер виноват из метаданных, фильтруешь, ищешь. Пять минут переключений. Сейчас это один экран.

Схема для нашего случая:

graph LR
    POD[Pod] -->|stdout/stderr| PROM[Promtail DaemonSet]
    POD -->|metrics| PEXP[Prometheus Exporter]
    PROM -->|push logs| LOKI[Loki]
    PEXP -->|scrape| PROM2[Prometheus]
    LOKI --> GR[Grafana Explore]
    PROM2 --> GR

Один label-set - {namespace, app, pod} - работает и там и там. Это не магия, просто Promtail берёт лейблы из Kubernetes-метаданных, а Prometheus тоже их использует для target labels. Они совпадают по определению.

Что не понравилось

LogQL - не PromQL. Язык запросов к логам в Loki называется LogQL, и в версии 0.1 он очень простой. По сути {selector} для фильтрации потоков и |= "string" для grep. Нет агрегаций, нет rate() по вхождениям паттерна, нет join с метриками. Для базовой отладки достаточно, но если привык к мощи PromQL - будет ощущение что инструмент недоделан. Что в общем-то правда, это 0.1.

Хранение без репликации. В текущей версии Loki - single instance без HA. Для пилота это окей, но в production вопрос висит. Горизонтальное масштабирование обещают, но пока его нет.

Retention. Настройки retention минимальные. Можно задать лимит по времени, но управления retention по лейблам нет - не получится хранить логи production дольше чем dev. Это тоже «запланировано, но не сделано».

Где сейчас

Loki работает на пилоте одну неделю. Пока - без нареканий по стабильности. Два разработчика из команды заказчика уже пользуются Explore для отладки, один сказал что «наконец-то можно смотреть логи там же где метрики». Это мы считаем успехом.

ELK мы не убирали - он работает параллельно для другого проекта где нужен полнотекстовый поиск по структурированным логам. Loki и ELK решают немного разные задачи. Loki - это «быстро найти логи по тому же context что и метрики». ELK - это «сложный анализ по содержимому логов».

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