تراكم في طابور outbox

الأعراض

• EventOutboxBacklog (warn) أو EventOutboxBacklogCritical (page) فعّال.
• rabbitmq_queue_messages على طابور *outbox* مرتفع.
• الأحداث المرسلة من الخدمات (orders, payments, fleet) لا تصل للمستهلكين.

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

# 1. Which queue, how deep, and is anyone consuming?
docker exec via_prod-rabbitmq rabbitmqctl list_queues name messages consumers \
  | sort -k2 -n -r | head -20

# 2. Identify the consumer service from the queue name (convention:
#    "<consumer>.<event-routing-key>"). Then check its container.
docker logs --tail 200 via_prod-<consumer-service> 2>&1 | tail -80

# 3. Is the downstream DB healthy? Pool exhaustion is the #1 cause.
curl -s http://prometheus:9090/api/v1/query \
  --data-urlencode 'query=db_pool_connections_in_use / db_pool_connections_max' \
  | jq '.data.result[] | select(.value[1] | tonumber > 0.9)'

# 4. Memory pressure on the consumer pod.
docker stats --no-stream via_prod-<consumer-service>

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

1. مستهلك ساقط: docker compose -f docker-compose.prod.yml up -d <consumer>. ارفع memory limit إن تكرر OOM.
2. مستهلك في حلقة استثناء: تعرف على الرسالة من السجل، ثم استخدم rabbitmqctl لتحويلها إلى DLX يدوياً.
3. DB مشبع: افتح runbook db-pool-exhausted، عالج الـ pool، ثم سيعود المستهلك للسحب.
4. انفجار من المنتج: تحقق rate(rabbitmq_queue_messages_published_total) — هل صعد فجأة؟

مسار التصعيد

1. Warn: عالجه On-call مباشرة.
2. Critical: PagerDuty + اتصل بصاحب الخدمة (نقش outbox = صاحب المستهلك المتأخر).
3. إذا تأثرت أحداث orders/payments أكثر من 10 دقائق: نشاط مالي معطل، صعّد للمالية والـ CTO.

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

1. بعد إصلاح المستهلك، تابع طول الطابور — يجب أن ينخفض بمعدل (consumer rps × prefetch).
2. لا تستخدم purge_queue إلا إذا فقدان الأحداث مقبول. اكتب الإقرار قبل التنفيذ.
3. إذا تم تحويل رسائل إلى DLX خلال الحادث: استخدم سكربت dlx_replay (إن وجد) بعد إصلاح المستهلك.