Пол мониторинга: источник ClickHouse в Grafana и экспортёр Kafka #114

New Issue

2026-08-21T14:43:11+03:00

ddmitry commented

2026-08-21 14:43:11 +03:00

Part of #11.

Цель

Поставить то, без чего не существует ни одной панели на SQL: свой образ Grafana
с плагином источника ClickHouse, доступ Grafana к ClickHouse и экспортёр метрик
Kafka. Панелей тикет не рисует — их дают #115 и #116.

Что войдёт

infra/grafana/Dockerfile — свой образ по образцу Airflow и Superset, плагин
ставится сборкой, версия закрепляется (ADR 0002).
compose.yaml: сервис grafana переезжает с image на build; туда же
монтируется infra/grafana/provisioning/dashboards с файлом провайдера.
Каталог заводится здесь пустым — чтобы #115 и #116 не лезли в compose.yaml
следом.
infra/grafana/provisioning/datasources/clickhouse.yml — второй источник
рядом с prometheus.yml. Учётные данные через .env; строка в
.env.example обязательна: make config-test гоняет compose config
именно с ним.
Доступ Grafana к ClickHouse — работа, а не строчка настройки. Читающих
ролей в infra/clickhouse/users.d/access.xml две, и у обеих из системных
таблиц только GRANT SELECT ON system.settings. Дашборды #116 живут на
system.query_log, частях MergeTree и очереди DDL через
clusterAllReplicas — это SELECT ON system.*, CLUSTER и REMOTE, а они
сейчас есть лишь у пишущей роли etl_writer.

Решение владельца при нарезке: заводится своя роль monitoring_reader и
свой пользователь grafana — по той же схеме, что уже в файле, у каждого
потребителя своя роль. Права: SELECT на stg.*, ods.*, dds.*, dm.*,
dic.* плюс SELECT ON system.*, CLUSTER и REMOTE. Догрузить
недостающее в analyst_reader отвергнуто: аналитик получил бы системные
таблицы и REMOTE заодно, а в system.query_log запросы Grafana стали бы
неотличимы от человеческих — ровно там, где дашборд «Запросы» и должен их
различать. Пускать Grafana под etl отвергнуто сразу: читатель не получает
права писать.

Решение идёт в ADR 0007 и README тем же PR (там сейчас «пять пользователей и
четыре роли»).
Экспортёр метрик Kafka отдельным сервисом плюс цель в
infra/prometheus/prometheus.yml, версия образа закрепляется.
Проверки, которые от этого покраснеют, чинятся здесь же.
check_prometheus_targets в scripts/stand-smoke.sh утверждает, что
Prometheus видит ровно три цели, и делает это дважды — по up и по
activeTargets. Четвёртая цель красит смоук. Новый сервис добавляется и в
LONG_LIVED_SERVICES (scripts/stand-common.sh), иначе он остаётся вне
вопроса «не убивало ли его ядро». README, строка про «три цели Prometheus», —
тем же PR.
docs/architecture/monitoring.md — справочник зоны (ADR 0011): из чего
мониторинг состоит и что скребёт Prometheus.

Границы

Ни одного JSON дашборда.
Prometheus остаётся тонким полом (ADR 0002): других целей не добавлять.

Кому что

monitoring.md и правку ADR 0007 пишет Opus — их читает человек. Кодексу:
Dockerfile, правки compose.yaml, prometheus.yml, access.xml и скриптов
проверок, прогоны.

Сначала прочитать

docs/adr/0002-monitoring-scope.md — почему образ свой; раздел «Что
проверено» — там плагин уже искали запросом;
docs/adr/0007-clickhouse-access.md и infra/clickhouse/users.d/access.xml —
устройство ролей;
scripts/stand-smoke.sh, функция check_prometheus_targets — что именно
утверждается про цели;
infra/superset/Dockerfile — образец своего образа.

Проверка

make config-test; на стенде make smoke и make check-services зелёные.

GET /api/plugins?type=datasource у Grafana возвращает плагин ClickHouse
(ADR 0002 снимал этот же запрос — тогда плагина не было).
Источник ClickHouse отвечает на пробный запрос из Grafana, в том числе на
запрос к system.* через clusterAllReplicas.
Цель экспортёра Kafka у Prometheus в состоянии up, отставание чтения
видно метрикой.
make clean && make up проходит с нуля; время подъёма названо в теле PR.

