Auditlogboek deel 3: webservicelog-ontwerp in de praktijk implementeren

What should the application log and how much?

Hallo, ik ben Otsuka, CTO bij Liberogic.

In the previous part, we compared log features across services such as AWS, Cloudflare, Vercel, Supabase, and headless CMS.

Each service provides execution logs, error logs, and records of administrative operations.

So if we combine all of these, will we have all the logs needed for a web service?

Unfortunately, it's not that simple.

Logs automatically retained by cloud services are different from logs that must be recorded by the application you build yourself.

This time, we'll organize how to think about log design in actual web services, focusing on practical implementation.

What you can't understand from service-side logs alone

If you're using Cloudflare Workers or Vercel Functions, execution results and errors are automatically recorded to some extent.

Met Supabase kun je logboeken van database, authenticatie, API en meer raadplegen.

Echter, de serviceprovider kan alleen zien wat er binnen die service is gebeurd.

Bijvoorbeeld: als je weet dat een databaseschrijfbewerking succesvol is geweest, weet je nog niet of het gaat om 'een aanvraag accepteren' of 'lidgegevens wijzigen'.

Dit soort zakelijke gebeurtenissen moet aan de applicatiekant betekenis krijgen en worden geregistreerd.

Niet alles hoort in logs

Je wilt misschien zoveel mogelijk informatie in logs opslaan ter voorbereiding op onderzoeken.

Maar meer logs betekent niet altijd beter.

Als je elke bewerking gedetailleerd registreert, verdwijnt de werkelijk belangrijke informatie in de massa. Naarmate de logbestanden groter worden, stijgen ook de kosten voor opslag en zoekopdrachten.

Daarom ontwerpen we logs met bewustzijn van de 'grenzen' van de verwerking.

Voor een contactformulier bijvoorbeeld:

• Verzending geslaagd
• Afgewezen vanwege invoerfouten
• Afgewezen als spam
• Opslag in database mislukt
• E-mailnotificatie verzenden mislukt

We registreren punten waar het verwerkingsresultaat verandert.

In plaats van alle tussenliggende variabelen en processen op te slaan, selecteren we de gebeurtenissen die nodig zijn om later het verloop te kunnen volgen.

Logs worden opgeslagen als gegevens, niet als tekst.

Het is handig om in logboeken informatie op te nemen die later kan worden doorzocht, in plaats van alleen 'Er is een fout opgetreden' te schrijven.

Het vastleggen van dergelijke items in een vastgesteld formaat wordt gestructureerde logging genoemd.

Als u items in een formaat zoals JSON op elkaar afstemt, kunt u eenvoudiger zoeken, zoals 'alleen verwerking met betrekking tot een specifieke aanvraag-ID controleren' of 'alleen mislukte e-mailverzendingen extraheren'.

Schrijf persoonlijke informatie niet in logs

Bij het bijhouden van logs van contactformulieren worden soms de naam, e-mailadres en inhoud van het contactformulier volledig geregistreerd.

Hoewel dit nuttig lijkt voor onderzoek, is dit een ontwerp dat u beter kunt vermijden.

Logbestanden kunnen naar meerdere services worden doorgestuurd of gedurende lange periodes worden opgeslagen. Als persoonlijke gegevens of verificatiegegevens daarin zijn opgenomen, kan het logbestand zelf een nieuwe bron van gegevenslekken worden.

Zakelijke gegevens zoals contactformulierinhoud worden opgeslagen in een database, terwijl in het logbestand alleen de ID ter identificatie van het contactformulier en het feit dat de indiening succesvol was worden geregistreerd.

Wanneer dat nodig is, gebruik je die ID om de informatie aan de databasezijde te matchen.

Nadenken over contactformulieren

Bij contactformulieren zie je vaak configuraties waarbij alleen een meldingsmail wordt verzonden.

Het risico is echter dat zelfs als het versturen van de mail succesvol is, het niet zeker is dat deze aankomt bij de ontvanger.

Daarom is het veiliger om de contactgegevens eerst op te slaan in de database en de mail alleen als melding voor het team te gebruiken.

Met deze configuratie kun je onderscheiden of "het contact zelf niet is aangekomen" of "het contact is opgeslagen, maar de meldingsmail is mislukt".

Dit soort subtiele verschillen zijn in de praktijk echt essentieel voor contactafhandeling.

Scheiding tussen korte-termijn zoeken en lange-termijn opslag

Bij dagelijkse probleemdiagnose is het van belang dat je recente logs snel kunt doorzoeken.

Voor audits en incidentonderzoeken daarentegen is het belangrijk dat logs, hoewel zelden gebruikt in het dagelijkse werk, maanden of jaren later nog kunnen worden opgehaald.

Plaats wat u nodig hebt voor recente onderzoeken op een gemakkelijk doorzoekbare plek, en verplaats langdurige audittrails naar een goedkope opslaglocatie.

Simpel, maar in de praktijk maakt deze verdeling echt het verschil.

Logs en dashboards zijn twee verschillende dingen

Als je logs hebt, lijkt het erop dat je alles kunt zien, van bezoekaantallen tot foutpercentages.

Echter, de getallen die je in logs en dashboards ziet, hebben een iets ander doel.

• Logs: individuele gebeurtenissen in detail onderzoeken
• Metrics: aantallen, verhoudingen en verwerkingstijden samenvoegen
• Dashboard: trends in het hele systeem in kaart brengen

Controleer de dagelijkse status via het dashboard en onderzoek logs in detail wanneer je afwijkingen vindt.

Door deze twee samen te gebruiken, werkt het veel beter.

Essentiële zaken om van tevoren vast te stellen

Tot slot vatten we de punten samen die je bij het ontwerpen van logs wilt controleren.

• Te registreren gebeurtenissen
• Items die in het logboek moeten worden opgenomen
• Uitsluiting van persoonlijke gegevens en verificatiegegevens
• Periode waarin recente logboeken kunnen worden doorzocht
• Bereik van logboeken voor langetermijnopslag
• Opslaglocatie voor lange-termijnlogboeken
• Personeelsleden die logboeken kunnen bekijken
• Verwijderingsmethode voor logboeken na afloop van de retentieperiode

Wanneer je het woord auditlogboeken hoort, kan het voelen alsof je alle bewerkingen moet registreren en een groot logbeheersysteem moet implementeren.

Voor typische websites en mediaplatforms kun je echter beginnen met het bepalen van de belangrijkste bewerkingen en verwerkingsresultaten, en vervolgens korte-termijnzoekopdrachten en langetermijnopslag scheiden.

Het gaat niet om het opsommen van de logboekfuncties van de services die u gebruikt, maar om te controleren of de records die het systeem als geheel nodig heeft, behouden blijven.

Wat moet er worden vastgelegd?

Waarom moet het worden vastgelegd?

Hoe lang moeten records worden bewaard?

Als u deze drie punten goed doordenkt, kunt u voorkomen dat de configuratie groter wordt dan nodig is en kunt u gemakkelijker een logboekontwerp maken dat bij het project past.

Logboeken vallen meestal niet op.

Maar of u kunt uitleggen wat er gebeurde wanneer iets misgaat, wordt bepaald door het initiële ontwerp.

Het is belangrijk om dit soort praktische details goed uit te werken.

Tot ziens.