Prometheus vs Grafana vs Datadog in 2026: Monitoringtools Vergeleken en DevOps-sollicitatievragen

Bij DevOps-sollicitaties duikt de vergelijking tussen Prometheus, Grafana en Datadog telkens opnieuw op. Het is een van de meest voorkomende technische discussiepunten, omdat het antwoord veel onthult over de operationele ervaring van een kandidaat. Wie de architectuur, sterktes en beperkingen van deze drie tools kan benoemen, laat zien dat de kennis verder reikt dan documentatie lezen alleen.

Architectuur en datamodel: drie fundamenteel verschillende benaderingen

De architectuurkeuzes achter deze tools vormen een geliefd onderwerp bij technische interviews. Interviewers gebruiken het om te peilen of een kandidaat begrijpt hoe monitoringdata door een systeem stroomt, van instrumentatie tot visualisatie.

Prometheus werkt met een pull-gebaseerd model. De server benadert op geconfigureerde intervallen HTTP-endpoints (standaard /metrics) en haalt daar tijdreeksdata op, die vervolgens worden opgeslagen in een eigen lokale time-series database (TSDB). Elke tijdreeks wordt uniek geidentificeerd door een metricnaam gecombineerd met key-value-labels. Sinds de release van Prometheus 3.0 in november 2024 hebben native histogrammen een stabiele status bereikt in versie 3.8, is OTLP-ingestie standaard beschikbaar en verbetert Remote Write 2.0 de mogelijkheden voor federatie tussen meerdere clusters.

Grafana slaat zelf geen metrics op en verzamelt ook geen data. Het functioneert als een visualisatieplatform dat verbinding maakt met databronnen als Prometheus, Loki, Tempo, InfluxDB, Elasticsearch en meer dan honderd andere. Grafana Labs biedt daarnaast Mimir (langetermijn-metricsopslag), Loki (logaggregatie) en Tempo (gedistribueerde tracing) aan. Samen vormen deze componenten een complete open-source observabilitystack, vaak aangeduid als de LGTM-stack. Versie 13, uitgebracht in mei 2026, introduceerde observability-as-code-workflows, Git Sync voor dashboardbeheer en SQL Expressions waarmee queries over meerdere databronnen heen geschreven kunnen worden.

Datadog hanteert een push-gebaseerde aanpak als volledig beheerd SaaS-platform. Op hosts geinstalleerde agents versturen metrics, logs en traces naar het cloudbackend van Datadog. Het volledige traject van ingestie, opslag, queries, alerting en dashboarding vindt plaats binnen een enkel beheerd ecosysteem. De ingebouwde Watchdog ML-engine detecteert automatisch anomalieen, zonder dat handmatige drempelwaardeconfiguratie nodig is.

# prometheus.yml - Pull-based scrape configuration
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'api-server'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        target_label: __address__
        regex: (.+)
        replacement: ${1}:${2}

Bovenstaande YAML illustreert het pull-model van Prometheus in de praktijk: via Kubernetes service discovery worden pods automatisch ontdekt en hun /metrics-endpoints elke 15 seconden gescraped.

PromQL versus Datadog-querytaal: syntaxis en toepassingen

Querytalen zijn een terugkerend thema in technische sollicitatiegesprekken. Van kandidaten wordt verwacht dat zij vlot kunnen werken met ten minste een van beide talen en de onderlinge afwegingen helder kunnen verwoorden.

PromQL (Prometheus Query Language) geldt als de standaard voor metricsqueries binnen het Prometheus- en Grafana-ecosysteem. De taal ondersteunt instant vectors, range vectors, aggregatie-operatoren en recording rules, wat diepgaande ad-hoc-analyse mogelijk maakt.

# Request rate per service over 5 minutes
rate(http_requests_total{job="api-server"}[5m])

# 99th percentile latency using native histograms
histogram_quantile(0.99, rate(http_request_duration_seconds[5m]))

# Error rate as percentage
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m])) * 100

# Predict disk full in 4 hours using linear regression
predict_linear(node_filesystem_avail_bytes[1h], 4 * 3600) < 0

De Datadog-querytaal volgt een andere syntaxis die is opgebouwd rondom functies en scopedefinities:

# Equivalent request rate in Datadog
sum:http.requests{service:api-server}.as_rate()

# Anomaly detection (Watchdog ML - no equivalent in PromQL)
anomaly(avg:system.cpu.user{service:api-server}, 'agile', 3)

