Сайт работает, а очередь растёт: как контролировать воркеры и задержку обработки
Мониторинг очередей и воркеров показывает, выполняются ли фоновые задачи вовремя, даже когда страницы сайта открываются без ошибок. Форма может принять заявку, магазин — показать подтверждение заказа, а обработчик ещё долго не передавать данные в CRM, не отправлять уведомление или не обновлять остатки. Для посетителя действие выглядит завершённым, хотя нужного бизнес-результата пока нет.
Поэтому одной проверки доступности сайта недостаточно. Нужно видеть накопленные задания, их возраст, реальную скорость завершения и состояние обработчиков. При этом большой размер очереди не всегда означает аварию, а пустая очередь не всегда подтверждает успешную работу.
Ниже разберём, что контролировать в RabbitMQ и приложении, как оценить время сокращения накопленного объёма и какие признаки помогают найти причину задержки. Числа и сценарии учебные: они иллюстрируют расчёты, а не устанавливают универсальные нормы для любого проекта.
Что именно считать выполненной фоновой задачей
Начните с результата, который нужен пользователю или сотруднику. Для заявки это может быть появление записи в CRM, для выгрузки — готовый файл, для обновления каталога — доступные на сайте новые данные. Формулировка «сообщение отправлено в очередь» описывает промежуточный этап, а не обязательно конечный результат.
Укажите допустимый срок для каждого типа задачи. Передача горячей заявки менеджеру и построение большого аналитического отчёта имеют разные требования. Если собрать их в один график, быстрые массовые операции могут скрыть задержку редких, но важных действий.
Полезно зафиксировать владельца процесса и место, где проверяется успех. Например: приложение приняло обращение, присвоило номер, поставило задание, получило подтверждение создания записи в CRM и сохранило итоговый статус. Такая последовательность позволяет отличить ожидание в очереди от медленного внешнего API и от ошибки фиксации результата.
Что означают ready, unacknowledged и общее количество сообщений
В официальном руководстве RabbitMQ по мониторингу отдельно описаны сообщения, готовые к доставке, и доставленные, но ещё не подтверждённые. В HTTP API этим состояниям соответствуют messages_ready и messages_unacknowledged; поле messages отражает их сумму. Названия метрик в конкретном экспортёре могут отличаться.
| Показатель | Что наблюдаем | Чего он не доказывает |
|---|---|---|
| Ready | Сообщения ожидают доставки потребителю | Что все ожидающие задания уже просрочены |
| Unacknowledged | Доставленные сообщения ожидают подтверждения | Что каждое прямо сейчас активно обрабатывается |
| Общее количество | Сумму двух указанных состояний | Количество успешно завершённых бизнес-операций |
| Изменение количества | Накопление или сокращение остатка за интервал | Причину изменения без дополнительных данных |
Если ready уменьшилось на сто, а unacknowledged выросло на сто, работа могла просто переместиться из очереди к потребителям. Полезный результат ещё предстоит подтвердить. Аналогично уменьшение общего количества после удаления или истечения срока сообщений нельзя записывать как успешную обработку.
Смотрите отдельные важные очереди, а не только суммарный остаток всего брокера. Тысячи некритичных уведомлений и одна зависшая задача передачи заказа требуют разной реакции. Для каждой очереди полезно знать назначение, тип заданий и ожидаемые способы завершения.
Почему возраст задачи важнее одного размера очереди
Очередь из пятидесяти заданий может обработаться за секунды, а одно застрявшее обращение — ждать часами. Поэтому контролируйте время от принятия операции до полезного результата и возраст ещё незавершённых задач. Именно второй показатель помогает замечать работу, которая вообще не попадает в статистику завершений.
Для собственной схемы достаточно нескольких временных отметок: операция принята, сообщение опубликовано, обработка начата, результат сохранён. Они разделяют ожидание доставки, длительность исполнения и полный срок выполнения. Согласуйте формат времени и часовой пояс, а на разных узлах следите за синхронизацией часов.
- Ожидание очереди: время начала обработки минус время публикации.
- Длительность попытки: время её завершения минус время начала.
- Полный срок операции: время полезного результата минус время принятия.
- Возраст незавершённой операции: текущее время минус время принятия.
Не рассчитывайте возраст только по последней завершённой задаче. Пока короткие операции проходят успешно, одна старая может оставаться заблокированной. Нужен контроль текущего незавершённого набора: например, количество просроченных операций и возраст самой старой среди тех, которые должны выполняться сейчас.
Доступность готового показателя возраста зависит от типа очереди и инструмента наблюдения. Если брокер не даёт нужного бизнес-показателя, сформируйте его на уровне приложения по сохранённым состояниям. При повторной попытке сохраняйте исходное время принятия отдельно от времени нового запуска: иначе каждый повтор будет делать старую проблему визуально молодой.
Как сравнивать скорость поступления и завершения
Размер очереди отвечает на вопрос «сколько осталось», а скорости помогают понять направление движения. Выберите одинаковое временное окно и сравнивайте поступление новых заданий с их окончательным успешным завершением. Все значения должны использовать одинаковую единицу: например, задания в минуту.
Обозначим входящий поток как λ, а устойчивую скорость полезного завершения как μ. Если λ больше μ, остаток растёт. Если μ больше λ, появляется возможность постепенно убрать накопленное. Когда значения равны, текущая нагрузка обслуживается без запаса для сокращения прежнего отставания.
Скорость доставки сообщений потребителям не подставляйте вместо скорости результата автоматически. Повторная доставка, раннее подтверждение или передача работы в ещё одну очередь меняют смысл показателя. Для расчёта сначала определите, какое событие считается завершением, и проверьте, что счётчик отражает именно его.
Сравнивайте несколько соседних окон, чтобы единичный всплеск не стал прогнозом на весь день. Отдельно смотрите состав задач: сто простых операций и сто тяжёлых отчётов создают разную нагрузку. При смене состава прежняя средняя производительность перестаёт быть надёжным основанием для оценки.
Как рассчитать время сокращения очереди с продолжающимся потоком
Предположим, накоплено 900 незавершённых заданий одного типа. Новые поступают со скоростью 120 в минуту, а обработчики устойчиво завершают 150 в минуту. Для учебной модели считаем поток и производительность постоянными, каждое задание завершается успешно один раз, удалений и повторных доставок нет.
Чистая скорость сокращения остатка составляет 150 − 120 = 30 заданий в минуту. Чтобы общий накопленный остаток вернулся к нулю в этой упрощённой модели, требуется 900 ÷ 30 = 30 минут. За это время поступят ещё 3600 заданий, а завершатся 4500: исходные 900 плюс новые 3600.
| Сценарий | Поступление | Завершение | Что происходит с остатком |
|---|---|---|---|
| Поток продолжается | 120 в минуту | 150 в минуту | Убывает на 30 в минуту; 900 сокращаются за 30 минут |
| Новые задания не поступают | 0 | 150 в минуту | 900 завершаются за 6 минут |
| Обработчики едва успевают | 120 в минуту | 120 в минуту | Исходное отставание не сокращается |
| Производительность снизилась | 120 в минуту | 80 в минуту | Остаток растёт на 40 в минуту |
Общая оценка времени возврата остатка к выбранному базовому уровню: (текущий остаток − базовый остаток) ÷ (μ − λ), если μ больше λ. Это оценка динамики общего объёма, а не обещание срока каждой заявки. При строгом порядке поступления первоначальная группа может завершиться раньше, пока новые задания занимают её место.
В реальной системе есть колебания, разные длительности и постоянное количество задач в работе, поэтому буквальный ноль не всегда разумная цель. Задайте нормальный рабочий остаток и пересчитывайте прогноз после изменения нагрузки. Если μ не превышает λ, конечного времени восстановления по этой модели нет: требуется изменить условия.
Пример накопления и восстановления после замедления
Другой условный сценарий начинается без отставания. В течение десяти минут поступает 120 заданий в минуту, а завершается только 80. За этот период добавляется (120 − 80) × 10 = 400 заданий незавершённого остатка. После исправления узкого места измеренная производительность становится равной 200 заданиям в минуту при прежнем входящем потоке.
Новый запас составляет 200 − 120 = 80 заданий в минуту, поэтому расчётное сокращение накопленных 400 занимает пять минут. За восстановительный период приходят ещё 600 заданий и завершаются 1000. Равенство 400 + 600 − 1000 = 0 позволяет проверить арифметику.
Это не основание сразу объявлять срок клиентам. Перед прогнозом убедитесь, что повышенная скорость сохраняется, а внешняя зависимость выдерживает поток. Если производительность измерена только на коротких задачах, а в остатке лежат тяжёлые, расчёт будет слишком оптимистичным. Полезно давать команде диапазон по нескольким наблюдаемым скоростям и обновлять оценку по мере восстановления.
Почему работающий процесс ещё не означает работающего потребителя
Воркер может присутствовать в списке процессов, но не получать задачи: потеряно соединение, закрыт канал, не восстановлена подписка или обработчик запущен с неверным окружением. Поэтому проверка «процесс существует» должна сопровождаться наблюдением за доставкой и завершением работы.
В документации RabbitMQ о потребителях consumer в протокольном смысле рассматривается как подписка на доставку. Один процесс может содержать несколько подписок, а запущенный процесс — не иметь действующей. Сопоставляйте ожидаемое число потребителей с архитектурой приложения, не приравнивая его автоматически к числу процессов.
Полезная карточка обработчика содержит время последней полученной задачи, время последнего результата, число выполняемых операций и состояние соединения. Если очередь непустая, а новые результаты не появляются, выясните, на каком этапе остановилось продвижение. При пустой очереди отсутствие завершений может быть нормальным простоем.
Для режима с одним активным потребителем несколько зарегистрированных подписок также не означают параллельную обработку всеми сразу. Перед оценкой мощности проверьте выбранный режим очереди и ограничения приложения. Наблюдаемое число подключений без этого контекста легко переоценить.
Как prefetch влияет на unacknowledged и распределение работы
Consumer prefetch в RabbitMQ ограничивает количество неподтверждённых доставок; в типичной настройке лимит применяется отдельно к каждому потребителю. Конкретная область ограничения зависит от настройки клиента и дополнительных лимитов. Prefetch не задаёт автоматически число одновременно выполняемых бизнес-операций.
Возьмём пять потребителей с ручным подтверждением и лимитом 20 на каждого, без дополнительного общего ограничения. Они могут суммарно удерживать до 100 неподтверждённых доставок. Если каждый обрабатывает только одну задачу одновременно, часть остальных сообщений будет ожидать внутри потребителей. График ready уменьшится, но реальная работа от этого не ускорится.
Слишком большой запас у одного обработчика способен ухудшить распределение длинных и коротких задач. Слишком маленький лимит в другой конфигурации может ограничить загрузку. Подбирайте значение на контролируемой нагрузке: сравнивайте полезную скорость, задержку, память и равномерность распределения. Простое повышение prefetch не устраняет медленную базу или лимит внешнего API.
Чем подтверждение сообщения отличается от успеха операции
RabbitMQ различает publisher confirms и consumer acknowledgements. Первое относится к взаимодействию издателя с брокером, второе — брокера с потребителем. Подтверждение публикации не означает, что воркер уже выполнил действие или что запись появилась в CRM.
Момент подтверждения со стороны потребителя должен соответствовать принятой модели ответственности. Если приложение подтверждает сообщение до сохранения необходимого результата, очередь может выглядеть пустой после неуспешной операции. Поэтому график подтверждений полезен, но его нужно сопоставить со статусами приложения.
В руководстве RabbitMQ по надёжности подчёркивается смысл передачи ответственности при подтверждении. Для вашей системы явно запишите, что именно выполнено к этому моменту: результат сохранён, задача надёжно передана дальше или завершено предусмотренное действие. Это решение должно быть согласовано с обработкой сбоев.
Повторная доставка также возможна и требует предусмотренного поведения приложения. Отслеживайте повторные попытки и повторное выполнение побочных действий отдельно от успешных уникальных операций. Если один проблемный объект бесконечно возвращается в обработку, высокий поток доставок может сочетаться с отсутствием полезного прогресса. Изоляция таких сообщений — отдельная часть схемы обработки ошибок.
Что проверять, если в RabbitMQ очередь растёт
Сначала сопоставьте рост остатка с входящим потоком и успешными результатами. Затем двигайтесь по цепочке от подписки до зависимости. Не меняйте сразу число воркеров, prefetch и настройки повторов: после нескольких одновременных изменений будет трудно понять, какое из них помогло или ухудшило ситуацию.
| Наблюдение | Что проверить первым |
|---|---|
| Ready растёт, ожидаемых потребителей нет | Запуск обработчиков, подписки, соединение и нужное окружение |
| Unacknowledged больше нуля, а полезных завершений нет дольше допустимого срока | Зависшие операции, ожидание зависимостей, подтверждение и лимиты доставки |
| Доставок много, результатов мало | Повторы, ошибки обработки и смысл счётчиков |
| Результаты продолжаются, но очередь растёт | Недостаток производительности относительно поступления |
| Остаток мал, старые задачи просрочены | Отдельные зависшие задания, приоритеты и правила выбора |
Постоянное число unacknowledged само по себе не доказывает зависание: завершённые доставки могут непрерывно заменяться новыми. Проверяйте скорость полезных результатов и возраст незавершённых операций, чтобы отличить такую работу от остановки продвижения.
При работающих подписках посмотрите длительность операций с базой, ответы внешнего API, доступные соединения, CPU, память и дисковые ограничения. Например, добавление обработчиков при исчерпанном пуле соединений может увеличить ожидание, а при ограничении партнёра — число отказов. Масштабирование имеет смысл после проверки свободной мощности следующего участка.
Проверку дополнительной мощности проводите постепенно. Зафиксируйте исходные входящий поток, успешное завершение и длительность задачи, добавьте согласованное число обработчиков, затем сравните тот же набор показателей. Если завершений стало больше, но выросли ошибки или время работы сайта, улучшение одного участка могло ухудшить общий результат.
Отдельно проверьте ограничения порядка выполнения. Некоторые операции нельзя безопасно распараллелить для одного объекта: например, обновления одного заказа должны применяться в предусмотренной последовательности. Поэтому увеличение числа потребителей требует не только свободных ресурсов, но и подтверждённой корректности обработки. Решение принимает команда, понимающая данные и побочные действия.
Удаление очереди или массовое подтверждение сообщений без выполнения способно уменьшить график, но не вернуть клиентам результат. Такие действия нельзя использовать как обычный способ устранения отставания. Сначала определите судьбу данных, допустимые повторения и план восстановления бизнес-операций.
Какие условия тревоги привязать к задачам бизнеса
Универсальный порог «больше тысячи сообщений» мало что говорит без производительности и допустимого срока. Лучше объединить признаки: возраст незавершённых задач, отсутствие прогресса при непустой очереди, рост отставания и исчезновение ожидаемых потребителей.
Для условной передачи заявок команда может требовать результат за пять минут. Тогда предупреждение о приближении к сроку должно оставлять время на реакцию, а уже просроченные обращения учитываются отдельно. Конкретные интервалы выбирайте по данным проекта; цифра из примера не становится рекомендуемой настройкой для любой CRM.
- Потеря обработчика: ожидаемая подписка отсутствует дольше допустимого переходного периода.
- Нет продвижения: задания есть, но полезные завершения не появляются.
- Нарушение срока: возраст незавершённых операций превышает согласованное ограничение.
- Растущий риск: остаток увеличивается, а прогноз восстановления ухудшается.
- Потеря измерений: сведения об очереди или результатах перестали обновляться.
Тревога должна сообщать назначение очереди, возраст проблемы, текущий остаток и последние скорости, а также ссылку на инструкцию. Назначьте ответственного и критерий восстановления. Снижения ready недостаточно, если просроченные операции продолжают ждать у потребителей.
Как проверить мониторинг до первого настоящего сбоя
Используйте отдельную тестовую очередь или стенд с синтетическими заданиями. Проверьте временную остановку потребителя, замедление зависимости и контролируемый рост входящего потока. Наблюдение должно различать эти ситуации и показывать ожидаемое место задержки.
Для каждой проверки зафиксируйте время нарушения, обнаружения, получения уведомления и возвращения полезных результатов. После восстановления убедитесь, что накопленные старые задачи завершаются, количество просроченных операций сокращается, а повторы не создают лишних действий. Сам факт перезапуска процесса ещё не завершает испытание.
В рабочем проекте начните с одной важной очереди: назначение, допустимый срок, ready и unacknowledged, поступление и результат, возраст незавершённого, ожидаемые потребители. Затем добавляйте диагностические показатели по реальным вопросам команды. Небольшая понятная схема полезнее большого экрана, на котором непонятно, кто и когда должен реагировать.
Как объединить контроль сайта и фоновой обработки
Внешняя HTTP-проверка показывает доступность выбранного URL из точки наблюдения, а внутренний контроль очередей — выполняется ли обещанное действие после приёма обращения. Сопоставляйте эти уровни по времени и идентификатору операции: так сообщение «форма работает» не будет скрывать отставание передачи заявок.
Подключите SiteGuard для внешнего HTTP-контроля доступности публичных страниц. Очереди, воркеры и фактическое завершение операций контролируйте отдельно в своей инфраструктуре.