Lief dagboek

Als developer bij Vollan werk ik aan verschillende applicaties, die applicaties hebben heel uiteenlopende functies en worden vaak door vele gebruikers tegelijk gebruikt. Een groot deel van mijn tijd besteed ik aan het ontwikkelen van nieuwe functionaliteiten en aanpassingen van onze software Clientbox.

Iedereen weet, waar gewerkt wordt gaat ook weleens iets verkeerd en zeker als je werkt met code. Dat is onvermijdelijk. Maar hoe komen we er achter wat er misgaat en welke oorzaak dat heeft? We zitten niet bij gebruikers op het scherm te kijken of de applicatie wel alles goed heeft afgehandeld. Hoe monitoren we of de applicatie zich gedraagt zoals we willen?

Logging

Dit doen we door constant een dagboek bij te houden. Gelukkig komt hier geen pen en papier aan te pas, maar we schrijven simpelweg een stukje code om het dagboek bij te werken. Dit wordt in developers-taal ‘logging’ genoemd.

Hiermee houden we in de gaten wat er allemaal gebeurt in de applicatie. En net zoals je in een echt dagboek niet alleen de negatieve dingen noteert, worden in een log niet alleen foutmeldingen bijgehouden. Eigenlijk worden alle activiteiten beschreven. Aan elke log zitten allerlei gegevens gekoppeld, zoals tijdstip, gebruiker of profiel.

Voorbeelden van zo’n log entry zijn bijvoorbeeld:

• Fout bij het exporteren van inkoopfactuur “INK-24000001” (1233). Melding: Error 500: Ongeldig: Grootboekrekening Type
• Authenticator successful!

Lange lijst

Per dag levert dat een enorme lijst met entries op van dingen die goed gaan, maar er staan ook foutmeldingen tussen. Met alleen meldingen van gebeurtenissen kunnen we weinig, zonder de oorzaak te weten van iets dat niet gaat zoals het hoort. Daarvoor kunnen heel veel redenen zijn en we kunnen natuurlijk alleen fouten oplossen die bij onszelf liggen.

Omdat onze applicaties vaak gekoppeld zijn met externe applicaties kan een error veroorzaakt worden door de andere applicatie, maar ook de fouten die gebruikers maken worden geregistreerd. Een boekhoudkoppeling die niet meer werkt, de gebruiker die iets foutief heeft ingesteld of de applicatie van de externe partij er tijdelijk uit ligt.

Filteren

Daarom zijn we er de laatste tijd actief mee aan de slag gegaan om meer informatie te koppelen aan entries in onze logs. Die extra informatie geeft ons meer duidelijkheid over wat er gebeurt in de applicatie. Alleen komen we dan bij het volgende punt: hoe filteren we al die informatie zodat we weten welke meldingen van belang zijn?

Dat is waar ik nu mee bezig ben.

Support dashboard

Door de standaardactiviteit van bedrijven te bekijken kunnen we afwijkingen gaan signaleren. Worden er op een ‘normale’ werkdag 1000 mails verzonden en nu maar de helft? Dan is dat gek en gaat er waarschijnlijk iets niet helemaal goed. Door deze gegevens per klant in de gaten te houden, kunnen we eerder zien of er afwijkingen zijn. Dat betekent proactief op fouten controleren en oorzaken sneller achterhalen. Zo wordt onze support beter en kunnen we steeds meer errors oplossen voordat de gebruiker het merkt.