ddmitry/clickstream-data-platform
1
0
Fork 0
Code Issues 16 Pull Requests Actions Packages Projects Releases Wiki Activity

Остальной стенд: Kafka, Airflow 3, Superset, мониторинг — make up и сквозной smoke #13

New Issue
Closed
opened 2026-07-30 16:43:53 +03:00 by ddmitry · 2 comments
ddmitry commented 2026-07-30 16:43:53 +03:00
Owner
Copy Link
Copy Source

Родитель

#3 — Этап 1: каркас стенда, кластерный compose.

Что сделать

Добавить рядом с кластером остальной стенд: Kafka, Airflow, Superset, Prometheus и Grafana. make up поднимает всё одной командой, make down гасит. Airflow подключается к ноде 1 ClickHouse, Superset — к ноде 2 (это осознанная ловушка правильных ошибок: забытый ON CLUSTER проявится потом в дашборде сам). Мониторинг видит цели: обе ноды ClickHouse и keeper.

Версия Airflow — третья. Её нужно зафиксировать явно, потому что API третьей версии отличается от второй (Datasets переименованы в Assets), и все DAG'и стенда пишутся уже под неё.

Критерии приёмки

  • Версия Airflow 3.x зафиксирована в compose явным тегом образа (не latest) и видна в интерфейсе.
  • make up поднимает весь стенд; все контейнеры доходят до здорового состояния.
  • Kafka отвечает: топики создаются и их список читается штатной командой.
  • Интерфейс Airflow открывается, планировщик живой, пример-DAG виден в списке и проходит ручной запуск.
  • Интерфейс Superset открывается; подключение к ноде 2 ClickHouse проходит проверку соединения.
  • Prometheus показывает цели в состоянии «up» для обеих нод ClickHouse и для keeper; Grafana открывается, Prometheus подключён как источник данных.
  • make down и сброс стенда описаны в документации и работают.
  • Порты и переменные окружения собраны в .env.example; секретов в репозитории нет.
  • Сквозная smoke-проверка собрана в одну команду и печатает понятный отчёт по каждому сервису.

Границы

  • Kafka-таблицы, матвью и приём событий — этап 2. Здесь только брокер и создание топиков.
  • Рабочие DAG'и (etl_pipeline и прочие) — этап 5. Здесь только пример-DAG, доказывающий, что Airflow работает.
  • Датасеты и дашборд Superset — этап 8. Здесь только рабочее подключение к ноде 2.
  • Правила оповещений и панели мониторинга — этап 9. Здесь только доступность целей.

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

  • docs/specs/2026-07-30-stand-v2-realism.md: раздел 6 (роли нод и бюджет памяти: полный стенд в покое около 3,4 ГБ, кластер добавляет 0,6–0,8 ГБ) и раздел 9 (объём: инфраструктура ~10–12 файлов, мониторинг 2–4 конфига).
  • AGENTS.md. Перед выбором образа и написанием примера-DAG уточнить API Airflow 3 через MCP Context7.

Проверка

  • make up, затем сквозная smoke-команда.
  • Глазами: интерфейсы Airflow, Superset, Grafana открываются; страница целей Prometheus зелёная по трём целям ClickHouse и keeper.
  • make down и повторный make up — стенд поднимается снова.

Блокируется

#12 — конфиги кластера и макросы должны быть на месте: Superset и мониторинг некуда направлять, пока нет двух нод и keeper.

