De meeste storingen worden niet ontdekt door een dashboard, maar door een telefoontje. Een klant die niet kan afrekenen, een collega die zijn order niet kwijt kan, of een mailtje met "hij doet het niet meer". Op dat moment loopt het probleem al even, weet je niet hoe lang, en moet je gaan zoeken in plaats van oplossen.
Dat is precies het verschil dat monitoring maakt. Niet omdat het storingen voorkomt — dat doet het niet — maar omdat het bepaalt of jij het eerste weet of het laatste.
Beschikbaarheid is maar één laag
Veel organisaties hebben iets van monitoring: een dienst die elke paar minuten controleert of de website reageert. Dat is een prima begin, maar het meet maar één ding, namelijk of de voordeur nog open staat. In de praktijk gaan applicaties zelden helemaal plat. Ze gaan gedeeltelijk stuk.
De koppeling met de boekhouding faalt sinds vanochtend stilletjes. Het uploaden van bestanden geeft een foutmelding, maar alleen bij grote bestanden. De betaalprovider antwoordt trager dan normaal, waardoor bestellingen blijven hangen. In al die gevallen staat je uptime-monitor op groen en is je klant alsnog de dupe.
Zinnige monitoring kijkt daarom naar drie lagen tegelijk:
- Beschikbaarheid — draait de applicatie, is de server bereikbaar, is er nog schijfruimte en geheugen?
- Fouten — treden er uitzonderingen op in de code, mislukken achtergrondtaken, lopen wachtrijen vol?
- Gedrag — worden de dingen die geld opleveren nog steeds gedaan? Denk aan het aantal bestellingen per uur, verzonden facturen of geslaagde synchronisaties.
Die laatste laag wordt het vaakst overgeslagen en is vaak het meest waardevol. Een systeem dat technisch gezond oogt maar sinds middernacht nul orders heeft verwerkt, vertelt je meteen dat er iets goed mis is.
Logging: de zwarte doos van je applicatie
Monitoring vertelt je dát er iets aan de hand is. Logging vertelt je wat er precies gebeurde. Zonder goede logging begint elk incident met gissen: welke gebruiker, welke actie, welke gegevens, hoe laat?
Goede logging betekent niet zoveel mogelijk wegschrijven. Een logbestand waarin alles staat, is net zo onbruikbaar als een leeg logbestand. Het gaat om vindbare context: een tijdstempel, wie of wat de actie uitvoerde, welk onderdeel het betrof en waar het misging. Als je logs op één plek verzamelt en doorzoekbaar maakt, verandert een onderzoek van uren in een zoekopdracht van minuten.
Let daarbij op wat je níet logt. Wachtwoorden, tokens, betaalgegevens en onnodige persoonsgegevens horen niet in een logbestand thuis. Logs worden vaak breder gedeeld en langer bewaard dan mensen zich realiseren, en zijn daarmee ook een privacy- en securityvraagstuk.
Niet toevallig staat "onvoldoende logging en monitoring" ook zelf in de OWASP top-10 van meest voorkomende beveiligingsrisico's voor webapplicaties.
Alarmen die je serieus blijft nemen
Een meldingssysteem dat te vaak afgaat, wordt genegeerd. Dat klinkt logisch, maar het gebeurt in de praktijk voortdurend: een kanaal vol waarschuwingen dat niemand meer opent, en waarin de ene echte storing tussen de ruis verdwijnt.
De vuistregel is simpel. Een melding die je 's nachts wakker maakt, moet iets zijn waar je 's nachts ook echt iets aan gaat doen. Alles wat kan wachten tot morgenochtend, is geen alarm maar een rapportage. Maak dat onderscheid expliciet en houd de lijst met echte alarmen kort.
Even belangrijk: leg vast wie er reageert. Een alarm zonder eigenaar is een alarm dat iedereen aan iemand anders overlaat.
Zo begin je, zonder groot project
Monitoring hoeft geen maandenlang traject te zijn. Vier stappen brengen je al ver:
- Bepaal wat écht kritiek is. Welke twee of drie processen mogen simpelweg niet stilvallen? Vaak zijn dat bestellen, betalen, inloggen of een koppeling met een systeem waar de rest van het bedrijf op wacht.
- Meet die processen direct. Niet alleen "de server leeft", maar "er zijn het afgelopen uur bestellingen binnengekomen" en "de synchronisatie van vannacht is geslaagd".
- Breng je logging op orde. Zorg dat fouten centraal binnenkomen inclusief context, zodat je niet per server hoeft te zoeken.
- Test het alarm. Simuleer een storing en controleer of de melding daadwerkelijk aankomt bij een mens die weet wat hij moet doen. Een ongeteste alarmering is een aanname, geen zekerheid.
Daarna kun je rustig uitbreiden: prestatiemeting, trends over langere periodes, of automatisch schalen bij drukte.
Veelgemaakte valkuilen
Alleen meten na de livegang van een project. Monitoring wordt vaak ingericht in de eerste onrustige weken en daarna nooit meer aangepast, terwijl de applicatie blijft veranderen. Nieuwe functionaliteit zonder bijbehorende meetpunten is een blinde vlek.
Wel meten, niet kijken. Dashboards die niemand opent, hebben dezelfde waarde als geen dashboard. Zorg dat de belangrijkste signalen actief naar je toe komen.
Denken dat je hostingpartij het regelt. Veel hostingpartijen bewaken de infrastructuur — de server, het netwerk, de opslag. De werking van jouw specifieke applicatie en haar koppelingen valt daar meestal buiten. Vraag concreet na wat wel en niet wordt bewaakt, en wie er 's avonds reageert.
Van reageren naar vóór zijn
Het echte rendement van monitoring zit niet in het sneller blussen van brandjes. Het zit in het patroon dat zichtbaar wordt: een taak die elke maandagochtend net iets langer duurt, een foutmelding die twee keer per week terugkomt, een schijf die langzaam voller loopt. Dat zijn de signalen waarmee je een storing voorkomt in plaats van oplost — en dat scheelt aanzienlijk meer dan de tijd die je in de inrichting steekt.
Goede monitoring hoort bovendien bij een breder plaatje: het is net zo goed een vast onderdeel van een getest herstelplan als van een norm als ISO 27001.
Wil je weten hoe jouw applicatie ervoor staat en welke signalen je nu mist? Neem contact met ons op voor een vrijblijvende check van je monitoring en logging. Beter een melding op je scherm dan een telefoontje van je klant.