# Wat is observability? Een praktische gids voor dev-teams

URL: https://codebasechat.com/nl/journal/wat-is-observability
Type: blog
Locale: nl
Published: 2026-10-27
Updated: 2026-10-28

---

> Wat is observability, en hoe verschilt het van monitoring? Een praktische gids over logs, metrics, traces en OpenTelemetry voor teams van 5 tot 50 engineers.

Het is 2 uur 's nachts, het checkout-endpoint geeft voor ongeveer één op de twintig verzoeken een 500-fout en de dashboards staan allemaal op groen. Dat gat tussen "het systeem zegt dat alles goed gaat" en "gebruikers zeggen dat het kapot is" is precies wat observability moet dichten. **Wat is observability?** Het is het vermogen om te begrijpen wat je systeem intern doet, op basis van de data die het uitstuurt (logs, metrics en traces), goed genoeg om vragen te beantwoorden die je niet vooraf had bedacht.

Die laatste zin is het hele punt. De rest van dit artikel is uitwerking.

## Observability versus monitoring: de vraag waarvoor je geen alert schreef

Monitoring beantwoordt vragen die je al kende. Ligt de CPU boven 90%? Is het foutpercentage boven 2%? Groeit de wachtrij? Jij kiest de metrics, stelt de drempels in, en er gaat een pager af zodra er één wordt overschreden.

Observability beantwoordt de vraag die je niet wist te stellen. Waarom duren verzoeken van precies één tenant, op precies één appversie, na een bepaalde deploy, vier seconden langer? Niemand heeft daar een alert voor, want niemand had het voorzien.

De twee zijn dus geen concurrenten. Monitoring is de alertlaag. Observability is wat je in staat stelt te onderzoeken zodra de alert afgaat, of zodra een klant mailt en er helemaal geen alert is afgegaan. Als je enige tool een muur van vooraf gebouwde dashboards is, heb je monitoring. Als je productiedata op elke dimensie kunt opsplitsen en één verzoek over services heen kunt volgen zonder nieuwe code uit te rollen, heb je observability.

## De drie signalen: metrics, logs en traces

Bij de meeste definities begint het met "drie pijlers". Het label is wat stijf, maar de drie datatypes zijn echt, en elk is goed in één taak.

- 
**Metrics** zijn getallen over tijd: aantal verzoeken per seconde, p95-latentie, geheugengebruik. Goedkoop om op te slaan, snel te bevragen, handig voor "is er iets mis?". Minder goed voor "welk verzoek, en waarom?".

- 
**Logs** zijn tijdgestempelde records van afzonderlijke gebeurtenissen: een betaling is mislukt, een retry is afgegaan, een feature flag is omgezet. Ze bevatten het detail, maar ongestructureerde logs op een druk gebruikte service worden al snel een hooiberg.

- 
**Traces** volgen één verzoek terwijl het services passeert. Elke stap is een span met een start, een duur en een paar attributen. Een trace komt het dichtst in de buurt van een stacktrace voor een gedistribueerd systeem.

![Afgedrukte logs naast een met de hand getekend diagram van verbonden services](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/f0aa73-i1.webp)

