diff --git a/docs/adr/0002-monitoring-scope.md b/docs/adr/0002-monitoring-scope.md index fb1f2c2..5bf6767 100644 --- a/docs/adr/0002-monitoring-scope.md +++ b/docs/adr/0002-monitoring-scope.md @@ -127,6 +127,14 @@ ClickHouse, Kafka и Airflow, 17 — в дашборде генератора, 1 keeper, и обе ноды читают её целиком — запрос вернул с каждой одни и те же 124 записи. Обёртка там не добавила бы правды, а удвоила бы каждую строку, поэтому единственная панель «Кластера» без неё — эта. Keeper своих системных таблиц не -имеет вовсе, и панель по нему приходит из Prometheus. Устройство обоих -дашбордов — [cluster.md](../architecture/monitoring/cluster.md) и +имеет вовсе, и панель по нему приходит из Prometheus. + +«Запросы» получили на две панели больше, чем сказано выше. Разбор запросов по +посетителям продиктован [ADR 0007](0007-clickhouse-access.md): своя учётка +Grafana заведена там ровно затем, чтобы её запросы были отличимы от +человеческих. +Отдельная панель ошибок понадобилась под здешний же сюжет про тяжёлый +`GROUP BY`: отказ по памяти случается на шарде, и текст ошибки — единственное +место, где написано, на каком. Устройство обоих дашбордов — +[cluster.md](../architecture/monitoring/cluster.md) и [queries.md](../architecture/monitoring/queries.md). diff --git a/docs/architecture/monitoring/README.md b/docs/architecture/monitoring/README.md index f671e32..69a806d 100644 --- a/docs/architecture/monitoring/README.md +++ b/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). ## Что проверено diff --git a/docs/architecture/monitoring/cluster.md b/docs/architecture/monitoring/cluster.md index f0dd258..69a263e 100644 --- a/docs/architecture/monitoring/cluster.md +++ b/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`), а не -блоками, дошедшими до устройства (`OSReadBytes`). Блочное чтение на стенде -почти всегда ноль: части лежат в страничном кэше, и слияние перечитывает их -оттуда. Работа при этом делается настоящая, и панель по блокам показывала бы, -что её нет. +У дисков считаются обращения к файлам — `OSReadChars` и `OSWriteChars`. +Счётчики блочного устройства (`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, и обёртка ей действительно не нужна: - запрос с ней вернул 124 записи с `clickhouse-01` и те же 124 с +- Обе ноды видны на всех панелях по системным таблицам, кроме одной. Без + `clusterAllReplicas` осталась очередь DDL, и обёртка ей действительно не + нужна: запрос с ней вернул 124 записи с `clickhouse-01` и те же 124 с `clickhouse-02`. - Под нагрузкой. `make generate-batch` (50 626 событий одной пачкой): процессор - поднялся с 0,06–0,07 ядра до 0,37–0,38, запись — с 300 КиБ/с до 1,1 МиБ/с, - активных частей стало 145 против 131. Через полминуты после конца вставки - процессор вернулся к 0,02–0,07 ядра, части осели до 135. -- Панель частей показала `ods.order_rep` по 136 строк в части против 11 171 у - `ods.event_rep` — заказы приезжают дневным слепком, события потоком. -- Панель слияний за полчаса: `stg.hits_raw_rep` съела 430 частей, `ods.event_rep` - — 401, и рядом с ними системные журналы с сопоставимыми числами. + поднялся с 0,04–0,18 ядра до 0,54 и 0,64, запись — с 400 КиБ/с до 2,1 и + 4,5 МиБ/с. Следующие десять секунд обе величины уже вернулись к прежним: на + таком объёме подъём и оседание укладываются в полминуты. +- Слияния под той же нагрузкой отозвались столбиком: два слияния в `stg`, + 15 съеденных частей. +- Блочное чтение действительно молчит: за минуту вокруг вставки `OSReadBytes` + был нулевым в десяти десятисекундных окнах из четырнадцати, а обращения к + файлам шли непрерывно во всех. +- Память: около 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}`) и правило, по которому пунктирной -становится только «коробка», сверены по документации Grafana через MCP -Context7. Оба применяются на стороне браузера, и через `/api/ds/query` их не -видно: там проверено, что нода приезжает меткой ряда, а метрика — его именем. +Подписи рядов (`${__field.labels.node}`) и правило, по которому пунктирным +становится только ряд «отведено», сверены по документации Grafana через MCP +Context7. И то и другое применяется на стороне браузера, через +`/api/ds/query` их не видно: там проверено только, что нода приезжает меткой +ряда, а метрика — его именем. diff --git a/docs/architecture/monitoring/queries.md b/docs/architecture/monitoring/queries.md index 43e5bb0..3db86fe 100644 --- a/docs/architecture/monitoring/queries.md +++ b/docs/architecture/monitoring/queries.md @@ -1,14 +1,14 @@ # Дашборд «Запросы» -`infra/grafana/provisioning/dashboards/queries.json` — четыре панели поверх -одной таблицы, `system.query_log`. Вопрос у экрана один: что выполнялось и во -что это обошлось? Состав панелей и довод за каждую — +`infra/grafana/provisioning/dashboards/queries.json` — три панели поверх одной +таблицы, `system.query_log`. Вопрос у экрана один: что выполнялось и во что это +обошлось? Состав панелей и довод за каждую — [ADR 0002](../../adr/0002-monitoring-scope.md). Свой вопрос каждая панель называет заголовком прямо на экране. Здесь — только то, чего в заголовке не скажешь. -Обе ноды пишут журнал каждая свой, поэтому все четыре панели читают его через +Журнал у каждой ноды свой, поэтому все три панели читают его через `clusterAllReplicas` — то же правило, что и на [«Кластере»](cluster.md). Окно — час, обновление — полминуты. Час взят потому, что сюда приходят с @@ -21,15 +21,18 @@ Grafana ходит в ClickHouse обычным пользователем, и её запросы ложатся в журнал наравне с человеческими. На спокойном стенде верх списка тяжёлых запросов занимает `grafana`: панель свежести с дашборда «Данные» читает по -полмиллиона строк раз в минуту. +полмиллиона строк за каждое обновление. -Это не помеха, а первое, что дашборд рассказывает: мониторинг тоже стоит -денег, и цену видно там же, где и всё остальное. Скрывать свои запросы -фильтром означало бы прятать эту цену — и заодно сделать панель «Кто -спрашивает» неполной ровно на самого частого посетителя. +Так и надо: мониторинг тоже стоит денег, и цену видно там же, где и всё +остальное. Спрячь мы свои запросы фильтром — цена ушла бы с глаз, а панель «Кто +спрашивает» недосчиталась бы самого частого посетителя. -Различать пользователей дашборд умеет потому, что у Grafana своя учётка со -своей ролью ([ADR 0007](../../adr/0007-clickhouse-access.md)). Ходи она под +Там же, в «Кто спрашивает», стоит `default` с сотнями запросов и одной +прочитанной строкой на каждый: это `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` - на `ods`) и ошибка в тексте запроса (несуществующая колонка) легли в панель - разными строками с полным текстом обеих. -- Панель «Кто спрашивает» разделила семь посетителей: `grafana`, `analyst`, - `etl`, `dict`, `bi`, `default` и фоновую работу сервера. Больше всех - прочитала `grafana` — её же панели, 11,5 млн строк за час. +- Ошибки видны и различаются по природе: отказ по правам (`bi` без `SELECT` на + `ods`) и ошибка в тексте запроса (несуществующая колонка) легли в панель + разными строками, каждая с полным текстом. +- Панель «Кто спрашивает» разделила шесть учёток — `grafana`, `analyst`, `etl`, + `dict`, `bi`, `default` — и фоновую работу сервера. Больше всех прочитала + `grafana`: 11,5 млн строк за час, своими же панелями. diff --git a/infra/grafana/provisioning/dashboards/cluster.json b/infra/grafana/provisioning/dashboards/cluster.json index 8653069..3e2ada0 100644 --- a/infra/grafana/provisioning/dashboards/cluster.json +++ b/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", - "title": "Слияния: сколько частей они съели и чего это стоило", + "type": "timeseries", + "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", - "format": 1, - "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" + "queryType": "timeseries", + "format": 0, + "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": {}, - "overrides": [ - { - "matcher": { - "id": "byName", - "options": "Пиковая память" - }, - "properties": [ - { - "id": "unit", - "value": "bytes" - } - ] + "defaults": { + "displayName": "${__field.labels.db}", + "min": 0, + "custom": { + "drawStyle": "bars", + "fillOpacity": 60, + "stacking": { + "mode": "normal" + } } - ] + }, + "overrides": [] } }, { diff --git a/infra/grafana/provisioning/dashboards/queries.json b/infra/grafana/provisioning/dashboards/queries.json index 871cdf3..daf9e23 100644 --- a/infra/grafana/provisioning/dashboards/queries.json +++ b/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, - "x": 8, + "w": 24, + "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