Prometheus-Interviewfragen 2026: Prometheus vs Grafana vs Datadog im Vergleich

Interviewfragen zu Prometheus kommen in fast jeder DevOps- und SRE-Runde vor, meist gefolgt von "Warum nicht Grafana oder Datadog?". Kandidaten müssen erklären können, wie Prometheus Metriken abfragt und speichert, korrektes PromQL schreiben und die Kompromisse gegenüber einer verwalteten Plattform begründen. Interviewer trennen damit echte Betriebserfahrung von Lehrbuchwissen. Das Interviewmodul zu Prometheus und Monitoring enthält dieselben Themen als Übungsfragen.

Prometheus-Interviewfragen in DevOps- und SRE-Runden

Die folgenden Prometheus-spezifischen Fragen tauchen am häufigsten auf, jeweils mit der Antwort, die ein sicherer Kandidat gibt. Sie setzen Prometheus 3.x voraus: Die aktuelle stabile Linie ist 3.15 (September 2026), 3.16 befindet sich im Release-Candidate-Stadium.

F: Warum holt Prometheus Metriken ab, statt sie per Push zu empfangen?

Das Pull-Modell macht den Zustand der Targets beobachtbar: Jeder Scrape erzeugt eine up-Zeitreihe, ein ausgefallenes Target erscheint also als up == 0 statt als Stille. Der Server bestimmt die Scrape-Rate und schützt sich so vor einem fehlerhaften Client, und jedes Target lässt sich manuell prüfen, indem sein /metrics-Endpunkt im Browser geöffnet wird. Der Preis: Prometheus muss jedes Target über das Netzwerk erreichen. Deshalb brauchen kurzlebige Batch-Jobs das Pushgateway, und netzwerkübergreifende Setups nutzen Remote Write.

F: Welche vier Metriktypen gibt es, und wann ist eine Summary die falsche Wahl?

Counter (steigt nur, wird beim Neustart zurückgesetzt), Gauge (steigt und fällt), Histogram (Beobachtungen werden in Buckets gezählt) und Summary (Quantile werden im Client berechnet). Die Quantile einer Summary lassen sich nicht aggregieren: Der Durchschnitt der p99-Werte von zehn Pods ergibt nicht das p99 des Service. Histogramme lassen sich zuerst über Instanzen summieren und dann auf dem Server in ein Quantil umrechnen, weshalb sie für Latenzen der Standard sind.

# 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])))

le in der by-Klausel der klassischen Variante zu vergessen, ist der häufigste PromQL-Fehler in Live-Coding-Runden: Die Abfrage liefert dann nichts Verwertbares.

F: Was ist der Unterschied zwischen rate(), irate() und increase()?

rate() liefert den durchschnittlichen Wert pro Sekunde über das gesamte Zeitfenster und behandelt Counter-Resets. irate() verwendet nur die letzten beiden Samples im Fenster, reagiert daher schnell, ist aber verrauscht: geeignet für einen herangezoomten Graphen, ungeeignet für Alerting. increase() ist rate() multipliziert mit der Fensterdauer. Da Prometheus bis an die Fenstergrenzen extrapoliert, kann increase() auf einem ganzzahligen Counter einen nicht ganzzahligen Wert liefern, und Interviewer fragen gern nach dem Grund.

F: Was ist Cardinality, und wie wird eine Cardinality-Explosion diagnostiziert?

Jede eindeutige Kombination aus Metrikname und Label-Werten ist eine eigene Zeitreihe im Arbeitsspeicher. Ein Label wie user_id, email oder ein roher URL-Pfad mit IDs vervielfacht die Zahl der Zeitreihen, bis dem Server der Speicher ausgeht. Die Diagnose beginnt auf der TSDB-Statusseite (/tsdb-status) oder mit einer Abfrage:

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

Die Korrektur erfolgt an der Quelle: das Label mit metric_relabel_configs verwerfen oder umschreiben, oder sample_limit am Scrape-Job setzen, damit ein einzelnes fehlerhaftes Deployment den Server nicht lahmlegt.

F: Wozu dienen Recording Rules?

Sie berechnen einen aufwändigen Ausdruck in jedem Evaluierungsintervall vor und speichern das Ergebnis als neue Zeitreihe. Dashboards und Alerts fragen dann die günstige, vorberechnete Zeitreihe ab. Die Namenskonvention lautet level:metric:operations:

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

