Monitoring inrichten die alarm slaat als het telt

Om 02.00 uur verwerkt de webshop geen bestellingen meer. De server reageert, de uptime-check staat op groen en niemand krijgt een melding. Pas als klanten 's ochtends vragen waar hun orderbevestiging blijft, gaat iemand kijken. Achteraf was het bijna altijd te zien geweest: er werd niets gemeten op de plek waar het misging, of de ene belangrijke waarschuwing verdween tussen honderd andere. Wie monitoring gaat inrichten, lost daarom twee dingen tegelijk op. Je meet wat de klant merkt, en je stuurt alleen een melding als iemand echt iets moet doen.

Begin bij het proces dat geld kost

Kies eerst het proces dat niet mag uitvallen. De tool volgt daaruit. Bij een webshop is dat meestal de route van productpagina naar betaling en orderbevestiging. Bij een SaaS-platform wegen inloggen, beschikbaarheid, responstijd en gegevensverwerking zwaarder. Voor een bureau kan een klantomgeving of een geplande data-import de grootste impact hebben.

Teken die keten uit, want hij is altijd langer dan de website. DNS, hosting, applicatie, database, betaalprovider, API-koppelingen, queue-workers en e-mailverzending horen er allemaal bij. Als één schakel hapert, loopt de klant vast terwijl je server keurig bereikbaar is.

Zet per keten één norm op papier, in de taal van het bedrijf. Een bestelling is binnen twee minuten verwerkt. Een klant kan altijd inloggen. De import is voor 08.00 uur klaar. Zulke zinnen houden het technische team weg van cijfers die voor de business weinig verschil maken, en ze vertellen je precies wat je straks moet meten.

Monitoring inrichten van buiten naar binnen

Meet eerst wat een gebruiker ervaart en pas daarna de onderdelen die die ervaring leveren. Een groene server zegt weinig als de checkout een foutmelding geeft.

Bouw eerst één synthetische check

Een externe beschikbaarheidscheck vertelt je of een pagina of endpoint antwoordt. Een synthetische check gaat verder: die voert automatisch een echte handeling uit, zoals inloggen, een product in de winkelmand leggen of een formulier versturen. Daarmee vang je problemen met sessies, certificaten, JavaScript of afhankelijkheden die een ping nooit ziet. Moet je kiezen waar je begint, begin dan met deze check op je belangrijkste proces.

Houd het aantal klein. Elke knop elke minuut testen levert vooral onderhoud op. Neem de paar handelingen waarvan uitval direct geld kost, werk blokkeert of je reputatie raakt. Werkt je doelgroep internationaal, meet dan vanaf meerdere locaties. Voor een Nederlandse B2B-omgeving volstaat meestal een meetpunt in Nederland of West-Europa.

Kijk naar trends in de technische lagen

Onder de gebruikersreis meet je vijf soorten signalen:

• Beschikbaarheid van servers, containers, databases en belangrijke API-endpoints.
• Capaciteit: CPU, geheugen, schijfruimte en netwerkverkeer.
• Prestaties: laadtijden, databasequeries, foutpercentages en wachtrijen.
• Applicatiefouten, zoals exceptions, mislukte achtergrondtaken en foutieve deployments.
• Veiligheid en continuïteit: verlopen certificaten, mislukte back-ups en afwijkende inlogpogingen.

Een CPU-piek van 90 procent die tien seconden duurt, mag je negeren. Een database die steeds trager wordt terwijl de time-outs oplopen, vraagt om actie. Kijk dus naar duur, trend en de combinatie van signalen. Een losse drempelwaarde op CPU levert vooral nachtelijke ruis op, en daar bel je buiten kantooruren beter niemand voor wakker.

Geef koppelingen een eigen check

Veel problemen ontstaan buiten de zichtbare website. Een koppeling met ERP, CRM, PIM, boekhouding of vervoerder kan falen terwijl de applicatie online blijft. Orders blijven hangen, de voorraad klopt niet meer of klanten krijgen geen bevestiging.

Meet per integratie het aantal geslaagde en mislukte acties, de verwerkingstijd en vooral de leeftijd van de laatste succesvolle run. Voor geplande taken heeft die laatste check de beste verhouding tussen moeite en opbrengst: is deze taak binnen de afgesproken tijd echt uitgevoerd? Een scheduler die draait maar niets bruikbaars oplevert, ziet er in elk dashboard gezond uit.

Een melding moet iemand iets laten doen

