Observability: logging, monitoring en tracing.

Drie pijlers van observability

Een applicatie draait in productie. Gebruikers klagen over traagheid. Je opent je server, kijkt naar de logs en ziet duizenden regels tekst voorbijscrollen. Geen idee waar je moet zoeken. Dit is het probleem dat observability oplost.

Observability is het vermogen om vanuit de buitenkant te begrijpen wat er binnenin je systeem gebeurt. Niet door te gokken of code te lezen, maar door de signalen die je applicatie afgeeft. Die signalen vallen uiteen in drie pijlers:

Logging beantwoordt de vraag: wat is er gebeurd? Logs zijn discrete events met context. Een gebruiker heeft ingelogd, een betaling is mislukt, een API-call gaf een timeout. Logs vertellen het verhaal achteraf.

Monitoring beantwoordt de vraag: is alles op dit moment in orde? Monitoring kijkt continu naar metrics en geeft een signaal zodra iets buiten de verwachte waarden valt. Responstijden, foutpercentages, geheugengebruik, queue-diepte.

Tracing beantwoordt de vraag: waar ging het request naartoe? In een architectuur met queues, externe API's en microservices legt tracing de volledige route vast die een verzoek aflegt door je systeem. Van de eerste HTTP-request tot de laatste database-query.

Elk van deze pijlers is op zichzelf nuttig. Maar de echte kracht zit in de combinatie. Monitoring vertelt je dat er iets mis is. Logging vertelt je wat er mis ging. Tracing vertelt je waar in de keten het probleem zit. Zonder alle drie vlieg je blind.

Logging goed doen

De meeste applicaties loggen wel iets, maar doen het verkeerd. Ongestructureerde tekst als "Error occurred in payment module" is nutteloos zodra je op schaal moet zoeken. Gestructureerde logging in JSON-formaat is de standaard. Elke logregel bevat vaste velden: timestamp, level, message, context. Dat maakt je logs doorzoekbaar, filterbaar en parseerbaar door tooling.

Log levels bestaan niet voor niets. DEBUG is voor development, INFO voor normale operaties, WARNING voor situaties die aandacht verdienen maar geen directe actie vereisen, ERROR voor fouten die impact hebben op gebruikers, CRITICAL voor systeemfalen. Gebruik ze consequent. Als alles ERROR is, is niets meer ERROR.

Wat je wel logt: inkomende requests en hun responstijden, foutmeldingen met volledige stacktraces, business events zoals bestellingen, registraties en betalingen, en externe API-calls met hun statuscodes. Wat je nooit logt: wachtwoorden, API-tokens, sessie-identifiers, persoonsgegevens of creditcardnummers. Dit klinkt vanzelfsprekend, maar het gebeurt vaker dan je denkt — vooral wanneer je volledige request-objecten logt zonder filtering.

In Laravel configureer je meerdere logging-kanalen naast elkaar. Voor productie combineer je doorgaans een dagelijks roterend logbestand met een externe service als Sentry voor error-tracking. Sentry groepeert fouten automatisch, toont de frequentie en geeft context zoals de browser, het OS en de request-data. Het verschil met handmatig door logbestanden zoeken is enorm.

De beste logregels zijn de regels die je niet hoeft te lezen. Tot het moment dat je ze nodig hebt — dan moeten ze er zijn, compleet en doorzoekbaar.

Monitoring: weten dat het werkt

Logging vertelt je achteraf wat er mis ging. Monitoring vertelt je nu dat er iets mis is. Het verschil is cruciaal: zonder monitoring ontdek je problemen pas wanneer gebruikers gaan klagen. En gebruikers klagen niet altijd — vaak vertrekken ze gewoon.

Health checks zijn de basis. Een endpoint dat verifieert of je applicatie bereikbaar is, of de database reageert, of de cache werkt en of de queue-worker draait. Laravel biedt hier ingebouwde ondersteuning voor. Een externe uptime-monitor zoals UptimeRobot of Oh Dear pingt dit endpoint regelmatig en stuurt een alert als het faalt.

Uptime monitoring van buitenaf is essentieel omdat je applicatie zelf niet altijd weet dat ze onbereikbaar is. Een DNS-probleem, een load balancer die misdraait of een netwerkstoring — je applicatie draait nog, maar niemand kan erbij. Externe monitoring vangt dit op.

