Самый неприятный вид отказа в мониторинге — тихий. Система работает, задачи выполняются, логи чистые. Просто данные на экране — вчерашние. Опрос в RackGrid устроен каскадом: планировщик раз в интервал запускает задачу «все контейнеры», та раскладывает задачи по контейнерам, те — по стойкам, те — по отдельным ASIC. Каждый уровень не делает работу, а разворачивает её дальше. На выходе — тысячи мелких независимых задач, которые разбирают воркеры параллельно. Fan-out сам по себе банален. Интересное — в защите от накопления долгов: У каждой подзадачи есть срок годности. При интервале опроса 300 секунд TTL подзадачи — 280. Не начала выполняться за это время — выбрасывается. Иначе после любого сбоя брокера система героически разбирает вчерашнюю очередь вместо того, чтобы показать сегодняшнее состояние. У каждого цикла свой уникальный идентификатор в составе идентификатора задачи. Звучит как мелочь на восемь символов, но без него список отозванных задач прошлого цикла продолжает блокировать задачи нового — и мониторинг тихо умирает, продолжая рапортовать, что всё в порядке. Это как раз тот самый тихий отказ. Мягкий и жёсткий лимиты на задачу опроса — 30 и 60 секунд. Одно зависшее устройство не занимает воркер навсегда. Разные очереди для разной работы. Быстрое обновление состояния и тяжёлая агрегация статистики физически не конкурируют за воркеров. Ошибка постановки задачи — не исключение, а метрика. Если брокер недоступен, задача не ставится, счётчик неудач растёт, это видно в логах — вместо каскада исключений на весь цикл. И отдельная деталь распределённого режима: лидер опрашивает только своё оборудование. Площадки, за которые отвечают удалённые агенты, он пропускает — иначе два источника писали бы в одну запись наперегонки. Об этом — в пятой части.