حركة مستمرة على DLX

الأعراض

• VIAEventBusDLXMessages (warn) أو VIAEventBusDLXSustained (page).
• rate(via_dlx_messages_total[5m]) > 0.
• audit_event_dlq يحوي صفوفاً جديدة.

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

# 1. Top offending consumers / event types in the last 10 min.
curl -s 'http://prometheus:9090/api/v1/query' --data-urlencode \
  'query=topk(5, sum by (consumer, event_type) (increase(via_dlx_messages_total[10m])))' \
  | jq '.data.result'

# 2. Pull a few raw envelopes from the DLQ table.
docker exec via_prod-audit-db psql -U "$AUDIT_POSTGRES_USER" \
  -d "$AUDIT_POSTGRES_DB" -c \
  "SELECT id, event_type, consumer, error_message, payload->>'event_id' AS event_id,
          created_at
   FROM audit_event_dlq
   ORDER BY created_at DESC LIMIT 10;"

# 3. Look at the offending consumer's logs around the timestamps.
docker logs --since 15m via_prod-<consumer> 2>&1 \
  | grep -iE 'nack|exception|traceback' | tail -40

# 4. RabbitMQ DLX queue depth + consumer count.
docker exec via_prod-rabbitmq rabbitmqctl list_queues name messages consumers \
  | grep dlx

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

1. مستهلك واحد يطلق NACK باستمرار: استثناء غير معالج في handler. أصلحه أو احذف publish قائمة المستهلك مؤقتاً.
2. عدم توافق schema: منتج رفع نسخة جديدة من شكل الحدث قبل المستهلك. تراجع المنتج أو لفّ المستهلك.
3. رسائل سامة: اعزلها (DLX يحتفظ بها)، تابع المعالجة العادية، ثم replay لاحقاً بعد إصلاح السبب.

مسار التصعيد

1. Warn (1m بأي معدل > 0): On-call عبر Slack.
2. Page tier (>100 خلال 10 دقائق): PagerDuty.
3. إذا تأثر event_type لـ orders.* أو payments.*: المالية تنبه فوراً، الحالة المالية متأخرة.

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

1. بعد إصلاح السبب الجذر، شغل dlx_replay لإعادة الرسائل من audit_event_dlq إلى exchange الأصلي.
2. لا تحذف صفوف audit_event_dlq يدوياً — هذه شجرة الإثبات للمشكلة.
3. افتح post-mortem إذا تجاوز عدد الرسائل في DLX 1000، أو إذا تأثرت أحداث مالية.