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 в окнах на полчаса, час и
    шесть часов.

docs/adr/0002-monitoring-scope.md

@@ -127,6 +127,14 @@ ClickHouse, Kafka и Airflow, 17 — в дашборде генератора, 1
 keeper, и обе ноды читают её целиком — запрос вернул с каждой одни и те же 124
 записи. Обёртка там не добавила бы правды, а удвоила бы каждую строку, поэтому
 единственная панель «Кластера» без неё — эта. Keeper своих системных таблиц не
-имеет вовсе, и панель по нему приходит из Prometheus. Устройство обоих
+имеет вовсе, и панель по нему приходит из Prometheus.
-дашбордов — [cluster.md](../architecture/monitoring/cluster.md) и
+
+«Запросы» получили на две панели больше, чем сказано выше. Разбор запросов по
+посетителям продиктован [ADR 0007](0007-clickhouse-access.md): своя учётка
+Grafana заведена там ровно затем, чтобы её запросы были отличимы от
+человеческих.
+Отдельная панель ошибок понадобилась под здешний же сюжет про тяжёлый
+`GROUP BY`: отказ по памяти случается на шарде, и текст ошибки — единственное
+место, где написано, на каком. Устройство обоих дашбордов —
+[cluster.md](../architecture/monitoring/cluster.md) и
 [queries.md](../architecture/monitoring/queries.md).

docs/architecture/monitoring/README.md

@@ -81,8 +81,8 @@ Grafana ходит пользователем `grafana` с ролью `monitorin
   обеих нод, части и слияния, keeper, очередь распределённых DDL. Устройство и
   разбор панелей — [cluster.md](cluster.md).
 - **«Запросы»** (`queries.json`) — что выполнялось и во что обошлось: тяжёлые
-  запросы, поток запросов, аппетит по пользователям, ошибки. Устройство и
+  запросы, аппетит по посетителям, ошибки. Устройство и разбор панелей —
-  разбор панелей — [queries.md](queries.md).
+  [queries.md](queries.md).
 
 ## Что проверено
 

docs/architecture/monitoring/cluster.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`), а не
+У дисков считаются обращения к файлам — `OSReadChars` и `OSWriteChars`.
-блоками, дошедшими до устройства (`OSReadBytes`). Блочное чтение на стенде
+Счётчики блочного устройства (`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, и обёртка ей действительно не нужна:
+  `clusterAllReplicas` осталась очередь DDL, и обёртка ей действительно не
-  запрос с ней вернул 124 записи с `clickhouse-01` и те же 124 с
+  нужна: запрос с ней вернул 124 записи с `clickhouse-01` и те же 124 с
   `clickhouse-02`.
 - Под нагрузкой. `make generate-batch` (50 626 событий одной пачкой): процессор
-  поднялся с 0,06–0,07 ядра до 0,37–0,38, запись — с 300 КиБ/с до 1,1 МиБ/с,
+  поднялся с 0,04–0,18 ядра до 0,54 и 0,64, запись — с 400 КиБ/с до 2,1 и
-  активных частей стало 145 против 131. Через полминуты после конца вставки
+  4,5 МиБ/с. Следующие десять секунд обе величины уже вернулись к прежним: на
-  процессор вернулся к 0,02–0,07 ядра, части осели до 135.
+  таком объёме подъём и оседание укладываются в полминуты.
-- Панель частей показала `ods.order_rep` по 136 строк в части против 11 171 у
+- Слияния под той же нагрузкой отозвались столбиком: два слияния в `stg`,
-  `ods.event_rep` — заказы приезжают дневным слепком, события потоком.
+  15 съеденных частей.
-- Панель слияний за полчаса: `stg.hits_raw_rep` съела 430 частей, `ods.event_rep`
+- Блочное чтение действительно молчит: за минуту вокруг вставки `OSReadBytes`
-  — 401, и рядом с ними системные журналы с сопоставимыми числами.
+  был нулевым в десяти десятисекундных окнах из четырнадцати, а обращения к
+  файлам шли непрерывно во всех.
+- Память: около 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}`) и правило, по которому пунктирной
+Подписи рядов (`${__field.labels.node}`) и правило, по которому пунктирным
-становится только «коробка», сверены по документации Grafana через MCP
+становится только ряд «отведено», сверены по документации Grafana через MCP
-Context7. Оба применяются на стороне браузера, и через `/api/ds/query` их не
+Context7. И то и другое применяется на стороне браузера, через
-видно: там проверено, что нода приезжает меткой ряда, а метрика — его именем.
+`/api/ds/query` их не видно: там проверено только, что нода приезжает меткой
+ряда, а метрика — его именем.

