Å tolke status og utgangskoder fra en proxy-overvåker
Rapporter kommando kjøring, HTTP-resultat og sertifikatvalidering hver for seg i en proxybasert nettstedssjekk.
En wrapper kan ikke gjøre null-utgangskoden fra nedlasteren om til en observert «HTTP 200 OK». Noter hva hvert lag faktisk rapporterte:
| Felt | Spørsmålet som besvares |
|---|---|
| Verktøy- eller plugin-utgang | Ble sjekken kjørt, og hvilken feilklasse ble rapportert? |
| Proxy-forhandling | Ble videresendingen eller den forespurte tunnelen tillatt? |
| Opprinnelsesstatus og forventet innhold | Returnerte applikasjonen det tiltenkte resultatet? |
| TLS-validering | Lyktes de konfigurerte identitetssjekkene? |
curl kan vanligvis returnere null etter en HTTP-feilrespons. fail-innstillingene endrer utgangsatferden, men en feilutgang identifiserer fortsatt ikke statusen entydig. Wgets utgangsverdier er også kategorier: en autentiseringsfeil er ikke en egen verdi for HTTP 401, og en tjenerfeilkategori identifiserer ikke hvert svar inni den. En sjekk som forventer 401, må observere det svaret.
Hold proxy-endepunktet og nettstedsnavnet atskilt. TCP-motparten i en HTTP-proxysjekk er proxyen; CONNECT navngir destinasjonen, hvis TLS-økt deretter kjører inne i tunnelen. Ved en HTTPS-proxy er tillit til den ytre proxyen nok en sertifikatsjekk.
Undersøk garantien til pluginen før du behandler et SSL-flagg som verifisering. Monitoring Plugins utfaser check_http til fordel for check_curl. check_http-dokumentasjonen advarer om at valg av SSL alene ikke verifiserer vertsnavn eller utstederens troverdighet; check_curls dokumenterte verify-peer-innstilling omfatter den verifiseringen.
Bruk også den tiltenkte autentiserte ruten. En portsonde kan forbli grønn mens driftskontoen mottar 407. Lever hemmeligheten gjennom distribusjonens egnede mekanisme, og rapporter trinnet som faktisk feilet: en avvist tunnel krever en annen reparasjon enn en uventet nettstedstatus.