0 Fork 0

Files

T

ddadmin 48bec014cf fix(monitoring): доводы приведены к замерам, пары нод больше не расходятся

- Зачем:
  - второй круг ревью нашёл, что текст спорит с собственной приёмкой: окно
    держалось доводом «слияния за минуту-две», а замер даёт двадцать секунд;
    довод панели ошибок опирался на отказ по памяти, которого 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 в окнах на полчаса, час и
    шесть часов; шаг столбика слияний проверен отдельным запросом.

2026-08-21 15:28:03 -04:00

6.1 KiB

Raw Blame History

Дашборд «Запросы»

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

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

Журнал у каждой ноды свой, поэтому все три панели читают его через clusterAllReplicas — то же правило, что и на «Кластере».

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

Первым в списке видно сам мониторинг

Grafana ходит в ClickHouse обычным пользователем, и её запросы ложатся в журнал наравне с человеческими. На спокойном стенде верх списка тяжёлых запросов занимает grafana: панель свежести с дашборда «Данные» читает по полмиллиона строк за каждое обновление.

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

Различать посетителей дашборд умеет потому, что у Grafana своя учётка со своей ролью (ADR 0007). Ходи она под аналитиком, панель «Кто спрашивает» показывала бы одну строку на всех.

Что отброшено и почему

Каждый запрос попадает в журнал дважды: строкой начала и строкой конца. В строке начала нет ни длительности, ни памяти, ни прочитанных строк — там их ещё неоткуда взять. Панели считают по строкам конца.

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

Панель ошибок, наоборот, куски шардов показывает: отказ случается там, где считали, и строка шарда — единственное место, где эта нода названа. В замере с принудительным пределом памяти 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 млн строк за час, своими же панелями.

6.1 KiB Raw Blame History Unescape Escape