انتقل إلى المحتوى

الفصل 13: مراقبة الصحة والتشخيصات

الجمهور المستهدف: مهندسو DevOps، مهندسو المنصة

نقاط نهاية الصحة

/api/health: فحص الحيوية

يُرجع حالة API الأساسية، ومعرّف git SHA، والإصدار. يُستخدم بواسطة سير عمل النشر والمراقبة الخارجية.

curl -sS https://scan.rtb.cat/api/health | jq .

/system/data-health: اكتمال البيانات

يُرجع حالة صحة البيانات لكل مشترٍ، بما في ذلك حالة حداثة كل نوع من التقارير. يقبل المعاملات days وbuyer_id وavailability_state.

يُستخدم بواسطة قائمة الإعداد وبوابة الصحة أثناء التشغيل.

صفحة حالة النظام (/settings/system)

تعرض الواجهة ما يلي:

الفحص ما يراقبه
Python إصدار بيئة التشغيل وتوافرها
Node حالة بناء Next.js والعرض من جانب الخادم
FFmpeg القدرة على توليد الصور المصغرة للفيديو
قاعدة البيانات اتصال Postgres وعدد الصفوف
الصور المصغرة حالة التوليد على دفعات وقائمة الانتظار
مساحة القرص استخدام قرص الآلة الافتراضية

سكربتات الصحة أثناء التشغيل

هذه السكربتات هي العمود الفقري التشغيلي للتحقق من أن النظام يعمل بشكل سليم من البداية إلى النهاية.

diagnose_v1_buyer_report_coverage.sh

يشخّص سبب وجود تغطية CSV مفقودة لمشترٍ محدد.

export CATSCAN_CANARY_EMAIL="cat-scan@rtb.cat"
scripts/diagnose_v1_buyer_report_coverage.sh \
  --buyer-id 1487810529 \
  --timeout 180 \
  --days 14

الفحوصات (بالترتيب): 1. ربط المقاعد: buyer_id -> bidder_id 2. مصفوفة الاستيراد: نجاح/فشل/لم يُستورد حسب نوع CSV 3. حداثة البيانات: تغطية الخلايا المستوردة/المفقودة 4. سجل الاستيراد: صفوف الاستيراد الأخيرة 5. حالة Gmail: عدد الرسائل غير المقروءة، آخر سبب، أحدث تاريخ قياس

النتيجة: PASS أو FAIL مع تشخيص محدد.

run_v1_runtime_health_strict_dispatch.sh

يُشغّل بوابة الصحة الكاملة أثناء التشغيل، والتي تفحص:

  • صحة API
  • صحة البيانات (الحداثة وتغطية الأبعاد)
  • صحة التحويلات والجاهزية
  • زمن بدء تشغيل QPS
  • ملخص اتفاقية مستوى الخدمة لصفحة QPS
  • اقتصاديات المحسّن والنماذج
  • التحقق من نقاط نهاية النماذج
  • سير عمل التسجيل والاقتراح
  • دورة حياة المقترح
  • تشغيل تجريبي للتراجع

يُرجع كل فحص PASS أو FAIL أو BLOCKED (مع ذكر السبب).

سير عمل CI: v1-runtime-health-strict.yml

يُشغّل بوابة الفحص الصارم في CI. يتم تشغيله يدويًا عبر workflow_dispatch.

gh workflow run v1-runtime-health-strict.yml \
  --ref unified-platform \
  -f api_base_url="https://scan.rtb.cat/api" \
  -f buyer_id="1487810529" \
  -f canary_profile="balanced" \
  -f canary_timeout_seconds="180"

مصادقة الاختبار الكناري

تتم مصادقة سكربتات التشغيل باستخدام متغيرات البيئة:

المتغير الغرض
CATSCAN_CANARY_EMAIL ترويسة X-Email لاستدعاءات API المباشرة (محليًا على الآلة الافتراضية)
CATSCAN_BEARER_TOKEN رمز الحامل (بيئة CI، مخزّن في أسرار GitHub)
CATSCAN_SESSION_COOKIE ملف تعريف ارتباط جلسة OAuth2 Proxy (بيئة CI)

من مضيف الآلة الافتراضية، استخدم CATSCAN_CANARY_EMAIL مع http://localhost:8000. من CI (خارجيًا)، استخدم CATSCAN_BEARER_TOKEN أو CATSCAN_SESSION_COOKIE مع https://scan.rtb.cat/api.

تفسير النتائج

الحالة المعنى
PASS نجح الفحص، النظام سليم
FAIL فشل الفحص، يجب التحقيق فورًا
BLOCKED لم يتمكن الفحص من الاكتمال بسبب تبعية مفقودة (مثلاً: لا توجد بيانات لهذا المشتري، أو نقطة نهاية مفقودة). ليس بالضرورة خطأ في الكود.

مواضيع ذات صلة