Автор: Лёша Королёв · Яндекс для разработчиков
Лёша Королёв — техлид команды observability в Яндекс Go. В этом докладе он показывает, как команда строит единый дашборд для платформы, в которой больше тысячи микросервисов, тысячи подов, базы данных, балансировщики, очереди и сотни изменений в проде каждый день. Когда происходит мажорный инцидент, проблема не в том, что у команды нет метрик. Проблема в том, что среди этого масштаба нужно быстро найти короткий путь к причине.
Дальше он разбирает, как устроен единый дашборд платформы такси и какие требования к нему предъявляет команда. Его задача — не показать всё на одном экране, а помочь ответить на два вопроса: в какой части платформы проблема и как такси чувствует себя прямо сейчас.
Кому смотреть: инженерам и техлидам, которые строят мониторинг для большой распределённой системы и хотят, чтобы дашборд помогал во время инцидента, а не просто содержал много графиков.
Из этого можно взять в работу: начните с бизнес-метрик. Если представить путь заказа как последовательность статусов, то бизнес- и техническая воронки быстро показывают, на каком участке возник сбой. А дальше ссылки должны вести от агрегированной картины к конкретному сервису и его логам.
Три концепции единого дашборда
Воронки. Внутреннее название набора статусов, через которые проходит заказ — от создания до завершения. На дашборде есть две воронки: одна построена по бизнес-метрикам, другая — по техническим метрикам, то есть по вызовам ручек, отвечающих за эти статусы. Вместе они помогают быстро определить, в какой части платформы искать проблему, и сузить список сервисов для дальнейшего разбора.
Критичные сервисы. Из более чем тысячи сервисов на дашборд вынесены 35, важных для работы такси. Для них показывается аптайм по ручкам, а сами панели выполняют навигационную функцию: от них можно перейти к деталям.
Иерархия ссылок. Большинство элементов дашборда кликабельны. Переход идёт от агрегированной метрики к более низкому уровню. Ссылки могут вести на другой дашборд или сразу в логи конкретного сервиса — с нужным интервалом времени и параметрами. Это превращает мониторинг из набора картинок в инструмент расследования.
Как это собрано
Графана получает метрики из внутреннего хранилища; его аналогом в Яндекс Cloud может служить Яндекс Мониторинг с похожим синтаксисом запросов. Для тяжёлых наборов данных используется отдельный сервис на Python, который предварительно агрегирует метрики. Например, у одного сервиса могут быть сотни подов и несколько ядер в каждом, поэтому показывать все данные по CPU напрямую на дашборде неудобно.
Отдельно хранятся аннотации — события, которые отмечаются на графике. Команда использует их для релизов: если метрика начала ухудшаться рядом с отметкой о релизе, это помогает быстрее найти направление поиска.
В сыром виде JSON дашборда быстро стал проблемой: файл вырос примерно до 18 тысяч строк, его было тяжело редактировать, одинаковые изменения приходилось повторять для десятков сервисов, а самописные скрипты разных разработчиков было трудно переиспользовать. Появлялись и расхождения между тестовой средой и продом.
Решением стала кодогенерация. Код на выходе создаёт JSON, который понимает Графана, при этом сохраняется возможность добавить сырой фрагмент JSON для новых функций без отдельной обёртки. Главное преимущество — возможность писать тесты для дашборда.
Что улучшает панели
На примере панели с ошибками докладчик показывает несколько простых, но важных правил:
- сортировать результаты, чтобы наверху были самые проблемные ручки;
- отбрасывать значения ниже заданного порога;
- ограничивать список top-10 — во время крупного инцидента всё равно не получится проверить сотни случаев;
- использовать трансформации для замены повторяющихся фрагментов текста;
- добавлять несколько ссылок и передавать в них параметры;
- не перегружать единый дашборд легендами и лишней информацией.
Дашборд нужно поддерживать
Единый дашборд нельзя один раз собрать и оставить без присмотра. Команда уже проходила через ситуацию, когда примерно за шесть месяцев такой инструмент начинал деградировать. Сейчас выделенные люди каждую неделю вносят изменения и улучшают его.
Источником задач служат разборы инцидентов: в шаблон разбора добавлена отдельная секция о том, как улучшить инструменты обсервабилити. Ещё один источник — симуляции, которые позволяют держать команду в форме и проверять, работают ли инструменты до настоящего мажора.
Выводы
- Используйте бизнес-метрики и по возможности показывайте их в виде воронки.
- Выносите на единый дашборд только критичные сервисы.
- Заранее зафиксируйте требования к дашборду и периодически проверяйте, что он им соответствует.
- Используйте кодогенерацию, если дашборд стал большим и повторяющимся.
- Постройте постоянный процесс улучшения — например, через разборы инцидентов и генерацию задач из них.