# Forecast query
forecast(avg:system.disk.free{host:web-01}, 'linear', 1)

Het verschil in expressiviteit is significant. PromQL biedt meer diepgang voor vrije analyse en complexe berekeningen. De Datadog-querytaal compenseert een deel van die flexibiliteit met ingebouwde ML-functies zoals anomaly() en forecast(). Het implementeren van vergelijkbare functionaliteit in een Prometheus-omgeving vereist externe tooling of custom oplossingen.

Alerting: regelgebaseerd versus ML-gestuurd

De alertingfilosofie loopt sterk uiteen tussen deze tools. Het vermogen om deze verschillen te doorgronden en te bespreken getuigt van operationele volwassenheid, een eigenschap waar interviewers expliciet naar zoeken.

Prometheus Alertmanager evalueert alertingregels op vaste intervallen en routeert meldingen via een configureerbare pipeline met ondersteuning voor groepering, demping (silencing) en inhibitie:

# alert-rules.yml - Prometheus alerting rules
groups:
  - name: api-server-alerts
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5..",job="api-server"}[5m]))
          / sum(rate(http_requests_total{job="api-server"}[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "API error rate above 5% for 5 minutes"
          runbook: "https://wiki.internal/runbooks/high-error-rate"

      - alert: PodMemoryPressure
        expr: |
          container_memory_working_set_bytes{namespace="production"}
          / container_spec_memory_limit_bytes{namespace="production"} > 0.9
        for: 10m
        labels:
          severity: warning

Bij deze aanpak is het de verantwoordelijkheid van het team om expliciete drempelwaarden vast te stellen. Het grote voordeel is volledige transparantie: elke alert is terug te voeren op een controleerbare expressie. Het nadeel is het risico op drempelvalmoeheid, waarbij statische waarden regelmatig moeten worden bijgesteld op basis van seizoenspatronen of veranderende verkeersprofielen.

Grafana Alerting (geunificeerd sinds Grafana 12 en verder) evalueert queries over alle gekoppelde databronnen en biedt multidimensionale alerts met configureerbaar notificatiebeleid.

Datadog Monitors combineren klassieke statische drempelwaarden met ML-gestuurde anomalie-, outlier- en forecastmonitors. Watchdog identificeert prestatieafwijkingen automatisch zonder dat daar handmatige regelcreatie voor nodig is. Dit reduceert de configuratielast aanzienlijk, maar gaat ten koste van inzicht in de onderliggende detectielogica.

Prijsstelling en Total Cost of Ownership

Kosten zijn een doorslaggevende factor bij toolselectie en komen geregeld ter sprake in system design-interviews. Een goed begrip van kostenstructuren demonstreert niet alleen technische kennis maar ook zakelijk bewustzijn.

| Dimensie | Prometheus + Grafana | Datadog | |----------|---------------------|--------| | Licentie | Gratis (AGPL / Apache 2.0) | $15-31/host/maand (jaarcontract) | | Metricsopslag | Zelfbeheerd (Mimir/Thanos) | Inbegrepen, prijs op basis van retentie | | Logbeheer | Loki (self-hosted) | $0,10/GB ingestie + indexeringskosten | | APM / Traces | Tempo (self-hosted) | $31/host/maand | | Infrastructuurkosten | Compute + storage voor de volledige stack | Niet van toepassing (SaaS) | | Operationele overhead | Hoog (upgrades, schaling, hoge beschikbaarheid) | Minimaal | | Geschatte jaarkosten (50 hosts) | $20K-60K (infrastructuur + engineeringtijd) | $50K-150K | | Vendor lock-in | Laag (OpenTelemetry, open standaarden) | Hoger (proprietary querytaal, agentafhankelijkheid) |

De open-source stack oogt op papier voordeliger, maar vergt gespecialiseerde engineeringtijd voor onderhoud, upgrades, capaciteitsplanning en configuratie van hoge beschikbaarheid. Het beheerde model van Datadog verplaatst die verantwoordelijkheid naar de leverancier. Voor organisaties met een klein infrastructuurteam (minder dan vijf engineers) resulteert een beheerde oplossing vaak in lagere totale kosten wanneer de tijdsbesteding van engineers wordt meegerekend in de berekening.

Kubernetes-monitoring: diepte van integratie

Meer dan 80% van alle Kubernetes-clusters maakt gebruik van Prometheus voor het verzamelen van metrics. Dit maakt Kubernetes-monitoring een van de meest besproken onderwerpen in interviews over containerorchestratie.

Prometheus + Grafana integreert native met Kubernetes via de kube-prometheus-stack Helm-chart. Deze chart rolt Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics en vooraf geconfigureerde Grafana-dashboards uit in een enkele installatie:

# Deploy full monitoring stack on Kubernetes
helm repo add prometheus-community \
  https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi

Het resultaat is een productieklare monitoringstack met persistente opslag en dertig dagen dataretentie. De Prometheus Operator maakt gebruik van Custom Resource Definitions (ServiceMonitor, PodMonitor) om scrape targets op een declaratieve manier te beheren.

Datadog wordt in Kubernetes uitgerold als een agent-DaemonSet in combinatie met een Cluster Agent. De Cluster Agent centraliseert de communicatie met de Kubernetes API-server, waardoor de belasting op die server afneemt bij grootschalige clusters. De Live Containers-weergave van Datadog biedt realtime inzicht in podstatussen, terwijl Orchestrator Explorer de relaties tussen deployments, services en pods visueel in kaart brengt.

Voor teams die reeds diep verankerd zijn in het Kubernetes-ecosysteem biedt de Prometheus-native aanpak het voordeel dat er geen externe afhankelijkheid wordt geintroduceerd. Teams die snelheid van opzet verkiezen boven operationele controle neigen eerder naar Datadog.

OpenTelemetry en leveranciersneutraliteit

OpenTelemetry (OTel) heeft zich in 2026 definitief gepositioneerd als de industriestandaard voor instrumentatie. In sollicitatiegesprekken wordt er steeds vaker naar gevraagd, vaak in directe samenhang met vergelijkingen tussen monitoringtools.

Prometheus 3.0 en hoger accepteert OTLP-metrics native, waardoor een aparte Collector als tussenlaag overbodig is geworden. Grafana Alloy, de opvolger van Grafana Agent, functioneert als zowel een OpenTelemetry Collector als een Prometheus-scraper. Datadog ondersteunt OTLP-ingestie maar adviseert het gebruik van de eigen proprietary agents voor "volledige functietoegang". Dit creert een subtiele maar reele vorm van vendor lock-in.

De brede adoptie van OpenTelemetry is van belang omdat het de instrumentatiecode ontkoppelt van de backendkeuze. Applicaties die zijn geinstrumenteerd met OTel SDK's kunnen telemetriedata verzenden naar Prometheus, Grafana Cloud, Datadog of elk ander compatibel backend, zonder dat de applicatiecode hoeft te worden aangepast. In system design-interviews is deze flexibiliteit een sterk argument bij het bespreken van een langetermijnstrategie voor observability.

Veelgestelde DevOps-sollicitatievragen over monitoring

Onderstaande vragen verschijnen regelmatig in sollicitatiegesprekken voor DevOps- en SRE-functies. Bij elk antwoord wordt toegelicht welk concept de interviewer toetst.

V: Wat is het verschil tussen monitoring, observability en alerting?

Monitoring houdt vooraf gedefinieerde metrics bij en controleert op bekende faalscenario's. Observability stelt teams in staat om onbekende faalscenario's te onderzoeken aan de hand van metrics, logs en traces, de zogenaamde "drie pijlers". Alerting genereert notificaties zodra condities vooraf ingestelde drempelwaarden of anomaliebaselines overschrijden. In essentie beantwoordt monitoring de vraag "functioneert het systeem correct?", terwijl observability de vraag beantwoordt "waarom functioneert het systeem niet correct?"

V: In welke situaties is Prometheus geen geschikte keuze?

Prometheus geeft prioriteit aan betrouwbaarheid van het monitoringsysteem zelf boven duurzaamheid van de opgeslagen data. Scenario's waarin Prometheus tekortschiet omvatten: langetermijnopslag die verder gaat dan dertig dagen (hiervoor is Thanos, Mimir of Cortex nodig), facturatiedata op requestniveau die honderd procent nauwkeurigheid vereist (Prometheus kan onder hoge belasting samples droppen), en eventgebaseerde systemen die push-gebaseerde dataverzameling nodig hebben (de pushgateway biedt hiervoor een workaround, maar met beperkingen).

V: Wat houdt Grafana's "Big Tent"-filosofie in en hoe beinvloedt dit de observabilityarchitectuur?

Grafana verbindt met elke willekeurige databron zonder dat datamigratie vereist is. Dit betekent dat teams Prometheus, Elasticsearch, CloudWatch en Datadog gezamenlijk kunnen bevragen vanuit een enkel dashboard. De keerzijde is operationele complexiteit: het beheren van meerdere backends vereist bredere infrastructuurexpertise dan een aanpak met een enkele leverancier. Interviewers verwachten dat kandidaten deze afweging helder kunnen formuleren.

V: Wat is de high-watermark-facturering van Datadog en waarom is dit relevant?

Datadog registreert het aantal hosts op uurbasis, verwijdert de bovenste een procent van de uren en factureert op basis van de 99e-percentiel piek. Dit houdt in dat tijdelijke auto-scaling pieken, bijvoorbeeld tijdens Black Friday-verkeer, de maandelijkse factuur opvoeren, zelfs nadat de betreffende instances zijn stopgezet. Kandidaten die dit punt benoemen laten zien dat zij praktijkervaring hebben met kostenbeheer, een competentie die SRE-functies in toenemende mate vereisen.

V: Hoe verschilt een SLO-gebaseerde alertingstrategie tussen Prometheus en Datadog?

Bij Prometheus wordt SLO-alerting vormgegeven met recording rules die error budgets en burn rate-alerts vooraf berekenen. Dit volgt de multi-window, multi-burn-rate-methodiek uit het SRE-handboek van Google. Datadog biedt hiervoor ingebouwde SLO-widgets en monitors die burn rate automatisch bijhouden. Beide benaderingen implementeren hetzelfde principe, maar Prometheus vergt meer handmatige configuratie waar Datadog een beheerde workflow aanbiedt. In een goed antwoord horen burn rate-vensters (1 uur, 6 uur, 3 dagen) en error budget-verbruikssnelheden aan bod te komen.

Voor verdere oefening met monitoringonderwerpen biedt de Prometheus monitoring interviewmodule aanvullende scenario's met gedetailleerde uitleg.

Besliskader: welke stack past bij welke situatie?

| Scenario | Aanbevolen stack | Onderbouwing | |----------|-----------------|-------------| | Startup met minder dan 10 engineers | Datadog of Grafana Cloud | Operationele overhead minimaliseren | | Grote organisatie met platformteam | Prometheus + Grafana + Loki | Volledige controle, lagere kosten per eenheid op schaal | | Multi-cloud of hybride omgeving | Prometheus + Grafana | Leveranciersneutraal, consistent over alle omgevingen | | Compliance-intensieve sectoren (financien, gezondheidszorg) | Self-hosted Prometheus + Grafana | Data blijft volledig onder eigen beheer | | Snelle groei met onvoorspelbare schaalbehoeften | Grafana Cloud (beheerde Mimir) | Schaalt mee zonder eigen infrastructuurbeheer | | ML-gestuurde anomaliedetectie is een vereiste | Datadog | Watchdog functioneert zonder configuratie |

De juiste keuze wordt bepaald door drie kernvariabelen: teamomvang, operationele volwassenheid en budgetkaders. Een universeel correct antwoord bestaat niet, en interviewers waarderen kandidaten die redeneren over afwegingen in plaats van een tool als winnaar te bestempelen.

Conclusie

• Prometheus vormt de standaard voor metricsverzameling in Kubernetes-omgevingen; versie 3.x brengt in 2026 native OTLP-ondersteuning en stabiele native histogrammen mee
• Grafana is nadrukkelijk een visualisatielaag en geen metricsdatabase -- het verbindt met meer dan honderd databronnen, en de LGTM-stack (Loki, Grafana, Tempo, Mimir) vormt een compleet open-source observabilityplatform
• Datadog levert het snelste traject naar full-stack observability met ML-gestuurde alerting, maar tegen hogere kosten en met het risico van vendor lock-in
• De adoptie van OpenTelemetry maakt de backendkeuze minder definitief: de instrumentatiecode blijft identiek, ongeacht welke tool de data opslaat en bevraagt
• Laat tijdens sollicitaties het vermogen zien om te redeneren over afwegingen tussen kosten, controle en complexiteit, in plaats van een enkele tool te promoten
• Gebruik voor gerichte voorbereiding de DevOps-interviewvragen module en verdiep aangrenzende kennis via de CI/CD-pipeline gids