Prometheus-sollicitatievragen 2026: Prometheus vs Grafana vs Datadog vergeleken

Vragen over Prometheus komen in vrijwel elke DevOps- en SRE-sollicitatie terug, meestal gevolgd door "waarom niet Grafana of Datadog?" Kandidaten moeten kunnen uitleggen hoe Prometheus metrics scrapet en opslaat, correcte PromQL schrijven en de afwegingen tegenover een beheerd platform onderbouwen. Interviewers gebruiken dit om echte operationele ervaring te onderscheiden van kennis uit het boek. De interviewmodule over Prometheus en monitoring behandelt dezelfde onderwerpen als oefenvragen.

Prometheus-sollicitatievragen in DevOps- en SRE-rondes

Dit zijn de Prometheus-specifieke vragen die het vaakst terugkomen, met het antwoord dat een zelfverzekerde kandidaat geeft. Ze gaan uit van Prometheus 3.x: de huidige stabiele lijn is 3.15 (september 2026), met 3.16 als release candidate.

V: Waarom haalt Prometheus metrics op in plaats van pushes te ontvangen?

Door te pullen wordt de gezondheid van targets zichtbaar: elke scrape levert een up-reeks op, zodat een uitgevallen target verschijnt als up == 0 in plaats van als stilte. De server bepaalt het scrapetempo, wat hem beschermt tegen een misdragende client, en een target is met de hand te controleren door het /metrics-endpoint in een browser te openen. De keerzijde is dat Prometheus elk target over het netwerk moet kunnen bereiken. Daarom hebben kortlopende batchjobs de Pushgateway nodig en gebruiken opstellingen over meerdere netwerken remote write.

V: Wat zijn de vier metrictypes, en wanneer is een summary de verkeerde keuze?

Counter (stijgt alleen, wordt gereset bij een herstart), gauge (stijgt en daalt), histogram (waarnemingen geteld in buckets) en summary (kwantielen berekend in de client). De kwantielen van een summary zijn niet te aggregeren: het gemiddelde van de p99 van tien pods is niet de p99 van de service. Histogrammen kunnen eerst over instances worden opgeteld en daarna op de server tot een kwantiel worden omgerekend. Daarom zijn ze de standaard voor latency.

# Classic histogram: aggregate the buckets, keep the le label
histogram_quantile(0.99,
  sum by (le, job) (rate(http_request_duration_seconds_bucket[5m])))

# Native histogram: no _bucket suffix, no le label
histogram_quantile(0.99,
  sum by (job) (rate(http_request_duration_seconds[5m])))

Het vergeten van le in de by-clausule van de klassieke vorm is de meest gemaakte PromQL-fout tijdens live coding: de query levert niets bruikbaars op.

V: Wat is het verschil tussen rate(), irate() en increase()?

rate() geeft het gemiddelde per seconde over het hele bereik en vangt counter-resets op. irate() gebruikt alleen de laatste twee samples in het bereik, reageert dus snel maar is onrustig: prima voor een ingezoomde grafiek, verkeerd voor alerting. increase() is rate() vermenigvuldigd met de duur van het bereik. Omdat Prometheus extrapoleert naar de grenzen van het venster, kan increase() op een integer-counter een niet-geheel getal opleveren, en interviewers vragen graag waarom.

V: Wat is cardinaliteit, en hoe wordt een cardinaliteitsexplosie gediagnosticeerd?

Elke unieke combinatie van metricnaam en labelwaarden is een aparte tijdreeks die in het geheugen wordt gehouden. Een label als user_id, email of een ruw URL-pad met ID's vermenigvuldigt het aantal reeksen tot de server geen geheugen meer heeft. De diagnose begint op de TSDB-statuspagina (/tsdb-status) of met een query:

# Top 10 metric names by number of series
topk(10, count by (__name__) ({__name__=~".+"}))

De oplossing ligt bij de bron: het label verwijderen of herschrijven met metric_relabel_configs, of sample_limit instellen op de scrapejob, zodat een enkele foute deployment de server niet kan platleggen.

V: Waarvoor dienen recording rules?

Ze berekenen een dure expressie vooraf bij elk evaluatie-interval en slaan het resultaat op als nieuwe reeks. Dashboards en alerts bevragen daarna die goedkope, vooraf berekende reeks. De naamgevingsconventie is level:metric:operations:

groups:
  - name: api-recording-rules
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

V: Wat doet de for-clausule in een alertingregel?

Een alert waarvan de expressie waar wordt, gaat van inactive naar pending en bereikt pas firing zodra de conditie de duur van for heeft standgehouden. Dat filtert uitschieters van een enkele scrape weg. keep_firing_for doet het omgekeerde: de alert blijft nog een tijd actief nadat de conditie is verdwenen, waardoor een flapperende alert niet twee keer pagineert.

V: Hoe wordt Prometheus hoog beschikbaar gemaakt?