F: Was bewirkt die for-Klausel in einer Alerting-Regel?

Ein Alert, dessen Ausdruck wahr wird, wechselt von inactive zu pending und erreicht firing erst, wenn die Bedingung für die Dauer von for bestanden hat. Das filtert Ausreißer aus einem einzelnen Scrape. keep_firing_for bewirkt das Gegenteil: Der Alert bleibt nach dem Ende der Bedingung noch eine Weile aktiv, sodass ein flatternder Alert nicht zweimal pagt.

F: Wie wird Prometheus hochverfügbar betrieben?

Zwei identische Replikate scrapen dieselben Targets, jedes mit einem eigenen externen Label replica. Beide senden Alerts an einen Alertmanager-Cluster, der Benachrichtigungen über sein Gossip-Protokoll dedupliziert. Für Abfragen dedupliziert Thanos Query oder Mimir die beiden Zeitreihen, indem das Replica-Label ignoriert wird. Prometheus selbst kennt kein Clustering: Die lokale TSDB eines einzelnen Servers wird nicht repliziert.

F: Federation oder Remote Write für Multi-Cluster-Setups?

Bei Federation scrapt ein globales Prometheus ausgewählte, meist aggregierte Zeitreihen vom /federate-Endpunkt des Prometheus jedes Clusters. Das passt für eine kleine Menge an Rollups. Remote Write streamt jedes Sample an einen zentralen Speicher wie Mimir, Thanos Receive oder ein Hersteller-Backend und ist die Standardantwort für globale Abfragen und Langzeitaufbewahrung.

F: Wie wird ein Target erkannt, das aus der Service Discovery verschwunden ist?

up == 0 greift nur, solange das Target noch entdeckt wird. Ist der Pod oder der Service-Discovery-Eintrag verschwunden, existiert die Zeitreihe nicht mehr, und der Alert feuert nie. absent(up{job="api-server"}) deckt diesen Fall ab.

F: Was hat sich mit Prometheus 3 geändert?

Prometheus 3.0 (November 2024) brachte eine neue Oberfläche, erlaubte UTF-8-Zeichen in Metrik- und Label-Namen und führte einen integrierten OTLP-Receiver unter /api/v1/otlp/v1/metrics ein, aktiviert mit --web.enable-otlp-receiver. Native Histogramme wurden in 3.8 stabil. Seit 3.9 hat das alte Feature-Flag keine Wirkung mehr, und die Ingestion erfordert scrape_native_histograms: true in der Scrape- oder globalen Konfiguration. 3.15 stabilisierte die XOR2-Chunk-Kodierung für Floats und ergänzte das Scrapen von OpenMetrics 2.0.

Architektur und Datenmodell: Wie jedes Tool Metriken verarbeitet

Sind die Prometheus-Grundlagen abgehakt, wechseln Interviewer meist zu den architektonischen Unterschieden zwischen den drei Tools.

Prometheus setzt auf ein Pull-basiertes Modell. Der Server fragt HTTP-Endpunkte (üblicherweise /metrics) in konfigurierbaren Intervallen ab und speichert die Zeitreihendaten in einer eigenen lokalen Time Series Database (TSDB). Jede Zeitreihe wird durch einen Metriknamen und eine Menge von Key-Value-Labels identifiziert. Die 3.x-Linie ergänzt stabile native Histogramme, einen OTLP-Receiver und Remote Write 2.0, um Samples an einen zentralen Speicher zu übertragen.

Grafana sammelt und speichert selbst keine Metriken. Stattdessen verbindet es sich mit Datenquellen, darunter Prometheus, Loki, Tempo, InfluxDB, Elasticsearch und über 100 weitere, und rendert Dashboards aus deren Daten. Grafana Labs entwickelt zusätzlich Mimir (Langzeit-Metrikspeicher), Loki (Log-Aggregation) und Tempo (Distributed Tracing). Gemeinsam mit Grafana bilden diese Komponenten den Open-Source-LGTM-Stack. Grafana 13, vorgestellt auf der GrafanaCON im April 2026, machte Git Sync für Dashboards allgemein verfügbar, aktivierte dynamische Dashboards standardmäßig und entfernte die Befehle grafana-cli und grafana-server.