Een alert is een technisch signaal. Een incident is een verstoring die actie vraagt. Stuur je alles door, van elke server, logregel en korte piek, dan neemt na een tijd niemand de meldingen nog serieus. Die alertmoeheid sluipt er sneller in dan de meeste teams denken.

Een bruikbare melding vertelt wat er geraakt is, hoe ernstig het is en wat de ontvanger nu moet doen. ‘CPU hoog’ is om 02.00 uur een nutteloze oproep. ‘Checkout-API geeft vijf minuten lang meer dan 10 procent fouten, orders kunnen mislukken’ is een reden om uit bed te komen.

Spreek de ernstniveaus af voordat er iets misgaat. Kritiek gaat direct naar een bereikbaar persoon, omdat een belangrijk proces stilstaat. Een waarschuwing beoordeel je tijdens werkuren. Informatieve gebeurtenissen blijven in een dashboard of rapportage.

Bouw daarnaast een hercontrole in. Eén mislukte request is meestal ruis, terwijl drie mislukte controles achter elkaar met een oplopend foutpercentage aandacht verdienen. Hier zit de echte afweging: elke minuut wachten maakt je meldingen betrouwbaarder en je reactie trager. Bij betalingen, beveiliging en mogelijk dataverlies wil je die minuten niet weggeven, dus daar alarmeer je direct. Voor de rest weegt een rustig team zwaarder dan een paar minuten winst.

Elk dashboard beantwoordt één vraag

Een operationeel dashboard laat zien of de kritieke diensten werken en waar een incident zit. Een capaciteitsdashboard toont groei, knelpunten en toekomstige investeringen. Een managementoverzicht vertaalt techniek naar beschikbaarheid, transacties en afgesproken serviceniveaus. Probeer je die drie op één scherm te krijgen, dan beantwoordt het scherm er geen enkele.

Tien heldere grafieken zijn meer waard dan vijftig waar niemand naar kijkt. Gebruik een vaste tijdsperiode en zet context in beeld, zoals deployments, piekbelasting en storingen bij externe leveranciers. Zonder die markeringen lijkt een afwijking mysterieus terwijl de oorzaak allang bekend is.

Metrics, logs en tracing doen elk een eigen klus. Metrics vertellen dat er iets mis is, bijvoorbeeld een stijgend foutpercentage. Logs leiden je naar de foutmelding en de betrokken gebruiker of order. Tracing laat zien waar een verzoek tijd verliest tussen applicatie, database en externe API. Voor een eenvoudige website kun je tracing overslaan. Voor een platform met meerdere services en koppelingen verdient het zich terug in zoektijd.

Wie pakt de melding om 02.00 uur op?

Werk je met een ontwikkelaar, een hostingpartij, een externe SaaS-leverancier en een interne producteigenaar, dan ziet iedereen hetzelfde probleem en voelt niemand zich eigenaar van de oplossing. Dat kost bij elke storing tijd.

Leg per kritieke service vast wie het eerste aanspreekpunt is, wie technische toegang heeft en wanneer er wordt opgeschaald. Hang aan de melding een kort runbook van een paar regels: controleer eerst deze afhankelijkheid, herstart deze service alleen na overleg, zet nieuwe orders tijdelijk in een wachtrij. Een dik handboek leest tijdens een storing toch niemand.

Test daarna of de melding aankomt. Een noodnummer dat nooit getest is, een verlopen token voor de berichtendienst of een mailbox die niemand leest, en je beste monitoring meldt in het luchtledige. Plan periodiek een oefening met een testmelding of een gecontroleerde storing.

Elke storing levert een betere check op

Na een storing repareer je eerst de directe fout. Vraag je daarna af waarom het probleem niet eerder zichtbaar was, of de melding is opgepakt en welke informatie je tijdens het zoeken miste.

Soms levert dat een extra controle op. Net zo vaak moet er een overbodige alert weg. Misschien ontbrak context over een deployment, stond een drempel te strak of blijkt een externe leverancier een single point of failure. Behandel monitoring als onderdeel van je technische dienstverlening, niet als eenmalige configuratie.

Die cyclus gaat sneller als ontwikkeling, hosting en beheer dicht bij elkaar liggen. Wie een wijziging doorvoert, ziet dan direct wat die in productie doet en kan bijsturen voordat klanten er last van hebben.

Begin deze week bij je drukste proces. Schrijf de norm op, bijvoorbeeld ‘een bestelling is binnen twee minuten verwerkt’, en zoek de check die afgaat als die norm niet gehaald wordt. Vind je die niet, dan weet je wat je eerste melding wordt.