docs/architecture/monitoring/queries.md

@@ -1,14 +1,14 @@
 # Дашборд «Запросы»
 
-`infra/grafana/provisioning/dashboards/queries.json` — четыре панели поверх
+`infra/grafana/provisioning/dashboards/queries.json` — три панели поверх одной
-одной таблицы, `system.query_log`. Вопрос у экрана один: что выполнялось и во
+таблицы, `system.query_log`. Вопрос у экрана один: что выполнялось и во что это
-что это обошлось? Состав панелей и довод за каждую —
+обошлось? Состав панелей и довод за каждую —
 [ADR 0002](../../adr/0002-monitoring-scope.md).
 
 Свой вопрос каждая панель называет заголовком прямо на экране. Здесь — только
 то, чего в заголовке не скажешь.
 
-Обе ноды пишут журнал каждая свой, поэтому все четыре панели читают его через
+Журнал у каждой ноды свой, поэтому все три панели читают его через
 `clusterAllReplicas` — то же правило, что и на [«Кластере»](cluster.md).
 
 Окно — час, обновление — полминуты. Час взят потому, что сюда приходят с
@@ -21,15 +21,18 @@
 Grafana ходит в ClickHouse обычным пользователем, и её запросы ложатся в
 журнал наравне с человеческими. На спокойном стенде верх списка тяжёлых
 запросов занимает `grafana`: панель свежести с дашборда «Данные» читает по
-полмиллиона строк раз в минуту.
+полмиллиона строк за каждое обновление.
 
-Это не помеха, а первое, что дашборд рассказывает: мониторинг тоже стоит
+Так и надо: мониторинг тоже стоит денег, и цену видно там же, где и всё
-денег, и цену видно там же, где и всё остальное. Скрывать свои запросы
+остальное. Спрячь мы свои запросы фильтром — цена ушла бы с глаз, а панель «Кто
-фильтром означало бы прятать эту цену — и заодно сделать панель «Кто
+спрашивает» недосчиталась бы самого частого посетителя.
-спрашивает» неполной ровно на самого частого посетителя.
 
-Различать пользователей дашборд умеет потому, что у Grafana своя учётка со
+Там же, в «Кто спрашивает», стоит `default` с сотнями запросов и одной
-своей ролью ([ADR 0007](../../adr/0007-clickhouse-access.md)). Ходи она под
+прочитанной строкой на каждый: это `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`
+- Ошибки видны и различаются по природе: отказ по правам (`bi` без `SELECT` на
-  на `ods`) и ошибка в тексте запроса (несуществующая колонка) легли в панель
+  `ods`) и ошибка в тексте запроса (несуществующая колонка) легли в панель
-  разными строками с полным текстом обеих.
+  разными строками, каждая с полным текстом.
-- Панель «Кто спрашивает» разделила семь посетителей: `grafana`, `analyst`,
+- Панель «Кто спрашивает» разделила шесть учёток — `grafana`, `analyst`, `etl`,
-  `etl`, `dict`, `bi`, `default` и фоновую работу сервера. Больше всех
+  `dict`, `bi`, `default` — и фоновую работу сервера. Больше всех прочитала
-  прочитала `grafana` — её же панели, 11,5 млн строк за час.
+  `grafana`: 11,5 млн строк за час, своими же панелями.

infra/grafana/provisioning/dashboards/cluster.json

@@ -77,7 +77,7 @@
           "editorType": "sql",
           "queryType": "timeseries",
           "format": 0,
