Slik overvåker du serveroppetid: kontroller, verktøy og varsler

For å overvåke oppetiden til en server kjører du automatiske kontroller utenfra serveren (ping, TCP-port eller HTTP-forespørsler fra flere lokasjoner), samler serverens egne helsesignaler med en agent, og varsler bare når flere lokasjoner feiler på rad. Deretter registrerer du hvert avbrudd, slik at du kan beregne tilgjengelighet mot SLA-en hver måned.

Viktigste punkter

• Eksterne syntetiske kontroller svarer på «kommer brukerne frem?». Interne agenter svarer på «hvorfor er den nede?». Du trenger begge.
• Kontroller fra minst tre lokasjoner og varsle ved påfølgende feil, for å unngå falske alarmer fra én dårlig nettverksvei. Microsoft anbefaler minst fem testlokasjoner for tilgjengelighetstester i Azure.
• Test det brukerne bruker: en HTTPS-forespørsel som kontrollerer statuskode og sideinnhold slår en ping.
• 99,9 % tilgjengelighet tillater fortsatt omtrent 43,8 minutter nedetid i måneden. Vit hva målet ditt tillater før du setter terskler for varsling.
• Unnta avtalte vedlikeholdsvinduer konsekvent, og rapporter oppetid fra de samme dataene hver måned.

Hva er overvåking av serveroppetid?

Overvåking av serveroppetid er kontinuerlig kontroll av om en server og tjenestene på den er nåbare og svarer riktig. Den gir to ting: varsler når noe går ned, og en historikk du kan gjøre om til en tilgjengelighetsprosent.

Oppetid og tilgjengelighet henger sammen, men er ikke det samme. En server kan være slått på (høy oppetid) mens webtjenesten returnerer feil (lav tilgjengelighet). For de fleste virksomheter er det tilgjengeligheten til tjenesten, sett fra brukerne, som er tallet som betyr noe.

Hvor mye nedetid tillater hvert oppetidsmål?

Tilgjengelighet er (total tid − nedetid) ÷ total tid. Tabellen gjør vanlige mål om til tillatt nedetid, med en gjennomsnittlig måned på 730 timer.

Et stramt mål endrer hvordan du overvåker. Ved 99,99 % kan et kontrollintervall på fem minutter ikke engang oppdage alle brudd, så du trenger kontroller hvert minutt eller oftere og en vaktrespons målt i minutter. Kapittelet i Googles SRE-bok om å omfavne risiko forklarer hvorfor hver ekstra nier koster mer, og hvorfor målet bør følge forretningsbehovet.

Hvilke kontroller bør du kjøre?

Eksterne (syntetiske) kontroller

• ICMP-ping: viser at verten svarer på nettverket. Billig, men mange brannmurer blokkerer den, og en vert kan svare på ping mens applikasjonene er nede.
• TCP-portkontroller: bekrefter at en tjeneste lytter, for eksempel 443 for HTTPS, 3389 for RDP eller 5432 for PostgreSQL.
• HTTP(S)-kontroller: ber om en URL og kontrollerer statuskode, responstid og et stykke forventet innhold. Bruk et eget helseendepunkt som også tester databasetilkoblingen.
• Kontroll av TLS-sertifikater: varsle før et sertifikat utløper. Et utløpt sertifikat er et avbrudd for brukerne selv om serveren er frisk.
• DNS-kontroller: bekreft at navnet løses til riktig adresse.

Interne (agentbaserte) signaler

• Heartbeat: agenten rapporterer hvert minutt. Et manglende heartbeat betyr at verten eller agenten er nede.
• Teller for systemoppetid: viser uplanlagte omstarter. På Linux bruker du uptime eller last reboot. På Windows registrerer hendelses-ID 6008 i systemloggen en uventet nedstenging.
• Ressursmålinger: CPU, minne, diskplass og disklatens. Fulle disker og tomt minne er vanlige årsaker til «oppe, men virker ikke».
• Tilstand for tjenester og prosesser: kjører webserveren, databasen eller den planlagte jobben?

For Windows-verter lister veiledningen vår om hvordan du overvåker ytelsen på Windows Server tellerne som er verdt å samle inn.

Hvilke verktøy kan overvåke serveroppetid?

Valget betyr mindre enn oppsettet. Et selvhostet verktøy trenger også overvåking: hvis den eneste overvåkingsserveren står i samme rack som serverne den følger med på, tar et strømbrudd ut begge deler. Kjør minst én ekstern kontroll fra et annet nettverk eller en skytjeneste.

Slik setter du opp oppetidsvarsler uten falske alarmer

