fix(monitoring): панели уточнены по ревью, приёмка снята под нагрузкой

- Зачем: - слияния в верхних строках показывали только журналы самого сервера, а предел в 15 строк рвал пару нод пополам: панели отвечали не на свой вопрос. - Что: - «Слияния» стали столбиками по слоям: журналы сервера отделены, ряды ods и stg видны своими. - «Части» показывают все таблицы слоёв целиком, без предела и без обрезанных пар. - у «Запросов» убран «Поток запросов» — его пол составляли пробники состояния; у «Кто спрашивает» убрана лишняя колонка. - ряд «коробка» назван «отведено» — как в заголовке панели. - доводы дописаны в cluster.md и queries.md, отступления от ADR 0002 записаны в сам ADR. - Проверка: - make config-test; make smoke 21/21; make check-clickhouse 10/10. - все десять панелей отвечают через /api/ds/query в окнах на полчаса, час и шесть часов.
2026-08-21 15:11:21 -04:00
1 parent 7ffb4606f1
commit 42075ff9fb
@@ -127,6 +127,14 @@ ClickHouse, Kafka и Airflow, 17 — в дашборде генератора, 1
 keeper, и обе ноды читают её целиком — запрос вернул с каждой одни и те же 124
 записи. Обёртка там не добавила бы правды, а удвоила бы каждую строку, поэтому
 единственная панель «Кластера» без неё — эта. Keeper своих системных таблиц не
-имеет вовсе, и панель по нему приходит из Prometheus. Устройство обоих
-дашбордов — [cluster.md](../architecture/monitoring/cluster.md) и
+имеет вовсе, и панель по нему приходит из Prometheus.
+
+«Запросы» получили на две панели больше, чем сказано выше. Разбор запросов по
+посетителям продиктован [ADR 0007](0007-clickhouse-access.md): своя учётка
+Grafana заведена там ровно затем, чтобы её запросы были отличимы от
+человеческих.
+Отдельная панель ошибок понадобилась под здешний же сюжет про тяжёлый
+`GROUP BY`: отказ по памяти случается на шарде, и текст ошибки — единственное
+место, где написано, на каком. Устройство обоих дашбордов —
+[cluster.md](../architecture/monitoring/cluster.md) и
 [queries.md](../architecture/monitoring/queries.md).
