Comprobacións de saúde de HAProxy para un proxy de reenvío Squid
Constrúa unha comprobación de saúde de HAProxy que fale cun proxy de reenvío e distinga a accesibilidade do listener, a aceptación de CONNECT e a recuperación desde a orixe.
Un ficheiro chamado /check.txt nun host de proxy parece un obxectivo de saúde obvio. A trampa é que o listener de reenvío explícito de Squid non é un sitio web normal que sirva a raíz de documentos dese host.
Unha petición con estilo de orixe como HEAD /check.txt HTTP/1.1 omite o obxectivo absoluto que se espera para unha petición HTTP normal a través dun proxy de reenvío. Segundo a configuración, pode ser rexeitada ou xestionala outro servizo local. Calquera dos dous resultados pode dicirlle menos do que suxire o panel.
Escolla o servizo que necesita manter dispoñible
| Comprobación | Evidencia útil |
|---|---|
| Conexión TCP ao listener do proxy | Un proceso accesible acepta esa conexión. |
| CONNECT a un obxectivo controlado | O proxy acepta esa petición de túnel. |
| Recuperación HTTP a través do proxy | A ruta de petición escollida pode devolver unha resposta esperada. |
Para o terceiro caso, a petición necesita un obxectivo, por exemplo:
HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internalO nome de host é ilustrativo. Use un punto de conexión controlado que o proxy poida resolver e ao que se lle permita chegar intencionadamente. http-check send de HAProxy admite escoller método, URI, versión e cabeceiras; configure esa petición explicitamente en lugar de herdanza sen cambios dun exemplo de servidor de orixe.
HEAD pode comprobar un estado de resposta e cabeceiras. Non pode validar un corpo de resposta que nunca se transfire. Se o contrato de saúde esixe un marcador no corpo, escolla unha comprobación GET axeitada e valide ese marcador.
Manteña estreitos a conta de comprobación e as restricións de orixe cando haxa autenticación de proxy. Eximir todo o listener da autenticación para obter unha marca verde cambia o servizo que se protexe.
Por último, decida que debe retirar unha comprobación fallida. Unha caída controlada da orixe pode facer fallar á vez a comprobación de reenvío de todos os proxies. Pode ser xustamente a dependencia que quere medir, ou un motivo para manter a saúde do listener e a dispoñibilidade de extremo a extremo como sinais separados.