Het onderzoek van Grafana uit 2025, met 1,255 respondenten, laat zien waar teams nu staan. [Het observability-onderzoek van Grafana](https://grafana.com/blog/2025/03/25/observability-survey-takeaways) vond dat 95% van de respondenten metrics gebruikt en 87% logs, maar slechts 57% traces. Traces zijn het signaal dat het meest helpt bij een bug in een gedistribueerd systeem, en het is het signaal dat de minste teams hebben ingericht.

Sla de vuistregel over die zegt dat metrics vertellen wat, logs waarom en traces waar. Die klinkt netjes en werkt in de praktijk niet: een goede gestructureerde log vertelt je vaak meer over "waar" dan een slecht geïnstrumenteerde trace.

## Wat een systeem in de praktijk observeerbaar maakt

Data uitsturen is nodig, maar niet genoeg. Een systeem is observeerbaar als de data drie eigenschappen heeft.

**Hoge cardinaliteit.** Je kunt filteren op gebruikers-ID, tenant, build-SHA, regio of feature flag. Als je tool dwingt om vooraf te aggregeren op servicenaam en statuscode, kun je die ene tenant in de foute toestand niet vinden.

**Context die signalen aan elkaar koppelt.** Een trace-ID op elke logregel betekent dat je van een trage span direct naar de exacte logs ervan kunt springen. Zonder die koppeling lees je twee losse verhalen en raad je hoe ze samenhangen.

**Genoeg detail om bruikbaar te zijn, maar niet zoveel dat het onbetaalbaar wordt.** Hier struikelen de meeste teams. In hetzelfde Grafana-onderzoek noemden respondenten samen meer dan 100 verschillende tools, diensten en projecten, en gebruikte het gemiddelde team er acht. Kosten waren een belangrijk criterium bij de keuze van tools. Alles verzamelen is makkelijk. Betalen ervoor is het deel dat mensen later ontdekken.

Hier is het startpunt met OpenTelemetry, de leverancier-neutrale instrumentatiestandaard. Dit is een minimaal Python-voorbeeld dat een span aanmaakt en de attributen toevoegt die je om 2 uur 's nachts wilt hebben:

`from opentelemetry import trace

tracer = trace.get_tracer("checkout")

def charge(order):
    with tracer.start_as_current_span("charge_card") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("tenant.id", order.tenant_id)
        span.set_attribute("app.version", APP_VERSION)
        result = payment_client.charge(order)
        span.set_attribute("payment.provider", result.provider)
        return result`Drie attributen maken het verschil tussen "checkout is traag" en "checkout is traag voor tenant 4412 op versie 3.8.1". De [OpenTelemetry-primer over observability](https://opentelemetry.io/docs/concepts/observability-primer/) legt de concepten achter dit voorbeeld dieper uit. Het is de moeite waard om hem één keer te lezen, ook als je leverancier de bedrading voor je doet.

## Waar observability-tools verschillen (en waar niet)

Onder de marketing ingesten de meeste platformen dezelfde drie signalen. Ze verschillen in prijsmodel, in bevraagbaarheid en in hoeveel instrumentatie ze voor je doen.

- 
**Alles-in-één-platformen** bundelen metrics, logs, traces, alerting en meer. Handig, met als nadeel facturen op basis van gebruik die meegroeien met je verkeer.

- 
**Open-sourcestacks** zoals Prometheus, Loki, Tempo en Grafana geven je controle en geen licentie per host, ten koste van zelf draaien en afstemmen.

- 
**OpenTelemetry-native backends** accepteren het standaardformaat rechtstreeks, zodat van leverancier wisselen niet betekent dat je elke service opnieuw moet instrumenteren.

Datadog is het referentiepunt voor de alles-in-één-categorie: brede dekking, een strakke interface en een factuur die een maandelijkse controle verdient. Het is de moeite waard als je één leverancier wilt en het budget hebt. Sla het over als voorspelbare kosten je belangrijkste beperking zijn.

Grafana is de pragmatische open-sourcekeuze. Je kunt beginnen met dashboards bovenop de data die je al hebt, en daarna logs en traces toevoegen zodra je ze nodig hebt. Reken wel op een flinke investering in engineeringtijd.

![Gedistribueerd tracewaterval op een laptopscherm](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/fb03e7-i2.webp)

SigNoz is vanaf het begin op OpenTelemetry gebouwd en zet metrics, logs en traces in één open-sourceinterface. Een redelijke keuze voor een team dat de ervaring van één scherm wil, zonder het prijskaartje van een alles-in-één-platform.

New Relic zit tussen beide werelden in, met een gehost platform en een gratis laag die ruim genoeg is om een echte evaluatie te draaien. Beoordeel het op de vraag of je eigen team er een echte productievraag mee kan beantwoorden, niet op de demo.

Geen van deze tools maakt je op zichzelf observeerbaar. De tool is een queryinterface. De instrumentatie is het product.

## Het deel dat de meeste gidsen overslaan: observability stopt bij de codegrens

Hier zit een gat dat je zult tegenkomen zodra je deze tools serieus gebruikt. Een trace vertelt je dat `charge_card` 3.9 seconden duurde en dat het trage deel een aanroep naar `payment_client` was. Het vertelt je niet wat `payment_client` werkelijk doet, wie het heeft geschreven, of waarom het drie keer opnieuw probeert zonder backoff.

Daarvoor verlaat je de observability-tool en lees je code. In een kleine service kost dat tien minuten. In een repo van 100K regels die door vier teams wordt beheerd, is het lezen vaak het langste deel van een incident. Je weet precies welke span traag is en je besteedt toch een uur om uit te zoeken hoe de code erachter in elkaar zit.

Dat is het overdrachtsprobleem tussen runtime-data en broncode, en daarom zien wij observability en codebegrip als twee helften van één workflow:

- 
Observability vertelt je **waar** het misgaat tijdens runtime: welke service, welke span, welke tenant.

- 
Codebegrip vertelt je **waarom** in de broncode: welke functie, welk retrybeleid, welke configuratie.

Teams die die lus sluiten (een spannaam wijst naar een bestand, een bestand wijst naar een eigenaar en een uitleg) verkorten de tijd tussen "alert is afgegaan" en "fix is begrepen". Het is vooral een kwestie van discipline. Geef spans de naam van functies, zet het repo-pad in een span-attribuut en houd per service een korte architectuurnotitie bij. Een AI-assistent die vragen over je repo kan beantwoorden, zoals "waar wordt het retrybeleid voor betalingsaanroepen ingesteld?", heeft dan iets concreets om zich aan vast te houden.

![Ontwikkelaar die met een codeeditor en een metrics-dashboard naast elkaar werkt](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/5fe138-i3.webp)

## Drie fouten waardoor teams denken dat observability niet werkt

**Dashboards als doel zien.** Een dashboard is een opgeslagen antwoord op een oude vraag. Teams die er veertig bouwen en nooit ad-hocqueries oefenen, eindigen met monitoring in een mooier jasje. Vraag bij elk incident: hebben we dit uit een dashboard beantwoord, of door de ruwe data te verkennen?

**Te vroeg samplen, of nooit.** Op een druk gebruikte service 100% van de traces bewaren wordt snel duur. Willekeurig 1% bewaren gooit dan weer de zeldzame falende aanvraag weg waar je om geeft. Tail-based sampling, dat trage en falende traces bewaart en de meeste gezonde traces weggooit, is het gebruikelijke compromis. Beslis dit vóór de eerste factuur, niet erna.

**Attribuutnamen laten uiteenlopen.** Eén service schrijft `user_id`, een andere `userId`, een derde `uid`. Dan levert de query die alle drie zou moeten omvatten maar een derde van het plaatje op. Spreek een kleine naamgevingsconventie af voor tenant-, gebruiker-, versie- en flagattributen, en schrijf die op in de repo waar mensen hem zullen vinden.

Geen van deze drie is een toolprobleem. Het zijn gewoontes, en gewoontes zijn goedkoper te repareren dan leveranciers.

## Een realistische manier om te beginnen zonder de oceaan te willen koken

Heb je vandaag niets, verzet je dan tegen de drang om in week één alles te instrumenteren. Dit is een volgorde die werkt voor teams van 5 tot 50 engineers:

- 
**Kies één kritieke gebruikersstroom.** Checkout, aanmelding, de belangrijkste API-aanroep. Niet het hele systeem.

- 
**Voeg gestructureerde logs toe met een request-ID.** JSON, één gebeurtenis per regel, met een trace- of request-ID op elke regel.

- 
**Instrumenteer die stroom met OpenTelemetry-traces.** Neem tenant-, versie- en flagattributen op uit het voorbeeld hierboven.

- 
**Definieer twee of drie service-level objectives.** Bijvoorbeeld: 99.5% van de checkout-verzoeken slaagt in minder dan 800 ms. Alerts hangen daaraan, niet aan de CPU.

- 
**Bekijk één echt incident aan de hand van de data.** Had je de oorzaak kunnen vinden zonder nieuwe code? Zo niet, dan is de lacune die je vindt je volgende instrumentatietaak.

Stap 5 is degene die wordt overgeslagen, en het is de enige die je vertelt of je observeerbaar bent. Al het andere is leidingwerk.

## Wat wij echt zouden doen

Heeft je team minder dan 20 engineers, begin dan met OpenTelemetry-instrumentatie en een backend waarvan je de prijs kunt voorspellen. De instrumentatie is draagbaar, dus de keuze voor de backend is omkeerbaar. Koop niet het grootste platform omdat een concurrent dat deed.

Betaal je al voor een alles-in-één-tool, scheur die dan niet weg. Controleer wat je ingest, laat de logs vallen die niemand bevraagt, en besteed de besparing aan het instrumenteren van de stromen die ertoe doen.

En welke kant je ook op gaat: schrijf op hoe een span terugverwijst naar code. Het dashboard laat zien dat het brandt. Iemand moet nog steeds de broncode lezen om te achterhalen waarom het begon.

## FAQ

### Wat is observability in eenvoudige woorden?

Observability is hoe goed je kunt begrijpen wat er in een systeem gebeurt, op basis van de data die het produceert. Als je de oorzaak van een probleem dat je niet voorzag kunt vinden, met logs, metrics en traces, zonder nieuwe code uit te rollen, dan is het systeem observeerbaar.

### Wat is het verschil tussen observability en monitoring?

Monitoring houdt toezicht op bekende problemen met vooraf gedefinieerde metrics en drempels. Observability laat je onbekende problemen onderzoeken door gedetailleerde telemetrie te verkennen. Monitoring is de alertlaag, en observability is wat je gebruikt om de oorzaak te vinden nadat een alert is afgegaan.

### Wat zijn de drie pijlers van observability?

Metrics, logs en traces. Metrics zijn getallen over tijd, logs zijn records van afzonderlijke gebeurtenissen en traces volgen één verzoek over services heen. Ze zijn het nuttigst wanneer ze via gedeelde ID's aan elkaar gekoppeld zijn.

### Heb ik OpenTelemetry nodig om observeerbaar te zijn?

Nee, maar het helpt. OpenTelemetry is een leverancier-neutrale standaard om logs, metrics en traces uit te sturen. Als je ermee instrumenteert, kun je later van observability-backend wisselen zonder je services opnieuw te instrumenteren.

### Is observability alleen voor microservices?

Nee. Gedistribueerde systemen profiteren het meest, omdat één verzoek veel services raakt, maar een monolith met een database, een queue en een paar externe API's heeft ook baat bij gestructureerde logs en traces.

### Hoeveel kost observability?

Dat hangt af van het datavolume en de tool. Gehoste platformen rekenen meestal op basis van gebruik, dus de rekening groeit met het verkeer, terwijl open-sourcestacks licentiekosten ruilen voor engineeringtijd. Ongebruikte logs laten vallen en traces samplen zijn de twee meest gebruikelijke manieren om de uitgaven te beperken.