Skip to main content

Voor kwaliteitsborging is een combinatie van proactieve maatregelen en efficiënte reactieve protocollen vereist. Met de juiste balans kunt u gebruikers uitstekende service en functionaliteit bieden op een server die het hele jaar door beschikbaar is. De enige manier om dat evenwicht te bereiken, is door de meest relevante statistieken voor servermonitoring te identificeren. 

Maar welke zouden dat kunnen zijn? Dat hangt af van uw gewenste kenmerken, waaronder de kenmerken die worden beschreven in het Kwaliteitsvolwassenheidsmodel, en van uw monitoringdoelstellingen. Toch zijn er enkele statistieken voor gezondheid en prestaties die QA-engineers altijd in de gaten moeten houden, wat er ook gebeurt. 

Door vanaf het begin de ideale statistieken voor servermonitoring te selecteren, kunt u een prestatienulmeting ontwikkelen die u als referentie kunt gebruiken wanneer er onvermijdelijk problemen met de gezondheid en prestaties ontstaan. 

Want more from The CTO Club?

Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.

Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at anytime.

In deze korte handleiding bekijken we waarom u deze belangrijke statistieken moet bijhouden. Bovendien krijgt u aanvullende inzichten in hun relevantie en hoe u ze kunt bijhouden. 

1. CPU-gebruik

Een van de belangrijkste redenen voor servermonitoring is het bewaken van de gezondheid van de infrastructuur en de basale serverprestaties. Een cruciaal onderdeel daarvan is de proactieve diagnose en beperking van mogelijke prestatieproblemen. Het meten van CPU- en schijfgebruik staat centraal in deze inspanningen. Daarom is CPU-gebruik een van de meest fundamentele en meest gemonitorde prestatiestatistieken

Deze statistiek wordt beschouwd als “hostgebaseerd,” omdat deze bijhoudt in hoeverre een afzonderlijke machine kan presteren en stabiel kan blijven. Dat gezegd hebbende, omvat het monitoren van CPU-gebruik een combinatie van passieve en actieve monitoring. Die laatste is vooral nuttig voor gecontroleerde belastingstests, terwijl de eerste metingen op het doel verzamelt tijdens echt verkeer. 

CPU-gebruik meten 

Voordat u begint, moet u: 

  1. De specifieke schijven selecteren die u wilt monitoren. 
  2. Bepalen waar die schijven zich bevinden. 
  3. Ervoor zorgen dat uw gegevensverzamelaar toegang heeft tot de processen van uw computer. 

Zodra u dat allemaal hebt ingesteld, moet u de meetfrequentie bepalen waarmee u deze statistieken wilt bijhouden. U kunt het CPU-gebruik bijvoorbeeld elke 30 seconden of elke minuut meten. 

Er zijn verschillende manieren om CPU-gebruik bij te houden, bijvoorbeeld door Taakbeheer te gebruiken of een opdracht zoals wmic CPU get load percentage voor Windows-systemen. Wanneer u echter een overzicht van uw server wilt krijgen, kunt u deze gegevens het beste op een dashboard weergeven. 

Onthoud: CPU-prestaties worden beïnvloed door hardwarecondities, zoals de CPU-temperatuur en de ventilatorsnelheid. Mogelijk wilt u deze factoren naast het gebruik (weergegeven als percentage) in deze twee toestanden monitoren, waarbij inactiviteit wordt genegeerd. 

Twee belangrijke zaken die u nauwlettend wilt monitoren zijn bevoorrechte tijd en gebruikerstijd, aangezien de som van deze twee processortijd oplevert. Ze worden als volgt gedefinieerd:

  • Bevoorrechte tijd: Percentage van de tijd die processors gebruiken om processen uit te voeren die niet door gebruikers worden gestart (d.w.z. kernelprocessen) 
  • Gebruikerstijd: Percentage van de tijd die processors gebruiken om gebruikersprocessen uit te voeren (bijv. opdrachtregelomgeving, e-mailserver, compiler) 
  • Processortijd: Totale hoeveelheid tijd waarin de CPU bezig was 

