En fil som heter /check.txt på en proxyvärd låter som ett självklart hälsomål. Haken är att Squids explicita vidarebefordringslyssnare inte är en vanlig webbplats som serverar den värdens dokumentrot.

En förfrågan i ursprungsstil som HEAD /check.txt HTTP/1.1 utelämnar det absoluta mål som förväntas för en vanlig HTTP-förfrågan via en vidarebefordrande proxy. Beroende på konfigurationen kan den avvisas eller hanteras av en annan lokal tjänst. Båda utfallen kan säga dig mindre än instrumentpanelen antyder.

Välj den tjänst du behöver hålla tillgänglig

KontrollAnvändbart bevis
TCP-anslutning till proxylyssnarenEn nåbar process accepterar den anslutningen.
CONNECT till ett kontrollerat målProxyn accepterar den tunnelbegäran.
HTTP-hämtning genom proxynDen valda begäransvägen kan returnera ett förväntat svar.

I det tredje fallet behöver begäran ett mål, till exempel:

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

Värdnamnet är bara illustrativt. Använd en kontrollerad slutpunkt som proxyn kan slå upp och som den avsiktligt har tillåtelse att nå. HAProxys http-check send stöder val av metod, URI, version och huvuden; konfigurera den begäran uttryckligen i stället för att ärva ett ursprungsserverexempel oförändrat.

HEAD kan kontrollera en svarsstatus och huvuden. Det kan inte validera en svarskropp som aldrig överförs. Om hälsokontraktet kräver en markör i kroppen, välj en lämplig GET-kontroll och validera den markören.

Håll kontrollkontot och källbegränsningarna snäva när proxyautentisering är inblandad. Att undanta hela lyssnaren från autentisering för att få en grön bock ändrar tjänsten som skyddas.

Bestäm slutligen vad en misslyckad kontroll ska ta bort. Ett kontrollerat ursprungsavbrott kan få varje proxys vidarebefordringskontroll att misslyckas samtidigt. Det kan vara precis det beroende du vill mäta, eller en anledning att hålla lyssnarhälsa och tillgänglighet från ände till ände som separata signaler.

Relaterade artiklar