## Родитель #3 — Этап 1: каркас стенда, кластерный compose. ## Что сделать Добавить рядом с кластером остальной стенд: Kafka, Airflow, Superset, Prometheus и Grafana. `make up` поднимает всё одной командой, `make down` гасит. Airflow подключается к ноде 1 ClickHouse, Superset — к ноде 2 (это осознанная ловушка правильных ошибок: забытый ON CLUSTER проявится потом в дашборде сам). Мониторинг видит цели: обе ноды ClickHouse и keeper. Версия Airflow — третья. Её нужно зафиксировать явно, потому что API третьей версии отличается от второй (Datasets переименованы в Assets), и все DAG'и стенда пишутся уже под неё. ## Критерии приёмки - [x] Версия Airflow 3.x зафиксирована в compose явным тегом образа (не `latest`) и видна в интерфейсе. - [x] `make up` поднимает весь стенд; все контейнеры доходят до здорового состояния. - [x] Kafka отвечает: топики создаются и их список читается штатной командой. - [x] Интерфейс Airflow открывается, планировщик живой, пример-DAG виден в списке и проходит ручной запуск. - [x] Интерфейс Superset открывается; подключение к ноде 2 ClickHouse проходит проверку соединения. - [x] Prometheus показывает цели в состоянии «up» для обеих нод ClickHouse и для keeper; Grafana открывается, Prometheus подключён как источник данных. - [x] `make down` и сброс стенда описаны в документации и работают. - [x] Порты и переменные окружения собраны в `.env.example`; секретов в репозитории нет. - [x] Сквозная smoke-проверка собрана в одну команду и печатает понятный отчёт по каждому сервису. ## Границы - Kafka-таблицы, матвью и приём событий — этап 2. Здесь только брокер и создание топиков. - Рабочие DAG'и (`etl_pipeline` и прочие) — этап 5. Здесь только пример-DAG, доказывающий, что Airflow работает. - Датасеты и дашборд Superset — этап 8. Здесь только рабочее подключение к ноде 2. - Правила оповещений и панели мониторинга — этап 9. Здесь только доступность целей. ## Сначала прочитать - `docs/specs/2026-07-30-stand-v2-realism.md`: раздел 6 (роли нод и бюджет памяти: полный стенд в покое около 3,4 ГБ, кластер добавляет 0,6–0,8 ГБ) и раздел 9 (объём: инфраструктура ~10–12 файлов, мониторинг 2–4 конфига). - `AGENTS.md`. Перед выбором образа и написанием примера-DAG уточнить API Airflow 3 через MCP Context7. ## Проверка - `make up`, затем сквозная smoke-команда. - Глазами: интерфейсы Airflow, Superset, Grafana открываются; страница целей Prometheus зелёная по трём целям ClickHouse и keeper. - `make down` и повторный `make up` — стенд поднимается снова. ## Блокируется #12 — конфиги кластера и макросы должны быть на месте: Superset и мониторинг некуда направлять, пока нет двух нод и keeper.
ddmitry added the ready-for-agent label 2026-07-30 16:43:53 +03:00
ddmitry commented 2026-07-30 18:36:45 +03:00
Author
Owner
Copy Link
Copy Source

Наблюдения ревьюера #12, которые чинить там не стали: они попадают в границы этого тикета.

  1. Healthcheck нод проверяет живость, а не готовность. SELECT 1 остаётся зелёным при недоступном keeper — проверено: обе ноды числились healthy ещё 25 секунд после остановки keeper. Сервисы этого этапа, которые повесят depends_on: service_healthy на clickhouse-01, унаследуют сигнал «процесс жив», а не «кластер работоспособен».

  2. CLICKHOUSE_SKIP_USER_SETUP=1 проглотит будущий пароль молча. Переменная стоит первой ветвью в цепочке if штатного entrypoint образа, поэтому добавленные позже CLICKHOUSE_USER/CLICKHOUSE_PASSWORD просто не будут применены — без ошибки. Сама переменная не карго-культ: без неё entrypoint пишет users.d/default-user.xml, ограничивающий default адресами 127.0.0.1/::1, и межнодовые запросы через Distributed ломаются.

  3. mem_limit: 1g на ноду — это потолок для всего, что придёт дальше. В покое кластер занимает 0,49 ГБ (222 + 216 + 51 МБ), запас есть, но под этим лимитом будут жить Kafka Engine, матвью и запросы Superset.

Наблюдения ревьюера #12, которые чинить там не стали: они попадают в границы этого тикета. 1. **Healthcheck нод проверяет живость, а не готовность.** `SELECT 1` остаётся зелёным при недоступном keeper — проверено: обе ноды числились `healthy` ещё 25 секунд после остановки keeper. Сервисы этого этапа, которые повесят `depends_on: service_healthy` на `clickhouse-01`, унаследуют сигнал «процесс жив», а не «кластер работоспособен». 2. **`CLICKHOUSE_SKIP_USER_SETUP=1` проглотит будущий пароль молча.** Переменная стоит первой ветвью в цепочке `if` штатного entrypoint образа, поэтому добавленные позже `CLICKHOUSE_USER`/`CLICKHOUSE_PASSWORD` просто не будут применены — без ошибки. Сама переменная не карго-культ: без неё entrypoint пишет `users.d/default-user.xml`, ограничивающий `default` адресами 127.0.0.1/::1, и межнодовые запросы через Distributed ломаются. 3. **`mem_limit: 1g` на ноду — это потолок для всего, что придёт дальше.** В покое кластер занимает 0,49 ГБ (222 + 216 + 51 МБ), запас есть, но под этим лимитом будут жить Kafka Engine, матвью и запросы Superset.
ddmitry commented 2026-07-31 08:38:52 +03:00
Author
Owner
Copy Link
Copy Source

Реализация готова, ветка feat/13-stand-full.