Houd er rekening mee dat het overschrijden van 100% niet altijd betekent dat een systeem overbelast is. Als u bijvoorbeeld een multiprocessorsysteem hebt, betekent dit alleen dat de som van de twee of meer CPU's groter is dan 100% (bijv. 50% en 60%). Houd hun individuele prestaties in de gaten om de gezondheid van het systeem te handhaven. 

Naast CPU- en schijfgebruik worden wachttijden ook als essentieel beschouwd bij het monitoren van de gezondheid en prestaties van de infrastructuur. 

Get regular tech leadership wisdom for delivering better software and systems.

Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form

Wachttijden 

Wachttijden geven inzicht in hoe efficiënt taken worden uitgevoerd en waarschuwen u voor mogelijke knelpunten. Maar alleen de wachttijden kennen, helpt u niet verder. U moet aanvullend onderzoek doen om het exacte prestatieprobleem vast te stellen. 

Hoge wachttijden zijn in korte pieken geen probleem, omdat er mogelijk intensieve taken worden uitgevoerd, maar alles wat verder gaat, is doorgaans reden tot zorg. 

2. Serverbeschikbaarheid 

Uw server is nutteloos als deze niet beschikbaar is voor uw gebruikers. Daarom is het monitoren van de serverbeschikbaarheid niet onderhandelbaar. Zodra de beschikbaarheid van uw server onder 99.999% (de standaard die bekendstaat als de “vijf negens”) komt, hebt u een ernstig probleem. 

Gebruik de onderstaande formules om begrijpelijke en bruikbare inzichten uit uw monitoringinspanningen te halen. 

Serverbeschikbaarheid meten

Hier zijn enkele kernbegrippen die u moet kennen bij het monitoren van de serverbeschikbaarheid: 

  • Beschikbaarheid: De hoeveelheid tijd dat je service of applicatie actief en beschikbaar is voor gebruikers. Formule: (Totale tijd - Uitvaltijd)/Totale tijd 
  • Gemiddelde tijd tussen storingen (MTBF): De gemiddelde tijd tussen incidenten met uitvaltijd. Formule: (Totale tijd - Uitvaltijd)/Aantal incidenten met uitvaltijd
  • Gemiddelde tijd tot oplossing (MTTR): De gemiddelde hoeveelheid tijd die nodig is om een storing op te lossen. Formule: Totale uitvaltijd/Aantal incidenten met uitvaltijd 
  • Gemiddelde tijd tot erkenning (MTTA): De gemiddelde hoeveelheid tijd die nodig is om een huidige storing te erkennen. Formule: Totale tijd tot erkenning/Aantal incidenten met uitvaltijd 

Al deze meetwaarden helpen bij het ontwikkelen van een totaalbeeld van de betrouwbaarheid van je infrastructuur en de reactiesnelheid van je team. 

Een gezonde MTTR en MTTA zijn bijvoorbeeld goed. Maar als je ook een hoge MTBF hebt, moet je de onderliggende oorzaken van de uitvaltijd van je server verder onderzoeken. Anders loopt het bedrijf nog steeds risico op aanzienlijke financiële verliezen en beschadigd gebruikersvertrouwen. 

Een screenshot van een Grafana-dashboard, een bekende tool voor het bijhouden van belangrijke meetwaarden voor servermonitoring.
Je kunt een servermonitoringtool gebruiken om het bijhouden van meetwaarden eenvoudiger te maken.

Uiteindelijk moet je streven naar de “vijf negens”, waarbij de uitvaltijd wordt beperkt tot maximaal ongeveer vijf minuten per jaar. Grafana- en Prometheus-servermonitoringsoftware worden beide vaak aanbevolen als gebruiksvriendelijke, gemakkelijk toegankelijke tools voor dit aspect van prestatiemonitoring.

3. Transacties (en foutpercentages) 

Je hebt een duidelijk beeld nodig van hoeveel verkeer je infrastructuur op een bepaald moment ondersteunt. Daarom is het essentieel om je transacties—oftewel het aantal verzoeken per seconde—en de bijbehorende gemiddelde responstijd in de gaten te houden. Deze informatie kan je helpen bepalen hoeveel resources en capaciteit nodig zijn om de server soepel te laten draaien. 

