Logs: Essentieel voor Developers en Operators
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...
De Ontvanger Bepaalt de Boodschap
Er zijn drie indelingen te maken in log-berichten, elk met een specifiek doelpubliek:
- Debug-informatie (Niveaus "trace" en "debug"): Gericht aan de ontwikkelaars van het project. Deze berichten zijn data-centric en bieden inzicht in de interne werking van de code. Ze moeten precies aangeven waar en wanneer de data is verzameld.
- Log statements op "info" niveau: Bestemd voor reguliere gebruikers van de software die bekend zijn met de componenten en de juiste flow. Deze berichten dienen als statusupdates of milestones.
- "Warning" en "Error" niveaus: Bedoeld voor operationele teams, die aangeven wanneer iets niet naar behoren functioneert.
- Warning: Gebruikt voor situaties die invloed hebben, maar het systeem nog niet in een "error" toestand brengen. De operator kan nog even afwachten...
- Error: Een hoger niveau van urgentie. Dit duidt aan dat de software zijn taak niet kan vervullen en dat actie vereist is van de operator.
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.
Gestructureerde Logging Frameworks
Gebruik bestaande logging frameworks om te profiteren van:
- Gestructureerde logging, wat leidt tot netjes georganiseerde en eenvoudig te interpreteren JSON-berichten.
- Tijdzone-correcte timestamps.
- De mogelijkheid om een context-ID (CID) mee te geven.
- Extra velden, zoals 'component', die aangeven welk deel van de software de log-lijn genereert.
- Charset en escaping uitdagingen automatisch afgehandeld.
- Mogelijkheid voor non-blocking logging, wat betekent dat je code niet wacht op het wegschrijven van logs.
Log Refactor
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.
En wat met de ERR van hierboven?
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.
