Gestructureerde logging is de praktijk waarbij je applicatielogs schrijft als consistente, machineleesbare records in plaats van losse tekstregels. Elke logregel wordt een set benoemde velden, meestal in JSON, zodat elk bericht dezelfde gelabelde onderdelen draagt: een tijdstempel, een niveau, een gebruikers-ID, een request-ID en de gebeurtenis zelf.
Stel je het verschil voor tussen een stapel handgeschreven notities en een nette spreadsheet. De notities lees je een voor een, maar je weet niet meteen hoeveel verkopen er op dinsdag waren. Zet dezelfde informatie in kolommen en de vraag kost één filter. Gestructureerde logging maakt van logbestanden die spreadsheet: tools groeperen, filteren en tellen regels in seconden, wat de basis is van bruikbare observability en goed samengaat met distributed tracing.
Dit telt het zwaarst als er iets stukgaat. In plaats van door duizenden regels te scrollen, zoekt een engineer op één request-ID en ziet hij het hele verhaal van wat er gebeurde. Het is een kleine verandering in hoe logging wordt geschreven die zich bij elk incident terugbetaalt. Je kunt er ook alerts en dashboards bovenop bouwen, want een tool kan tellen hoeveel regels in de laatste vijf minuten het niveau error hadden en je waarschuwen zodra dat aantal oploopt. De overstap vraagt wat discipline. Ontwikkelaars moeten veldnamen afspreken en zich eraan houden, zodat user_id in elke service hetzelfde betekent en niet in de ene plek als userId en in de andere als uid opduikt. Die moeite loont. Zodra het formaat consistent is, kun je de logs van een stuk of tien losse services in één zoektool gieten en als één stroom lezen, en juist dat maakt van een kluwen bewegende delen één systeem waar je echt over kunt nadenken.
Bij TopDevs zetten we gestructureerde logging vanaf dag één op, zodat we bij een vreemde bug van een klant de oorzaak in minuten vinden in plaats van te gokken door een muur van tekst.
