Att tolka status och utgångskoder från en proxyövervakare
Rapportera kommando körning, HTTP-resultat och certifikatvalidering var för sig i en proxybaserad webbplatskontroll.
En wrapper kan inte göra noll-utgångskoden från nedladdaren till en observerad ”HTTP 200 OK”. Anteckna vad varje lager faktiskt rapporterade:
| Fält | Frågan som besvaras |
|---|---|
| Verktygs- eller pluginutgång | Kördes kontrollen, och vilken felklass rapporterades? |
| Proxyförhandling | Tilläts vidarebefordran eller den begärda tunneln? |
| Ursprungsstatus och förväntat innehåll | Returnerade applikationen det avsedda resultatet? |
| TLS-validering | Lyckades de konfigurerade identitetskontrollerna? |
curl kan vanligtvis returnera noll även efter ett HTTP-felsvar. Dess fail-alternativ ändrar utgångsbeteendet, men en felutgång identifierar fortfarande inte statusen entydigt. Även Wgets utgångsvärden är kategorier: ett autentiseringsfel är inte ett eget värde för HTTP 401, och en serverfelkategori identifierar inte varje svar inom den. En kontroll som väntar sig 401 måste observera det svaret.
Håll proxyändpunkten och webbplatsnamnet åtskilda. TCP-motparten i en HTTP-proxykontroll är proxyn; CONNECT namnger målet, vars TLS-session sedan körs inne i tunneln. Vid en HTTPS-proxy är förtroendet för den yttre proxyn ännu en certifikatkontroll.
Granska pluginens garanti innan du behandlar en SSL-flagga som verifiering. Monitoring Plugins avvecklar check_http till förmån för check_curl. check_http-dokumentationen varnar för att val av enbart SSL inte verifierar värdnamn eller utfärdarens förtroende; check_curls dokumenterade verify-peer-alternativ omfattar den verifieringen.
Använd också den avsedda autentiserade vägen. En portkontroll kan förbli grön medan driftkontot får 407. Lämna över hemligheten via distributionens lämpliga mekanism och rapportera steget som faktiskt misslyckades: en nekad tunnel kräver en annan åtgärd än en oväntad webbplatsstatus.