Software monitoring en alerting voor KMO's: weet je dat er iets stuk is vóór je klant belt?

De meeste KMO's ontdekken dat hun software stuk is op dezelfde manier: een klant belt. Of stuurt een mail. Of, in het slechtste geval, gaat gewoon stilletjes weg zonder iets te zeggen. Tegen de tijd dat je het weet, is de schade al aangericht.

Monitoring en alerting lossen dat niet op door je code beter te maken. Een bug blijft een bug, of je hem nu meet of niet. Wat ze wél veranderen is de tijd tussen "er gaat iets mis" en "iemand is het aan het oplossen". Voor veel KMO's is dat gat nu uren, soms een heel weekend. Goede monitoring maakt er minuten van.

Tegelijk is monitoring die slecht is opgezet een probleem op zich: een muur van meldingen waar niemand nog naar kijkt. Dus dit artikel gaat over drie dingen: wat je écht moet meten, waar je vooral níét wakker van moet liggen, en de paar plekken waar je wél proactief moet ingrijpen.

Wat monitoring écht oplevert

Even de verwachtingen scherp zetten, want hier gaat het vaak mis. Monitoring maakt je software niet stabieler in de zin dat er minder kapotgaat. Wat het doet:

• Je ziet problemen vroeger. Een schijf die langzaam volloopt of een geheugenlek dat omhoog kruipt, is uren van tevoren zichtbaar, in plaats van pas op het moment dat de boel crasht.
• Je herstelt sneller. De juiste persoon krijgt meteen een seintje in plaats van het toevallig te ontdekken. En goede meetgegevens vertellen je niet alleen dat er iets mis is, maar geven richting over waar.
• Je kunt veiliger uitrollen. Als je releases aan monitoring hangt, zie je binnen minuten of een nieuwe versie de boel omhoog jaagt, en rol je terug vóór het echt pijn doet.
• Je weet wat "normaal" is. Door continu te meten leer je hoe je systeem zich op een gewone dag gedraagt. Pas dan vallen de afwijkingen op.

Niets daarvan vereist een duur platform of een team van specialisten. Voor een doorsnee KMO gaat het om een handvol goed gekozen signalen.

Begin bij wat je klant merkt

De grootste fout die we zien: bedrijven meten honderd interne technische cijfers, maar weten niet of een echte gebruiker op dit moment een foutmelding krijgt. Draai dat om. Meet eerst wat je klant merkt, dan pas wat er onder de motorkap gebeurt.

In de praktijk komt dat neer op vier dingen:

• Fouten. Welk deel van de aanvragen faalt? Dit is bijna altijd je belangrijkste signaal, want een mislukte aanvraag is meteen iets dat een gebruiker raakt. Let op de stille fouten: een pagina die netjes laadt maar leeg of fout is, telt óók als fout.
• Snelheid. Hoe lang duurt een aanvraag? Meet dit niet als gemiddelde maar als "de traagste 5%". Als één op de twintig aanvragen vijf seconden duurt, verdwijnt dat volledig in een mooi ogend gemiddelde, terwijl je klanten er wel degelijk last van hebben.
• Verkeer. Hoeveel aanvragen krijg je? Vooral als context: 5% fouten betekent iets heel anders bij 50 bezoekers dan bij 50.000. En verkeer dat plots wegvalt, is vaak zélf een symptoom dat er iets stuk is.
• Verzadiging. Hoe vol zitten je middelen, hoe dicht zit je tegen de limiet? Dit is je vroegwaarschuwing.

En dan het belangrijkste, dat geen enkel standaard-dashboard voor je invult: je bedrijfsmetrics. Lukt het inloggen? Komen bestellingen door? Worden facturen verstuurd, draaien de betalingen? Een systeem kan technisch volledig "groen" staan terwijl er al een uur geen enkele bestelling meer binnenkomt. Dát is wat je als eerste wil weten.

Waar je vooral níét wakker van moet liggen

Nu het deel dat de meeste mensen verkeerd doen. Niet alles wat je meet, verdient een alert die je 's nachts wakker belt.

De grootste valkuil is alerteren op oorzaken in plaats van symptomen. CPU op 90% klinkt alarmerend, maar is op zichzelf geen probleem: als je aanvragen nog steeds snel en foutloos binnenkomen, dan dóét die CPU gewoon zijn werk. Pas wanneer hoge CPU samengaat met stijgende traagheid of fouten wordt het interessant. Dus meet CPU zeker, je hebt het nodig om problemen te diagnosticeren, maar maak er geen alert van.

Waarom dit belangrijk is: te veel of te gevoelige alerts leiden tot wat we alert fatigue noemen. Mensen beginnen meldingen te negeren omdat ze toch meestal vals alarm zijn, en precies daardoor missen ze de echte. Een alert die afgaat moet iets betekenen.

Een handige toets voor elke melding die je overweegt: als deze waarde verdrievoudigt, doe ik dan iets? Is het antwoord nee, dan hoeft het geen alert te zijn. Zet het op een dashboard dat je af en toe bekijkt en klaar.

