Je systeem begrijpen in productie

Observability is het vermogen om de interne toestand van je systeem te begrijpen op basis van de externe output die het produceert. Dat klinkt abstract, maar het verschil met traditionele monitoring is concreet: monitoring vertelt je dat er iets mis is, observability helpt je te begrijpen waarom.

In een wereld van microservices, containers en gedistribueerde systemen is dat onderscheid cruciaal. Je kunt niet meer met een debugger door je productiesysteem stappen. Je moet je systeem zo instrumenteren dat het je vertelt wat er binnenin gebeurt.

De drie pijlers

Observability rust op drie pijlers die elkaar aanvullen:

1. Logs. Discrete events die iets beschrijven dat is gebeurd. "Gebruiker X heeft ingelogd." "Betaling Y is mislukt met foutcode Z." Logs zijn het meest vertrouwde instrument, maar op zichzelf onvoldoende. In een gedistribueerd systeem heb je duizenden logs per seconde, verspreid over tientallen services.

2. Metrics. Numerieke waarden die je in de tijd meet. Response times, foutpercentages, CPU-gebruik, queue-diepte. Metrics zijn ideaal voor dashboards en alerting. Ze vertellen je snel dat er iets afwijkt, maar niet precies wat.

3. Traces. Een trace volgt een enkel request door alle services heen. Van de API-gateway, via de business logic service, naar de database en terug. Distributed tracing laat je zien waar de vertraging zit, welke service een fout veroorzaakt, en hoe de flow door je systeem loopt.

De kracht zit in de combinatie. Een alert op een metric leidt je naar de juiste traces, die je naar de relevante logs brengen. Zonder die samenhang ben je een speld in een hooiberg aan het zoeken.

Van monitoring naar observability

Traditionele monitoring is reactief: je definieert vooraf welke vragen je wilt stellen (is de CPU-load boven 80%?) en je alert als een drempel wordt overschreden. Observability is proactief: je instrumenteert je systeem zo dat je vragen kunt stellen die je van tevoren niet had bedacht.

Het verschil wordt duidelijk bij onbekende problemen. Als een klant meldt dat het systeem traag is, maar alleen op dinsdag, alleen voor een specifiek type transactie, dan heb je observability nodig om dat te onderzoeken. Geen vooraf gedefinieerde alert had dit gevangen.

Praktische implementatie in .NET

OpenTelemetry is de standaard geworden voor instrumentatie. Het is vendor-neutral en wordt breed ondersteund. In .NET kun je met het System.Diagnostics namespace en de OpenTelemetry .NET SDK je applicatie instrumenteren.

Structured logging met bibliotheken als Serilog maakt je logs doorzoekbaar. Log niet "Er ging iets mis met order 12345" maar leg properties vast: OrderId, CustomerId, ErrorCode. Dit maakt je logs queryable in tools als Seq, Elastic of Grafana Loki.

Correlation ID's zijn onmisbaar. Genereer een uniek ID bij het eerste request en propageer dit door alle services heen. Zo kun je alle logs en traces van een enkel request aan elkaar knopen.

Kies een observability platform dat de drie pijlers integreert. Grafana (met Loki, Tempo en Prometheus/Mimir), Elastic, of Datadog zijn gangbare keuzes. Het belangrijkste criterium: kun je vanuit een alert in een metric doorklikken naar de bijbehorende traces en logs?

Begin vandaag

Je hoeft niet alles tegelijk te implementeren. Begin met structured logging en correlation ID's. Voeg dan metrics toe voor je belangrijkste business KPI's. Implementeer als laatste distributed tracing. Elke stap levert direct waarde op.

NForza en observability

NForza helpt teams om hun systemen observeerbaar te maken. Met onze ervaring in missiekritische .NET-systemen weten we welke instrumentatie ertoe doet en welke alleen ruis oplevert. Goede observability is geen kwestie van alles loggen, maar van de juiste dingen zichtbaar maken.