بناء مجمع لفحص الحالة متعدد المناطق
مستخدم في ساو باولو يصادف عقدة طرفية (edge node) معطلة. لا يقوم بتقديم تقرير عن الخطأ، بل يغلق علامة التبويب ويشاهد شيئًا آخر.
أدوات مراقبة وقت التشغيل (uptime monitor) العادية تغفل عن هذا الأمر. فمعظم أدوات المراقبة تقوم بالفحص من موقع واحد فقط، ومن ذلك الموقع، يبدو كل شيء يعمل بشكل ممتاز (green).
كانت صفحة الحالة الخاصة بنا تشير إلى أن وقت التشغيل بنسبة 100%، بينما كان المستخدمون الحقيقيون يواجهون حالات انتهاء المهلة (timeouts). كان فحص حالة عالمي واحد يخدعنا.
إليكم كيف بنينا نظامًا يقول الحقيقة.
المشكلة: انحياز العينات (Sampling Bias) إذا كانت أداة المراقبة الخاصة بك موجودة في مركز بيانات واحد، فهي لا ترى إلا واقعًا واحدًا. قد تظهر لك النتائج خضراء حتى لو كانت العقد الطرفية في سنغافورة وساو باولو تفقد الاتصالات.
حركة مرور الفيديو تزيد الأمر سوءًا. تشمل الإخفاقات الإقليمية الشائعة ما يلي:
- مسارات BGP سيئة تؤثر على قارة واحدة.
- عمليات إخلاء ذاكرة التخزين المؤقت (Cache evictions) التي تفرض العودة البطيئة إلى المصدر (origin fallbacks).
- أخطاء في القرص تسبب انتهاء مهلة مصافحة TLS.
- مشكلات في DNS لدى محللات (resolvers) محلية محددة.
استجابة "200 OK" واحدة لا تخبرك بشيء تقريبًا.
قواعدنا الثلاث للحالة الصحية: لقد تجاوزنا مجرد رموز الحالة (status codes). نحن نحدد الحالة الصحية باستخدام ثلاثة مقاييس:
- إمكانية الوصول (Reachability): يجب أن تنتهي مصافحات TCP و TLS في غضون 800 مللي ثانية.
- زمن الاستجابة (Latency): نقوم بتتبع p95 لزمن الوصول إلى أول بايت (TTFB). فالمتوسطات تخفي "الذيل البطيء" (slow tail) الذي يزعج المستخدمين.
- الصحة (Correctness): يجب أن يحتوي جسم الاستجابة على علامة متوقعة. فاستجابة 200 OK التي تعيد صفحة خطأ تُعد فشلاً.
الحل: الفحص متعدد المناطق (Multi-Region Probing) توقفنا عن استخدام أداة مراقبة واحدة كبيرة. وبدلاً من ذلك، نقوم بنشر ملفات ثنائية (binaries) صغيرة بلغة Go على خوادم VPS إقليمية رخيصة.
كل أداة فحص (prober):
- تفحص العقد الطرفية من منظور محلي.
- تستخدم
httptraceللحصول على بيانات TTFB حقيقية. - ترسل النتائج إلى مجمع مركزي.
نستخدم SQLite للتخزين. فهي بسيطة وتتعامل مع عبء العمل لدينا دون أي عبء إضافي (zero overhead). نقوم بتخزين العينات الخام بدلاً من البيانات المجمعة مسبقًا، مما يسمح لنا بإعادة تقييم السجل أو تصحيح أخطاء إخفاقات محددة لاحقًا.
السر: النصاب (Quorum) الشبكات مليئة بالضجيج. فقدان حزمة بيانات واحدة لا يعني انقطاع الخدمة.
نستخدم نظام نصاب (quorum) لمنع الإنذارات الكاذبة. لا نعلن عن تعطل عقدة طرفية إلا عندما تتفق مناطق متعددة على ذلك. إذا رصدت منطقة واحدة إخفاقًا بينما لم ترصد المناطق الأخرى ذلك، فلا نقوم بإرسال تنبيه للفريق. هذا الخيار التصميمي أزال 90% من تنبيهاتنا الكاذبة.
دروس رئيسية:
- افحص ما يصل إليه المستخدمون، وليس مسارًا اصطناعيًا.
- تتبع زمن استجابة الذيل (p95)، وليس المتوسطات.
- استخدم أدوات فحص رخيصة وقابلة للاستبدال في مناطق عديدة.
- استخدم نظام النصاب لتجنب إرهاق التنبيهات (pager fatigue).
- حافظ على بساطة بنية التخزين لديك.
لست بحاجة إلى منصة مراقبة ضخمة. بل تحتاج إلى مجسات محلية، وبيانات خام، وقاعدة ترفض الذعر من الضجيج.