Datadog arbeitet als Push-basierter SaaS-Dienst. Agenten auf den Hosts senden Metriken, Logs und Traces an das Cloud-Backend. Sämtliche Funktionen, also Ingestion, Speicherung, Abfrage, Alerting und Dashboards, befinden sich innerhalb einer einzigen verwalteten Plattform. Die Watchdog-Engine erkennt Anomalien automatisch, ohne dass manuelle Schwellenwerte definiert werden müssen.

# 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__

Diese YAML-Konfiguration zeigt das Pull-Modell: Kubernetes-Pods werden über Service Discovery erkannt, nur Pods mit der Annotation prometheus.io/scrape: "true" bleiben erhalten, die Adresse wird auf den annotierten Port umgeschrieben, und /metrics wird alle 15 Sekunden abgefragt. Die zweite Regel verbindet beide Source-Labels mit ;, weshalb der reguläre Ausdruck auf host:port;port passt.

PromQL vs. Datadog-Abfragesprache: Syntax und Möglichkeiten

Abfragesprachen gehören zu den häufigsten technischen Interviewthemen im Bereich Monitoring. Von Kandidaten wird erwartet, mindestens eine Sprache fließend zu beherrschen und die jeweiligen Trade-offs erklären zu können.

PromQL (Prometheus Query Language) ist der Standard für Metrikabfragen im gesamten Prometheus- und Grafana-Ökosystem. Die Sprache unterstützt Instant Vectors, Range Vectors, Aggregationsoperatoren und 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

Datadogs Abfragesprache verfolgt einen anderen Ansatz, der auf Funktionsaufrufen und Scoping basiert:

# 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 bietet mehr Ausdruckskraft für Ad-hoc-Analysen. Datadogs Sprache tauscht einen Teil dieser Flexibilität gegen eingebaute algorithmische Funktionen wie anomalies() (Algorithmen basic, agile, robust) und forecast() (linear, seasonal) ein, die im Prometheus-Stack zusätzliches externes Tooling erfordern würden.

Alerting-Strategien: Regelbasiert vs. ML-gestützt

Die Alerting-Philosophie unterscheidet sich grundlegend zwischen den Tools. Das Verständnis dieser Unterschiede signalisiert in Interviews operative Reife.

Prometheus Alertmanager empfängt die Alerts aus Regeln, die Prometheus in festen Intervallen auswertet, und leitet sie über eine konfigurierbare Pipeline mit Grouping, Silencing und Inhibition weiter:

# 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

Dieser Ansatz erfordert die explizite Definition von Schwellenwerten. Der Vorteil liegt in der vollständigen Transparenz: Jeder Alert besitzt eine überprüfbare Expression. Der Nachteil ist die sogenannte Threshold Fatigue, da statische Schwellenwerte regelmäßig an saisonale Muster angepasst werden müssen.

Grafana Alerting (das vereinheitlichte Alerting-System, Standard seit Grafana 9) wertet Abfragen über beliebige verbundene Datenquellen aus und unterstützt mehrdimensionale Alerts mit Notification Policies.

Datadog Monitors kombinieren statische Schwellenwerte mit Anomalie-, Outlier- und Forecast-Monitoren. Watchdog erkennt Performance-Anomalien automatisch, ohne dass manuelle Regeln erstellt werden müssen. Das reduziert den Konfigurationsaufwand, geht jedoch auf Kosten geringerer Transparenz in der Erkennungslogik.

Preise und Gesamtbetriebskosten (TCO) 2026

Die Preisgestaltung ist in der Praxis ein entscheidender Faktor bei der Tool-Auswahl und wird in System-Design-Interviews regelmäßig thematisiert. Kandidaten, die Kostenstrukturen verstehen und artikulieren können, demonstrieren unternehmerisches Bewusstsein. Die Datadog-Angaben unten sind Listenpreise bei jährlicher Abrechnung.

Der Open-Source-Stack erscheint auf dem Papier günstiger, erfordert jedoch dedizierte Engineering-Zeit für Upgrades, Kapazitätsplanung und Hochverfügbarkeits-Konfiguration. Datadogs verwaltetes Modell verlagert diesen Aufwand auf den Anbieter. Für Teams mit weniger als fünf Infrastruktur-Ingenieuren haben verwaltete Lösungen häufig niedrigere Gesamtkosten, sobald die Engineering-Zeit eingerechnet wird.

Kubernetes-Monitoring: Integrationstiefe im Vergleich

Prometheus ist das Standard-Metriksystem des Kubernetes-Ökosystems. Damit ist dieses Thema in Interviews zum Monitoring von Container-Orchestrierung das dominierende.