De vuistregel die alles samenbindt: alert op symptomen, gebruik de rest om te diagnosticeren. Je alerts beantwoorden de vraag "hebben klanten er last van?". Al je andere cijfers staan klaar zodat je, zódra een alert afgaat, snel kunt zien wáár het misloopt.

De uitzondering: opslag (en deels geheugen)

Op die "alerteer niet op resources"-regel is er één belangrijke uitzondering, en die is het waard om goed te begrijpen. Het verschil zit hem in of een middel zichzelf weer vrijmaakt of niet.

CPU is elastisch: een piek lost zichzelf op zodra hij voorbij is, en alles wat er misgaat is dat het even trager wordt. Opslag is het tegenovergestelde. Een schijf loopt maar één kant op, vol, en maakt zichzelf niet vrij. De faalmodus is bovendien hard en soms onomkeerbaar: geen logs meer kunnen wegschrijven, een database die corrupt raakt of vastloopt, een systeem dat niet meer herstelt. En, cruciaal, het is voorspelbaar. Je ziet de trend uren of dagen van tevoren.

Daarom is opslag wél een geval voor proactief alerteren. De betere aanpak is hier op de trend alerteren ("schijf vol over vier uur bij dit tempo") in plaats van op een vaste drempel van 90%. Die vaste drempel komt te laat op een kleine, snel vollopende schijf, en veel te vroeg op een grote, trage. Een volle schijf raakt trouwens ook rechtstreeks je data, wat weer alles te maken heeft met de vraag of je backups eigenlijk wel werken.

Geheugen zit ertussenin. Hoge geheugenbezetting is vaak prima, dat is gewoon je systeem dat de beschikbare ruimte benut. Wat je wél wil vangen is de langzame opwaartse trend, een lek dat omhoog kruipt richting een crash. Dus: alerteer op de helling, niet op de momentane waarde.

Gefaalde logins: één meting, twee verhalen

Een mooi voorbeeld van een metric die de moeite waard is, omdat hij je twee verschillende dingen tegelijk kan vertellen.

Als betrouwbaarheidssignaal verraadt een plotselinge piek in mislukte logins dat je inlogsysteem stuk is, bijvoorbeeld na een slechte update, waardoor je echte klanten er niet meer in komen. Als beveiligingssignaal verraadt het patroon een aanval: veel mislukte pogingen verspreid over veel accounts wijst op geautomatiseerd uitproberen van gestolen wachtwoorden, terwijl veel pogingen op één account een gerichte aanval is.

Je alerteert dus niet op een absoluut aantal, want er falen er altijd een paar, mensen vergeten nu eenmaal hun wachtwoord. Je alerteert op een afwijking van je normale niveau, en de vorm van die afwijking vertelt je meteen welk van de twee problemen je hebt. Dat tweede verhaal, de beveiligingskant, wordt overigens almaar relevanter nu meer bedrijven onder strengere regels vallen; zie ook NIS2 voor KMO's.

Vergeet je afhankelijkheden niet

Een laatste laag die makkelijk vergeten wordt. De meeste software leunt op dingen van buitenaf: een externe API, een database, een betaalprovider, een mailservice. Heel veel "onverklaarbare" storingen zitten niet in je eigen code, maar in iets waar je van afhangt.

Meet daarom de foutmarge en de snelheid van die verbindingen apart. Als je dat doet, zie je bij een storing meteen waar de schuld ligt, in plaats van uren te zoeken in je eigen code terwijl het probleem ergens anders zit.

Hoe we het bij Tandem aanpakken

Geen verrassing als je onze andere artikels gelezen hebt: we houden het bewust saai en klein. Een KMO heeft geen observability-platform met vijftig dashboards nodig, het heeft een handvol signalen nodig die ertoe doen. Een uitgebreide monitoring-stack opzetten "omdat het kan" is gewoon een variant van overengineering: kost die je jarenlang blijft betalen, voor inzicht dat niemand gebruikt.

Concreet: we alerteren op de symptomen die je klanten raken (aanvragen die falen, te traag worden, bedrijfsprocessen die stilvallen) en op de paar resources die hard en voorspelbaar kapotgaan, zoals opslag. De rest meten we ook, maar het staat op een dashboard, niet op een pieper. Elke alert die afgaat, moet betekenen dat er iets moet gebeuren. Zo blijft het signaal scherp en gaat niemand het negeren.

Tot slot

De waarde van monitoring zit niet in het aantal grafieken dat je verzamelt. Ze zit in het antwoord op één vraag: weet je dat er iets stuk is vóór je klant het je vertelt? Voor de meeste KMO's is het antwoord vandaag nee, en dat is met verrassend weinig op te lossen.

Twijfel je of je het zou merken wanneer een kritiek deel van je software uitvalt? We kijken er graag eens samen naar. Geen rapport van dertig pagina's, gewoon een eerlijke check van welke signalen je écht in de gaten zou moeten houden. Plan een kennismaking.