طابور بلا مستهلك

الأعراض

ConsumerStuck فعّال (page).
rabbitmq_queue_consumers == 0 على طابور به > 10 رسائل.
الفرق عن outbox-backlog: هنا لا يوجد مستهلك أصلاً (حاوية ساقطة)، هناك المستهلك بطيء.

الفحوصات الأولى

first-checks.sh

# 1. Which queue is orphaned?
docker exec via_prod-rabbitmq rabbitmqctl list_queues name messages consumers \
  | awk '$3 == "0" && $2 > "10" {print}'

# 2. Map queue → consumer service. Convention: queue name carries the
#    consumer's service prefix (e.g. "notification.order.placed" →
#    notification-service consumes it).
QUEUE_NAME=<from step 1>

# 3. Is the consumer container even running?
docker ps --filter "name=via_prod-<consumer>" --format \
  'table {{.Names}}\t{{.Status}}\t{{.RestartCount}}'

# 4. Why did it die?
docker logs --since 30m via_prod-<consumer> 2>&1 | tail -100

# 5. RabbitMQ connection-side view (does the broker think the consumer
#    ever connected?).
docker exec via_prod-rabbitmq rabbitmqctl list_connections name client_properties \
  | grep -i <consumer>

المعالجة الفورية

الحاوية متوقفة: docker compose -f docker-compose.prod.yml up -d <consumer>.
الحاوية تعمل لكن لا تتصل: تأكد أن RABBITMQ_URL صحيح في env، وأن RabbitMQ يقبل اتصالات.
حلقة استثناء عند الاتصال: افتح آخر استثناء واصلحه — قد يكون auth, network, أو schema mismatch.
حالة طوارئ: إن استحال إصلاح المستهلك سريعاً وكانت الرسائل تتراكم بسرعة، شغل سكربت drain-to-DLX يدوياً وافتح ticket.

مسار التصعيد

PagerDuty → On-call.
إذا الطابور يحمل أحداث orders/payments: صعّد للمالية فوراً (الحالة المالية تتأخر).
إذا الانقطاع > 15 دقيقة: انشر إعلان حالة.

الاستعادة / التراجع

بمجرد عودة المستهلك، تابع rabbitmq_queue_consumers ≥ 1 ثم rabbitmq_queue_messages_ready ينخفض.
إذا أُجريت drain-to-DLX، شغل dlx_replay بعد التحقق من إصلاح السبب الجذر.
افتح post-mortem إذا تجاوز الانقطاع 10 دقائق.

Loading...جاري التحميل...

كل الأدلة

دليل الاستجابة — حرج

طابور بلا مستهلك

الأعراض

ConsumerStuck فعّال (page).
rabbitmq_queue_consumers == 0 على طابور به > 10 رسائل.
الفرق عن outbox-backlog: هنا لا يوجد مستهلك أصلاً (حاوية ساقطة)، هناك المستهلك بطيء.

الفحوصات الأولى

first-checks.sh

# 1. Which queue is orphaned?
docker exec via_prod-rabbitmq rabbitmqctl list_queues name messages consumers \
  | awk '$3 == "0" && $2 > "10" {print}'

# 2. Map queue → consumer service. Convention: queue name carries the
#    consumer's service prefix (e.g. "notification.order.placed" →
#    notification-service consumes it).
QUEUE_NAME=<from step 1>

# 3. Is the consumer container even running?
docker ps --filter "name=via_prod-<consumer>" --format \
  'table {{.Names}}\t{{.Status}}\t{{.RestartCount}}'

# 4. Why did it die?
docker logs --since 30m via_prod-<consumer> 2>&1 | tail -100

# 5. RabbitMQ connection-side view (does the broker think the consumer
#    ever connected?).
docker exec via_prod-rabbitmq rabbitmqctl list_connections name client_properties \
  | grep -i <consumer>

المعالجة الفورية

الحاوية متوقفة: docker compose -f docker-compose.prod.yml up -d <consumer>.
الحاوية تعمل لكن لا تتصل: تأكد أن RABBITMQ_URL صحيح في env، وأن RabbitMQ يقبل اتصالات.
حلقة استثناء عند الاتصال: افتح آخر استثناء واصلحه — قد يكون auth, network, أو schema mismatch.
حالة طوارئ: إن استحال إصلاح المستهلك سريعاً وكانت الرسائل تتراكم بسرعة، شغل سكربت drain-to-DLX يدوياً وافتح ticket.

مسار التصعيد

PagerDuty → On-call.
إذا الطابور يحمل أحداث orders/payments: صعّد للمالية فوراً (الحالة المالية تتأخر).
إذا الانقطاع > 15 دقيقة: انشر إعلان حالة.

الاستعادة / التراجع

بمجرد عودة المستهلك، تابع rabbitmq_queue_consumers ≥ 1 ثم rabbitmq_queue_messages_ready ينخفض.
إذا أُجريت drain-to-DLX، شغل dlx_replay بعد التحقق من إصلاح السبب الجذر.
افتح post-mortem إذا تجاوز الانقطاع 10 دقائق.