الموثوقية والإتاحة والمرونة

فحوصات الصحة ونبضات القلب

18 دقيقة الدرس 7 من 10

فحوصات الصحة ونبضات القلب

النظام الذي لا يستطيع اكتشاف أعطاله لا يستطيع التعافي منها. فحوصات الصحة ونبضات القلب هي الآليات التي تمنح منسقي الحاويات وموازنات التحميل والمهندسين المناوبين صورةً حية ومستمرة عن الحالات السليمة وتلك التي توقفت عن العمل بصمت. بدونها، تستمر الحاوية المعطوبة في استقبال الطلبات، وتقبل قاعدة البيانات المتدهورة كتابات لن تُنفَّذ أبدًا، ويستنزف المعالج الجامح كل الذاكرة المتاحة وهو يُعيد بيانات فاسدة — كل ذلك دون أن يلاحظه أحد.

تتناول هذه الدرس نموذجين تكامليين للاكتشاف (السحب والدفع)، والفرق بين فحص الحيوية وفحص الجاهزية، وحالات الفشل التي يفوّتها كل نهج، والأرقام الضرورية لاتخاذ هذه القرارات بشكل عملي.

نموذجان للاكتشاف: السحب مقابل الدفع

السحب (الفحص النشط) — يُرسل وحدة تحكم (موازن تحميل، أو Kubernetes kubelet، أو عميل Consul) طلبًا إلى الحالة على فترات منتظمة. تستجيب الحالة، ويفسّر المتحكم الاستجابة. هذا هو النموذج الأكثر شيوعًا والافتراضي في AWS Target Groups وGCP وNGINX وKubernetes.

الدفع (نبضة القلب) — تُرسل الحالة إشارات دورية إلى مُجمِّع مركزي أو خدمة مراقبة. الصمت يعني الفشل. يُستخدم هذا النموذج في انتهاء جلسات ZooKeeper وبروتوكول Gossip في Consul وحيوية وسيط Kafka وبروتوكولات عضوية المجموعة مثل SWIM.

فكرة أساسية: تكتشف فحوصات السحب الأعطال من الخارج؛ أما نبضات القلب فتكتشفها من الداخل. العملية المتوقفة في حالة إغلاق ستجتاز نبضة القلب لكنها ستفشل في فحص السحب. انقطاع الشبكة سيؤدي إلى انتهاء مهلة فحص السحب حتى لو كانت الحالة سليمة تمامًا. استخدم الاثنين معًا للحصول على دفاع متعمق.

نموذج السحب: يختبر المتحكم كل حالة. نموذج الدفع: ترسل الحالات نبضات قلب؛ والصمت يُطلق تنبيهًا.

الحيوية مقابل الجاهزية مقابل فحوصات الإطلاق

قدّمت Kubernetes تصنيفًا واضحًا اعتمدته معظم الأنظمة الحديثة:

فحص الإطلاق (Startup probe) — هل لا تزال العملية في مرحلة التهيئة؟ يمنع فحص الحيوية من إعادة تشغيل حاوية بطيئة الإطلاق (مثل إحماء JVM). يعمل فقط حتى ينجح للمرة الأولى.
فحص الحيوية (Liveness probe) — هل العملية حية أساسًا؟ يؤدي فشله إلى إعادة التشغيل. استخدمه للكشف عن الإغلاقات ونفاد الذاكرة والحالات غير القابلة للاسترداد. أبقه رخيصًا وسريعًا — يجب ألا يعتمد على خدمات خارجية.
فحص الجاهزية (Readiness probe) — هل الحالة جاهزة لاستقبال الحركة؟ فشله يزيل الحالة من تجمع موازن التحميل دون إعادة تشغيلها. استخدمه للإشارة إلى الإحماء، أو عدم توفر التبعيات، أو التهدئة المتعمدة قبل النشر المتدرج.

خطأ شائع: جعل فحص الحيوية يستدعي قاعدة بيانات أو API خارجي. إذا تعطّل هذا الاعتماد، ستُعاد تشغيل جميع حالاتك في آنٍ واحد — وهو انهيار ذاتي ناجم عن اندفاع الجميع معًا. يجب أن تتحقق الحيوية من العملية نفسها فقط (مثل زيادة عداد داخلي بسيط). احتفظ بفحوصات التبعية للجاهزية.

ما يجب أن يتحقق منه مسار الصحة

مسار GET /health المصمم جيدًا ليس قيمة ثنائية. يُعيد جسم JSON منظّمًا مع حالات المكونات الفرعية حتى يتمكن المشغلون من تشخيص المشكلة بدقة:

HTTP 200 OK
{
  "status": "degraded",
  "checks": {
    "db_primary":   { "status": "ok",      "latency_ms": 4   },
    "db_replica":   { "status": "ok",      "latency_ms": 6   },
    "cache":        { "status": "ok",      "latency_ms": 1   },
    "message_queue":{ "status": "timeout", "latency_ms": 5000 },
    "disk_space":   { "status": "ok",      "free_gb": 48     }
  },
  "version": "v3.17.2",
  "uptime_seconds": 86402
}

أعد HTTP 200 للحالة السليمة وHTTP 503 للحالة غير السليمة (وليس 500 — قد يُضلّل موازنات التحميل). الحالة degraded يمكنها إعادة 200 إذا كانت الحالة قادرة على تقديم الطلبات بسعة منخفضة؛ أعد 503 فقط عندما تكون الحالة غير قادرة فعلًا على تقديم الطلبات.

