Website under construction feedback appreciated at [email protected]
← Terug naar blog
devops

Observability zonder dat je drie tools koopt

Yair Knijn · · 4 min lezen

Observability heeft een reputatie gekregen als iets duur en complex. Drie pilaren (logs, metrics, traces), drie tools, drie facturen. Dat hoeft niet. Je kunt een werkbare stack bouwen met één coherent geheel, zeker als je weet wat je kiest en waarom.

De drie pilaren, kort

Logs zijn tekstuele records van wat er is gebeurd. “Request failed, status 503, user ID 4821.” Goed voor debuggen achteraf.

Metrics zijn numerieke tijdreeksen. CPU-gebruik, requestduur in percentiles, foutpercentage per endpoint. Goed voor dashboards en alerts.

Traces volgen een request door je hele systeem. Van API-gateway via service A naar database en terug. Goed voor het vinden van de bottleneck als je weet dat iets traag is maar niet waar.

Je hebt alle drie nodig. Het punt is dat je ze uit dezelfde tool kunt halen.

OpenTelemetry als fundament

OpenTelemetry (OTel) is de standaard geworden voor het genereren en verzenden van observability-data. Het is een open source CNCF-project met brede ondersteuning: vrijwel elke taal heeft een SDK, vrijwel elk platform heeft een integratie.

Het idee is dat je je applicatie instrumenteert met de OTel SDK, en daarna kiest waar de data naartoe gaat via de OpenTelemetry Collector. Die collector is je router: stuur logs naar Loki, metrics naar Mimir, traces naar Tempo. Of stuur alles naar Datadog. Of naar twee bestemmingen tegelijk.

De OTel SDK koppelt je code los van je vendor. Als je vandaag Jaeger gebruikt en morgen overstapt op Honeycomb, herschrijf je geen instrumentatie.

Bekijk OpenTelemetry en observability trainingen

De Grafana stack: volledig zelf-gehost, volledig gratis

De meest populaire open source observability-stack combineert:

  • Loki voor logs (geen full-text index, alleen labels, dus goedkoop in opslag)
  • Mimir voor metrics (horizontaal schaalbare Prometheus-backend)
  • Tempo voor traces (object-storage-native, goedkoop bij hoge volumes)
  • Grafana als frontend voor alle drie

Je draait dit zelf op Kubernetes of op een paar VM’s. De software is gratis; je betaalt alleen voor compute en opslag. Voor een middelgrote organisatie met tien services en gemiddeld verkeer kom je uit op een paar tientjes per maand aan cloudkosten.

Het nadeel is dat je het zelf beheert. Upgrades, retentieconfiguratie, schaling als het volume groeit: dat ben jij. Voor een klein team zonder dedicated platform-engineer kan dat te veel zijn.

Grafana Labs biedt ook een managed versie aan (Grafana Cloud) met een genereuze gratis tier. Tot 50 GB logs, 10.000 metrics series en 50 GB traces per maand kost het niets. Daarboven betaal je per eenheid.

Wanneer cloud-managed zinnig is

Als je niet zelf wilt beheren, zijn er drie serieuze opties: Grafana Cloud, Honeycomb en Datadog.

Grafana Cloud is de goedkoopste van de drie voor standaard gebruik. Je betaalt voor wat je stuurt, en de prijsstructuur is redelijk transparant.

Honeycomb is gebouwd rond traces en is sterk in high-cardinality queries. Je kunt vragen stellen als “toon alle requests waarbij user-ID begint met 48xx en de duur boven 800ms was.” Dat kan Prometheus niet goed. Honeycomb kost meer dan Grafana maar is voor bepaalde use cases het geld waard.

Datadog is de marktleider. De interface is goed, de integraties zijn breed, en sales is agressief. Reken op €15 tot €30 per host per maand voor de standaard infra + logs + APM bundel. Bij tien hosts is dat €150-300 per maand, bij honderd hosts loopt het op naar €1.500-3.000. Dat telt op.

De kostenvalkuil bij hoge cardinality

Met Datadog en vergelijkbare tools betaal je soms per metric-serie in plaats van per datapunt. Als je labels toevoegt met hoge cardinality (denk aan user-ID of request-ID als label), exploodeert het aantal series en daarmee de factuur.

Hetzelfde geldt voor logvolumes. Als je elke SQL-query logt op debug-niveau in productie, stuur je snel tientallen gigabytes per dag naar een platform dat per gigabyte afrekent.

Dit is beheersbaar, maar je moet er bewust mee omgaan: stel log-levels correct in, gebruik sampling voor traces, en zet cardinality-limieten op je metrics.

Wanneer Datadog de juiste keuze is

Datadog is rechtvaardigbaar als je team geen tijd heeft om een self-hosted stack te beheren, als je al veel Datadog-integraties gebruikt (AWS, Kubernetes, third-party services), of als compliance vereist dat je audit logs en monitoring bij een gecertificeerde provider onderbrengt.

Voor een startup of een klein DevOps-team is de Grafana stack of Grafana Cloud vrijwel altijd de betere keuze. Begin daar, en ga naar Datadog als je een concreet probleem hebt dat Grafana niet oplost.

observability opentelemetry monitoring devops