Ei fil som heiter /check.txt på ein proxyvert høyrest ut som eit opplagt helsemål. Haken er at Squid sin eksplisitte vidaresendingslyttar ikkje er eit vanleg nettstad som tener dokumentrota til den verten.

Ein førespurnad i opphavsstil som HEAD /check.txt HTTP/1.1 utelét det absolutte målet som vert venta for ein vanleg HTTP-førespurnad gjennom ein vidaresendingsproxy. Avhengig av konfigurasjonen kan han verte avvist eller handsama av ei anna lokal teneste. Begge utfalla kan fortelje deg mindre enn dashbordet antydar.

Vel tenesta du må halde tilgjengeleg

SjekkNyttig prov
TCP-samband til proxlyttarenEin tilgjengeleg prosess godtek det sambandet.
CONNECT til eit kontrollert målProxyen godtek den tunnel-førespurnaden.
HTTP-henting gjennom proxyenDen valde førespurnadsstigen kan gje eit venta svar.

I det tredje tilfellet treng førespurnaden eit mål, til dømes:

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

Vertnamnet er berre illustrativt. Bruk eit kontrollert endepunkt som proxyen kan løyse opp og med vilje har løyve til å nå. http-check send hjå HAProxy støttar val av metode, URI, versjon og hovud; set opp den førespurnaden eksplisitt i staden for å arve eit opphavsserver-døme uendra.

HEAD kan sjekke ein svartilstand og hovud. Det kan ikkje validere ein svarlekam som aldri vert overført. Om helsekontrakten krev ein markør i lekamen, vel ein høveleg GET-sjekk og valider den markøren.

Hald sjekkkontoen og kjeldegrensene trange når proxyautentisering er med. Å fritekje heile lyttaren frå autentisering for å få ein grøn hake endrar tenesta som vert verna.

Til slutt, avgjer kva ein mislukka sjekk skal fjerne. Eit kontrollert opphavsavbrot kan få vidaresendingssjekken til kvar proxy til å mislukkast samstundes. Det kan vere nettopp den avhengnaden du vil måle, eller ein grunn til å halde lytterhelse og ende-til-ende-tilgjenge som skilde signal.

Relaterte artiklar