Als ontwikkelaar is het toevoegen van log-statements aan je code een onvermijdelijke stap. In eerste instantie dienen deze logs voor debugging, maar al snel breiden ze uit naar meldingen over misconfiguraties en andere fouten. Deze logs krijgen extra betekenis wanneer de code door meerdere mensen of teams wordt gebruikt, of zelfs overgedragen wordt aan derden.
Stel je voor, je start software op en ziet de volgende logs:
Dit wijst op een probleem, maar wat precies? Dat is de vraag. Het enige wat je vindt op het internet is een gebruiker die hetzelfde probleem heeft...
Er zijn drie indelingen te maken in log-berichten, elk met een specifiek doelpubliek:
Logs op "warning" en "error" niveau moeten 'actionable' zijn. Ze moeten duidelijk maken wat er misgaat en wat er moet gebeuren om het probleem op te lossen. Verwijzingen naar documentatie of aanvullende informatie zijn hierbij zeer waardevol.
Denk eraan: operators lezen je logs mogelijk om 3 uur 's nachts, in de hoop snel weer naar bed te kunnen.
Gebruik bestaande logging frameworks om te profiteren van:
Bij het herzien van code, overweeg ook een log-refactor. Vraag jezelf af: geven de logs duidelijk weer wat er misgaat en wat de volgende stappen zijn? Zorg ervoor dat een operator nooit een log-level lager dan "info" hoeft in te stellen. Als dat wel nodig is, mist er essentiële informatie op de hogere niveaus.
Die was eigenlijk een "debug" melding. Finaal zijn we de code ingedoken, en hebben we uitgepluisd wat er gebeurde. Uiteindelijk hebben we de logging in dat deel van de code wat aangepast en de wijzigingen voorgesteld in het project.
Het effectief beheren van logs is cruciaal. Het helpt niet alleen bij het debuggen en onderhouden van software, maar het zorgt er ook voor dat de juiste informatie op het juiste moment bij de juiste mensen terechtkomt.