Zo Bepaal je Direct de Server-Uptime op Linux en Windows
Als je infrastructuur beheert, is de eerste stap in het beheersen van hoe je server-uptime berekent simpelweg ontdekken hoe lang een machine al draait. Ik leerde dit op de harde manier in 2017 toen de claim van “100% uptime” van een klant instortte nadat ik ontdekte dat hun primaire webserver stilletjes opnieuw was opgestart tijdens een kernel-panic de vorige maand.
De snelste methode op Linux is het ingebouwde uptime-commando. Het toont de huidige tijd, sessieduur en load averages. Maar die uitvoer alleen bevestigt niet dat de server verkeer serveerde. Voor forensisch detail combineer ik het met last reboot, dat het wtmp-logboek leest en eerdere opstarttijdstempels van maanden terug toont.
Linux: Van /proc/uptime tot systemd
Voor scriptmatige controles retourneert cat /proc/uptime twee getallen: seconden sinds opstart en seconden inactief. Ik gebruik het eerste veld in Bash-lussen om de leeftijd te berekenen zonder menselijk leesbare tekst te parseren. Op systemd-hosts levert systemd-analyze uptime een nette regel “Bootup is 42d 3h 12min ago” op die perfect is voor rapporten.
Toen ik last reboot voor het eerst probeerde op een zwaar gevirtualiseerde host, maakte ik de fout om de hypervisorlaag te negeren. Een live-migratie kan de gast pauzeren, en sommige orchestration-platforms resetten de uptime-teller. Dat is een randgeval dat de meeste tutorials overslaan, maar het corrumpeert direct je basislijn als je aanneemt dat de OS-klok gelijk is aan de realiteit.
Nog een Linux-eigenaardigheid: wtmp roteert. Nadat logrotate oude logs comprimeert, kan last reboot alleen recente vermeldingen tonen. Als je historisch bewijs nodig hebt voor een kwartaal-SLA, archiveer wtmp dan of gebruik een monitoring-agent die opnames naar een externe time-series-database registreert.
Windows: PowerShell en WMI
Op Windows moet je het veld “Up time” in Taakbeheer niet alleen vertrouwen—het rondt vreemd af. Open PowerShell en voer Get-Uptime uit. Het retourneert een TimeSpan-object; (Get-Uptime).TotalDays geeft een precies decimaal getal dat ik in een CSV kan pipen. In legacy-omgevingen zonder PowerShell 6+ gebruik ik systeminfo | find 'System Boot Time' (met de locatie-kanttekening die ik eerder noemde).
Voor een diepere inventaris haalt Get-CimInstance Win32_OperatingSystem | Select LastBootUpTime de exacte datetime uit WMI. Ik heb ooit een vals “0 dagen uptime”-alarm gedebugd dat werd veroorzaakt door WMI-repository-corruptie na een geforceerde stroomuitval. De oplossing was het herbouwen van WMI, niet het herstarten van de server—een herinnering dat je meetinstrument het falende onderdeel kan zijn.
Cloud- en Virtualisatie-Kanttekeningen
In AWS of Azure kan de interne uptime van de instantie verschillen van de “instance launch time” in de console vanwege stop/start-cycli die de schijf behouden maar het RAM resetten. Het ding dat niemand je vertelt over server-uptime is dat het uptime-commando kernel-continuïteit meet, niet de beschikbaarheid van je applicatie. Een server kan “up” zijn terwijl je webservice 30 minuten dood is—toch toont de metriek 100%.
Dat onderscheid is waarom ik OS-commando’s altijd aanvul met synthetische health-checks. Alleen dan kun je de vraag “Hoe bepaal je server-uptime?” eerlijk beantwoorden met gegevens die aansluiten op de gebruikerservaring.
Ik raad ook aan om de opstarttijd vast te leggen via de BMC- of hypervisor-API voor fysieke hosts. In één datacenter veroorzaakte een voedingstoring een harde reset die het OS registreerde als een “schone afsluiting” vanwege een buggy ACPI-handler. Alleen het out-of-band-beheerlogboek onthulde de waarheid. Het stapelen van gegevensbronnen is wat een echte uptime-audit onderscheidt van een gok.
Ruwe Opstarttijd Omzetten in een Beschikbaarheidspercentage
Zodra je de verstreken runtime hebt, is de wiskundige kern van hoe je server-uptime berekent eenvoudig: deel uptime door de totale verstreken periode en vermenigvuldig met 100. De gangbare formule ((totale tijd − downtime)/totale tijd × 100) is correct, maar concurrenten tonen zelden de rommelige real-world-inputs die het resultaat met hele procentpunten veranderen.
Stel dat je Linux-server 44 dagen uptime toont. Als het meetvenster 45 dagen is, was de downtime 1 dag. Beschikbaarheid = (44/45)*100 = 97,78%. Ik heb ooit 97,8% gerapporteerd aan een manager die 99,9% verwachtte; de kloof was een enkele nachtelijke backup-reboot die we vergaten uit te sluiten. Dat verhaal benadrukt waarom gepland onderhoud gescheiden moet worden voordat je cijfers publiceert.
Voor snelle conversies laat onze Server Uptime Calculator je ruwe dagen invoeren en automatisch het percentage en SLA-niveau uitvoeren. Maar het zelf begrijpen van de wiskunde voorkomt dat je een tool vertrouwt die mogelijk schrikkelseconden of gedeeltelijke periodes verkeerd behandelt.
Volgens de NIST-glossary is beschikbaarheid de mate waarin een systeem operationeel is wanneer vereist. Die definitie sluit impliciet periodes uit waarin het systeem niet bedoeld was om gebruikers te bedienen—nog een reden waarom ruwe uptime context nodig heeft voordat het een KPI wordt.
Waarom het Bemonsteringsinterval het Getal Verandert
Als je monitor elke 5 minuten peilt, kan een storing van 2 minuten nooit worden geregistreerd. Ik heb uptime-rapporten zien verbeteren na het verlengen van het poll-interval—niet omdat het systeem genas, maar omdat de meting blind werd. Voor geloofwaardige berekeningen stel je de bemonsteringsfrequentie fijner in dan je kleinste acceptabele storing, doorgaans 30 seconden of minder voor 99,99%-doelen.
Schrikkelseconden en Kalender-Eigenaardigheden
Jaarlijkse berekeningen gaan uit van 8.760 uur, maar schrikkeljaren hebben 8.784. Als je SLA op een strikt 365-dagencontract draait, voegt een schrikkeldag 24 uur “toegestane” tijd toe die het downtime-percentage kan verdunnen. De meeste mensen realiseren dit pas als ze februari-facturen reconciliëren. Ik vermeld altijd expliciet de referentieperiode: “afgelopen 365 dagen” versus “kalenderjaar 2024”.
Een andere subtiele bias verschijnt wanneer je over een rollend venster van 30 dagen berekent versus een kalendermaand. Februari heeft 28 dagen; een rollend venster van 30 dagen drijft over maandgrenzen en kan schrikkeldag-aanpassingen dubbel tellen. Ik standaardiseer op vaste kalenderintervallen voor externe rapporten en gebruik rollende vensters alleen voor interne trenddetectie.
Wat 90%, 95% en 99,99% Uptime Echt Betekenen in Reële Downtime
Zoekopdrachten zoals “Wat betekent 90% uptime?” of “Wat is 95% uptime in een jaar?” onthullen dat mensen in percentages denken maar in uren leven. Laten we vertalen met concrete getallen. Een 90% uptime-doel betekent dat de service 10% van het jaar down kan zijn. Met 8.760 uur per jaar is dat 876 uur—ongeveer 36,5 volledige dagen downtime. Dat is catastrofaal voor e-commerce maar mogelijk acceptabel voor een interne testopstelling.
Een 95% uptime-jaar staat 5% downtime toe: 438 uur, of 18,25 dagen. Ik heb kleine SaaS-startups per ongeluk 95% SLA’s zien tekenen omdat het verkoopteam niet besefte dat dit bijna drie weken potentiële uitval betekende. De wiskunde is meedogenloos, en klanten merken het.
Aan de hoge kant: “Hoe lang is 99,99% uptime?” Het antwoord: 0,01% downtime is gelijk aan 52,56 minuten per jaar (8.760 × 0,0001 = 0,876 uur). Dat is ruwweg één onderhoudsvenster. Hieronder staat de spiekbrief-tabel die ik in onze NOC gepind houd, uitgebreid met maandelijkse equivalenten.
- 90% uptime: 876 uur/jaar down (36,5 dagen) = 73 uur/maand
- 95% uptime: 438 uur/jaar down (18,25 dagen) = 36,5 uur/maand
- 99% uptime: 87,6 uur/jaar down (3,65 dagen) = 7,3 uur/maand
- 99,9% uptime: 8,76 uur/jaar down (0,365 dagen) = 43,8 minuten/maand
- 99,99% uptime: 0,876 uur/jaar down (52,6 minuten) = 4,38 minuten/maand
- 99,999% uptime: 5,26 minuten/jaar down = 26 seconden/maand
De meeste mensen realiseren zich niet dat de overstap van 99,9% naar 99,99% de jaarlijkse downtime met bijna 8 volledige uren vermindert—maar vereist een radicaal andere architectuur (redundante failover, niet alleen gecontroleerde reboots).
Industrieverwachtingen per Tier
Een 90% of 95% tier is gebruikelijk voor niet-kritieke interne tools waar gebruikers kunnen wachten. 99% is het minimum voor veel legacy-bedrijfsapps. 99,9% (de “drie negens”) is de basislijn die de meeste cloudproviders adverteren voor objectopslag. 99,99% (“vier negens”) wordt verwacht voor betaalgateways, en 99,999% (“vijf negens”) is gereserveerd voor carrier-grade telecom—vaak bereikt via geografische redundantie die meer kost dan de servers zelf.
Wanneer een manager vraagt “Wat is 95% uptime in een jaar?” laat ik hen het 18-dagen-cijfer zien en vraag ik of ze hun winkelpui een halve maand donker zouden accepteren. Dat herkadert het abstracte percentage in een bedrijfsrisico.
Om 99,999% in perspectief te plaatsen: het bereiken van vijf negens vereist doorgaans het elimineren van single points of failure op elke laag: stroom, netwerk, compute en software. De infrastructuurkosten kunnen 5–10× hoger liggen dan bij een drie-negens-opstelling. Ik heb geadviseerd voor bedrijven die 99,999% nastreefden omdat een concurrent dat in hun marketing zei, om er vervolgens achter te komen dat hun gebruikers het verschil boven 99,9% niet zouden merken. Stem de tier af op de werkelijke gebruikerstolerantie.
Het Uitsluiten van Gepland Onderhoud: De Kloof in de Meeste SLA-wiskunde
Een ontbrekend stuk in artikelen van concurrenten is hoe om te gaan met geplande patching. Als je servers wekelijks reboot voor beveiligingsupdates, is dat ~4 minuten per reboot × 52 = 208 minuten “downtime” die niet tegen beschikbaarheid zou mogen tellen als je contract gepland werk uitsluit. Het proces voor het berekenen van server-uptime moet het meetvenster definiëren en goedgekeurd onderhoud aftrekken.
Het Schrijven van een Uitsluitingsbeleid
In de praktijk tag ik onderhoudsperioden in ons monitoringtool (we gebruiken Prometheus met silence-regels). Dan wordt de beschikbaarheidsformule: (Totale Periode − Ongeplande Downtime − Uitgesloten Onderhoud) / (Totale Periode − Uitgesloten Onderhoud) × 100. Deze genuanceerde afweging voorkomt dat teams worden gestraft voor noodzakelijk werk, terwijl de metriek eerlijk blijft.
Te veel uitsluiten maakt je SLA betekenisloos; niets uitsluiten geeft een kunstmatig laag cijfer dat valse escalaties veroorzaakt. Een gebalanceerd beleid dat ik heb gebruikt: vensters uitsluiten met >24u voorafgaande kennisgeving, e-mailbevestiging van de klant en succesvolle gezondheidsverificatie na de check.
Real-World Auditverhaal
Toen ik een managed service provider auditte, sloten ze 12% van het jaar uit als “onderhoud” zonder klantgoedkeuring. Dat is een vertrouwensschending. Nadat we die uren herclassificeerden als ongepland, daalde hun 99,95%-claim naar 98,8%—een verschil dat SLA-creditrefundes voor de klant vrijmaakte. Documenteer altijd het uitsluitingsbeleid in de master service agreement, niet in een tribal-knowledge-spreadsheet.
Als je de native SLA van een cloudprovider gebruikt, onthoud dan dat zij beschikbaarheid vanaf hun kant berekenen, niet vanuit jouw synthetische checks. Ik heb discrepanties gezien waar AWS 99,99% rapporteerde voor EC2, maar onze app-niveau-monitoring 99,95% toonde vanwege een verkeerd geconfigureerde security group die inkomend verkeer blokkeerde. De provider weigerde credits omdat hun metriek zei “instance draait”. Je berekeningsmethode moet de laag weerspiegelen die jij beheert.
Uptime Berekenen over een Vloot van Servers
Single-server-wiskunde is triviaal; vloten zijn dat niet. Als je 10 webnodes achter een load balancer draait, laat één dode node de service niet vallen. Dus hoe bereken je de totale uptime? Het naïeve gemiddelde van elk node-percentage is fout omdat het verkeersgewicht en het redundantiemodel negeert.
Active-Active vs Active-Passive
In een active-active-cluster dienen alle nodes, dus het verliezen van één vermindert capaciteit maar niet beschikbaarheid als de LB belasting afwerpt. In active-passive moet een mislukte primaire failoveren; de failover-tijd telt als downtime tenzij je sub-seconde health checks hebt. Ik heb een “redundant” paar 100% node-uptime zien rapporteren terwijl de service 90 seconden 503-fouten ervoer tijdens VIP-migratie—precies de kloof die SLA-rapporten verpest.
De Verkeersgewogen Gebruikersminuten-Methode
Mijn voorkeursmethode voor aggregatie: bereken “verloren gebruikersminuten” = som over elke node van (downtime × verkeersfractie). Als node A 50% van het verkeer neemt en 2 uur down is, is de effectieve downtime-bijdrage 1 uur. Dit stemt de wiskunde af op gebruikersimpact, waar contracten daadwerkelijk om geven.
Voor een realistisch voorbeeld: een vloot van 5 nodes, elk met 99,9% uptime onafhankelijk, verkeer gelijk verdeeld. Kans dat alle vijf up zijn = 0,999^5 = 0,995, dus vlootbeschikbaarheid ~99,5%. Dat is lager dan het cijfer van elke individuele node—een contra-intuïtief inzicht dat beginners missen. Redundantie verbetert veerkracht maar niet het simpele gemiddelde.
Multi-Regio Overwegingen
Regio’s toevoegen verandert de formule opnieuw. Als us-east down is maar eu-west up, en DNS routeert 100% van de gebruikers binnen 60 seconden naar de gezonde regio, is de wereldwijde downtime slechts dat venster van 60 seconden. Echter, als je datalaag niet gerepliceerd is, kan de app “up” zijn maar nutteloos. Ik behandel regionale berekening als een hiërarchie: node → service → regio → wereldwijd, elk gewogen op live gebruikersvolume per minuut gesampled.
Monitoringtools zoals Datadog of Grafana nemen per-host uptime op en laten je een service-level objective (SLO) definiëren die automatisch weegt op instantie. Maar je moet de health check kalibreren: een flapperende check creëert valse downtime-gebeurtenissen die de berekening verpesten, een probleem dat we hierna behandelen.
Voor degenen die van kansrekening houden: de vlootbeschikbaarheidsformule bij onafhankelijke storingen is 1 − (1−p)^n voor identieke nodes achter een perfecte load balancer zonder capaciteitsverlies. Maar onafhankelijkheid is in de praktijk een leugen—gecorreleerde storingen van een gedeelde switch of een slechte deploy halen meerdere nodes tegelijk naar beneden. Ik kort het theoretische cijfer af met een “correlatiefactor” op basis van eerdere incidenten, meestal 0,2–0,5%. Die eerlijke schatting is beter dan doen alsof de wiskunde puur is.
Veelvoorkomende Fouten Die Je Uptime-Cijfers Scheef Trekken
Zelfs met correcte commando’s gaat meting mis. Fout 1: ping gebruiken als uptime-proxy. ICMP kan geblokkeerd zijn terwijl HTTP werkt, of vice versa. Fout 2: Tijdzoneverschuivingen tijdens DST-wijziging dubbeltellen of overslaan een uur in jaarlijkse totalen tenzij je standaardiseert op UTC. Fout 3: Geen rekening houden met container-restarts—een Kubernetes-pod-restart reboott de node niet, maar je app-uptime reset wel.
Het Flapperende Check-Probleem
Een health check die elke 10 seconden togglet, genereert duizenden downtime-incidenten. Ik heb ooit een dashboard geërfd waar een TLS-certificaatwaarschuwing de “up”-bit omdraaide; de maandelijkse uptime toonde 82% ondanks dat gebruikers het nooit merkten. We voegden een 3-sample-bevestigingsregel toe en het echte cijfer sprong naar 99,97%. Daarom moeten ruwe gebeurtenistellingen worden gedebounced vóór berekening.
Een ander randgeval: virtuele machines die worden opgeschort in plaats van afgesloten. De gast-OS-klok pauzeert; bij hervatting kan uptime een gat of negatieve drift tonen als NTP het corrigeert. Controleer altijd kruislings met hypervisor-logs. De gevaarlijkste misvatting is het gelijkstellen van uptime aan betrouwbaarheid. Een server die 400 dagen up is maar 3 van die dagen 500-fouten geeft, is niet “beschikbaar” volgens de NIST-definitie.
Logrotatie kan ook je bewijs wissen. Op een server waar wtmp maandelijks wordt getrunceerd, kun je een 40-dagen-uptimeclaim achteraf niet bewijzen. Stuur boot-gebeurtenissen vanaf dag één door naar een centrale syslog of metriekopslag—niet pas nadat het SLA-geschil op je bureau ligt.
Permissies zijn een andere stille moordenaar. Een niet‑geprivilegieerde monitoringagent kan mogelijk niet /var/log/wtmp lezen, wat leidt tot een lege rebootgeschiedenis en in sommige dashboards standaard resulteert in “uptime onbekend = 100%”. Ik test de agent altijd als de serviceaccount, niet als root, om te zien wat hij daadwerkelijk verzamelt. De kloof tussen het perspectief van root en dat van de agent is waar onjuiste uptimerapporten ontstaan.
Een in de praktijk geteste checklist voor het rapporteren van serveruptime
Om dit bruikbaar te maken, volgt hier het exacte raamwerk dat ik gebruik bij het opstellen van een maandelijks uptimerapport voor belanghebbenden. Het combineert de meetcommando’s met de wiskunde en de bovenstaande uitsluitingslogica.
- Stap 1: Verzamel ruwe opstarttijden via
Get-Uptime(Windows) oflast reboot(Linux) op alle hosts; archiveer naar een centrale opslag. - Stap 2: Raadpleeg de monitoringgeschiedenis (Prometheus/Datadog) om ongeplande uitvalintervallen op serviceniveau te identificeren, niet alleen op OS‑niveau.
- Stap 3: Definieer en trek geplande onderhoudsvensters af die met schriftelijke goedkeuring en voorafgaande kennisgeving zijn uitgesloten.
- Stap 4: Bereken de beschikbaarheid per host met (venster − uitvaltijd)/venster ×100, in de UTC‑referentieperiode.
- Stap 5: Agregeer vlootcijfers via verkeersgewogen verloren gebruikersminuten, niet naïeve gemiddelden.
- Stap 6: Koppel het uiteindelijke percentage aan de SLA‑spiekbrief (90/95/99/99.9/99.99) en rapporteer minuten uitval, niet alleen het percentage.
Beslismatrix: Welke berekeningsmethode past bij uw scenario
Gebruik deze matrix om zonder overdenken de juiste aanpak te kiezen:
- Enkele server, intern hulpmiddel: OS‑uptimecommando + eenvoudige formule. Sluit onderhoud uit als het beleid dit voorschrijft.
- Klantgerichte enkele regio: Synthetische controles op serviceniveau + gewogen uitvaltijd; rapporteer tegen de 99,9%‑tier.
- Multi‑node actief‑actief: Verkeersgewogen gebruikersminuten; negeer reboots van één node als de load balancer gezond is.
- Wereldwijde service met meerdere regio’s: Hiërarchische aggregatie met live gebruikersroutering; streef naar 99,99% met DNS‑failover.
- Compliance‑gebonden workload: Extern auditlogboek van opstartmomenten + NIST‑conforme beschikbaarheidsdefinitie; geen stille uitsluitingen.
Door dit proces te volgen, veranderden onze vage “we zijn stabiel”‑updates in board‑klare metrieken. Het bracht ook aan het licht dat onze claim van 99,95% eigenlijk 99,92% was zodra het correct gewogen werd—een klein maar materieel verschil voor restitutieberekeningen.
Nog een tip: automatiseer de checklist met een script dat op de eerste van elke maand draait, de commando’s uitvoert, de monitoring‑API raadpleegt en een Markdown‑rapport genereert. Ik heb een Python‑job die precies dit doet; het kostte een dag om te schrijven en heeft tientallen uren handmatig SSH‑geschuif bespaard. Het script volgt nog steeds de zes bovenstaande stappen—automatisering moet discipline vastleggen, niet omzeilen.
Onthoud: hoe u serveruptime berekent is niet alleen rekenkunde; het is een discipline van definiëren wat “up” betekent voor uw gebruikers. Begin met de OS‑commando’s, verfijn met servicecontroles en sluit gepland werk eerlijk uit. Dat is het praktijkpad van ruwe shell‑output naar betrouwbare SLA.