Een schijf op 87% is één meting. Je weet daarmee niet of het gebruik al maanden rond dat niveau ligt of richting vol oploopt. Die situaties vragen om een andere aanpak: in het ene geval hoef je misschien niets te doen, in het andere heb je mogelijk een plan nodig.
Goed servermetrics lezen betekent een eenmalige sprong onderscheiden van een aanhoudende stijging. Eén waarde geeft je een momentopname; een reeks metingen laat je beoordelen wat er verandert.
Monitoringsystemen gebruiken verschillende technieken voor verschillende problemen: afvlakken, statistische controles, of eisen dat een toestand aanhoudt voordat er een alert volgt. InfraNest gebruikt recente metingen om in te schatten of bepaalde servermetrics oplopen naar een relevante grens en, als de data dat onderbouwt, hoeveel tijd er ongeveer resteert.
Waarom één meting weinig zegt
Eén meting op één moment heet een singleton in het meetkader dat wordt beschreven in RFC 2330. Die vertelt je wat de metric op dat moment was, maar niet of hij stabiel is of verandert. Daarvoor heb je metingen over tijd nodig.
Dat geldt ook voor counters. Een counter stijgt doorgaans tot hij wordt gereset, dus de ruwe waarde is zelden de bruikbare grootheid. Prometheus gebruikt functies als rate() of increase() om te schatten hoeveel een counter binnen een tijdvenster verandert. Gauges, zoals vrije schijfruimte, kunnen zowel stijgen als dalen; daarvoor is een op gauges gerichte functie als deriv() geschikter.
Verschillende tools beantwoorden verschillende vragen
Dit probleem is oud, maar er bestaat geen enkele techniek die elke sprong van elke trend scheidt. Monitoringsystemen gebruiken verschillende methoden, afhankelijk van wat ze meten en wat ze moeten beslissen.
| Techniek | Waar het bij helpt | Hoe |
|---|---|---|
| Unix load average | Hoe de systeembelasting over tijd verandert | Rapporteert exponentieel gedempte gemiddelden over 1, 5 en 15 minuten. Deze meten uitvoerbare of niet-onderbreekbare taken (geen CPU-percentage), en het kortere gemiddelde reageert sneller op recente veranderingen. |
| CloudWatch “Datapoints to Alarm” | Of een metric herhaaldelijk een grens overschreed | Vereist een ingesteld aantal overschrijdende datapunten binnen een vast aantal evaluatieperiodes, bijvoorbeeld 3 van de 5. |
Prometheus rate() en irate() |
Hoe snel een counter stijgt | rate() schat de gemiddelde stijging per seconde over een venster; irate() gebruikt de laatste twee samples en reageert sneller op recente veranderingen. |
Prometheus for-clausule |
Of een alertvoorwaarde aanhoudt | Stelt het afgaan uit tot de voorwaarde gedurende de ingestelde duur actief is gebleven. |
| Regels voor statistische procesbeheersing | Of een proces mogelijk is verschoven of afgedreven | Regels voor controlekaarten zoeken naar ongebruikelijke punten of patronen ten opzichte van een procesbaseline. De regels hangen af van de methode; ze zijn geen universele definitie van een trend. |
| SRE multi-window burn-rate-alerts | Of een error budget te snel wordt verbruikt | Combineert korte en lange vensters om verschillende niveaus van SLO-risico te herkennen. Ontworpen voor betrouwbaarheid van diensten, niet voor algemene capaciteitsprognoses van servers. |
Deze technieken zijn verwant, maar niet uitwisselbaar. Een alert dat een aanhoudende overschrijding vereist, beantwoordt een andere vraag dan een schatting van wanneer een stijgende waarde een grens zou kunnen bereiken.
Prometheus-voorbeeld: een gauge voor vrije schijfruimte
node_filesystem_free_bytes is een gauge, dus gebruik deriv() om te schatten hoe snel de vrije ruimte verandert. Een negatief resultaat betekent dat de vrije ruimte afneemt:
deriv(node_filesystem_free_bytes{mountpoint="/"}[6h])
Met predict_linear() kun je schatten of de vrije ruimte binnen de komende dag nul bereikt, en eisen dat die voorwaarde aanhoudt voordat er een alert afgaat:
- alert: DiskFillingFast
expr: predict_linear(node_filesystem_free_bytes{mountpoint="/"}[6h], 24 * 3600) < 0
for: 10m
predict_linear() gebruikt lineaire regressie. Dit voorbeeld voorspelt het bereiken van nul vrije bytes (geen door de gebruiker ingestelde schijfdrempel) en het is niet dezelfde berekening die InfraNest gebruikt.
Je serverpark in één oogopslag beoordelen
Een server die rond de 60% blijft en een server met een korte, hoge piek kunnen over een rapportageperiode een vergelijkbaar gemiddelde hebben. Door naast het gemiddelde ook naar de piek te kijken, wordt dat verschil zichtbaar.
Het Capacity & growth report van InfraNest toont piek- en gemiddelde waarden per periode voor CPU, geheugen en schijf, plus een kleine CPU-sparkline die een indruk geeft van het verloop. Een schijfschatting verschijnt alleen als recente metingen die onderbouwen. Het is een live prognose, getoond voor een rapportageperiode waar vandaag in valt, en geen prognose voor elke schijf of voor een maand uit het verleden.
Controleer vóór het vergelijken van cijfers hoeveel dagen er zijn gemeten. Een server waarvan maar een deel van de periode is vastgelegd, is niet direct vergelijkbaar met een server die de hele periode is gemeten. En bij cyclisch of onregelmatig gebruik is er mogelijk geen betrouwbare trend om door te trekken.
Hoe InfraNest inschat wanneer een trend ertoe doet
Op de pagina van een gemonitorde server kan InfraNest een samenvatting tonen zoals:
Online 18d 4h, maar CPU bereikt over ongeveer 6 dagen de alertgrens van 90%
De knop brengt je naar de bijbehorende grafiek. Voor schijven telt de schatting af tot vol. Voor CPU, geheugen en load telt die af tot een actieve alertregel met een bovengrens. Schijven worden anders behandeld: een volle schijf is een capaciteitsgrens, of er nu een schijfalertregel is ingesteld of niet.
De schatting is bewust voorzichtig:
- Ze gebruikt maximaal de laatste zeven dagen aan uurlijkse metingen; dat betekent niet dat er altijd zeven volle dagen geschiedenis nodig zijn.
- Ze heeft minstens 12 bruikbare metingen nodig en geeft geen schatting als de metingen geen geloofwaardige stijgende trend onderbouwen, bijvoorbeeld na een eenmalige sprong of als de reeks te sterk schommelt.
- Schattingen voor CPU, geheugen en load vereisen een actieve regel met een bovengrens. Schijfschattingen niet.
- Ze rapporteert de vroegste kwalificerende trend in plaats van een aparte deadline voor elke metric te tonen.
- CPU-metingen die de provider rapporteert, kunnen zonder agent een schatting onderbouwen. Geheugen, schijfgebruik en load average vereisen metingen van de agent.
De samenvatting zelf laat geen drempelalert afgaan en opent geen incident. Ze schat wanneer een stijgende waarde haar grens kan bereiken; dat is geen belofte over wanneer je een melding krijgt. Numerieke alerts evalueren een gemiddelde over de ingestelde duur. Daarnaast kan een gemonitorde schijf die naar schatting binnen 14 dagen volloopt, verschijnen in de aandachtslijst en de digest van InfraNest.
De samenvatting is nuttige context, geen vervanging voor alerting. Alerts blijven de ingestelde drempelvoorwaarden afhandelen; de schatting kan je eerder een reden geven om een mogelijk capaciteitsprobleem te onderzoeken.
Voor het overzicht van je hele serverpark, zie het Capacity & growth report. Voor hoe drempels worden ingesteld en geëvalueerd, zie alertregels per server.
Aan de slag
Stel server monitoring in om de metingen te verzamelen die voor je servers beschikbaar zijn. Door de provider gerapporteerde metrics kunnen CPU-metingen leveren waar dat wordt ondersteund; installeer de agent om geheugen, schijfgebruik en load average te verzamelen.
Veelgestelde vragen
#Hoeveel geschiedenis heeft InfraNest nodig voordat er een trendlijn verschijnt?
Een server heeft meer dan een dag of twee aan metingen nodig voordat InfraNest een oordeel geeft. Bij te weinig geschiedenis is er niet genoeg data om een echte trend van ruis te onderscheiden, dus wordt de lijn gewoon weggelaten in plaats van te gokken.
#Werkt de trendlijn ook op servers zonder de monitoringagent?
Ja. Servers zonder agent worden meegenomen voor de metingen die hun cloudprovider rapporteert; de agent voegt extra metrics toe zoals geheugen, schijfruimte en load average, maar is niet vereist voor de trendzin zelf.
#Waarom toont mijn server geen trendlijn, terwijl een metric hoog lijkt?
Een hoge meting die vlak blijft, die één keer sprong en daarna stabiliseerde, of die op en neer schommelt, krijgt geen trendlijn — alleen een metric die echt gestaag stijgt. Een hoge maar stabiele meting wordt elders niet voor je verborgen; ze krijgt alleen geen valse deadline.
#Is de trendprognose hetzelfde als een serveralert?
Nee. De trendlijn is context, geen melding — er gaat niets af en niemand krijgt een bericht als ze verschijnt. Het echte alert gaat pas af zodra de metric je drempel overschrijdt en daar blijft gedurende de duur die je hebt ingesteld.
Probeer het met een gratis tool
Was dit artikel nuttig?