-          "rawSql": "SELECT\n    $__timeInterval(event_time) AS t,\n    hostName() AS node,\n    -- Занятое меряется резидентной памятью: именно её ядро сравнивает с\n    -- пределом контейнера, когда решает, убить ли ноду.\n    maxIf(value, metric = 'MemoryResident') AS \"занято\",\n    maxIf(value, metric = 'CGroupMemoryTotal') AS \"коробка\"\nFROM clusterAllReplicas('clickstream_cluster', system.asynchronous_metric_log)\nWHERE $__timeFilter(event_time)\n    AND metric IN ('MemoryResident', 'CGroupMemoryTotal')\nGROUP BY t, node\nORDER BY t, node"
+          "rawSql": "SELECT\n    $__timeInterval(event_time) AS t,\n    hostName() AS node,\n    -- Занятое меряется резидентной памятью: именно её ядро сравнивает с\n    -- пределом контейнера, когда решает, убить ли ноду.\n    maxIf(value, metric = 'MemoryResident') AS \"занято\",\n    maxIf(value, metric = 'CGroupMemoryTotal') AS \"отведено\"\nFROM clusterAllReplicas('clickstream_cluster', system.asynchronous_metric_log)\nWHERE $__timeFilter(event_time)\n    AND metric IN ('MemoryResident', 'CGroupMemoryTotal')\nGROUP BY t, node\nORDER BY t, node"
         }
       ],
       "fieldConfig": {
@@ -90,7 +90,7 @@
           {
             "matcher": {
               "id": "byRegexp",
-              "options": "коробка.*"
+              "options": "отведено.*"
             },
             "properties": [
               {
@@ -176,7 +176,7 @@
           "editorType": "sql",
           "queryType": "table",
           "format": 1,
-          "rawSql": "SELECT\n    concat(database, '.', table) AS \"Таблица\",\n    hostName() AS \"Нода\",\n    count() AS \"Частей\",\n    sum(rows) AS \"Строк\",\n    round(sum(rows) / count()) AS \"Строк в части\",\n    sum(bytes_on_disk) AS \"На диске\"\nFROM clusterAllReplicas('clickstream_cluster', system.parts)\nWHERE active\nGROUP BY \"Таблица\", \"Нода\"\nORDER BY \"Частей\" DESC, \"Таблица\"\nLIMIT 15"
+          "rawSql": "SELECT\n    concat(database, '.', table) AS \"Таблица\",\n    hostName() AS \"Нода\",\n    count() AS \"Частей\",\n    sum(rows) AS \"Строк\",\n    round(sum(rows) / count()) AS \"Строк в части\",\n    sum(bytes_on_disk) AS \"На диске\"\nFROM clusterAllReplicas('clickstream_cluster', system.parts)\nWHERE active\n    AND database != 'system'\nGROUP BY \"Таблица\", \"Нода\"\nORDER BY \"Частей\" DESC, \"Таблица\", \"Нода\"\n"
         }
       ],
       "fieldConfig": {
@@ -198,8 +198,8 @@
       }
     },
     {
-      "type": "table",
+      "type": "timeseries",
-      "title": "Слияния: сколько частей они съели и чего это стоило",
+      "title": "Слияния: сколько частей они съедают в каждом слое",
       "datasource": {
         "type": "grafana-clickhouse-datasource",
         "uid": "clickhouse"
@@ -210,7 +210,11 @@
         "x": 12,
         "y": 8
       },
-      "options": {},
+      "options": {
+        "tooltip": {
+          "mode": "multi"
+        }
+      },
       "targets": [
         {
           "refId": "A",
@@ -219,27 +223,24 @@
             "uid": "clickhouse"
           },
           "editorType": "sql",
-          "queryType": "table",
+          "queryType": "timeseries",
-          "format": 1,
+          "format": 0,
-          "rawSql": "SELECT\n    concat(database, '.', table) AS \"Таблица\",\n    hostName() AS \"Нода\",\n    sum(length(merged_from)) AS \"Частей съело\",\n    count() AS \"Слияний\",\n    sum(rows) AS \"Строк переварило\",\n    round(sum(duration_ms) / 1000, 1) AS \"Заняло, с\",\n    max(peak_memory_usage) AS \"Пиковая память\"\nFROM clusterAllReplicas('clickstream_cluster', system.part_log)\nWHERE $__timeFilter(event_time)\n    AND event_type = 'MergeParts'\nGROUP BY \"Таблица\", \"Нода\"\nORDER BY \"Частей съело\" DESC, \"Таблица\"\nLIMIT 15"
+          "rawSql": "SELECT\n    $__timeInterval(event_time) AS t,\n    database AS db,\n    sum(length(merged_from)) AS \"частей съедено\"\nFROM clusterAllReplicas('clickstream_cluster', system.part_log)\nWHERE $__timeFilter(event_time)\n    AND event_type = 'MergeParts'\n    AND database != 'system'\nGROUP BY t, db\nORDER BY t, db"
         }
       ],
       "fieldConfig": {
-        "defaults": {},
+        "defaults": {
-        "overrides": [
+          "displayName": "${__field.labels.db}",
-          {
+          "min": 0,
-            "matcher": {
+          "custom": {
-              "id": "byName",
+            "drawStyle": "bars",
-              "options": "Пиковая память"
+            "fillOpacity": 60,
-            },
+            "stacking": {
-            "properties": [
+              "mode": "normal"
-              {
+            }
-                "id": "unit",
-                "value": "bytes"
-              }
-            ]
           }
-        ]
+        },
+        "overrides": []
       }
     },
     {

infra/grafana/provisioning/dashboards/queries.json

@@ -54,44 +54,6 @@
         ]
       }
     },
