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

`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)). Ходи она под
аналитиком, панель «Кто спрашивает» показывала бы одну строку на всех.

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

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

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

Панель ошибок, наоборот, куски шардов показывает. Отказ по памяти случается
там, где считали, — на шарде; инициатор в своей строке передаст только текст
ошибки, а нода, на которой всё случилось, останется неназванной.

## Пустой пользователь

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

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

Дашборд проверен на живом стенде 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 млн строк за час.