Tegelijkertijd kan het bijhouden van het foutpercentage, oftewel het percentage mislukte verzoeken ten opzichte van het totale aantal ontvangen verzoeken, verdere inzichten bieden in de belastbaarheid van je service. Om de waarde van deze meetwaarde te maximaliseren, kun je het beste via passieve monitoring na verloop van tijd een basislijn ontwikkelen. 

Dit is cruciaal voor je vermogen om trends te monitoren. Als je terug kunt kijken en de maximale capaciteit en resources kunt bepalen die nodig zijn voor een soepele werking, kun je proactief handelen om die benodigdheden toe te wijzen en infrastructuurproblemen te lokaliseren. Zo verlaag je waargenomen foutpercentages en optimaliseer je de gemiddelde responstijd. 

Transacties en foutpercentages monitoren 

De volgende tools zijn betrouwbaar voor passieve technieken voor prestatiemonitoring: 

  • Sniffers: Deze zijn ontworpen om metingen op “microscopisch niveau” te verzamelen door het verkeersverloop op bekabelde en draadloze netwerken te “afluisteren”. Wireshark is een van de meest algemeen geaccepteerde standaarden en verzamelt gegevens over kenmerken zoals tijdstempel, MAC- en IP-adres, levensduur en meer. Deze kunnen online of offline worden gebruikt. 
  • Logvoorzieningen: Deze zijn meestal geïntegreerd in besturingssystemen en applicaties. Ze verzamelen voornamelijk informatie over de activiteiten en gebeurtenissen die door applicaties worden gegenereerd voor offline gebruik. 

Een van de tien beste tools voor webservermonitoring die bijzonder geschikt is voor het monitoren van transacties, is Monitis. Het is een alles-in-één monitoringsysteem voor servers, websites en applicaties. Het is geschikt voor zowel Windows- als Linux-systemen en ideaal om de basis te dekken, waaronder beschikbaarheid. 

De doelstelling en het doel van de monitoringinspanningen bepalen welke exacte metingen worden uitgevoerd en hoe deze technieken worden gebruikt. 

Andere meetwaarden om samen met transacties te monitoren 

Responstijd en het totale aantal threads houden rechtstreeks verband met transacties. Deze geven je inzicht in hoe lang je server nodig heeft om op een verzoek te reageren en in het aantal threads (die de transacties uitvoeren) dat wordt gebruikt om al deze verzoeken af te handelen. 

Elke thread gebruikt CPU-tijd en RAM. Te veel threads kunnen leiden tot ondermaatse prestaties. Er valt hierbij behoorlijk wat te monitoren, waaronder: 

  • Het totale aantal threads in een webserver of containerpool, waaronder deze typen:
    • Actief 
    • Inactief 
    • Vastgelopen 
    • Stand-by 
  • Openstaande gebruikersverzoeken en wachtrijlengte 

Je kunt de reactietijd van een server doorgaans meten als Time to First Byte (TTFB). Dit is het aantal milliseconden dat een browser nodig heeft om de eerste byte van een serverreactie te ontvangen. Over het algemeen is alles boven de vijf seconden kritiek. 

De juiste statistieken kiezen voor serverprestatiemonitoring

Er is een lange lijst met statistieken die je kunt monitoren wanneer je de status en prestaties van je server volgt, maar de specifieke doelen hangen voornamelijk af van het doel van je monitoringinspanningen. 

Sommige statistieken zijn het meest geschikt om inzicht te krijgen in de belastbaarheid van je hardware en besturingssysteem, terwijl andere ideaal zijn om gebruikersactiviteit te observeren. In elk geval zijn CPU, uptime en transacties fundamentele zaken die je niet over het hoofd mag zien. 

Naarmate je vordert als QA-lead en je doelstellingen onvermijdelijk veranderen, voeg je ongetwijfeld meer statistieken voor servermonitoring toe aan je dashboard. Voor meer deskundige inzichten in welke statistieken dat zouden moeten zijn en hoe je ze beheert, schrijf je in voor de nieuwsbrief