Отслеживать очередь задач нужно не только по числу сообщений. Очередь может быть почти пустой, но одна важная заявка зависла в retry; worker может числиться запущенным, но не завершать задания; ошибки могут уходить в dead-letter без заметного влияния на общий график.

Надежный мониторинг связывает технические метрики с результатом: письмо отправлено, заказ выгружен, изображение обработано, отчет построен. Тогда проблема обнаруживается до того, как о ней сообщит клиент.

Сначала опишите назначение каждой очереди

  • Какие задачи в нее поступают.
  • Какое время ожидания допустимо.
  • Можно ли безопасно выполнить job повторно.
  • Что происходит после исчерпания retry.
  • Какой бизнес-процесс зависит от результата.
  • Кто отвечает на алерт и как восстанавливает обработку.

Одна граница для всех очередей почти всегда бесполезна. Отправка кода входа должна выполняться за секунды, а ночная обработка каталога может занимать часы.

Базовые метрики очереди

Количество ожидающих задач

Queue depth показывает накопление работы, но его нужно сравнивать с обычным профилем нагрузки и производительностью worker. Краткий пик не всегда является аварией.

Возраст самой старой задачи

Oldest job age часто важнее длины. Если очередь небольшая, но первая задача ждет 20 минут при норме в одну минуту, обработка уже нарушена.

Скорость поступления и завершения

Сравнение enqueue rate и completion rate показывает, успевает ли система за потоком. Если вход стабильно выше обработки, backlog будет расти даже без ошибок.

Время выполнения

Следите за медианой и высокими процентилями по типам job. Среднее значение скрывает небольшую группу очень медленных задач.

Отслеживайте состояние worker

  • Число активных процессов по каждой очереди.
  • Время последнего heartbeat.
  • Количество взятых и успешно завершенных job.
  • Использование CPU, памяти и открытых соединений.
  • Частота перезапусков и exit code.
  • Версия приложения и конфигурации worker.
  • Текущая задача и время ее выполнения без чувствительного payload.

Статус process running недостаточен. Worker может зависнуть в сетевом вызове, потерять соединение с брокером или бесконечно повторять одну задачу. Нужен heartbeat и признак реального прогресса.

Разделите метрики по типам задач

Общий график объединяет быстрые письма и тяжелые импорты, поэтому проблема одного типа становится незаметной. Добавляйте ограниченные labels: queue, job_type, status и environment. Не используйте user_id, order_id и другие значения с высокой кардинальностью как label метрики.

  • Количество созданных задач каждого типа.
  • Успехи и ошибки по типу job.
  • Длительность и время ожидания.
  • Число retry и окончательных отказов.
  • Размер обрабатываемого пакета, если он влияет на время.
  • Версия обработчика после deploy.

Мониторьте retry отдельно

Повторная попытка может быть нормальной реакцией на краткий сбой. Проблема начинается, когда retry скрывает постоянную ошибку, увеличивает задержку или создает повторный внешний эффект.

  • Считайте число попыток по типу ошибки.
  • Используйте ограниченный exponential backoff с jitter.
  • Не повторяйте ошибки валидации и отсутствия прав как временные.
  • Сохраняйте техническую причину последнего отказа.
  • Проверяйте идемпотентность перед повтором платежа, письма или записи во внешнюю систему.
  • Алерт должен срабатывать до исчерпания всех попыток для критичной задачи.

Настройте dead-letter очередь

После исчерпания retry задача не должна исчезать. Dead-letter хранит ее для разбора и контролируемого повторного запуска. Доступ к содержимому ограничивают, потому что payload может содержать персональные или коммерческие данные.

  • Количество новых dead-letter сообщений.
  • Возраст самой старой необработанной ошибки.
  • Типы job и технические коды причин.
  • Ответственный и статус разбора.
  • Безопасная команда requeue после исправления.
  • Срок хранения и правила удаления.

Найдите poison job

Одна задача с постоянной ошибкой может возвращаться в начало, занимать worker и мешать остальным. Признаки: одинаковый job_id в логах, частые retry, рост времени ожидания при небольшой длине очереди.

  1. Остановить бесконечный цикл повторов.
  2. Переместить задачу в контролируемый failed или dead-letter статус.
  3. Сохранить минимально необходимый контекст для диагностики.
  4. Проверить данные и внешний сервис.
  5. Исправить обработчик или входные данные.
  6. Повторить задачу идемпотентно на тесте, затем в рабочем окружении.

Добавьте correlation ID

Одна операция проходит через сайт, базу, очередь и внешнее API. Correlation ID связывает эти шаги в журнале. При этом метрики остаются агрегированными, а конкретный ID используется только для поиска в логах и trace.

  • Идентификатор создается при входном запросе или бизнес-событии.
  • Передается в job metadata и дочерние задачи.
  • Присутствует в структурированных логах.
  • Не заменяет уникальный idempotency key.
  • Не содержит персональные данные и секреты.

Свяжите очередь с бизнес-результатом

