ملف باسم /check.txt على مضيف وكيل يبدو هدفاً بديهياً للفحص. المفارقة أن مستمع Squid الأمامي الصريح ليس موقعاً عادياً يخدم جذر مستندات ذلك المضيف.

طلب بأسلوب المصدر مثل HEAD /check.txt HTTP/1.1 يحذف الهدف المطلق المتوقع لطلب HTTP عادي عبر وكيل أمامي. وحسب الإعداد قد يُرفض أو تتولاه خدمة محلية أخرى. وكلتا النتيجتين قد تخبرك أقل مما توحي به لوحة المراقبة.

اختر الخدمة التي تريد إبقاءها متاحة

الفحصالدليل المفيد
اتصال TCP بمستمع الوكيلعملية يمكن الوصول إليها تقبل ذلك الاتصال.
CONNECT إلى هدف خاضع للسيطرةالوكيل يقبل طلب النفق ذلك.
استرجاع HTTP عبر الوكيلمسار الطلب المختار يستطيع إرجاع استجابة متوقعة.

في الحالة الثالثة يحتاج الطلب إلى هدف، مثلاً:

HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internal

اسم المضيف للتوضيح فقط. استخدم نقطة نهاية خاضعة للسيطرة يستطيع الوكيل تحليلها ويُسمح له عمداً بالوصول إليها. يدعم http-check send في HAProxy اختيار الطريقة وURI والإصدار والترويسات؛ اضبط ذلك الطلب صراحة بدل وراثة مثال خادم مصدر دون تغيير.

يستطيع HEAD فحص حالة الاستجابة والترويسات. لكنه لا يستطيع التحقق من جسم استجابة لا يُنقل قط. وإذا كان عقد الصحة يشترط علامة في الجسم، فاختر فحص GET مناسباً وتحقق من تلك العلامة.

أبقِ حساب الفحص وقيود المصدر ضيقة عند وجود مصادقة الوكيل. فإعفاء المستمع كله من المصادقة للحصول على علامة خضراء يغيّر الخدمة التي تُحمى.

أخيراً، حدّد ما ينبغي أن يزيله فحص فاشل. انقطاع مصدر خاضع للسيطرة يمكن أن يُفشل فحص التمرير عند كل وكيل في الوقت نفسه. وقد يكون ذلك بالضبط الاعتماد الذي تريد قياسه، أو سبباً لإبقاء صحة المستمع والتوافر من طرف إلى طرف إشارتين منفصلتين.

مقالات ذات صلة