-    {
-      "type": "timeseries",
-      "title": "Поток запросов: сколько выполнено и сколько упало",
-      "datasource": {
-        "type": "grafana-clickhouse-datasource",
-        "uid": "clickhouse"
-      },
-      "gridPos": {
-        "h": 8,
-        "w": 8,
-        "x": 0,
-        "y": 10
-      },
-      "options": {
-        "tooltip": {
-          "mode": "multi"
-        }
-      },
-      "targets": [
-        {
-          "refId": "A",
-          "datasource": {
-            "type": "grafana-clickhouse-datasource",
-            "uid": "clickhouse"
-          },
-          "editorType": "sql",
-          "queryType": "timeseries",
-          "format": 0,
-          "rawSql": "SELECT\n    $__timeInterval(event_time) AS t,\n    countIf(type = 'QueryFinish') AS \"выполнено\",\n    countIf(type IN ('ExceptionBeforeStart', 'ExceptionWhileProcessing')) AS \"упало\"\nFROM clusterAllReplicas('clickstream_cluster', system.query_log)\nWHERE $__timeFilter(event_time)\n    AND is_initial_query\nGROUP BY t\nORDER BY t"
-        }
-      ],
-      "fieldConfig": {
-        "defaults": {
-          "min": 0
-        },
-        "overrides": []
-      }
-    },
     {
       "type": "table",
       "title": "Кто спрашивает: сколько запросов и какой у них аппетит",
@@ -101,8 +63,8 @@
       },
       "gridPos": {
         "h": 8,
-        "w": 16,
+        "w": 24,
-        "x": 8,
+        "x": 0,
         "y": 10
       },
       "options": {},
@@ -116,7 +78,7 @@
           "editorType": "sql",
           "queryType": "table",
           "format": 1,
-          "rawSql": "SELECT\n    if(empty(user), 'фоновая работа сервера', user) AS \"Кто\",\n    count() AS \"Запросов\",\n    sum(read_rows) AS \"Прочитано строк\",\n    max(read_rows) AS \"Самый читающий, строк\",\n    max(memory_usage) AS \"Самый прожорливый, память\",\n    round(quantile(0.9)(query_duration_ms)) AS \"Девять из десяти быстрее, мс\"\nFROM clusterAllReplicas('clickstream_cluster', system.query_log)\nWHERE $__timeFilter(event_time)\n    AND type != 'QueryStart'\n    AND is_initial_query\nGROUP BY \"Кто\"\nORDER BY \"Прочитано строк\" DESC"
+          "rawSql": "SELECT\n    if(empty(user), 'фоновая работа сервера', user) AS \"Кто\",\n    count() AS \"Запросов\",\n    sum(read_rows) AS \"Прочитано строк\",\n    max(memory_usage) AS \"Самый прожорливый, память\",\n    round(quantile(0.9)(query_duration_ms)) AS \"Девять из десяти быстрее, мс\"\nFROM clusterAllReplicas('clickstream_cluster', system.query_log)\nWHERE $__timeFilter(event_time)\n    AND type != 'QueryStart'\n    AND is_initial_query\nGROUP BY \"Кто\"\nORDER BY \"Прочитано строк\" DESC"
         }
       ],
       "fieldConfig": {
@@ -145,7 +107,7 @@
         "uid": "clickhouse"
       },
       "gridPos": {
-        "h": 7,
+        "h": 8,
         "w": 24,
         "x": 0,
         "y": 18