Дашборд «Данные»: свежесть, поток, брак, сходимость #115

New Issue

2026-08-21T14:43:45+03:00

ddmitry commented

2026-08-21 14:43:45 +03:00

Part of #11. Блокируется #114.

Цель

Главный дашборд ADR 0002: один экран, отвечающий на вопрос «с потоком всё в
порядке?». Три из шести его вопросов — свежесть, брак, сходимость — у
предшественника не заданы вовсе, и в этом весь смысл дашборда.

Что войдёт

Дашборд «Данные» в infra/grafana/provisioning/dashboards/, панели на SQL к
ClickHouse. Состав — шесть вопросов из ADR 0002, раздел «Решение».

Источники стоят: ods.event_dist, ods.event_errors_dist, ods.order_dist,
ods.order_errors_dist, stg.hits_raw_dist, stg.orders_raw_dist, _load_ts
у слепка.

Одна панель из шести неочевидна — сходимость: произведённое живёт в Kafka
(экспортёр из #114 или system.kafka_consumers), приземлившееся — в ClickHouse.
Как их свести в одну панель и с какой стороны считать — решение исполнителя;
записать его в monitoring.md вместе с доводом.

Границы

Порогов и цветовых вердиктов на панелях нет (спека, раздел 9): на дашборд
смотрят глазами, красное и зелёное живёт в проверках.
Правил оповещения не заводить — они в хвосте этапа, #117.
Команд, настроек и пометок про тик в JSON дашборда не держать (ADR 0002).
Чтецов Kafka панелью не читать. stg.hits_raw_kafka и
stg.orders_raw_kafka — таблицы движка Kafka, а не хранилище; у второго
стоит kafka_commit_on_select = 1, и запрос из панели забрал бы слепок у
дага приёма. Приземлившееся считается по stg.*_raw_dist, произведённое —
по метрикам экспортёра или system.kafka_consumers. Настройка
stream_like_engine_allow_direct_select лежит в
sql/stg/orders_raw_load.sql — в панель её не переносить.

Кому что

Панели и их SQL пишет Opus: заголовок панели и текст запроса читает менти.
Кодексу — обвязка JSON, прогоны, снятие приёмки.

Сначала прочитать

docs/adr/0002-monitoring-scope.md — состав и разбор того, чего у
предшественника не было;
docs/architecture/storage.md — какие таблицы что держат;
docs/architecture/testing.md, раздел «Корректность процессов живёт в дагах
DQ» — почему вердикты не здесь.

Проверка

make config-test; на стенде make smoke и make check-clickhouse зелёные,
дашборд поднимается из provisioning без ручных шагов.

Все шесть панелей отвечают на живом стенде после make up: ни одной
пустой, ни одной с ошибкой запроса.
Панель брака видит подсунутую негодную строку, доля меняется. Опыт
разовый, за собой прибраться (testing.md).
Панель свежести реагирует на остановленный поток и возвращается назад,
когда поток пущен.
Сходимость сходится на спокойном стенде; выбранный способ счёта записан в
monitoring.md.

Part of #11. Блокируется #114. ## Цель Главный дашборд ADR 0002: один экран, отвечающий на вопрос «с потоком всё в порядке?». Три из шести его вопросов — свежесть, брак, сходимость — у предшественника не заданы вовсе, и в этом весь смысл дашборда. ## Что войдёт Дашборд «Данные» в `infra/grafana/provisioning/dashboards/`, панели на SQL к ClickHouse. Состав — шесть вопросов из ADR 0002, раздел «Решение». Источники стоят: `ods.event_dist`, `ods.event_errors_dist`, `ods.order_dist`, `ods.order_errors_dist`, `stg.hits_raw_dist`, `stg.orders_raw_dist`, `_load_ts` у слепка. Одна панель из шести неочевидна — **сходимость**: произведённое живёт в Kafka (экспортёр из #114 или `system.kafka_consumers`), приземлившееся — в ClickHouse. Как их свести в одну панель и с какой стороны считать — решение исполнителя; записать его в `monitoring.md` вместе с доводом. ## Границы - **Порогов и цветовых вердиктов на панелях нет** (спека, раздел 9): на дашборд смотрят глазами, красное и зелёное живёт в проверках. - Правил оповещения не заводить — они в хвосте этапа, #117. - Команд, настроек и пометок про тик в JSON дашборда не держать (ADR 0002). - **Чтецов Kafka панелью не читать.** `stg.hits_raw_kafka` и `stg.orders_raw_kafka` — таблицы движка Kafka, а не хранилище; у второго стоит `kafka_commit_on_select = 1`, и запрос из панели забрал бы слепок у дага приёма. Приземлившееся считается по `stg.*_raw_dist`, произведённое — по метрикам экспортёра или `system.kafka_consumers`. Настройка `stream_like_engine_allow_direct_select` лежит в `sql/stg/orders_raw_load.sql` — в панель её не переносить. ## Кому что Панели и их SQL пишет Opus: заголовок панели и текст запроса читает менти. Кодексу — обвязка JSON, прогоны, снятие приёмки. ## Сначала прочитать - `docs/adr/0002-monitoring-scope.md` — состав и разбор того, чего у предшественника не было; - `docs/architecture/storage.md` — какие таблицы что держат; - `docs/architecture/testing.md`, раздел «Корректность процессов живёт в дагах DQ» — почему вердикты не здесь. ## Проверка `make config-test`; на стенде `make smoke` и `make check-clickhouse` зелёные, дашборд поднимается из provisioning без ручных шагов. - [x] Все шесть панелей отвечают на живом стенде после `make up`: ни одной пустой, ни одной с ошибкой запроса. - [x] Панель брака видит подсунутую негодную строку, доля меняется. Опыт разовый, за собой прибраться (`testing.md`). - [x] Панель свежести реагирует на остановленный поток и возвращается назад, когда поток пущен. - [x] Сходимость сходится на спокойном стенде; выбранный способ счёта записан в `monitoring.md`.

ddmitry referenced this issue

2026-08-21 14:44:11 +03:00

Дашборды «Кластер» и «Запросы»: системные таблицы через clusterAllReplicas #116

~~ddmitry referenced this issue 2026-08-21 14:44:38 +03:00~~

Хвост этапа 9: runbook keeper и system.text_log #117

ddmitry added the ready-for-agent label 2026-08-21 14:44:54 +03:00

ddmitry added a new dependency 2026-08-21 14:44:58 +03:00

#114 Пол мониторинга: источник ClickHouse в Grafana и экспортёр Kafka

ddmitry added a new dependency 2026-08-21 14:44:59 +03:00

#117 Хвост этапа 9: runbook keeper и system.text_log

ddmitry referenced this issue

2026-08-21 14:45:13 +03:00