Коротко. Под Directum RX хватает пяти дашбордов: домашняя страница и по одному подробному на хосты, PostgreSQL, RabbitMQ и поиск. Главная устроена как шесть дверей: алерты, журналы, скорость, задания, данные, платформа. У каждой слово состояния и ссылки, названные вопросом. Данные дают общедоступные экспортёры, пороги берутся из истории системы и совпадают с алертами, цвет появляется только там, где нужно внимание.

Grafana под Directum RX обычно появляется так: поставили Prometheus, импортировали десяток готовых дашбордов из каталога, на каждом по сорок графиков. Через месяц в неё никто не заходит, а при аварии дежурный листает экраны и не понимает, куда смотреть. Разбираем, как собрать небольшой набор дашбордов, по которому за минуту видно, что с системой и где искать причину.

Симптом

Графиков много, ответа нет. На вопрос «система сейчас работает нормально?» Grafana не отвечает одним экраном: нужно открыть дашборд хостов, потом базы, потом брокера и сложить картину в голове. Пороги на графиках не совпадают с порогами в алертах, поэтому красная зона на панели есть, а уведомление не пришло, или наоборот. Время на разных панелях в разных поясах. У половины панелей надпись «No data», и никто не помнит, давно ли.

Почему так

Готовый дашборд из каталога делали для продукта вообще. На нём есть всё, что отдаёт экспортёр, потому что автор не знает, что важно именно вам. Для RX важны несколько вещей: открывается ли система у пользователя, двигаются ли задания, хватает ли места и не копятся ли блокировки в базе. Эти ответы размазаны по разным дашбордам, а первого экрана, который их собирает, в каталоге нет. Его приходится делать самим.

Что поставить

Данные для дашбордов дают общедоступные экспортёры. Свои писать не нужно.

  • node_exporter на каждый хост: процессор, память, диски, сеть.
  • postgres_exporter для PostgreSQL: соединения, блокировки, репликация, размер базы.
  • Встроенный плагин Prometheus в RabbitMQ: очереди, потребители, неподтверждённые сообщения.
  • Экспортёр Elasticsearch или OpenSearch: состояние кластера, шарды, куча JVM.
  • blackbox_exporter: проверка снаружи, что страница входа открывается, и срок сертификата.

Последний пункт ставят реже всех, а он единственный смотрит на систему глазами пользователя.

Какие дашборды собрать

Хватает пяти: домашняя страница и четыре подробных дашборда по слоям. Домашняя отвечает на вопрос «куда идти», остальные нужны, чтобы дойти до причины.

Домашняя страница: шесть дверей

У себя мы пришли к главной странице, которая устроена как страница статуса сервиса. На ней шесть разделов, мы называем их дверями, и каждый отвечает на один вопрос человека с проблемой:

  1. Что горит. Сработавшие алерты: сколько критичных, сколько предупреждений, давно ли.
  2. Что в журналах. Ошибки приложения за последние минуты и ссылки в поиск по логам.
  3. Почему медленно. Время ответа основных операций, вход в систему, долгие запросы.
  4. Двигаются ли задания. Фоновые процессы, очереди, интеграции с внешними системами.
  5. Что с данными. База, брокер, хранилище документов, поиск: место, соединения, блокировки, копии.
  6. Что с платформой. Хосты или кластер: процессор, память, диски, перезапуски.

Каждая дверь это одно слово состояния и три-четыре ссылки. Слово написано текстом: «норма», «внимание», «авария». Ссылки названы вопросом, который задаёт человек, а не именем дашборда: «какая очередь растёт», «кто держит блокировку», «когда кончится диск». Графиков на главной нет.

Страница рассчитана на тихий день. Когда всё в порядке, она почти бесцветная, и это намеренно: цвет появляется только там, где нужно внимание. При аварии на экране одно цветное слово, и по нему видно, в какую дверь идти.

Пороги для слов взяты из истории самой системы. Если предупреждений в обычный день двадцать, порог «внимание» на пяти будет гореть всегда, и раздел перестанут читать. Сначала смотрят, как система живёт неделю, потом ставят границу чуть выше обычного.

Подробные дашборды

Хосты. Процессор, память, диск по операциям и по месту, сеть. Для дисков полезнее прогноз, через сколько дней кончится место, чем процент занятого.

PostgreSQL. Соединения по состояниям, долгие транзакции, блокировки, скорость записи журнала, отставание реплики, размер базы и самых больших таблиц.

RabbitMQ. Длина очередей, скорость публикации и разбора, очереди без потребителей, память и диск узла относительно его порогов.

Поиск. Состояние кластера, неназначенные шарды, заполнение кучи JVM, место на диске.

Готовые дашборды из каталога для этих четырёх годятся как основа: «Node Exporter Full» для хостов, «RabbitMQ-Overview» для брокера. Лишние панели из них лучше убрать сразу.

Правила, без которых дашборд не работает

Порог на панели равен порогу в алерте. Если уведомление приходит при 85% заполнения диска, красная зона на плитке начинается там же. Иначе панель и уведомление противоречат друг другу, и верить перестают обоим.

Одно время на всех панелях. Часовой пояс дашборда задаётся явно, одинаковый у всех. При разборе инцидента по переписке разница в три часа стоит получаса путаницы.

Переменная для контура и хоста. Один дашборд на прод и тест с выпадающим списком вместо двух копий, которые разойдутся через месяц.

«No data» это тоже сигнал. Пустая плитка должна быть заметной, например серой с подписью. Экспортёр мог упасть неделю назад, и зелёная плитка всё это время показывала последнее известное значение.

Подпись говорит, что делать. В описании панели одна строка: что значит красный цвет и куда идти дальше. Дежурный в три часа ночи не будет вспоминать, чем опасна очередь без потребителей.

Что сделать

  1. Поставить пять экспортёров из списка выше и убедиться, что Prometheus их опрашивает.
  2. Собрать домашнюю страницу из шести разделов со словом состояния и ссылками, сделать её стартовой в Grafana.
  3. Взять по одному подробному дашборду на слой и выкинуть из него панели, на которые никто не смотрит.
  4. Свести пороги панелей с правилами алертов, поставить всем один часовой пояс.
  5. Раз в квартал открывать главную и проверять, что каждый раздел показывает живые данные.

Какие правила алертов стоят за этими плитками, разобрано в статье про мониторинг Directum RX.

Чего не делать

  • Не импортировать дашборды пачкой. Двадцать экранов, которые никто не настроил под вашу систему, хуже одного своего.
  • Не строить главную из графиков. График показывает историю, а первому экрану нужно состояние сейчас.
  • Не дублировать дашборд под каждый контур. Копии расходятся, и через полгода непонятно, какая верная.
  • Не оставлять пороги по умолчанию. Красная зона с 80% по памяти на сервере базы будет гореть всегда, и её перестанут замечать.
  • Не считать Grafana мониторингом. Она показывает то, на что смотрят. Будить должен алерт.