Logging is het vastleggen van wat je software doet als een stroom van gebeurtenissen met een tijdstempel. Elke keer dat iemand inlogt, een betaling slaagt of er een fout optreedt, wordt er een regel weggeschreven: wanneer het gebeurde, wat er gebeurde en vaak een paar details over wie of wat erbij betrokken was.
Zie het als de zwarte doos in een vliegtuig. Zolang alles goed gaat, kijkt niemand ernaar. Maar op het moment dat er iets misgaat, zijn die vastgelegde gebeurtenissen de eerste plek waar je kijkt om precies te reconstrueren wat er gebeurde en in welke volgorde. Goede logs maken van een vage klacht als ‘de site was gisteren traag’ een exacte tijdlijn waar je iets mee kunt.
De meeste logs dragen een niveau, van debug en info tot waarschuwing en error. In productie bewaar je meestal info en hoger, zodat de ruis laag blijft, en zet je het detail pas terug naar debug als je een specifiek probleem najaagt. De andere helft van de truc is wat elke regel zegt. Een regel met “er ging iets mis” vertelt je niets. Eentje met de gebruiker, de aanvraag en de exacte fout vertelt je bijna alles.
Logs werken het best samen met twee broertjes. Metrics vertellen je dat het aantal fouten omhoogschoot, en logs vertellen je waarom. Samen met traces vormen ze de basis van observability, het vermogen om een systeem van buitenaf te begrijpen. Logs in een vast, leesbaar formaat wegschrijven maakt ze later ook veel makkelijker te doorzoeken, en dat is precies het doel van structured logging.
Bij TopDevs zetten we logging vanaf dag één op in elk project, zodat we bij een melding van een klant de oorzaak in minuten kunnen aanwijzen in plaats van te gokken.
