Прямой ответ
Очередь — буфер между производителем и потребителем. Её состояние показывает, успевает ли обработка за поступлением. Четыре метрики описывают это состояние, и каждая отвечает на свой вопрос.
| Метрика | Что показывает | Тревожный признак |
|---|---|---|
| Глубина очереди | Сколько сообщений ожидает | Монотонный рост |
| Отставание потребителя | Сколько сообщений не обработано | Рост быстрее поступления |
| Скорость обработки | Сколько сообщений в секунду обрабатывается | Падение при прежнем поступлении |
| Возраст старейшего сообщения | Как долго сообщение ждёт | Превышение целевого времени |
Глубина очереди сама по себе не показатель проблемы: очередь существует, чтобы накапливать сообщения в пике. Проблему показывает тренд — монотонный рост означает, что потребление медленнее поступления.
Отставание потребителя в Kafka вычисляется как разница между последним смещением в разделе и смещением, подтверждённым потребителем:
lag = latest_offset - committed_offset
Отставание растёт в двух случаях: увеличилось поступление либо замедлилась обработка. Различение требует сравнения со скоростью публикации.
Возраст старейшего сообщения — наиболее понятная метрика для бизнеса. Она отвечает на вопрос «как долго пользователь ждёт результата», тогда как глубина очереди отвечает на вопрос о внутреннем состоянии системы.
AGE =Histogram(
"queue_message_age_seconds",
"Возраст обрабатываемого сообщения",
["queue"],
buckets=(1, 5, 15, 60, 300, 900, 3600),
)
AGE.labels(queue="orders").observe(
(time.time() - message.published_at).total_seconds()
)
Гистограмма даёт процентили, и p95 возраста показывает задержку для большинства сообщений; о процентилях — в статье про гистограммы метрик.
Тревога настраивается на тренд, а не на абсолютное значение:
# рост отставания в течение 10 минут
- alert: ConsumerLagGrowing
expr: increase(kafka_consumer_lag[10m]) > 0
and kafka_consumer_lag > 1000
for: 10m
Условие на абсолютное значение предотвращает тревогу при нормальном пиковом накоплении; о настройке — в статье про правила оповещений.
Разбор накопления сообщений
Накопление само по себе не инцидент, но требует ответа на три вопроса.
Растёт или стабилизируется? Сравнение скоростей поступления и обработки показывает, очистится очередь самостоятельно или продолжит расти. При отрицательной разнице накопление не рассосётся.
Какова причина? Три типичные причины дают разные действия:
| Причина | Признак | Действие |
|---|---|---|
| Рост поступления | Скорость публикации выросла | Масштабировать потребителей |
| Замедление обработки | Длительность обработки выросла | Найти медленный этап |
| Снижение числа потребителей | Метрика потребителей упала | Восстановить доступность |
Сколько времени до очистки? Деление накопленного объёма на разницу скоростей даёт оценку. Если оценка превышает целевое время обработки, требуется вмешательство.
Отдельный случай — накопление при низкой нагрузке. Небольшая глубина с большим возрастом сообщений означает, что обработка идёт очень медленно либо остановлена. Тревога только на глубину такой случай пропускает, поэтому возраст старейшего сообщения измеряется всегда.
Проверка доступности потребителей — обязательная часть разбора. Нулевое отставание при остановленном потребителе выглядит как норма, и без отдельной метрики активности остановка не обнаруживается.
Практика: настройка мониторинга очередей
1. Измеряйте и поступление, и обработку. Сравнение двух скоростей показывает, растёт отставание или стабилизируется.
2. Следите за возрастом, а не только за глубиной. Глубина в миллион сообщений при высокой скорости обработки может быть нормой, а тысяча сообщений с часовым возрастом — проблемой.
3. Настраивайте тревогу на тренд отставания. Абсолютный порог зависит от нагрузки и даёт ложные срабатывания в пике.
4. Мониторьте глубину очереди недоставленных сообщений. Накопление в ней означает, что часть операций не выполнена; о разборе — в статье про DLQ.
5. Измеряйте длительность обработки сообщения. Рост длительности при прежнем поступлении предсказывает накопление до его появления; о метриках — в статье про инструментирование приложения.
6. Следите за числом активных потребителей. Падение числа потребителей уменьшает пропускную способность и ведёт к накоплению.
7. Проверяйте частоту повторных доставок. Рост повторов указывает на сбои обработки и снижает эффективную пропускную способность.
8. Считайте время до очистки очереди. При известной скорости обработки можно оценить, когда накопленные сообщения будут обработаны.
Рекомендации:
- Не алертуйте на глубину без контекста. Пиковое накопление с последующей очисткой — нормальная работа очереди.
- Разделяйте метрики по очередям. Агрегированное значение скрывает накопление в одной очереди при норме в остальных.
- Учитывайте задержку сбора метрик. Метрика, обновляемая раз в минуту, не показывает кратковременные всплески.
- Проверяйте доступность потребителя отдельно. Нулевое отставание при остановленном потребителе выглядит как норма.
- Документируйте ожидаемые значения. Понимание нормы позволяет отличить отклонение от обычного пика.
Практический сценарий: незамеченное накопление при работающем потребителе
Контекст: пользователи пожаловались на задержку уведомлений в несколько часов. Очередь при этом считалась исправной: тревога по глубине не срабатывала.
- Диагностика. Глубина очереди составляла около двух тысяч сообщений, что было ниже порога тревоги. Возраст старейшего сообщения при этом превышал четыре часа: обработка шла, но очень медленно.
- Причина. Один из обработчиков выполнял внешний вызов без таймаута и зависал на десятки минут на отдельных сообщениях. Пропускная способность упала, но накопление оставалось ниже порога тревоги, поскольку поступление тоже было небольшим.
- Действия. (а) Добавили метрику возраста старейшего сообщения с тревогой при превышении пяти минут; (б) добавили гистограмму длительности обработки сообщения для выявления медленных случаев; (в) внешнему вызову установили таймаут и повтор с нарастающей задержкой; (г) тревогу по глубине перевели на тренд отставания вместо абсолютного порога; (д) добавили проверку числа активных потребителей.
- Результат. Замедление обработки обнаруживается по возрасту сообщений в течение минут, а не по обращению пользователей через несколько часов.
Вывод: глубина очереди не показывает задержку при низком поступлении. Возраст старейшего сообщения и длительность обработки выявляют замедление напрямую, а тревога на тренд отставания избегает ложных срабатываний в пике.
FAQ
Какая метрика важнее: глубина или отставание? Для оценки задержки — возраст старейшего сообщения. Глубина и отставание показывают объём накопления, но не время ожидания.
Почему тревога на абсолютное значение плохо работает? Нормальный уровень накопления зависит от нагрузки. В пике порог превышается без проблемы, а при низкой нагрузке проблема не достигает порога.
Что означает нулевое отставание? Потребитель обработал все доступные сообщения либо не работает. Различие проверяется метрикой активности потребителя.
Как оценить время до очистки очереди? Делением накопленного объёма на разницу скоростей обработки и поступления. При отрицательной разнице очередь не очистится.
Источники: Kafka docs (Monitoring), Prometheus docs (Histograms), RabbitMQ docs (Monitoring) — ссылки в шапке.