Технически job может завершиться успешно, но результат не достигнут: API вернул пустой ответ, письмо принято локальным сервисом, но не передано провайдеру, импорт записал ноль строк. Поэтому нужны бизнес-проверки.

  • Заказы из сайта появились в учете.
  • Письма получили message ID провайдера.
  • Отчеты созданы за ожидаемый период.
  • Изображения имеют все обязательные размеры.
  • Платежные статусы обновились.
  • Очередь уведомлений не только пуста, но и создает ожидаемое число доставок.

Постройте информативный dashboard

  • Depth и oldest age по очередям.
  • Enqueue и completion rate.
  • Успехи, retry и failed.
  • Длительность по типам job и процентилям.
  • Активные worker и время heartbeat.
  • Рестарты, CPU и память.
  • Dead-letter и возраст ошибок.
  • Ключевые бизнес-результаты.

Dashboard должен позволять отличить рост входящего потока от падения производительности, ошибку одного типа job от общего сбоя и нехватку worker от медленного внешнего API.

Настройте алерты по симптомам, а не по шуму

  • Oldest age выше допустимого времени несколько интервалов подряд.
  • Completion rate равен нулю при наличии ожидающих задач.
  • Нет heartbeat хотя бы у минимального числа worker.
  • Доля failed или retry выше обычного уровня.
  • Появились новые dead-letter задачи.
  • Backlog растет дольше допустимого окна.
  • Бизнес-результат отсутствует при наличии входных событий.

Каждый алерт должен содержать очередь, окружение, начало проблемы, ссылку на dashboard и короткий runbook. Не включайте полный payload задачи в уведомление.

Учитывайте плановые пики

Ночной импорт, рассылка и закрытие месяца создают ожидаемую нагрузку. Статический порог depth будет шуметь. Используйте отдельные правила для расписания, прогноз времени очистки backlog или алерт по возрасту вместо одного количества.

Проверьте брокер и хранилище очереди

  • Доступность Redis, RabbitMQ, SQS или базы.
  • Память, диск и политика eviction.
  • Число соединений и ошибки reconnect.
  • Visibility timeout и время выполнения job.
  • Ack выполняется только после успешной обработки.
  • Задачи не теряются при перезапуске worker.
  • Разные окружения используют разные очереди и ключи.

Если visibility timeout короче реального выполнения, одна задача может обрабатываться параллельно несколькими worker. Это выглядит как дубли и увеличивает нагрузку.

Контролируйте deploy worker

После публикации кода старые процессы могут продолжать выполнять предыдущую версию. Нужен graceful restart: завершить текущую задачу, остановить прием новых, запустить worker новой версии и проверить heartbeat.

  • Версия worker видна в метриках или безопасном status endpoint.
  • Deploy не завершен, пока минимальное число новых worker не готово.
  • Старые job совместимы с новым обработчиком или мигрируются.
  • Длительные задачи имеют корректный timeout остановки.
  • Supervisor или оркестратор ограничивает циклические рестарты.

Подготовьте runbook восстановления

  1. Подтвердить влияние и определить проблемную очередь.
  2. Проверить heartbeat worker и доступность брокера.
  3. Сравнить входящую и исходящую скорость.
  4. Найти dominant error или зависший тип job.
  5. Остановить опасный retry или изолировать poison job.
  6. Восстановить worker либо внешний dependency.
  7. Масштабировать обработку только после устранения ошибки.
  8. Контролировать уменьшение oldest age и backlog.
  9. Проверить бизнес-результат и безопасно обработать dead-letter.

Как проверить мониторинг

  • Остановить один тестовый worker и дождаться ожидаемого алерта.
  • Создать контролируемую ошибочную job.
  • Проверить retry, переход в dead-letter и уведомление.
  • Создать backlog и увидеть рост oldest age.
  • Восстановить обработку и проверить автоматическое закрытие алерта.
  • Убедиться, что dashboard разделяет типы задач.
  • Проверить runbook человеком, который не строил систему.

Типичные ошибки

  • Следить только за длиной очереди.
  • Считать запущенный процесс доказательством обработки.
  • Не видеть возраст самой старой job.
  • Объединять все типы задач в одну метрику.
  • Повторять постоянные ошибки бесконечно.
  • Удалять failed job без журнала и разбирательства.
  • Передавать персональные данные и токены в labels или уведомления.
  • Масштабировать worker при недоступном внешнем API и усиливать сбой.

Профилактика

Мониторинг очереди проектируется вместе с job: определите таймаут, retry, идемпотентность, метрики и бизнес-подтверждение до запуска. При добавлении нового типа задачи dashboard и алерты должны обновляться в той же поставке.

Итог

Чтобы отслеживать очередь задач, нужны depth, возраст, скорость, длительность, состояние worker, retry и dead-letter. Но окончательный показатель — выполнение бизнес-действия. Такой набор позволяет отличить нагрузку от сбоя и быстро выбрать безопасное восстановление.

Если нужно настроить наблюдаемость очередей, я могу разобрать текущие worker и брокер, добавить метрики, heartbeat, структурированные логи, dashboard и алерты, настроить dead-letter и подготовить runbook для зависших и ошибочных задач.