Door twee identieke replica's dezelfde targets te laten scrapen, elk met een eigen extern label replica. Beide sturen alerts naar een Alertmanager-cluster, dat notificaties dedupliceert via zijn gossipprotocol. Voor queries dedupliceert Thanos Query of Mimir de twee reeksen door het replicalabel te negeren. Prometheus zelf kent geen clustering: de lokale TSDB van een enkele server wordt niet gerepliceerd.

V: Federatie of remote write voor opstellingen met meerdere clusters?

Met federatie scrapet een globale Prometheus geselecteerde, meestal geaggregeerde reeksen van het /federate-endpoint van de Prometheus in elk cluster. Dat past bij een klein aantal rollups. Remote write streamt elke sample naar een centrale opslag zoals Mimir, Thanos Receive of een backend van een leverancier, en is het standaardantwoord voor globale queries en langetermijnretentie.

V: Hoe wordt een target gedetecteerd dat uit service discovery is verdwenen?

up == 0 gaat alleen af zolang het target nog wordt ontdekt. Als de pod of de vermelding in service discovery weg is, houdt de reeks op te bestaan en gaat de alert nooit af. absent(up{job="api-server"}) dekt dat geval af.

V: Wat is er veranderd in Prometheus 3?

Prometheus 3.0 (november 2024) bracht een nieuwe UI, stond UTF-8-tekens toe in metric- en labelnamen en voegde een ingebouwde OTLP-receiver toe op /api/v1/otlp/v1/metrics, in te schakelen met --web.enable-otlp-receiver. Native histogrammen werden stabiel in 3.8. Sinds 3.9 doet de oude feature flag niets meer en vereist ingestie scrape_native_histograms: true in de scrape- of globale configuratie. Versie 3.15 maakte de XOR2-chunkcodering voor floats stabiel en voegde scraping van OpenMetrics 2.0 toe.

Architectuur en datamodel: hoe elke tool met metrics omgaat

Zodra de basis van Prometheus is behandeld, stappen interviewers meestal over op de architectuurverschillen tussen de drie tools.

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 geïdentificeerd door een metricnaam gecombineerd met key-value-labels. De 3.x-lijn voegt stabiele native histogrammen toe, een OTLP-receiver en Remote Write 2.0 om samples naar centrale opslag te versturen.

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. Grafana 13, aangekondigd op GrafanaCON in april 2026, maakte Git Sync voor dashboards algemeen beschikbaar, zette dynamische dashboards standaard aan en verwijderde de commando's grafana-cli en grafana-server.

Datadog hanteert een push-gebaseerde aanpak als volledig beheerd SaaS-platform. Op hosts geïnstalleerde 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 platform. De Watchdog-engine signaleert anomalieën automatisch, zonder handmatige configuratie van drempelwaarden.

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

scrape_configs:
  - job_name: 'api-server'
    scrape_native_histograms: true
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__

Deze YAML beschrijft het pull-model van Prometheus: pods worden via Kubernetes service discovery ontdekt, alleen pods met de annotatie prometheus.io/scrape: "true" blijven over, het adres wordt herschreven naar de geannoteerde poort en /metrics wordt elke 15 seconden gescrapet. De tweede regel voegt beide bronlabels samen met ;, en daarom matcht de regex host:port;port.

PromQL versus Datadog-querytaal: syntaxis en mogelijkheden

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.

# 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 (no built-in PromQL equivalent)
anomalies(avg:system.cpu.user{service:api-server}, 'agile', 3)

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

PromQL biedt meer expressiviteit voor ad-hoc-analyse. De Datadog-querytaal levert een deel van die flexibiliteit in voor ingebouwde algoritmische functies zoals anomalies() (algoritmen basic, agile, robust) en forecast() (linear, seasonal), die in een Prometheus-stack externe tooling zouden vereisen.

Alerting: regelgebaseerde versus ML-gestuurde detectie

De alertingfilosofie loopt sterk uiteen tussen deze tools, en wie deze verschillen kan bespreken, toont in een interview operationele volwassenheid.

Prometheus Alertmanager ontvangt alerts van regels die Prometheus op vaste intervallen evalueert, en routeert ze via een configureerbare pipeline met 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 stelt het team expliciete drempelwaarden vast. Het voordeel is volledige transparantie: elke alert is terug te voeren op een controleerbare expressie. Het nadeel is drempelmoeheid, omdat statische waarden vaak seizoensgebonden bijstelling nodig hebben.

Grafana Alerting (het geünificeerde alertingsysteem, standaard sinds Grafana 9) evalueert queries over alle gekoppelde databronnen en biedt multidimensionale alerts met notificatiebeleid.

Datadog Monitors combineren statische drempelwaarden met anomalie-, outlier- en forecastmonitors. Watchdog signaleert prestatieafwijkingen automatisch, zonder handmatig aangemaakte regels. Dat verlaagt de configuratielast, ten koste van inzicht in de detectielogica.

Prijsstelling en Total Cost of Ownership in 2026