Part of #11. ## Цель Поставить то, без чего не существует ни одной панели на SQL: свой образ Grafana с плагином источника ClickHouse, доступ Grafana к ClickHouse и экспортёр метрик Kafka. Панелей тикет не рисует — их дают #115 и #116. ## Что войдёт - `infra/grafana/Dockerfile` — свой образ по образцу Airflow и Superset, плагин ставится сборкой, версия закрепляется (ADR 0002). - `compose.yaml`: сервис `grafana` переезжает с `image` на `build`; туда же монтируется `infra/grafana/provisioning/dashboards` с файлом провайдера. Каталог заводится здесь пустым — чтобы #115 и #116 не лезли в `compose.yaml` следом. - `infra/grafana/provisioning/datasources/clickhouse.yml` — второй источник рядом с `prometheus.yml`. Учётные данные через `.env`; строка в `.env.example` обязательна: `make config-test` гоняет `compose config` именно с ним. - **Доступ Grafana к ClickHouse — работа, а не строчка настройки.** Читающих ролей в `infra/clickhouse/users.d/access.xml` две, и у обеих из системных таблиц только `GRANT SELECT ON system.settings`. Дашборды #116 живут на `system.query_log`, частях MergeTree и очереди DDL через `clusterAllReplicas` — это `SELECT ON system.*`, `CLUSTER` и `REMOTE`, а они сейчас есть лишь у пишущей роли `etl_writer`. Решение владельца при нарезке: заводится **своя роль `monitoring_reader` и свой пользователь `grafana`** — по той же схеме, что уже в файле, у каждого потребителя своя роль. Права: `SELECT` на `stg.*`, `ods.*`, `dds.*`, `dm.*`, `dic.*` плюс `SELECT ON system.*`, `CLUSTER` и `REMOTE`. Догрузить недостающее в `analyst_reader` отвергнуто: аналитик получил бы системные таблицы и `REMOTE` заодно, а в `system.query_log` запросы Grafana стали бы неотличимы от человеческих — ровно там, где дашборд «Запросы» и должен их различать. Пускать Grafana под `etl` отвергнуто сразу: читатель не получает права писать. Решение идёт в ADR 0007 и README тем же PR (там сейчас «пять пользователей и четыре роли»). - Экспортёр метрик Kafka отдельным сервисом плюс цель в `infra/prometheus/prometheus.yml`, версия образа закрепляется. - **Проверки, которые от этого покраснеют, чинятся здесь же.** `check_prometheus_targets` в `scripts/stand-smoke.sh` утверждает, что Prometheus видит **ровно три** цели, и делает это дважды — по `up` и по `activeTargets`. Четвёртая цель красит смоук. Новый сервис добавляется и в `LONG_LIVED_SERVICES` (`scripts/stand-common.sh`), иначе он остаётся вне вопроса «не убивало ли его ядро». README, строка про «три цели Prometheus», — тем же PR. - `docs/architecture/monitoring.md` — справочник зоны (ADR 0011): из чего мониторинг состоит и что скребёт Prometheus. ## Границы - Ни одного JSON дашборда. - Prometheus остаётся тонким полом (ADR 0002): других целей не добавлять. ## Кому что `monitoring.md` и правку ADR 0007 пишет Opus — их читает человек. Кодексу: Dockerfile, правки `compose.yaml`, `prometheus.yml`, `access.xml` и скриптов проверок, прогоны. ## Сначала прочитать - `docs/adr/0002-monitoring-scope.md` — почему образ свой; раздел «Что проверено» — там плагин уже искали запросом; - `docs/adr/0007-clickhouse-access.md` и `infra/clickhouse/users.d/access.xml` — устройство ролей; - `scripts/stand-smoke.sh`, функция `check_prometheus_targets` — что именно утверждается про цели; - `infra/superset/Dockerfile` — образец своего образа. ## Проверка `make config-test`; на стенде `make smoke` и `make check-services` зелёные. - [x] `GET /api/plugins?type=datasource` у Grafana возвращает плагин ClickHouse (ADR 0002 снимал этот же запрос — тогда плагина не было). - [x] Источник ClickHouse отвечает на пробный запрос из Grafana, в том числе на запрос к `system.*` через `clusterAllReplicas`. - [x] Цель экспортёра Kafka у Prometheus в состоянии `up`, отставание чтения видно метрикой. - [x] `make clean && make up` проходит с нуля; время подъёма названо в теле PR.

ddmitry referenced this issue

2026-08-21 14:43:45 +03:00

Дашборд «Данные»: свежесть, поток, брак, сходимость #115

ddmitry referenced this issue

2026-08-21 14:44:11 +03:00

Дашборды «Кластер» и «Запросы»: системные таблицы через clusterAllReplicas #116

ddmitry added the ready-for-agent label 2026-08-21 14:44:53 +03:00

ddmitry added a new dependency 2026-08-21 14:44:58 +03:00

#115 Дашборд «Данные»: свежесть, поток, брак, сходимость

ddmitry added a new dependency 2026-08-21 14:44:58 +03:00

#116 Дашборды «Кластер» и «Запросы»: системные таблицы через clusterAllReplicas

ddmitry referenced this issue