For oppetidsovervåking er det korte svaret: 2xx-svar betyr oppe, 5xx-svar betyr nede, og alt imellom avhenger av hva du forventer av den aktuelle URL-en. En 301 er greit hvis siden er flyttet med vilje, en 401 er greit på et API-endepunkt som krever en nøkkel, og en 404 på kassesiden din er et driftsavbrudd. Den riktige monitoren sjekker etter statuskoden du forventer, ikke bare etter «alt annet enn en feil».
Denne jukselappen går gjennom statuskodefamiliene sett fra et overvåkingsperspektiv: hva hver kode betyr, om den bør regnes som nede, og hvordan du setter opp sjekkene slik at de bare varsler om reelle problemer.
De fem familiene i korte trekk
SerieBetydningFor en monitor1xxInformasjon, forespørselen fortsetterSjelden sett; ikke et endelig svar2xxVellykketSom regel oppe3xxOmdirigering, se et annet stedOppe eller nede, avhengig av hensikten4xxKlientfeil, forespørselen var feilAvhenger av endepunktet5xxServerfeil, serveren feiletNede
Det første sifferet forteller hvem som er ansvarlig. 4xx betyr at serveren mener forespørselen var feil. 5xx betyr at serveren innrømmer at den feilet. For en monitor som sender den samme forespørselen hvert minutt, betyr en plutselig 4xx som regel at noe likevel er endret på serversiden: en side er fjernet, en tilgang er endret eller en brannmur har begynt å blokkere.
1xx: informasjon
Koder som 100 Continue, 101 Switching Protocols og 103 Early Hints er foreløpige svar. En klient ser dem før det endelige svaret, eller ikke i det hele tatt. En overvåkingssjekk venter på den endelige statuskoden, så du kan se bort fra denne familien. Hvis en sjekk noen gang ender på en 1xx, ble forbindelsen brutt midt i svaret, og det er en feil.
2xx: vellykket
KodeNavnMerknader for overvåking200OKStandardsvaret ved suksess201CreatedForventet etter en POST som oppretter noe202AcceptedForespørselen er satt i kø; arbeidet skjer senere204No ContentSuksess med tomt innhold; vanlig for DELETE og enkelte helsesjekker
En 200 er ingen garanti for at siden fungerer. Mange applikasjoner fanger opp sine egne feil og viser en feilside med status 200: «Database connection failed», en tom mal, en vedlikeholdsmelding. Legg til innholdsvalidering på viktige sjekker: forvent et ord eller et JSON-felt som bare dukker opp når siden virkelig fungerer. Med 204 finnes det ikke noe innhold å validere, så sjekk bare statuskoden.
3xx: omdirigeringer
KodeNavnTypisk bruk301Moved PermanentlyGammel URL til ny URL, HTTP til HTTPS302FoundMidlertidig omdirigering, ofte til en innloggingsside303See OtherOmdirigering etter en skjema-POST304Not ModifiedHurtigbufret kopi er fortsatt gyldig; bare etter betingede forespørsler307Temporary RedirectSom 302, men beholder metoden og innholdet308Permanent RedirectSom 301, men beholder metoden og innholdet
Omdirigeringer og monitorer
Overvåkingsverktøy håndterer omdirigeringer på en av to måter: enten følger de dem og rapporterer statusen til den endelige siden, eller så stopper de ved det første svaret og rapporterer 3xx-koden. Finn ut hva verktøyet ditt gjør for hver sjekk, for begge deler kan skjule problemer:
Hvis monitoren følger omdirigeringer, kan en side som plutselig sender deg til forsiden eller en innloggingsskjerm, likevel ende i en 200. Innholdsvalidering fanger opp dette: forsiden inneholder ikke ordene fra kassesiden din.
Hvis monitoren ikke følger omdirigeringer, setter du forventet status til omdirigeringskoden og sjekker den endelige URL-en med en egen monitor.
Det tryggeste er å overvåke den endelige URL-en direkte. Hvis northwind.shop omdirigerer til www.northwind.shop, overvåker du www-versjonen, og legger bare til en egen sjekk for omdirigeringen hvis den betyr noe for deg, for eksempel for gamle kampanjelenker. En omdirigeringsløkke, der to URL-er peker på hverandre, viser seg som et tidsavbrudd eller en «too many redirects»-feil og bør alltid regnes som nede.
4xx: klientfeil
KodeNavnNede?400Bad RequestSom regel en ødelagt sjekk eller et endret API401UnauthorizedForventet på beskyttede endepunkter uten påloggingsdetaljer403ForbiddenForventet for blokkerte stier; et problem hvis den dukker opp plutselig404Not FoundNede for enhver URL som skal finnes405Method Not AllowedSjekken bruker feil metode, eller ruten er endret408Request TimeoutServeren ga opp å vente på forespørselen410GoneFjernet med vilje429Too Many RequestsBegrenset av rate limiting
401 og 403 på beskyttede endepunkter
Noen endepunkter skal avvise anonyme forespørsler. Et admin-API som returnerer 401 uten token, fungerer som det skal. Du kan overvåke det på to måter:
Forvent avvisningen. Sett forventet status til 401. Sjekken bekrefter at serveren er oppe og at autentiseringslaget er på plass. Hvis den noen gang returnerer 200 uten påloggingsdetaljer, er det et sikkerhetsproblem som fortjener et varsel.
Send påloggingsdetaljer. Legg til en header med API-nøkkel eller basic auth i sjekken, og forvent 200 pluss riktig innhold. Dette tester hele veien, også databasen bak endepunktet.
Det andre alternativet tester mer, så bruk det for alt kundene er avhengige av. Bruk en egen skrivebeskyttet nøkkel til overvåkingen, aldri en personlig nøkkel eller en admin-nøkkel.
En plutselig 403 på en offentlig side er en annen sak. Det betyr som regel at en brannmur, en sikkerhetsplugin eller en CDN-regel har begynt å blokkere forespørsler, noen ganger bare fra bestemte land eller IP-områder. Hvis én overvåkingslokasjon får 403 og en annen får 200, er en geo- eller IP-regel den sannsynlige årsaken.
429 Too Many Requests
En 429 betyr at serveren begrenser hvor mange forespørsler klienten får sende. For overvåking betyr det én av to ting: grensene dine er for strenge for normal trafikk, eller monitoren selv treffer en grense fordi den deler adresse med andre klienter. Sjekk Retry-After-headeren og oppsettet for rate limiting. Hvis ekte brukere får 429 ved normal belastning, bør du behandle det som et driftsavbrudd.
5xx: serverfeil
KodeNavnHva den som regel betyr500Internal Server ErrorApplikasjonen krasjet på denne forespørselen501Not ImplementedServeren støtter ikke metoden502Bad GatewayProxyen fikk et ugyldig svar fra applikasjonen bak seg503Service UnavailableOverbelastet, i vedlikehold eller ingen frisk backend504Gateway TimeoutProxyen ventet for lenge på applikasjonen
Behandle enhver 5xx som nede. Kodene skiller seg i hvor du bør se først: en 500 peker mot applikasjonsloggene, en 502 mot en applikasjonsprosess som har krasjet eller starter på nytt, en 504 mot trege spørringer eller eksterne kall, og en 503 mot kapasitet eller vedlikehold. Guiden vår om feilen 503 Service Unavailable går grundig gjennom årsakene og løsningene.
Noen CDN-er og proxyer bruker egne koder i 5xx-serien, for eksempel 520 til 530, for problemer mellom CDN-et og opprinnelsesserveren din. De er ikke en del av HTTP-standarden, men for en besøkende betyr de det samme: nettstedet er nede.
Ikke alle feil har en statuskode
Noen av de vanligste driftsavbruddene gir aldri noen statuskode i det hele tatt:
DNS-feil: domenet slås ikke opp, for eksempel etter en utløpt registrering eller en slettet post.
Tilkobling avvist eller tilbakestilt: ingenting lytter på porten, eller en brannmur dropper forbindelsen.
TLS-feil: et utløpt eller feil sertifikat stopper forespørselen før noe HTTP skjer.
Tidsavbrudd: serveren godtar forbindelsen, men svarer aldri i tide.
En god monitor rapporterer disse som feil med den faktiske feilmeldingen, slik at varselet sier «sertifikatet er utløpt» og ikke bare «nede». Det er også derfor det lønner seg å legge til sjekker for utløp av sertifikat og domene ved siden av HTTP-monitorene dine.
Slik setter du forventet status i en monitor
For hver URL du overvåker, bestemmer du hvordan et friskt svar ser ut, og skriver det ned som konfigurasjonen for sjekken:
Velg URL-en som betyr noe. Den endelige URL-en etter omdirigeringer, ikke kortlenken.
Angi metoden. GET for sider, og det endepunktet krever for API-er.
Angi forventet status. Som regel 200. Bruk 201, 204, 301 eller 401 når det er det tiltenkte svaret.
Legg til påloggingsdetaljer ved behov. Headere eller basic auth for beskyttede endepunkter.
Legg til innholdsvalidering. Et ord på siden eller et felt i JSON-svaret som bare dukker opp når alt fungerer.
Angi et tidsavbrudd. Et svar som tar 30 sekunder, er en feil for en besøkende selv om det ender i 200.
Slik ser det ut for et health-endepunkt på lumenanalytics.io, først testet manuelt med curl:
curl -sS -o /dev/null -w «%{http_code} %{time_total}s\n» \
-H «Authorization: Bearer $MONITOR_TOKEN» \
https://api.lumenanalytics.io/v1/health
Hvis det skriver ut 200 og en rimelig tid, legger du den samme metoden, headeren og forventede statusen inn i monitoren. I Uptimecheck godtar oppetidsmonitorer og API-monitorer egen metode, headere (for eksempel basic auth eller et bearer-token), innhold, nøkkelord- og JSON-sjekker, og sjekken feiler når statuskoden eller svaret ikke er det du forventer. Vil du lese mer om hvordan du utformer selve endepunktet, kan du se slik bygger du et health check-endepunkt, og sjekklisten for API-overvåking for hvilke endepunkter du bør dekke.
Rask oversikt: er det nede?
Nede: enhver 5xx, en 404 på en URL som skal finnes, tidsavbrudd, DNS- og TLS-feil, avviste tilkoblinger.
Sannsynligvis nede: en plutselig 403 eller 429 på en offentlig side, en 400 eller 405 på en sjekk som pleide å gå gjennom.
Oppe: statuskoden du har satt som forventet, med innholdet du validerer for, innen rimelig tid.
Oppsummering
Statuskoder er det første en monitor ser på, og den raskeste måten å finne ut hvor et problem befinner seg. 5xx betyr at serveren feilet, 4xx betyr at noe er endret i hva serveren godtar, og 3xx krever en beslutning om hvor sjekken skal ende. Sett opp hver monitor med statusen den skal få, valider innholdet på viktige sider og la varselet inneholde koden, slik at den som tar det, vet hvor hen skal begynne.
Uptimecheck sjekker nettstedene og API-ene dine så ofte som hvert minutt og varsler deg når statuskoden eller svaret ikke er det du forventer. Prøv gratis i 14 dager, uten kredittkort.