بررسی‌های سلامت HAProxy برای پروکسی پیشرو Squid

فایلی با نام /check.txt روی میزبان پروکسی هدف سلامتی بدیهی به نظر می‌رسد. نکته اینجاست که شنونده پیشرو صریح Squid یک وب‌سایت معمولی که ریشه اسناد آن میزبان را سرو کند نیست.

درخواستی به سبک مبدأ مانند HEAD /check.txt HTTP/1.1 هدف مطلقی که برای یک درخواست HTTP معمولی از طریق پروکسی پیشرو انتظار می‌رود را حذف می‌کند. بسته به پیکربندی، ممکن است رد شود یا سرویس محلی دیگری آن را مدیریت کند. هر دو نتیجه ممکن است کمتر از آنچه داشبورد نشان می‌دهد به شما بگویند.

سرویسی را انتخاب کنید که باید در دسترس بماند

در حالت سوم، درخواست به یک هدف نیاز دارد، برای نمونه:

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

نام میزبان فقط نمونه است. از یک نقطه پایانی تحت کنترل استفاده کنید که پروکسی بتواند آن را تفکیک کند و عمداً اجازه دسترسی به آن را داشته باشد. http-check send در HAProxy انتخاب روش، URI، نسخه و سرآیندها را پشتیبانی می‌کند؛ آن درخواست را صریح پیکربندی کنید نه اینکه نمونه سرور مبدأ را بدون تغییر به ارث ببرید.

HEAD می‌تواند وضعیت پاسخ و سرآیندها را بررسی کند. اما نمی‌تواند بدنه پاسخی را که هرگز منتقل نمی‌شود اعتبارسنجی کند. اگر قرارداد سلامت نشانگری در بدنه می‌خواهد، یک بررسی GET مناسب انتخاب کنید و همان نشانگر را اعتبارسنجی کنید.

وقتی احراز هویت پروکسی در میان است، حساب بررسی و محدودیت‌های مبدأ را تنگ نگه دارید. معاف کردن کل شنونده از احراز هویت برای گرفتن تیک سبز، سرویسی را که محافظت می‌شود تغییر می‌دهد.

سرانجام تصمیم بگیرید یک بررسی ناموفق چه چیزی را باید حذف کند. قطع سرویس مبدأ تحت کنترل می‌تواند بررسی ارسال همه پروکسی‌ها را همزمان رد کند. این ممکن است دقیقاً همان وابستگی باشد که می‌خواهید اندازه بگیرید، یا دلیلی برای نگه داشتن سلامت شنونده و دسترس‌پذیری سرتاسری به‌عنوان دو سیگنال جداگانه.