Проверки на състоянието на HAProxy за препращащ прокси Squid
Изградете проверка на състоянието на HAProxy, която говори с препращащ прокси, и разграничавайте достъпност на слушателя, приемане на CONNECT и извличане от източника.
Файл с име /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 проверка и валидирайте този маркер.
Дръжте проверяващия акаунт и ограниченията на източника тесни, когато има удостоверяване на проксито. Освобождаването на целия слушател от удостоверяване, за да получите зелена отметка, променя услугата, която се защитава.
Накрая решете какво трябва да премахне неуспешната проверка. Контролирано прекъсване на източника може да провали проверката за препращане на всяко прокси едновременно. Това може да е точно зависимостта, която искате да измерите, или причина да държите състоянието на слушателя и наличността от край до край като отделни сигнали.