Kosten zijn een doorslaggevende factor bij toolselectie en komen geregeld ter sprake in system design-interviews. Een goed begrip van kostenstructuren toont zakelijk bewustzijn. De Datadog-bedragen hieronder zijn catalogusprijzen bij jaarlijkse facturering.

De open-source stack oogt op papier voordeliger, maar vergt engineeringtijd voor upgrades, capaciteitsplanning en configuratie van hoge beschikbaarheid. Het beheerde model van Datadog verplaatst die last naar de leverancier. Voor teams met minder dan vijf engineers op de infrastructuur leveren beheerde oplossingen vaak lagere totale kosten op zodra engineeringtijd wordt meegerekend.

Kubernetes-monitoring: diepte van integratie

Prometheus is het standaard metricssysteem van het Kubernetes-ecosysteem, waardoor dit het dominante interviewonderwerp is bij monitoring van 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. Het overschrijven van chartwaarden op deze manier komt uitgebreider aan bod in de interviewgids over Helm-charts.

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

Voor teams die al in het Kubernetes-ecosysteem zitten, voorkomt de Prometheus-native aanpak een externe afhankelijkheid. Teams die snelle opzet met minder operationele investering voorop stellen, neigen eerder naar Datadog.

OpenTelemetry en leveranciersneutraliteit

OpenTelemetry (OTel) is de industriestandaard voor instrumentatie geworden, en interviewers vragen er steeds vaker naar naast vergelijkingen tussen monitoringtools.

Prometheus 3.x accepteert OTLP-metrics rechtstreeks zodra --web.enable-otlp-receiver is ingesteld, waardoor een Collector als tussenlaag niet langer nodig is. Grafana Alloy, de opvolger van Grafana Agent, functioneert zowel als OpenTelemetry Collector als Prometheus-scraper. Datadog ondersteunt OTLP-ingestie maar adviseert de eigen proprietary agents voor "volledige functietoegang", wat een zachte vorm van lock-in creëert.

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

Observability-sollicitatievragen die de drie tools vergelijken

Naast Prometheus zelf toetsen deze vragen of een kandidaat over tools heen kan redeneren. Bij elk antwoord staat het concept centraal dat de interviewer controleert.

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. Monitoring beantwoordt de vraag "is het systeem gezond?", observability de vraag "waarom is het systeem niet gezond?"

V: In welke situaties is Prometheus geen geschikte keuze?

Prometheus geeft prioriteit aan betrouwbaarheid boven duurzaamheid: de beschikbaarheid van het monitoringsysteem zelf gaat voor. Scenario's waarin Prometheus tekortschiet: langetermijnopslag van meer dan dertig dagen (hiervoor is Thanos, Mimir of Cortex nodig), facturatiedata op requestniveau die honderd procent nauwkeurigheid vereist (scrape-gebaseerde verzameling kan samples missen), en eventgebaseerde systemen die push-gebaseerde verzameling nodig hebben (de Pushgateway bestaat, maar alleen voor batchjobs op serviceniveau).

V: Wat houdt Grafana's "Big Tent"-filosofie in en hoe beïnvloedt 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.

Besliskader: welke stack past bij welke situatie?

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.

Bronnen

• Prometheus-releases: 3.15.0 (september 2026) maakt de XOR2-chunkcodering stabiel, voegt scraping van OpenMetrics 2.0 toe en markeert --log.level als verouderd
• Specificatie van native histogrammen in Prometheus: stabiel sinds 3.8, scrape_native_histograms verplicht sinds 3.9
• Wat is er nieuw in Grafana 13.0: Git Sync algemeen beschikbaar, dynamische dashboards standaard, breaking changes
• Catalogusprijzen van Datadog: prijzen voor infrastructure, APM en logs uit de kostentabel
• Algoritmische functies van Datadog: syntaxis van anomalies() en forecast()

Wat te onthouden voor een Prometheus- of observability-interview

• Prometheus is de standaard voor metricsverzameling in Kubernetes-omgevingen; pull versus push, de vier metrictypes, rate() versus irate(), cardinaliteit en hoge beschikbaarheid horen paraat te zijn
• Op Prometheus 3.9 en later worden native histogrammen alleen ingenomen wanneer scrape_native_histograms: true is ingesteld
• Grafana is een visualisatielaag en geen metricsdatabase: het verbindt met meer dan honderd databronnen, waaronder Prometheus, en de LGTM-stack (Loki, Grafana, Tempo, Mimir) vormt een compleet open-source observabilityplatform
• Datadog levert het snelste traject naar full-stack observability met ingebouwde anomaliedetectie, tegen hogere kosten en met vendor lock-in
• De adoptie van OpenTelemetry maakt de backendkeuze minder definitief: de instrumentatie blijft identiek, ongeacht welke tool de data opslaat en bevraagt
• Laat tijdens sollicitaties zien dat afwegingen tussen kosten, controle en complexiteit worden doordacht, in plaats van een enkele tool te promoten
• Voor bredere voorbereiding behandelt de gids met essentiële DevOps-sollicitatievragen de aangrenzende onderwerpen die interviewers aan monitoring koppelen