أفضل ممارسة: ضع مهلة داخلية ضيقة لكل فحص فرعي (مثل 200 ميلي ثانية). فحص الصحة الذي يستغرق 5 ثوانٍ يُبطل الغرض منه — إما يُنتهي وقت الاستجابة فيُصنَّف التحكم الحالة على أنها غير سليمة، أو يُعيق تجمع خيوط الفحص. يجب أن يستجيب المسار بأكمله في أقل من 500 ميلي ثانية.

توقيت الفحص: الأرقام المهمة

ثلاثة معاملات تتحكم في مدى سرعة اكتشاف الفشل مقارنةً بعدد الإيجابيات الكاذبة:

الفترة الزمنية (Interval) — كم مرة يختبر المتحكم في الدقيقة. القيم الشائعة: 10–30 ثانية. الفترات الأقصر تكتشف الأعطال أسرع لكنها تزيد الحمل على الأساطيل الكبيرة.
المهلة (Timeout) — كم ينتظر المتحكم قبل احتساب الطلب فشلًا. يجب أن تكون أقل من الفترة. الشائع: 3–10 ثوانٍ.
العتبة (Threshold) — كم فشل متتالي قبل التصنيف كغير سليم، وكم نجاح متتالي للعودة إلى السليم. الشائع: فشلان أو ثلاثة، نجاحان. يُخفف هذا من الأعطال العابرة التي تُسبّب إعادات تشغيل غير ضرورية.

وقت الاكتشاف = الفترة × عتبة الفشل + المهلة. مع فترة 10 ثوانٍ ومهلة 5 ثوانٍ وعتبة 3 فشلات، يبلغ أقصى زمن اكتشاف 35 ثانية. خلال تلك الفترة لا تزال الحركة تتجه نحو الحالة المعطوبة. صمّم ميزانيات إعادة المحاولة (الدرس 6) بناءً على ذلك.

بروتوكول Gossip وSWIM: نبضات القلب على نطاق المجموعة

عندما يكون لديك مئات أو آلاف العقد، يُنشئ استطلاع كل عقدة من متحكم مركزي نقطة فشل وحيدة وعنق زجاجة للتوزيع. تستخدم الأنظمة الموزعة مثل Consul وCassandra وAkka بدلًا من ذلك بروتوكول SWIM (عضوية قابلة للتوسع وضعيفة الاتساق بأسلوب العدوى):

كل عقدة تختار بشكل دوري نظيرًا عشوائيًا وترسل إليه ping.
إذا لم يستجب النظير في الموعد المحدد، تختار العقدة k عقدًا عشوائيًا أخرى وتطلب منها إرسال ping-req إلى المشتبه به نيابةً عنها (فحص غير مباشر).
فقط إذا فشلت جميع الفحوصات غير المباشرة أيضًا، تُصنَّف العقدة المشتبه بها كـمشتبه، وبعد فترة سماح إضافية تُصنَّف كـميتة.
تنتشر تحديثات العضوية عبر بروتوكول الإشاعة (Gossip) — مُضمَّنة في الرسائل العادية — فيتقارب المجموعة بأكمله في O(log N) جولة.

هذا يجعل معدل نطاق ترددي الاكتشاف ثابتًا لكل عقدة بغض النظر عن حجم المجموعة — خاصية بالغة الأهمية للأنظمة ذات آلاف العقد.

الفحص غير المباشر في SWIM: تطلب العقدة A من المساعدَين C وD فحص العقدة المشتبه بها B. تُعلَن ميتةً فقط عند فشل جميع المسارات.

اعتبارات تشغيلية

مسارات فحص الصحة تحتاج إلى حماية للمصادقة — فهي تكشف عن الطوبولوجيا الداخلية وحالة التبعيات. استخدم قيودًا على مستوى الشبكة (VPC فقط، الشبكة الفرعية الخاصة) أو رأس سر مشترك. لا تعرّض أبدًا /health/detail للإنترنت العام.

فرّق بين الفحوصات السطحية والعميقة. الفحص السطحي يتحقق من أن العملية تعمل ويمكنها قبول الاتصالات. الفحص العميق يتحقق من أنها قادرة فعلًا على أداء عمل مفيد (الاستعلام من قاعدة البيانات، القراءة من القائمة). استخدم السطحي للحيوية والعميق للجاهزية. الفحوصات العميقة على كل فترة اختبار قد تُغرق قاعدة بياناتك بحركة مصطنعة.

سجّل أعطال فحوصات الصحة بمستوى خطورة منفصل. فشل عابر واحد هو ضجيج؛ فشلان متتاليان للمكوّن ذاته يجب أن يُنبّها مهندسًا. جمِّع الأعطال عبر الأسطول — إذا فشلت 40% من الحالات في فحص جاهزية قاعدة البيانات في آنٍ واحد، فهذه مشكلة في قاعدة البيانات، وليست 40 مشكلة منفصلة للحالات.

الشواهد الاصطناعية (Synthetic Canaries): بدلًا من الاعتماد فقط على فحوصات الصحة السلبية، جدوِل معاملات اصطناعية تُمارس تدفقات المستخدم الكاملة (تسجيل الدخول، جلب البيانات، كتابة سجل) على الإنتاج أو بيئة ظل كل دقيقة. تكتشف هذه الفحوصات الأعطال المنطقية — مثل إعادة بيانات خاطئة — التي لن تكشفها استجابة HTTP 200 البسيطة أبدًا.

فحوصات الصحة ونبضات القلب هي الجهاز العصبي للبنية الموزعة المرنة. بدونها تطير أعمى؛ ومع فحوصات مُعايَرة جيدًا، يستطيع نظامك اكتشاف الأعطال والتحايل عليها في ثوانٍ بدلًا من دقائق.