clickstream-data-platform/docs/adr/0002-monitoring-scope.md

ADR 0002. Что показывает мониторинг стенда

Дата: 31 июля 2026 года. Статус: принято.

Решение

Мониторинг стенда — несколько дашбордов Grafana, по одному на вопрос. Дашборд, отвечающий на три вопроса сразу, не отвечает ни на один; отдельных файлов не жалко.

«Данные» — главный дашборд, вопросы дата-инженера:

• свежесть: сколько прошло с момента, когда доехало последнее событие;
• поток: строк в час по источникам и как это выглядит против вчерашнего;
• брак: сколько записей ушло в таблицы *_errors и какая это доля;
• сходимость: сколько произвели в Kafka против того, сколько приземлилось в ClickHouse;
• отставание чтения из Kafka;
• дневной слепок заказов: доехал ли и вовремя ли.

Источник большинства этих панелей — не Prometheus, а сам ClickHouse: он подключается в Grafana источником данных, панели пишутся на SQL. Метрики дата-инженера живут в его собственных таблицах, а не в счётчиках сервисов.

«Кластер» — состояние машины: процессор и память обеих нод, обращения к дискам, части MergeTree и слияния, keeper, очередь распределённых DDL. Дашборд кажется чужим для дата-инженера, но чужой он только на вид: «слишком много частей» — это ошибка того, кто вставляет мелкими пачками слишком часто, а видна она именно здесь. То же с памятью: тяжёлый GROUP BY без ограничения — запрос человека, симптом — на графике памяти.

Смотреть этот дашборд осмысленно под нагрузкой: видно, как процессор и обращения к дискам лезут вверх на вставке и медленно оседают, когда домержились части. Одно число «жив или нет» этому не учит, форма кривой — учит.

«Запросы» — system.query_log таблицей: что выполнялось, сколько заняло, сколько памяти и строк прочитало. Здесь человек сам отвечает себе на вопрос «почему мой дашборд в Superset тормозит».

Системные таблицы у каждой ноды свои, поэтому панели по ним пишутся через clusterAllReplicas — иначе видно половину правды. Это отдельный маленький урок, и он нужен.

Серверный журнал (system.text_log) подключается на этапе 9 вместе с runbook «keeper упал / DDL повис в очереди»: там он и окупается. Довод за него один — общая ось времени: в одной панели оба узла, над ней всплеск процессора, под ней очередь DDL. docker logs даёт две отдельные ленты и сопоставление руками. Издержки: журнал выключен по умолчанию, включается настройкой, таблице нужен TTL. Если окажется дороже, чем даёт, — уходит первым.

Prometheus остаётся, но сжимается до тонкого пола: живы ли контейнеры, не упёрлись ли ноды в память. Он нужен, чтобы при плохой метрике данных одним взглядом отделить «сломался конвейер» от «сломалась машина». Отдельный сборщик метрик Kafka нужен ради отставания чтения. Сборщик метрик Airflow через StatsD не берём.

Почему

Образцом служил мониторинг предшественника: четыре дашборда, десять правил оповещения, два внешних сборщика и урок курса. Форма там хорошая и берётся целиком — сначала смотрим, потом ломаем одну вещь управляемым образом, видим, как мониторинг это показал, и возвращаем назад. Содержание берётся не целиком.

Панелей с запросами в трёх «настоящих» дашбордах предшественника — 28. На вопрос «с данными всё в порядке?» отвечают шесть. Остальное — процессор, память, части и слияния, размер набора DAG-файлов, время их разбора, пульс планировщика, свободные слоты исполнителя. И при этом ни одной панели про свежесть, ни одной про долю брака, ни одной про сходимость Kafka с ClickHouse. То есть три главных вопроса дата-инженера там просто не заданы.

Отсюда решение: инфраструктурные панели не убираются, а переносятся на свой дашборд, и рядом появляется тот, которого не было.

Три вещи предшественника не повторяем.

Правило оповещения Kafka No Messages Produced краснеет на здоровом стенде, когда живой поток просто не запущен, и уроку приходится за это извиняться отдельным абзацем. Правило, красное в нормальном состоянии, учит не тому, что задумано: оно учит не смотреть на оповещения.

Самый проработанный дашборд предшественника — про генератор, которого в бою не существует: 17 панелей с гистограммами задержек и пульсом против 12 у ClickHouse. Силы ушли туда, где инструментировать было легко, а не туда, где стоит вопрос.

Три текстовые панели там хранят команды и пометку «настроено под тик 5 секунд» прямо в JSON дашборда. Поменяется тик — панель молча соврёт. Документация живёт в документации.

Сборщик метрик Airflow через StatsD — это отдельный контейнер плюс файл перевода имён, и весь его выход — внутренности планировщика: пульс, слоты, время разбора файлов. Дежурному по платформе это нужно, дата-инженеру — нет. Вопрос «доехал ли вчерашний слепок заказов» дешевле и честнее задать самим данным.

Что проверено

31 июля 2026 года. Мониторинг предшественника разобран по файлам в configs/grafana/provisioning/ и configs/prometheus.yml репозитория clickstream-ch-kafka-superset-demo: 28 панелей с запросами в дашбордах ClickHouse, Kafka и Airflow, 17 — в дашборде генератора, 10 правил оповещения.

Источник данных ClickHouse — плагин, в образе Grafana его нет. Проверено запросом к живому стенду (/api/plugins?type=datasource): 19 встроенных источников, ClickHouse среди них отсутствует. Плагин ставится сборкой своего образа Grafana, как уже собираются свои образы Airflow и Superset. Установка при старте контейнера отвергнута: она делает make up зависимым от сети и от доступности каталога плагинов, то есть стенд перестаёт подниматься по причинам, к нему не относящимся. Версия плагина закрепляется, как закреплены остальные.

Состав панелей выбран до этапа 9 намеренно: уроки пишутся отдельной работой (спека, раздел 10), но рассказать урок можно только про то, что дашборд показывает. Скопируй мы состав предшественника — урок неизбежно получился бы про пульс планировщика.