NoActiveCeleryWorkers врёт: воркер жив и берёт задачи каждую минуту, а тревога говорит «все periodic-таски встали» — на самом деле не поднят экспортер (ag… #3493

New issue

Open

opened 2026-09-12 12:00:24 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-09-12 12:00:24 +00:00

Collaborator

Найдено 12.09.2026 по сообщению в канале тревог. Правило заведено PR #3489 сегодня же.

Что утверждает тревога

🔴 NoActiveCeleryWorkers — celery-exporter не видит ни одного heartbeat от воркера Site Finder. Все periodic-таски (парсинг, аналитика, синк слоёв) встали.

Что на самом деле (замеры 12.09, 11:54-11:56 UTC, только чтение)

Воркер жив и работает. docker logs gendesign-worker-1:

11:55:00 Task tasks.nspd_geo.cleanup_zombies received
11:55:00 Task tasks.nspd_geo.cleanup_zombies succeeded in 0.0022s
11:56:00 Task tasks.cadastre.cleanup_zombies received  … succeeded
11:56:00 Task tasks.nspd_geo.cleanup_zombies received  … succeeded

Задачи приходят и выполняются каждую минуту. gendesign-worker-1 и gendesign-beat-1 — Up (healthy).

Метрик celery в Prometheus нет вообще. {__name__=~"celery.*"} → пустой результат. Скрейп-цели с celery нет ни одной (активных целей всего 4), в prometheus.yml слово celery не встречается.
Контейнера экспортера не существует. docker ps -a | grep -i celery на Poincare → пусто. В docker-compose.metrics-agent.yml:284 сервис объявлен под профилем apps, но не поднят.
Причина — Deploy Metrics / agent-apps падает. На трёх последних мержах подряд: server = success, agent-infra = success, agent-apps = failure. Прод-чекаут при этом на свежем main (994eb793), то есть код доехал, а контейнер не поднялся.

В чём дефект

Условие правила — count(celery_worker_up == 1) == 0 **or absent(celery_worker_up)**. Ветка absent() заведена осознанно (в комментарии рядом: «если сам celery-exporter не поднялся»), и это правильно. Но текст тревоги описывает только первую ветку и утверждает следствие, которого из второй не следует: «все periodic-таски встали».

Две разные новости схлопнуты в одну формулировку:

«воркер мёртв» — авария продукта, надо бежать;
«мы не видим метрику» — авария наблюдаемости, продукт при этом работает.

Сегодня сработала вторая, а прочиталась первая. Это тот же класс, что #3464 (текст тревоги утверждает не то, что проверяет условие), только там врало число, а здесь — вывод.

Чинить

Разделить формулировки. Либо два правила (… == 0 и absent(...)) со своими текстами, либо один текст, честный для обеих веток: «экспортер не отдаёт heartbeat воркера — это может значить и остановку воркера, и то, что не поднят сам экспортер; проверить docker ps воркера прежде чем бежать». Образец разделения уже есть рядом — CadvisorDown ссылается именно на него.
Починить agent-apps — без него правило будет сигналить вечно и обесценит канал (у нас это уже было: тревога, которую никто не разбирает, гасит и остальные).
Пока экспортера нет — правило стоит держать выключенным, а не firing.

Приёмка

celery_worker_up присутствует в Prometheus и равен 1; при намеренной остановке воркера тревога приходит с текстом про воркера, при остановке экспортера — с текстом про наблюдаемость.

Refs #3489, #3464, #3471.

Найдено 12.09.2026 по сообщению в канале тревог. Правило заведено PR #3489 сегодня же. ## Что утверждает тревога > 🔴 **NoActiveCeleryWorkers** — celery-exporter не видит ни одного heartbeat от воркера Site Finder. **Все periodic-таски (парсинг, аналитика, синк слоёв) встали.** ## Что на самом деле (замеры 12.09, 11:54-11:56 UTC, только чтение) 1. **Воркер жив и работает.** `docker logs gendesign-worker-1`: ``` 11:55:00 Task tasks.nspd_geo.cleanup_zombies received 11:55:00 Task tasks.nspd_geo.cleanup_zombies succeeded in 0.0022s 11:56:00 Task tasks.cadastre.cleanup_zombies received … succeeded 11:56:00 Task tasks.nspd_geo.cleanup_zombies received … succeeded ``` Задачи приходят и выполняются каждую минуту. `gendesign-worker-1` и `gendesign-beat-1` — `Up (healthy)`. 2. **Метрик celery в Prometheus нет вообще.** `{__name__=~"celery.*"}` → пустой результат. Скрейп-цели с celery нет ни одной (активных целей всего 4), в `prometheus.yml` слово `celery` не встречается. 3. **Контейнера экспортера не существует.** `docker ps -a | grep -i celery` на Poincare → пусто. В `docker-compose.metrics-agent.yml:284` сервис объявлен под профилем `apps`, но не поднят. 4. **Причина — `Deploy Metrics / agent-apps` падает.** На трёх последних мержах подряд: `server = success`, `agent-infra = success`, **`agent-apps = failure`**. Прод-чекаут при этом на свежем main (`994eb793`), то есть код доехал, а контейнер не поднялся. ## В чём дефект Условие правила — `count(celery_worker_up == 1) == 0 **or absent(celery_worker_up)**`. Ветка `absent()` заведена осознанно (в комментарии рядом: «если сам celery-exporter не поднялся»), и это правильно. Но **текст** тревоги описывает только первую ветку и утверждает следствие, которого из второй не следует: «все periodic-таски встали». Две разные новости схлопнуты в одну формулировку: - «воркер мёртв» — авария продукта, надо бежать; - «мы не видим метрику» — авария наблюдаемости, продукт при этом работает. Сегодня сработала вторая, а прочиталась первая. Это тот же класс, что #3464 (текст тревоги утверждает не то, что проверяет условие), только там врало число, а здесь — вывод. ## Чинить 1. **Разделить формулировки.** Либо два правила (`… == 0` и `absent(...)`) со своими текстами, либо один текст, честный для обеих веток: «экспортер не отдаёт heartbeat воркера — это может значить и остановку воркера, и то, что не поднят сам экспортер; проверить `docker ps` воркера прежде чем бежать». Образец разделения уже есть рядом — `CadvisorDown` ссылается именно на него. 2. **Починить `agent-apps`** — без него правило будет сигналить вечно и обесценит канал (у нас это уже было: тревога, которую никто не разбирает, гасит и остальные). 3. Пока экспортера нет — правило стоит держать выключенным, а не firing. ## Приёмка `celery_worker_up` присутствует в Prometheus и равен 1; при намеренной остановке воркера тревога приходит с текстом про воркера, при остановке экспортера — с текстом про наблюдаемость. Refs #3489, #3464, #3471.