Grafana 3.x + Elasticsearch: метрики и логи в одном дашборде

Когда мы запускали Prometheus рядом с Zabbix, там была одна незакрытая история: «для нормальной визуализации нужен Grafana, и это отдельная история». Grafana к тому моменту уже стояла и показывала метрики. Но логи жили отдельно - в Kibana. Два окна, два контекста, и при разборе инцидента приходилось прыгать между ними, сопоставляя таймлайны вручную.

В Grafana 3.x это изменилось: появился нативный datasource для Elasticsearch. Мы его подключили - и вот что получилось.

Что добавила третья версия

Grafana 3 вышла весной, но мы взялись за elasticsearch datasource только сейчас, когда наш ELK-стек на клиентской инфраструктуре стал достаточно стабильным чтобы не хотелось его трогать лишний раз.

Кроме datasource для Elasticsearch, третья версия принесла:

• Переработанный алертинг. Теперь это не плагин, а встроенная функциональность с собственным state machine: ok - pending - alerting. Уведомления идут в Slack, PagerDuty, email, webhook. Alertmanager у Prometheus остаётся богаче по логике маршрутизации, но для большинства сценариев хватает.
• Playlist и kiosk-режим. Мелочь, но на телевизор в серверной это удобно.
• Улучшенный templating. Переменные теперь умеют быть multi-value из коробки - можно выбрать несколько хостов в одном фильтре.

Нас интересовал datasource - про него и говорим.

Подключение Elasticsearch к Grafana

Настройка несложная. В Data Sources добавляем тип Elasticsearch, указываем URL до кластера, имя индекса и поле с таймстемпом:

URL: http://elasticsearch.internal:9200
Index name: [logstash-]YYYY.MM.DD
Time field name: @timestamp
Elasticsearch version: 5.x

Grafana ходит к ES напрямую из браузера или через встроенный прокси - в зависимости от настройки. Мы используем прокси, чтобы не открывать 9200 наружу.

После добавления datasource в редакторе панелей появляется знакомый query builder с агрегациями ES: Terms, Date Histogram, Avg/Max/Min/Sum по полям. Всё то, что в Kibana делается через Visualize, здесь доступно внутри Grafana-панелей.

Что получилось на дашборде

На одном дашборде собрали три слоя:

Метрики из Prometheus. CPU, memory, latency сервисов - всё что было раньше, никуда не делось.

Лог-паттерны из Elasticsearch. Count ошибок из application.log за тот же временной диапазон - через Terms-агрегацию по полю level. Выглядит как обычный graph: ось X - время, ось Y - количество ERROR-записей.

Аннотации из ES. Это оказалось неожиданно полезным. Grafana умеет рисовать вертикальные линии на графиках по результатам ES-запроса. Мы настроили аннотации по событиям деплоя - они пишутся в отдельный индекс как простые документы. Теперь на графике CPU видно: вот тут был деплой, и вот тут поползла латентность.

Про MTTR на практике

В прошлую пятницу был эпизод: латентность API начала расти, ночью. Дежурный открыл один дашборд - и сразу увидел: метрики ухудшились примерно в 02:15, в то же время count ERROR в логах подскочил, а за пять минут до этого была аннотация деплоя. Сопоставление, которое раньше занимало десять минут прыжков между Grafana и Kibana, стало вопросом одного взгляда.

Выяснилось что деплой принёс регрессию в одном из сервисов. Откат, всё встало.

Это не значит что Kibana теперь не нужна. Для полнотекстового поиска по логам, для разбора конкретного трейса, для ad hoc-запросов - Kibana остаётся основным инструментом. Grafana + Elasticsearch datasource закрывает другой сценарий: агрегированная картина в реальном времени рядом с метриками.

Что не очень

Честности ради - несколько вещей раздражают.

Таблицы с сырыми логами. В Grafana нет нормального способа показать сырые лог-строки как в Kibana Discover. Table panel работает с агрегациями, а не с raw documents. Для debugging конкретного события всё равно надо лезть в Kibana.

Алертинг работает только на time series панелях. На панелях с ES-агрегациями алерты настраиваются, но только если панель возвращает числовой ряд. Сложные условия вроде «ERROR rate вырос на 20% относительно прошлого часа» требуют аккуратного написания запроса.

Производительность. При широком временном диапазоне ES-запросы заметно медленнее, чем Prometheus. Это не Grafana виновата - просто другой профиль хранилища.

Где сейчас

Дашборд с совмещёнными метриками и лог-агрегациями катим на все проекты managed-сопровождения где уже стоит ELK. На тех, где ELK нет - пока остаётся только Prometheus + Grafana, вопрос достаточно ли этого решается индивидуально.

Алертинг в Grafana тестируем параллельно с Alertmanager. Пока они сосуществуют: Alertmanager обрабатывает алерты по метрикам с маршрутизацией и глушилками, Grafana-алерты используем для быстрых порогов прямо на дашборде без лишних yml-файлов. Конкурируют или дополняют - станет понятно через пару месяцев эксплуатации.