Prometheus + Grafana integriert sich nativ über das kube-prometheus-stack Helm Chart. Dieses Chart deployt Prometheus Operator, Alertmanager, Node-Exporter, kube-state-metrics und vorkonfigurierte Grafana-Dashboards in einer einzigen Installation:

# 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

Dieser Befehl deployt einen produktionsreifen Monitoring-Stack mit persistentem Storage und 30 Tagen Daten-Retention. Der Prometheus Operator verwendet Custom Resource Definitions (ServiceMonitor, PodMonitor), um Scrape-Targets deklarativ zu konfigurieren. Das Überschreiben von Chart-Werten auf diese Weise behandelt der Interviewleitfaden zu Helm Charts ausführlicher.

Datadog deployt ein Agent-DaemonSet und einen Cluster Agent. Der Cluster Agent übernimmt die Kommunikation mit dem Kubernetes-API-Server zentral und reduziert damit die Last auf die API. Die Live-Containers-Ansicht bietet Echtzeit-Transparenz über Pod-Zustände, und der Orchestrator Explorer visualisiert Beziehungen zwischen Deployments, Services und Pods.

Für Teams, die bereits im Kubernetes-Ökosystem verwurzelt sind, vermeidet der Prometheus-native Ansatz die Einführung einer externen Abhängigkeit. Teams, die eine schnelle Einrichtung mit geringerem operativen Aufwand priorisieren, tendieren eher zu Datadog.

OpenTelemetry und Herstellerneutralität

OpenTelemetry (OTel) hat sich als Industriestandard für die Instrumentierung von Anwendungen etabliert. In Vorstellungsgesprächen wird zunehmend nach der Rolle von OTel im Kontext von Monitoring-Vergleichen gefragt.

Prometheus 3.x akzeptiert OTLP-Metriken direkt, sobald --web.enable-otlp-receiver gesetzt ist, sodass kein Collector mehr als Zwischenschicht nötig ist. Grafana Alloy, der Nachfolger des Grafana Agent, fungiert gleichzeitig als OTel Collector und als Prometheus Scraper. Datadog unterstützt OTLP-Ingestion, empfiehlt jedoch die proprietären Agenten für den "vollen Funktionsumfang", eine Form des weichen Vendor Lock-in.

Die strategische Bedeutung von OTel liegt in der Entkopplung von Instrumentierung und Backend-Wahl. Anwendungscode, der mit OTel-SDKs instrumentiert ist, kann Telemetriedaten an Prometheus, Grafana Cloud, Datadog oder jedes andere kompatible Backend senden, ohne Codeänderungen vornehmen zu müssen. Diese Flexibilität ist ein starkes Argument in System-Design-Interviews, insbesondere wenn es um langfristige Observability-Strategien geht.

Observability-Interviewfragen im Vergleich der drei Tools

Über Prometheus hinaus prüfen diese Fragen, ob ein Kandidat toolübergreifend argumentieren kann. Jede Antwort hebt das Konzept hervor, das der Interviewer prüft.

F: Was unterscheidet Monitoring, Observability und Alerting voneinander?

Monitoring verfolgt vordefinierte Metriken und prüft bekannte Fehlermodi. Observability ermöglicht die Untersuchung unbekannter Fehlermodi durch Metriken, Logs und Traces, die sogenannten "drei Säulen". Alerting löst Benachrichtigungen aus, wenn Bedingungen definierte Schwellenwerte oder Anomalie-Baselines überschreiten. Monitoring beantwortet die Frage "Ist das System gesund?", während Observability die Frage "Warum ist das System nicht gesund?" adressiert.

F: In welchen Szenarien ist Prometheus keine gute Wahl?

Prometheus ist auf Zuverlässigkeit statt auf Dauerhaftigkeit optimiert: Die Verfügbarkeit des Monitoring-Systems selbst hat Priorität. Szenarien, in denen Prometheus an seine Grenzen stößt: Langzeitspeicherung über 30 Tage hinaus (erfordert Thanos, Mimir oder Cortex), abrechnungsrelevante Daten pro Request, die 100-prozentige Genauigkeit erfordern (die Scrape-basierte Erfassung kann Samples verpassen), und Event-basierte Systeme, die Push-basierte Erfassung benötigen (das Pushgateway existiert, aber nur für Batch-Jobs auf Service-Ebene).

F: Wie beeinflusst Grafanas "Big Tent"-Philosophie die Observability-Architektur?

