ddadmin
48bec014cf
- Зачем:
- второй круг ревью нашёл, что текст спорит с собственной приёмкой: окно
держалось доводом «слияния за минуту-две», а замер даёт двадцать секунд;
довод панели ошибок опирался на отказ по памяти, которого ADR 0004 на этом
стенде не обещает.
- Что:
- «Части» сортируются по таблице: сортировка по числу частей разводила две
ноды одной таблицы, как только между ними вставала чужая.
- у «Слияний» столбик шириной в минуту, иначе редкие события выходили
волосяной линией; из заголовка убран «слой» — фильтр отсекает журналы
сервера, а не выбирает слои.
- в cluster.md исправлены довод за окно, ложное «времени в system.parts нет»,
счёт панелей без нод (их две, не одна) и разрешение, в котором снят замер
процессора.
- панель ошибок и её запись в ADR 0002 переписаны под проверенное: отказ на
шарде воспроизведён принудительным пределом памяти.
- из queries.md убран абзац про SELECT 1 — он объяснял пол удалённой панели.
- Проверка:
- make config-test; make smoke 21/21; make check-clickhouse 10/10.
- все десять панелей отвечают через /api/ds/query в окнах на полчаса, час и
шесть часов; шаг столбика слияний проверен отдельным запросом.
77 lines
6.1 KiB
Markdown
77 lines
6.1 KiB
Markdown
# Дашборд «Запросы»
|
||
|
||
`infra/grafana/provisioning/dashboards/queries.json` — три панели поверх одной
|
||
таблицы, `system.query_log`. Вопрос у экрана один: что выполнялось и во что это
|
||
обошлось? Состав панелей и довод за каждую —
|
||
[ADR 0002](../../adr/0002-monitoring-scope.md).
|
||
|
||
Свой вопрос каждая панель называет заголовком прямо на экране. Здесь — только
|
||
то, чего в заголовке не скажешь.
|
||
|
||
Журнал у каждой ноды свой, поэтому все три панели читают его через
|
||
`clusterAllReplicas` — то же правило, что и на [«Кластере»](cluster.md).
|
||
|
||
Окно — час, обновление — полминуты. Час взят потому, что сюда приходят с
|
||
вопросом о прошлом: «почему у меня всё стояло десять минут назад». Полминуты —
|
||
чтобы только что запущенный тяжёлый запрос не пришлось ждать: в журнал он
|
||
попадает через несколько секунд после конца.
|
||
|
||
## Первым в списке видно сам мониторинг
|
||
|
||
Grafana ходит в ClickHouse обычным пользователем, и её запросы ложатся в
|
||
журнал наравне с человеческими. На спокойном стенде верх списка тяжёлых
|
||
запросов занимает `grafana`: панель свежести с дашборда «Данные» читает по
|
||
полмиллиона строк за каждое обновление.
|
||
|
||
Так и надо: мониторинг тоже стоит денег, и цену видно там же, где и всё
|
||
остальное. Спрячь мы свои запросы фильтром — цена ушла бы с глаз, а панель «Кто
|
||
спрашивает» недосчиталась бы самого частого посетителя.
|
||
|
||
Различать посетителей дашборд умеет потому, что у Grafana своя учётка со своей
|
||
ролью ([ADR 0007](../../adr/0007-clickhouse-access.md)). Ходи она под
|
||
аналитиком, панель «Кто спрашивает» показывала бы одну строку на всех.
|
||
|
||
## Что отброшено и почему
|
||
|
||
Каждый запрос попадает в журнал дважды: строкой начала и строкой конца. В
|
||
строке начала нет ни длительности, ни памяти, ни прочитанных строк — там их
|
||
ещё неоткуда взять. Панели считают по строкам конца.
|
||
|
||
Распределённый запрос кладёт в журнал не только себя. Инициатор пишет свою
|
||
строку, а каждый шард — свою, про доставшийся ему кусок. Две панели из трёх
|
||
считают только запросы инициатора: иначе один запрос человека выглядел бы
|
||
тремя, а прочитанные строки сложились бы дважды.
|
||
|
||
Панель ошибок, наоборот, куски шардов показывает: отказ случается там, где
|
||
считали, и строка шарда — единственное место, где эта нода названа. В замере с
|
||
принудительным пределом памяти `clickhouse-01` записал свой отказ, а
|
||
`clickhouse-02` — свой, и вторая строка видна только без фильтра по
|
||
инициатору.
|
||
|
||
## Пустой пользователь
|
||
|
||
Часть строк журнала приходит без имени пользователя: так записана собственная
|
||
работа сервера — чтение топиков движком Kafka, вставки материализованных
|
||
представлений, обслуживание. Панели подписывают такие строки «фоновая работа
|
||
сервера»: пустая клетка в таблице читается как поломка, а это не она.
|
||
|
||
## Что проверено
|
||
|
||
Дашборд проверен на живом стенде 21 августа 2026 года.
|
||
|
||
- Дашборд поднимается из каталога сам, все три панели отвечают через
|
||
`/api/ds/query` в окне на час. Пустых нет.
|
||
- Тяжёлый запрос виден. `GROUP BY` по `ods.event_dist` от учётки `analyst`
|
||
приехал в панель со своими числами: 741 мс, 53,32 МиБ памяти, 701 994
|
||
прочитанные строки.
|
||
- Ошибки видны и различаются по природе: отказ по правам (`bi` без `SELECT` на
|
||
`ods`) и ошибка в тексте запроса (несуществующая колонка) легли в панель
|
||
разными строками, каждая с полным текстом.
|
||
- Строка шарда в панели ошибок настоящая. Принудительный предел памяти на
|
||
распределённом `GROUP BY` дал две записи: `clickhouse-01` с
|
||
`is_initial_query = 1` и `clickhouse-02` с нулём. Вторая пропала бы, стой на
|
||
панели тот же фильтр, что на соседних.
|
||
- Панель «Кто спрашивает» разделила шесть учёток — `grafana`, `analyst`, `etl`,
|
||
`dict`, `bi`, `default` — и фоновую работу сервера. Больше всех прочитала
|
||
`grafana`: 11,5 млн строк за час, своими же панелями.
|