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

`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 млн строк за час, своими же панелями.