Grafana verbindet sich mit jeder Datenquelle, ohne eine Datenmigration zu erfordern. Teams können Prometheus, Elasticsearch, CloudWatch und Datadog in einem einzigen Dashboard zusammenführen. Der Kompromiss liegt in der operativen Komplexität: Die Wartung mehrerer Backends erfordert mehr Infrastruktur-Expertise als ein Single-Vendor-Ansatz. Interviewer testen, ob Kandidaten diesen Trade-off klar formulieren können.

F: Was ist Datadogs High-Watermark-Abrechnung, und warum ist sie relevant?

Datadog misst die Host-Anzahl stündlich, verwirft das obere ein Prozent der Stunden und rechnet auf Basis des Peaks im 99. Perzentil ab. Temporäre Auto-Scaling-Spitzen, etwa während Black-Friday-Traffic, erhöhen die monatliche Rechnung also auch dann, wenn die Instanzen längst terminiert sind. Wer das erwähnt, zeigt echte Betriebserfahrung im Kostenmanagement, die SRE-Rollen zunehmend verlangen.

F: Wie unterscheidet sich SLO-basiertes Alerting zwischen Prometheus und Datadog?

In Prometheus nutzt SLO-basiertes Alerting Recording Rules, um Error Budgets und Burn-Rate-Alerts vorab zu berechnen, nach dem Multi-Window-, Multi-Burn-Rate-Ansatz aus Googles SRE Workbook. Datadog bietet eingebaute SLO-Widgets und Monitors, die die Burn Rate automatisch verfolgen. Beide Ansätze implementieren dasselbe Konzept, aber Prometheus erfordert mehr manuelle Konfiguration, während Datadog einen verwalteten Workflow bereitstellt. In einer guten Interviewantwort sollten Burn-Rate-Fenster (1h, 6h, 3d) und Error-Budget-Verbrauchsraten konkret benannt werden.

Entscheidungs-Framework: Den richtigen Stack wählen

Die richtige Wahl hängt von drei Variablen ab: Teamgröße, operative Reife und Budgetrestriktionen. Es gibt keine universell korrekte Antwort. Interviewer erwarten, dass Kandidaten Trade-offs systematisch durchdenken, anstatt einen einzelnen Gewinner zu proklamieren.

Quellen

• Prometheus-Releases: 3.15.0 (September 2026) stabilisiert die XOR2-Chunk-Kodierung, ergänzt das Scrapen von OpenMetrics 2.0 und markiert --log.level als veraltet
• Spezifikation der nativen Histogramme in Prometheus: stabil seit 3.8, scrape_native_histograms erforderlich seit 3.9
• What's new in Grafana 13.0: Git Sync GA, dynamische Dashboards als Standard, Breaking Changes
• Datadog-Listenpreise: Preise für Infrastructure, APM und Logs aus der Kostentabelle
• Algorithmische Funktionen in Datadog: Syntax von anomalies() und forecast()

Was für ein Prometheus- oder Observability-Interview hängen bleiben sollte

• Prometheus ist der Standard für Metrikerfassung in Kubernetes-Umgebungen; Pull vs. Push, die vier Metriktypen, rate() vs. irate(), Cardinality und HA sollten sitzen
• Ab Prometheus 3.9 werden native Histogramme nur noch ingestiert, wenn scrape_native_histograms: true gesetzt ist
• Grafana ist eine Visualisierungsschicht und keine Metrik-Datenbank: Es verbindet sich mit über 100 Datenquellen, darunter Prometheus, und der LGTM-Stack (Loki, Grafana, Tempo, Mimir) bildet eine vollständige Open-Source-Observability-Plattform
• Datadog bietet den schnellsten Weg zur Full-Stack-Observability mit eingebauter Anomalieerkennung, allerdings zu höheren Kosten und mit stärkerem Vendor Lock-in
• OpenTelemetry entkoppelt die Instrumentierung von der Backend-Wahl und macht die Entscheidung für ein bestimmtes Tool weniger endgültig
• In Vorstellungsgesprächen gilt es, Trade-offs zwischen Kosten, Kontrolle und Komplexität abzuwägen, anstatt ein einzelnes Tool als Allheilmittel darzustellen
• Für eine breitere Vorbereitung deckt der Leitfaden zu den wichtigsten DevOps-Interviewfragen die angrenzenden Themen ab, die Interviewer an Monitoring anschließen