@@ -81,8 +81,8 @@ Grafana ходит пользователем `grafana` с ролью `monitorin
  обеих нод, части и слияния, keeper, очередь распределённых DDL. Устройство и
  разбор панелей — [cluster.md](cluster.md).
 - **«Запросы»** (`queries.json`) — что выполнялось и во что обошлось: тяжёлые
-  запросы, поток запросов, аппетит по пользователям, ошибки. Устройство и
-  разбор панелей — [queries.md](queries.md).
+  запросы, аппетит по посетителям, ошибки. Устройство и разбор панелей —
+  [queries.md](queries.md).

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

@@ -14,13 +14,18 @@
 | Диски | `system.metric_log` |
 | Части | `system.parts` |
 | Слияния | `system.part_log` |
-| Keeper | экспортёр keeper через Prometheus |
+| Keeper | встроенные метрики keeper через Prometheus |
 | Распределённый DDL | `system.distributed_ddl_queue` |

 Окно у дашборда — полчаса, обновление — полминуты, и это выбрано под нагрузку.
-Вставка на стенде занимает секунды, а оседание после слияний — минуту-другую;
-в часовом окне и то и другое схлопнулось бы в один столбик. Урок здесь — форма
-кривой, и окно подобрано так, чтобы форма была видна.
+Вставка на стенде занимает секунды, а слияния разбирают её следы за минуту-две;
+в часовом окне и подъём, и оседание схлопнулись бы в один столбик. Урок здесь —
+форма кривой, и окно подобрано так, чтобы форма была видна.
+
+Две панели окна не знают, и обе по делу. «Части» показывают состояние сейчас:
+`system.parts` — опись живых частей, времени в ней нет вовсе. Очередь DDL
+показывает последние двадцать записей: в спокойные полчаса она пуста, а пустая
+панель ничего бы не рассказала.

 ## Обе ноды на одной панели

@@ -39,24 +44,25 @@
 ## Пол на графиках — журналы самого сервера

 ClickHouse ведёт около десятка собственных журналов: `metric_log`,
-`trace_log`, `text_log`, `query_log` и соседние. Все они — таблицы MergeTree, и
-пишутся они постоянно, даже когда на стенде не происходит ничего. Отсюда три
-следствия, которые иначе выглядят поломкой:
+`trace_log`, `text_log`, `query_log` и соседние. Все они — таблицы MergeTree:
+их пишут и сливают постоянно, даже когда на стенде не происходит ничего.
+Отсюда процессор и диски, которые никогда не падают в ноль.

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

-Мера отсюда простая: своя нагрузка читается как подъём над полом, а не как
-число само по себе.
+У частей и слияний пол отделим: в `system.parts` и `system.part_log` у каждой
+строки написано, какой таблице она принадлежит. Обе панели поэтому спрашивают
+только про слои стенда. Довод в размере: за спокойные полчаса слияния съели
+6 492 части в системных журналах против 219 в `ods` и `stg` вместе. Оставь мы
+журналы в кадре, ряды слоёв прижались бы к нулю, и панель рассказывала бы про
+уборку за сервером вместо ваших вставок. Сколько эта уборка стоит, видно этажом
+выше, на процессоре и дисках.

-Панели этот пол не вычитают, и не по недосмотру. Процессор и диски меряются
-счётчиками процесса — в них нет колонки «чья это работа», и вычесть журналы
-оттуда нечем. Отфильтруй мы `system` в тех двух панелях, где это технически
-возможно, они разошлись бы с остальными, и разбираться пришлось бы уже с
-расхождением.
+Слияния показаны по слоям, а не по нодам и не по таблицам. Шарды сливают
+симметрично, и второй ряд на слой удвоил бы легенду, ничего не добавив. Какая
+именно таблица держит части, отвечает соседняя панель.

 ## Что именно меряют процессор, память и диски

@@ -69,18 +75,18 @@ ClickHouse ведёт около десятка собственных журн
 своей (`MemoryTracking`). Разница не косметическая: на праздной ноде
 `MemoryTracking` — 113 МиБ при 846 МиБ резидентной памяти, а ядро, решая, кого
 убить за нехватку памяти, смотрит на вторую величину
-([ADR 0004](../../adr/0004-resource-limits.md)). Панель по первой показывала бы
-здоровый вид у ноды, которую вот-вот убьют.
+([ADR 0004](../../adr/0004-resource-limits.md)). По первой нода, которую
+вот-вот убьют, выглядит совершенно здоровой.

-Пунктирная «коробка» рядом — предел памяти контейнера, и он тоже читается
-живьём, метрикой `CGroupMemoryTotal`. Впиши мы 4 ГиБ числом в JSON, панель
-молча соврала бы в тот день, когда предел поменяют.
+Пунктирный ряд «отведено» — предел памяти контейнера, та самая коробка из
+ADR 0004. Он тоже читается живьём, метрикой `CGroupMemoryTotal`: впиши мы
+4 ГиБ числом в JSON, панель молча соврала бы в тот день, когда предел поменяют.

-Диски меряются обращениями к файлам (`OSReadChars`, `OSWriteChars`), а не
-блоками, дошедшими до устройства (`OSReadBytes`). Блочное чтение на стенде
-почти всегда ноль: части лежат в страничном кэше, и слияние перечитывает их
-оттуда. Работа при этом делается настоящая, и панель по блокам показывала бы,
-что её нет.
+У дисков считаются обращения к файлам — `OSReadChars` и `OSWriteChars`.
+Счётчики блочного устройства (`OSReadBytes`) для той же панели не годятся:
+блочное чтение на стенде почти всё время нулевое, части лежат в страничном
+кэше, и слияние перечитывает их оттуда. Работа при этом идёт настоящая, и
+панель по блокам показывала бы её рваным пунктиром.

 ## Keeper и очередь DDL — то, что живёт вне нод

@@ -90,14 +96,12 @@ Keeper — отдельный сервис, системных таблиц у
 Показывает она размер дерева. В keeper лежит журнал репликации, а в нём —
 запись на каждую часть: пока поток идёт, дерево растёт, а когда части
 домержились и старые записи убраны, оседает. Замер за полчаса живого потока:
-9 078 узлов на подъёме, 11 512 на пике, 10 308 через десять минут после
-остановки потока.
+9 078 узлов на подъёме, 11 512 на пике, 10 308 через десять минут после того,
+как поток встал.

 Очередь распределённых DDL — вторая половина того же сюжета: через keeper
-проходит каждый запрос `ON CLUSTER`. Панель показывает последние двадцать
-записей независимо от окна дашборда: в спокойные полчаса очередь пуста, и
-пустая панель ничего бы не рассказала. Повод заглянуть — не «сколько там
-сейчас», а «доехал ли мой `ON CLUSTER` до обеих нод и что ответила каждая».
+проходит каждый запрос `ON CLUSTER`. Заглядывают сюда с одним вопросом: доехал
+ли он до обеих нод и что ответила каждая.

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

@@ -105,23 +109,29 @@ Keeper — отдельный сервис, системных таблиц у

 - Дашборд поднимается из каталога сам, все семь панелей отвечают через
  `/api/ds/query` в окне на полчаса. Пустых нет.
- Обе ноды видны на каждой панели по системной таблице. Единственная панель без
-  `clusterAllReplicas` — очередь DDL, и обёртка ей действительно не нужна:
-  запрос с ней вернул 124 записи с `clickhouse-01` и те же 124 с
+- Обе ноды видны на всех панелях по системным таблицам, кроме одной. Без
+  `clusterAllReplicas` осталась очередь DDL, и обёртка ей действительно не
+  нужна: запрос с ней вернул 124 записи с `clickhouse-01` и те же 124 с
  `clickhouse-02`.
 - Под нагрузкой. `make generate-batch` (50 626 событий одной пачкой): процессор
-  поднялся с 0,06–0,07 ядра до 0,37–0,38, запись — с 300 КиБ/с до 1,1 МиБ/с,
-  активных частей стало 145 против 131. Через полминуты после конца вставки
-  процессор вернулся к 0,02–0,07 ядра, части осели до 135.
- Панель частей показала `ods.order_rep` по 136 строк в части против 11 171 у
-  `ods.event_rep` — заказы приезжают дневным слепком, события потоком.
- Панель слияний за полчаса: `stg.hits_raw_rep` съела 430 частей, `ods.event_rep`
-  — 401, и рядом с ними системные журналы с сопоставимыми числами.
+  поднялся с 0,04–0,18 ядра до 0,54 и 0,64, запись — с 400 КиБ/с до 2,1 и
+  4,5 МиБ/с. Следующие десять секунд обе величины уже вернулись к прежним: на
+  таком объёме подъём и оседание укладываются в полминуты.
+- Слияния под той же нагрузкой отозвались столбиком: два слияния в `stg`,
+  15 съеденных частей.
+- Блочное чтение действительно молчит: за минуту вокруг вставки `OSReadBytes`
+  был нулевым в десяти десятисекундных окнах из четырнадцати, а обращения к
+  файлам шли непрерывно во всех.
+- Память: около 1 ГиБ занятого против 4 ГиБ отведённого на каждой ноде.
+- Панель частей показала `ods.order_rep` по 142 строки в части против 13 046 у
+  `ods.event_rep` — заказы приезжают дневным слепком, события потоком. Все
+  таблицы слоёв поместились целиком, каждая обеими нодами: восемь строк.
 - Очередь DDL показала `CREATE MATERIALIZED VIEW ... ON CLUSTER` в состоянии
-  `Finished` и временем по каждой ноде: `make generate-batch` поднимает
+  `Finished` и со временем по каждой ноде: `make generate-batch` поднимает
  `clickhouse-init`, и тот заново прогоняет DDL.

-Подписи рядов (`${__field.labels.node}`) и правило, по которому пунктирной
-становится только «коробка», сверены по документации Grafana через MCP
-Context7. Оба применяются на стороне браузера, и через `/api/ds/query` их не
-видно: там проверено, что нода приезжает меткой ряда, а метрика — его именем.
+Подписи рядов (`${__field.labels.node}`) и правило, по которому пунктирным
+становится только ряд «отведено», сверены по документации Grafana через MCP
+Context7. И то и другое применяется на стороне браузера, через
+`/api/ds/query` их не видно: там проверено только, что нода приезжает меткой
+ряда, а метрика — его именем.
@@ -1,14 +1,14 @@
 # Дашборд «Запросы»

-`infra/grafana/provisioning/dashboards/queries.json` — четыре панели поверх
-одной таблицы, `system.query_log`. Вопрос у экрана один: что выполнялось и во
-что это обошлось? Состав панелей и довод за каждую —
+`infra/grafana/provisioning/dashboards/queries.json` — три панели поверх одной
+таблицы, `system.query_log`. Вопрос у экрана один: что выполнялось и во что это
+обошлось? Состав панелей и довод за каждую —
 [ADR 0002](../../adr/0002-monitoring-scope.md).

 Свой вопрос каждая панель называет заголовком прямо на экране. Здесь — только
 то, чего в заголовке не скажешь.

-Обе ноды пишут журнал каждая свой, поэтому все четыре панели читают его через
+Журнал у каждой ноды свой, поэтому все три панели читают его через
 `clusterAllReplicas` — то же правило, что и на [«Кластере»](cluster.md).

 Окно — час, обновление — полминуты. Час взят потому, что сюда приходят с
@@ -21,15 +21,18 @@
 Grafana ходит в ClickHouse обычным пользователем, и её запросы ложатся в
 журнал наравне с человеческими. На спокойном стенде верх списка тяжёлых
 запросов занимает `grafana`: панель свежести с дашборда «Данные» читает по
-полмиллиона строк раз в минуту.
+полмиллиона строк за каждое обновление.

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

-Различать пользователей дашборд умеет потому, что у Grafana своя учётка со
-своей ролью ([ADR 0007](../../adr/0007-clickhouse-access.md)). Ходи она под
+Там же, в «Кто спрашивает», стоит `default` с сотнями запросов и одной
+прочитанной строкой на каждый: это `SELECT 1` от проверки состояния
+контейнера, она ходит к каждой ноде раз в несколько секунд.
+
+Различать посетителей дашборд умеет потому, что у Grafana своя учётка со своей
+ролью ([ADR 0007](../../adr/0007-clickhouse-access.md)). Ходи она под
 аналитиком, панель «Кто спрашивает» показывала бы одну строку на всех.

 ## Что отброшено и почему
@@ -39,7 +42,7 @@ Grafana ходит в ClickHouse обычным пользователем, и
 ещё неоткуда взять. Панели считают по строкам конца.

 Распределённый запрос кладёт в журнал не только себя. Инициатор пишет свою
-строку, а каждый шард — свою, про доставшийся ему кусок. Три панели из четырёх
+строку, а каждый шард — свою, про доставшийся ему кусок. Две панели из трёх
 считают только запросы инициатора: иначе один запрос человека выглядел бы
 тремя, а прочитанные строки сложились бы дважды.

@@ -58,14 +61,14 @@ Grafana ходит в ClickHouse обычным пользователем, и

 Дашборд проверен на живом стенде 21 августа 2026 года.

- Дашборд поднимается из каталога сам, все четыре панели отвечают через
+- Дашборд поднимается из каталога сам, все три панели отвечают через
  `/api/ds/query` в окне на час. Пустых нет.
 - Тяжёлый запрос виден. `GROUP BY` по `ods.event_dist` от учётки `analyst`
  приехал в панель со своими числами: 741 мс, 53,32 МиБ памяти, 701 994
  прочитанные строки.
- Ошибки видны, и обе стороны различаются: отказ по правам (`bi` без `SELECT`
-  на `ods`) и ошибка в тексте запроса (несуществующая колонка) легли в панель
-  разными строками с полным текстом обеих.
- Панель «Кто спрашивает» разделила семь посетителей: `grafana`, `analyst`,
-  `etl`, `dict`, `bi`, `default` и фоновую работу сервера. Больше всех
-  прочитала `grafana` — её же панели, 11,5 млн строк за час.
+- Ошибки видны и различаются по природе: отказ по правам (`bi` без `SELECT` на
+  `ods`) и ошибка в тексте запроса (несуществующая колонка) легли в панель
+  разными строками, каждая с полным текстом.
+- Панель «Кто спрашивает» разделила шесть учёток — `grafana`, `analyst`, `etl`,
+  `dict`, `bi`, `default` — и фоновую работу сервера. Больше всех прочитала
+  `grafana`: 11,5 млн строк за час, своими же панелями.