1. Bruk flere lokasjoner. Microsoft anbefaler minst fem testlokasjoner for tilgjengelighetstester i Azure og en varslingsterskel lik antall lokasjoner minus to, for eksempel tre som feiler av fem.
2. Krev påfølgende feil. Azures alternativ for nye forsøk rapporterer en feil først etter at tre påfølgende forsøk har feilet. Microsoft oppgir at omtrent 80 % av feilene forsvinner ved nytt forsøk.
3. Sett alvorlighetsgrad etter påvirkning. En kundeportal i produksjon varsler teknikeren på vakt. En testserver sender en sak.
4. Rut varsler til folk som kan handle, med eskalering hvis ingen kvitterer innen en fastsatt tid.
5. Demp planlagt vedlikehold i overvåkingsverktøyet i stedet for å ignorere varsler av vane.
6. Varsle også ved gjenoppretting, slik at teamet vet når hendelsen er over.

Googles SRE-veiledning om overvåking av distribuerte systemer legger til en nyttig regel: hvert varsel som vekker noen, skal være hastende, mulig å handle på og kreve et menneske. Alt annet hører hjemme i en sak eller et dashbord.

Slik rapporterer du oppetid mot en SLA

• Definer hva som regnes som nede, for eksempel «helseendepunktet feiler fra tre av fem lokasjoner i to påfølgende kontroller».
• Avtal hvilke vedlikeholdsvinduer som unntas, og registrer dem i verktøyet.
• Beregn månedlig tilgjengelighet fra kontrollresultatene, ikke fra hukommelse eller saksnotater.
• Før en avbruddslogg med start, slutt, årsak og løsning. Mønstre, som avbrudd etter hver patch-natt, viser hvor du bør investere.
• Sammenlign tallet ditt med det skyleverandøren forplikter seg til. For eksempel forplikter Amazon Compute SLA seg til 99,99 % månedlig oppetid for EC2 utrullet på tvers av flere tilgjengelighetssoner i en region, men bare 99,5 % for en enkelt EC2-instans. Applikasjonens tilgjengelighet kan aldri bli høyere enn det den svakeste avhengigheten leverer.

Overvåking forteller deg om avbrudd. Redundans forhindrer dem. Kjør kritiske arbeidsbelastninger på mer enn én server eller tilgjengelighetssone bak en lastbalanserer, slik at en enkelt feil ikke tar ned tjenesten. WorkBuster, en SaaS-plattform for rekruttering, kjører på EC2 bak en Application Load Balancer med MySQL RDS over flere AZ-er, en autoskaleringsgruppe og CloudWatch-dashbord og -alarmer. Kundecaset om WorkBuster viser hele oppsettet.

Slik hjelper Opsio

Opsio driver 24/7-overvåking og håndtering av hendelser for servere og skybaserte arbeidsbelastninger på AWS, Azure og Google Cloud. Vi setter opp kontroller, ruting av varsler og månedlige tilgjengelighetsrapporter, og teknikerne våre handler på varslene. Se sidene våre om skyovervåking og support, fjernovervåking av infrastruktur og observerbarhet med Prometheus og Grafana.

Ofte stilte spørsmål

Hvordan sjekker jeg hvor lenge en server har vært oppe?

På Linux kjører du uptime eller last reboot. På Windows åpner du fanen Ytelse i Oppgavebehandling, kjører systeminfo og leser «System Boot Time», eller sjekker systemloggen. Disse viser tid siden siste oppstart, ikke om tjenestene var tilgjengelige.

Hvor ofte bør oppetidskontroller kjøre?

Hvert minutt til hvert femte minutt for de fleste produksjonstjenester. Tilpass intervallet til målet ditt: ved 99,99 % har du bare omtrent 4,4 minutter nedetid i måneden, så et intervall på fem minutter er for tregt til å måle det.

Er ping nok til å overvåke serveroppetid?

Nei. Ping beviser bare at nettverksstacken svarer. Legg til en TCP- eller HTTPS-kontroll mot tjenesten brukerne er avhengige av, helst med kontroll av innhold, pluss agentbaserte kontroller på selve serveren.

Hva er en god oppetidsprosent for en server?

For forretningsapplikasjoner er 99,9 % et vanlig mål. Kundevendte tjenester sikter ofte mot 99,95 % eller høyere. Høyere mål krever redundans: AWS forplikter seg for eksempel til bare 99,5 % for en enkelt EC2-instans, men 99,99 % for EC2 fordelt over tilgjengelighetssoner.

Kan jeg overvåke oppetid gratis?

Ja. Verktøy med åpen kildekode som Prometheus med blackbox_exporter, Zabbix eller Nagios koster ingenting i lisens, men du betaler med hosting og vedlikeholdstid. Skyleverandørenes egne kontroller er rimelige for et lite antall endepunkter.

Les også

• What Is Cloud Monitoring
• Hva er sanntidsovervåking av servere og applikasjoner?
• Slik overvåker du ytelsen på Windows Server: verktøy og målinger