Monitoring voelt als gratis verzekering. Je zet wat controles aan, je krijgt inzicht, en je slaapt beter. Wat vrijwel niemand je vertelt: die controles kosten zelf iets, en als je niet oplet, kosten ze méér dan het probleem dat ze horen op te sporen. Ik ontdekte op een dag dat mijn bewaking de grootste verbruiker op mijn hele systeem was geworden. De waakhond at meer dan de kudde die hij moest beschermen.

In dit stuk deel ik drie manieren waarop bewaking stiekem je duurste post wordt. Alle drie heb ik ze zelf meegemaakt, en alle drie zijn ze in elk bedrijf te vertalen, want het onderliggende patroon is niet technisch: het is dat een beschermingsmaatregel die je nooit meer herijkt, langzaam een kostenpost wordt die je nooit meer opmerkt.

Kostenpost één: gezondheidscontroles die een halve server opeten#

De eerste ontdekking was de pijnlijkste. Ik draai veel losse dienstjes naast elkaar, en bijna elk daarvan had zijn eigen gezondheidscontrole: elke paar seconden even checken of het nog leeft. Op zichzelf een prima idee. Maar bij tientallen van die dienstjes, elk met een eigen ritme, tellen die kleine controles keihard op.

Toen ik het narekende, schrok ik. De gezondheidscontroles alleen al genereerden meer dan negenhonderd checks per minuut, en verbruikten samen structureel vier tot vijf van mijn processorkernen. Dag en nacht. Niet tijdens een piek, niet tijdens een incident, gewoon als vaste achtergrondbelasting. Er was geen enkel functioneel probleem, geen storing, geen crash. De belasting kwam volledig van het voortdurend controleren óf er een probleem was.

Het venijnige is wat dat doet met de rest van je bewaking. Als je normale belasting kunstmatig hoog staat door je eigen controles, verlies je het zicht op echte pieken. Een werkelijk probleem verdrinkt in de ruis van je eigen waakzaamheid. De bewaking maskeerde precies de incidenten die ze had moeten opsporen.

De fix was niet minder bewaken, maar slimmer bewaken. Ik heb de intervallen doorgelicht: waarom checkt dit dienstje elke vijf seconden als elke minuut ruimschoots volstaat? En op plekken waar een andere laag de dienst toch al controleerde, heb ik de dubbele controle helemaal geschrapt. Alleen al het verdubbelen van de te krappe intervallen halveerde het volume.

Kostenpost twee: logs die je schijf volschrijven#

De tweede sluipmoordenaar zijn logbestanden. Bewaking produceert logs, en logs die niemand begrenst blijven groeien. Ik heb meegemaakt dat een op hol geslagen controle duizenden foutregels per dag wegschreef, en dat die logs zonder enige limiet doorgroeiden tot de schijf vol dreigde te raken.

Een volle schijf is geen abstract probleem. Het is het moment waarop van alles tegelijk begint te falen: diensten kunnen niet meer schrijven, databases lopen vast, en je hele systeem kan stilvallen. En de oorzaak is dan niet een aanval of een hardwarefout, maar je eigen bewaking die haar eigen observaties niet opruimde. De verzekering veroorzaakt de schade waartegen ze verzekert.

De les is simpel maar wordt overal vergeten: elk logbestand hoort een maximum te hebben. Standaard, altijd, zonder uitzondering. Een log dat oud is mag worden weggerold en verwijderd. Onbegrensd loggen is een tijdbom die vroeg of laat afgaat, meestal op het slechtst denkbare moment.

Kostenpost drie: de kapotte controleur die zichzelf niet stopt#

De derde is de gemeenste, want die combineert kosten met een defect. Ik had een controlerend proces dat door een fout in een oneindige lus terechtkwam. Het probeerde iets, faalde, probeerde het meteen opnieuw, faalde weer, en zo door, zo snel als het kon. Het resultaat: een volledige processorkern permanent voor honderd procent bezet, dag in dag uit, door een proces dat niets nuttigs meer deed.

Het probleem was niet dat het faalde. Software faalt, dat is normaal. Het probleem was dat het bleef ramen op volle snelheid, zonder ooit even op adem te komen. Een goed ontworpen proces dat faalt, wacht steeds langer voor het opnieuw probeert, en stopt helemaal na een aantal mislukkingen. Dat heet terugvalgedrag, en het ontbrak hier volledig. Zonder rem beukt een kapot proces net zo hard door als een werkend proces, alleen dan zonder enig resultaat.

De oplossing is een ingebouwde noodrem: na een paar mislukte pogingen stopt het proces met proberen en gaat het alleen nog observeren en melden. Niet blijven beuken, maar erkennen dat er iets structureel mis is en de handdoek in de ring gooien in plaats van de server te gijzelen.

De rode draad: bewaking is geen gratis achtergrondruis#

Wat deze drie gevallen delen, is een denkfout die ik zelf jarenlang maakte: dat bewaking gratis op de achtergrond draait. Dat is ze niet. Elke controle kost processortijd, elke log kost schijfruimte, elk proces dat faalt kan doorbeuken tot het iets anders sloopt. Bewaking is een systeem als elk ander, en het verdient dezelfde discipline als het systeem dat het bewaakt.

Drie principes die ik sindsdien standaard toepas:

  • Herzie de intervallen periodiek. Vraag bij elke controle: hoe vaak is echt nodig? Bijna altijd kan het minder vaak dan je ooit instelde. Te frequent controleren voegt geen zekerheid toe, alleen kosten.
  • Geef elke log een limiet, standaard. Nooit een logbestand aanzetten zonder maximum en zonder opruiming. Onbegrensd groeien is geen optie, het is uitstel van een storing.
  • Bouw overal een noodrem in. Elk proces dat iets herhaaldelijk probeert, moet na een paar mislukkingen stoppen en escaleren in plaats van eindeloos doorbeuken. Falen mag, maar doorrammen op volle snelheid nooit.

Wat betekent dit voor jouw bedrijf?#

Ook als jij nooit een processorkern zult tellen, betaal je hier waarschijnlijk voor. Elke cloud-rekening, elke leverancier die “monitoring inbegrepen” zegt, elk dashboard dat je hebt aangezet: het kost allemaal iets, en dat iets loopt op als niemand het herijkt.

Drie dingen om vandaag te doen:

  1. Vraag wat je bewaking kost. Niet wat de dienst kost, maar wat het bewaken ervan verbruikt. Als niemand daar antwoord op heeft, staat het waarschijnlijk te hoog ingesteld.
  2. Behandel je verzekeringen als kostenposten. Een controle die je ooit aanzette en nooit meer bekeek, is precies waar verspilling zich verstopt. Zet periodiek een moment om te vragen: gebruik ik dit nog, en niet te zwaar?
  3. Zorg dat kapot ook echt stopt. Vraag bij elke automatisering: wat gebeurt er als dit faalt? Blijft het rustig hangen, of beukt het door tot het iets anders meesleurt? Het antwoord bepaalt of een klein defect een grote storing wordt.

De ironie van goede bewaking is dat je haar bijna niet mag voelen. Zodra je monitoring de grootste verbruiker op je systeem is, beschermt ze je niet meer, dan is ze zelf het probleem geworden.

Wil je in kaart brengen waar in jouw bedrijf de bewaking meer kost dan ze oplevert? Neem via de consulting-pagina contact op, of pak de gratis Ai-kostenwijzer voor het mkb om je Ai-kosten per onderdeel inzichtelijk te maken.