Queue-diepte is een metric die vaak over het hoofd wordt gezien. Wanneer jobs zich sneller opstapelen dan ze worden verwerkt, groeit de queue. Dat betekent trage e-mails, vertraagde webhooks, achterlopende exports. Monitor het aantal wachtende jobs en stel een alert in wanneer de queue boven een drempelwaarde komt.

Tijdens development gebruiken we tooling die elke query, elk request, elke achtergrondtaak en elke foutmelding toont in een overzichtelijk dashboard. In productie gebruik je Sentry voor error-tracking en CloudWatch op AWS voor infrastructuurmetrics als CPU, geheugen en Lambda-invocations. De combinatie geeft je zicht op zowel applicatie- als infrastructuurniveau.

Tracing: de route van een request

In een monoliet is debuggen relatief eenvoudig: een request komt binnen, wordt verwerkt en gaat weer terug. Maar zodra je queues, externe services, webhooks en achtergrondprocessen toevoegt, wordt het plaatje complexer. Een gebruiker plaatst een bestelling en er gebeuren twaalf dingen: validatie, voorraadcontrole, betaling via een externe gateway, e-mailbevestiging via een queue, voorraadupdate via een event, facturatie via een achtergrondproces. Waar in die keten zit de vertraging?

Distributed tracing lost dit op door een uniek correlation ID mee te geven aan elk request. Dat ID reist mee door je hele systeem: van de initieel HTTP-request, door de queue-job, naar de API-call, tot in de database-query. Wanneer een gebruiker een trage respons ervaart, zoek je het correlation ID op en zie je precies welke stap de bottleneck was.

In de praktijk genereer je bij elk binnenkomend request een uniek ID dat meereist door je hele systeem: in elke logregel, elke achtergrondtaak en elke uitgaande API-call. Services als Sentry en AWS X-Ray visualiseren de volledige keten als een waterfall-diagram. In plaats van gissen zie je direct dat de derde API-call in de keten 4,2 seconden duurde terwijl de rest in milliseconden afrondde.

Alerting zonder alarm-moeheid

Observability zonder alerting is een dashboard dat niemand bekijkt. Maar alerting die verkeerd is ingericht is minstens zo schadelijk: te veel alerts leidt tot alarm-moeheid. Het team negeert notificaties, dempt kanalen en mist uiteindelijk de ene alert die ertoe deed.

De belangrijkste regel: alert op symptomen, niet op oorzaken. Je gebruiker merkt niets van een hoog CPU-percentage, maar wel van een trage pagina. Alert dus op responstijden en foutpercentages, niet op server-metrics. Hoge CPU kan een symptoom zijn van een probleem, maar het kan ook volkomen normaal zijn tijdens een piek.

Definieer heldere severity levels. CRITICAL betekent: gebruikers zijn nu getroffen, iemand moet direct actie ondernemen. WARNING betekent: er is iets dat aandacht verdient, maar het heeft nog geen impact. INFO is voor notificaties die geen actie vereisen. Koppel hier escalatiepaden aan: een WARNING gaat naar een Slack-kanaal, een CRITICAL gaat naar de telefoon van de dienstdoende engineer.

Begin met weinig alerts en voeg er alleen toe wanneer je een incident hebt gehad dat je eerder had willen detecteren. Elke alert die je toevoegt moet een duidelijke actie hebben: als iemand de alert ziet, moet die weten wat de volgende stap is. Een alert zonder actie is ruis.

Het doel van observability is niet om alles te weten. Het doel is om binnen vijf minuten te weten waar je moet zoeken wanneer het misgaat.

Conclusie

Observability is geen luxe voor grote bedrijven met dedicated SRE-teams. Het is een basisvereiste voor elke applicatie die in productie draait en waar gebruikers van afhankelijk zijn. Gestructureerde logging, proactieve monitoring, distributed tracing en doordachte alerting vormen samen het systeem waarmee je storingen niet alleen detecteert, maar ook snel diagnosticeert en oplost.

De investering betaalt zich terug bij het eerste incident dat je in minuten oplost in plaats van uren. Wij helpen je graag bij het inrichten van een observability-strategie die past bij jouw Laravel-stack en de schaal van je applicatie.