Hvordan 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». Skriv ned hva hvert lag faktisk rapporterte:
| Felt | Spørsmål som besvares |
|---|---|
| Utgang fra verktøy eller plugin | Ble sjekken kjørt, og hvilken feilklasse ble rapportert? |
| Forhandling med proxyen | Ble videresendingen eller den forespurte tunnelen tillatt? |
| Opprinnelsesstatus og forventet innhold | Returnerte applikasjonen det tiltenkte resultatet? |
| TLS-validering | Var de konfigurerte identitetssjekkene vellykkede? |
curl kan som regel returnere null også etter et HTTP-feilsvar. fail-valgene endrer utgangsatferden, men en feilutgang identifiserer fortsatt ikke statusen entydig. Også Wgets utgangsverdier er kategorier: en autentiseringsfeil er ikke en egen verdi for HTTP 401, og en tjenerfeilkategori identifiserer ikke hvert svar innenfor den. En sjekk som forventer 401, må observere nettopp det svaret.
Hold proxy-endepunktet og nettstedsnavnet atskilt. TCP-motparten i en HTTP-proxysjekk er proxyen; CONNECT navngir destinasjonen, og TLS-økten dens foregår deretter inne i tunnelen. Ved en HTTPS-proxy er tilliten til den ytre proxyen enda en sertifikatsjekk.
Undersøk garantien pluginen gir før du behandler et SSL-flagg som verifisering. Monitoring Plugins faser ut check_http til fordel for check_curl. check_http-dokumentasjonen advarer om at valg av kun SSL ikke verifiserer vertsnavn eller utstederens troverdighet; den dokumenterte verify-peer-innstillingen i check_curl dekker den verifiseringen.
Bruk også den tiltenkte autentiserte ruten. En portsonde kan stå grønn mens driftskontoen mottar 407. Overlever hemmeligheten gjennom distribusjonens egnede mekanisme, og rapporter trinnet som faktisk feilet: en avvist tunnel krever en annen retting enn en uventet nettstedstatus.