Что стоит на стенде. Рядом с кластером ClickHouse подняты Kafka (KRaft, без ZooKeeper), Postgres для метаданных Airflow и Superset, Airflow 3.3 четырьмя сервисами (api-server, планировщик, обработчик DAG, разовая инициализация), Superset 6.1 и мониторинг — Prometheus и Grafana. make up поднимает всё одной командой. Ловушка правильных ошибок сохранена намеренно: подключение Airflow ведёт на ноду 1, подключение Superset — на ноду 2, поэтому забытый ON CLUSTER виден в дашборде сам.

Проверка. make smoke — сквозная проверка стенда, 24 пункта. Это не «контейнер запущен»: временный топик в Kafka создаётся, находится и удаляется; Prometheus видит ровно три цели ClickHouse со значением up=1; Airflow пускает по учётным данным и реально запускает пример DAG через API; Superset проверяет своим test-db подключение, вынутое из собственных метаданных; расход памяти сверяется с порогом 3,4 ГБ.

Прогон приёмки на чистых томах: make clean → cp .env.example .env → make up (1 мин 51 с) → make smoke — 24 пройдено, 0 ошибок, 2171 MiB. Также зелены make config-test (статические ворота, 3/0 и 5/0), make smoke-cluster (8/8) и make smoke-guards (3/0 и 3/0) — стражи специально ломают стенд и проверяют, что отчёт краснеет, а после восстановления снова зеленеет.

Конвейер. Постановка прошла два слепых ревью (26 замечаний, все приняты), реализация — саморевью, два слепых ревью кода с разными линзами и триаж: 16 исправлено, 1 отклонено обоснованно. Узкие перепроверки закрыли все находки обеих линий.

Отдельно поймано на приёмке, уже исправлено: восстановленные статические ворота были написаны на ripgrep, которого на машине нет, и при этом печатали «ЗЕЛЁНО» поверх упавшей проверки — код возврата подстановки процесса не ловился, и проверка синтаксиса Bash молча не проверяла ничего.

Решения записаны в docs/adr/0001-stand-services.md, состав стенда и порядок работы — в README.md.

Реализация готова, ветка `feat/13-stand-full`. **Что стоит на стенде.** Рядом с кластером ClickHouse подняты Kafka (KRaft, без ZooKeeper), Postgres для метаданных Airflow и Superset, Airflow 3.3 четырьмя сервисами (api-server, планировщик, обработчик DAG, разовая инициализация), Superset 6.1 и мониторинг — Prometheus и Grafana. `make up` поднимает всё одной командой. Ловушка правильных ошибок сохранена намеренно: подключение Airflow ведёт на ноду 1, подключение Superset — на ноду 2, поэтому забытый `ON CLUSTER` виден в дашборде сам. **Проверка.** `make smoke` — сквозная проверка стенда, 24 пункта. Это не «контейнер запущен»: временный топик в Kafka создаётся, находится и удаляется; Prometheus видит ровно три цели ClickHouse со значением `up=1`; Airflow пускает по учётным данным и реально запускает пример DAG через API; Superset проверяет своим `test-db` подключение, вынутое из собственных метаданных; расход памяти сверяется с порогом 3,4 ГБ. Прогон приёмки на чистых томах: `make clean` → `cp .env.example .env` → `make up` (1 мин 51 с) → `make smoke` — 24 пройдено, 0 ошибок, 2171 MiB. Также зелены `make config-test` (статические ворота, 3/0 и 5/0), `make smoke-cluster` (8/8) и `make smoke-guards` (3/0 и 3/0) — стражи специально ломают стенд и проверяют, что отчёт краснеет, а после восстановления снова зеленеет. **Конвейер.** Постановка прошла два слепых ревью (26 замечаний, все приняты), реализация — саморевью, два слепых ревью кода с разными линзами и триаж: 16 исправлено, 1 отклонено обоснованно. Узкие перепроверки закрыли все находки обеих линий. Отдельно поймано на приёмке, уже исправлено: восстановленные статические ворота были написаны на `ripgrep`, которого на машине нет, и при этом печатали «ЗЕЛЁНО» поверх упавшей проверки — код возврата подстановки процесса не ловился, и проверка синтаксиса Bash молча не проверяла ничего. **Решения** записаны в `docs/adr/0001-stand-services.md`, состав стенда и порядок работы — в `README.md`.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
needs-info
needs-triage
ready-for-agent
ready-for-human
wayfinder:grilling
wayfinder:map
wayfinder:prototype
wayfinder:research
wayfinder:task
wontfix
No labels ready-for-agent
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
ddmitry (Dmitry Dementiev)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Depends on
#12 Кластер ClickHouse: 2 ноды + keeper в compose, smoke ON CLUSTER
ddmitry/clickstream-data-platform
Reference: ddmitry/clickstream-data-platform#13