Å tolke status og utgangskodar frå ein proxy-overvakar
Rapporter kommando køyring, HTTP-resultat og sertifikatvalidering kvar for seg i ein proxybasert nettstadssjekk.
Ein wrapper kan ikkje gjere null-utgangskoden frå nedlastaren om til ein observert «HTTP 200 OK». Noter kva kvart lag faktisk rapporterte:
| Felt | Spørsmålet som blir svara |
|---|---|
| Utgang frå verktøy eller plugin | Vart sjekken køyrd, og kva feilklasse vart rapportert? |
| Proxy-forhandling | Vart vidaresendinga eller den førespurde tunnelen tillaten? |
| Status for opphavet og forventa innhald | Returnerte applikasjonen det tiltenkte resultatet? |
| TLS-validering | Lukkast dei konfigurerte identitetssjekkane? |
curl kan vanlegvis returnere null etter ein HTTP-feilrespons. fail-innstillingane endrar utgangsåtferda, men ein feilutgang identifiserer framleis ikkje statusen eintydig. Også utgangsverdiane til Wget er kategoriar: ein autentiseringsfeil er ikkje ein eigen verdi for HTTP 401, og ein tenarfeilkategori identifiserer ikkje kvart svar inni han. Ein sjekk som ventar 401, må observere det svaret.
Hald proxy-endepunktet og nettstadsnamnet fråskilde. TCP-motparten i ein HTTP-proxysjekk er proxyen; CONNECT namngjev destinasjonen, der TLS-økta hans deretter går føre seg inne i tunnelen. Ved ein HTTPS-proxy er tillit til den ytre proxyen nok ein sertifikatsjekk.
Gransk garantien til pluginen før du behandlar eit SSL-flagg som verifisering. Monitoring Plugins utfasar check_http til fordel for check_curl. check_http-dokumentasjonen åtvarar om at val av SSL åleine ikkje verifiserer vertsnamn eller tillit til utferdaren; den dokumenterte verify-peer-innstillinga i check_curl omfattar den verifiseringa.
Bruk også den tiltenkte autentiserte ruta. Ein portsonde kan bli grøn medan driftskontoen får 407. Lever hemmelægda gjennom eigna mekanisme i utrullinga, og rapporter trinnet som faktisk feila: ein avvist tunnel krev ei anna reparasjon enn ein uventa nettstadsstatus.