Summary of "Царь-дашборд: как построить дашборд всей платформы Такси / Леша Королев, Яндекс Go"

Царь-дашборд: как построить дашборд всей платформы Такси

(Леша Королев, Yandex Go)

Обзор

Цель: построить единый, охватывающий всю платформу дашборд, который ускоряет обнаружение и расследование крупных инцидентов в Yandex Taxi.
Контекст: платформа большого масштаба — тысячи микросервисов, тысячи pod’ов, сотни изменений в день. Дашборд служит навигацией и инструментом триажа для быстрого локализации корневых причин.

Архитектура и стек технологий

Визуализация: Grafana (панели, преобразования, datalinks).
Хранилище метрик: внутренняя time-series система (аналог Yandex Monitoring / Yandex Cloud); все сервисы пишут туда метрики.
Вспомогательные сервисы:
- Python-сервис для подготовки/агрегации некоторых типов метрик.
- Отдельное хранилище аннотаций (релизы/события для отображения на графиках).
Генерация дашбордов: toolchain для генерации кода («Gen» / «cogen»), который эмитирует Grafana JSON; при необходимости умеет встраивать «сырые» JSON-блоки.
Тестирование: автоматические тесты для сгенерированных дашбордов/панелей, чтобы избежать регрессий между тестом и продом.

Ключевые продуктовые фичи и UI-концепции

Funnels (воронки)
- Две параллельные воронки на заказ: бизнес-воронка (прогресс бизнес-метрик) и техническая воронка (вызовы в хендлеры).
- Помогают быстро локализовать, какая часть платформы затронута.
Панель критических сервисов («светофор»)
- Вместо отображения всех ~1000 сервисов фокус на ~35 критических сервисах (доступность/uptime по сервису/хендлеру).
- Служит хабом навигации и уменьшает шум.
Иерархия ссылок / datalinks
- Почти каждый граф/панель кликабелен и ведёт в более детальные представления (per-service dashboards, логи, выбранный временной интервал).
- Ссылки переносят параметры (service id, time ranges).
Аннотации
- Отображение релизов/событий на временных рядах для корреляции деградаций с деплоями.
Преобразования / текстовая обработка
- Использование Grafana transformations для чистки легенд, сворачивания повторяющихся меток и текстовых замен.
Агрегация и контроль кардинальности
- Агрегирование метрик с высокой кардинальностью (пример: CPU по множеству pod’ов) для читаемости.
- Фильтры top-N или пороговые отсечения (показывать топ-10, отрезать значения ниже N).
Поведение панелей
- Сортировка / под-сортировка и топ-N усечение, чтобы уменьшить шум во время инцидентов.

Операционные практики и уроки

Начинайте с малого: сосредоточьтесь на бизнес-метриках и критических сервисах (воронки + critical services), а не на попытке показать всё.
Используйте code generation (cogen) рано — редактирование одного монолитного JSON было болезненно (дашборд вырос до ~18 000 строк); cogen даёт переиспользование, согласованность и автотесты.
Поддерживайте выделенную команду для постоянных улучшений дашборда — дашборды деградируют, если их оставить без внимания.
Фидбэк из инцидентов: включайте раздел «observer tools» в ретроспективы и переводите выводы в таски по улучшению дашборда.
Тренировки и симуляции: используйте сценарии (в докладе — «Saphir») для валидации алертов и полезности дашборда в реальных инцидентных условиях.
Документируйте требования/спеки дашборда и контролируйте их через тесты и ревью, чтобы панели оставались пригодными для использования.

Практические рекомендации / чеклист

Визуализируйте бизнес-метрики — используйте воронки для ускорения поиска корней проблем.
Ограничьте охват дашборда критическими сервисами; на едином дашборде показывайте только метрики от этих сервисов.
Определите и задокументируйте требования к дашборду; делайте их видимыми операторам и рецензентам.
Используйте генерацию кода для дашбордов и начинайте с неё как можно раньше.
Внедряйте непрерывное улучшение (таски из ретроспектив инцидентов, симуляции, выделенная поддержка).

Проблемы внедрения и решения

Проблема: монолитный, ручной Grafana JSON — тяжело менять, разных команд были несогласованные скрипты, дрейф тест/прод.
- Решение: перейти на code generation (cogen/Gen), сохранить возможность инъекции raw JSON и добавить автоматические тесты.
Проблема: слишком много шума от списков высокой кардинальности и громоздких легенд.
- Решение: агрегация, top-N фильтры, текстовые трансформации и отказ от подробных легенд на едином дашборде.

Руководства и практические советы, упомянутые в докладе

Пошаговая логика структуры дашборда: почему воронки, почему критические сервисы, как устроена иерархия ссылок.
Практические приёмы для Grafana: datalinks, panel link lists, transformations, top-N фильтрация.
Операционный гайд: организация поддержки, как встраивать выводы из ретроспектив, как запускать симуляции для проверки полезности дашборда.

Основные участники / источники

Алексей (Леша) Королёв — Tech Lead, Ability team, Yandex Taxi / Yandex Go (основной докладчик).
Артём — коллега, упоминается в Q&A.
Saphir — источник подхода симуляций, использованных для тестирования и валидации.