Prometheus vs Grafana vs Datadog 2026: Monitoring-Vergleich, Architektur und DevOps-Interviewfragen

In nahezu jedem DevOps- oder SRE-Vorstellungsgespräch fällt früher oder später die Frage nach dem Unterschied zwischen Prometheus, Grafana und Datadog. Wer diese drei Tools nicht nur oberflächlich kennt, sondern ihre Architektur, Stärken und Kompromisse fundiert erklären kann, hebt sich deutlich von anderen Kandidaten ab. Dieser Artikel stellt die zentralen Unterschiede gegenüber, analysiert die jeweiligen Abfragesprachen und Alerting-Ansätze und bereitet auf die häufigsten Interviewfragen zum Thema Monitoring vor.

Architektur und Datenmodell im Vergleich

Die architektonischen Grundlagen unterscheiden sich fundamental zwischen diesen drei Werkzeugen. Interviewer nutzen dieses Thema gezielt, um die Tiefe des technischen Verständnisses zu prüfen.

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. Prometheus 3.0, veröffentlicht im November 2024, brachte mit Version 3.8 stabile native Histogramme, nativ integrierte OTLP-Ingestion und Remote Write 2.0 für verbesserte Cluster-Federation.

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 bilden diese Komponenten den sogenannten LGTM-Stack, eine vollständige Open-Source-Observability-Plattform. Version 13, erschienen im Mai 2026, führte Observability-as-Code-Tooling, Git Sync für Dashboards und SQL Expressions für quellenübergreifende Abfragen ein.

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

Die folgende Prometheus-Konfiguration veranschaulicht das Pull-Modell anhand einer Kubernetes-Integration:

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

Diese YAML-Konfiguration zeigt das Pull-Modell: Kubernetes-Pods werden über Service Discovery automatisch erkannt und ihre /metrics-Endpunkte alle 15 Sekunden abgefragt. Die relabel_configs steuern, welche Pods gescraped werden und auf welchem Port die Metriken verfügbar sind. Im Gegensatz dazu benötigt Datadog lediglich die Installation eines Agents als DaemonSet -- die Konfiguration erfolgt zentral über die Web-Oberfläche.

PromQL vs. Datadog-Abfragesprache

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 im gesamten Prometheus- und Grafana-Ökosystem. Die Sprache unterstützt Instant Vectors, Range Vectors, Aggregationsoperatoren und Recording Rules. Ihre Ausdruckskraft ermöglicht komplexe Ad-hoc-Analysen, erfordert allerdings eine spürbare Einarbeitungszeit.

# 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

Die rate()-Funktion berechnet die durchschnittliche Änderungsrate eines Counters über ein Zeitfenster. In Interviews wird regelmäßig nach dem Unterschied zwischen rate() (geglättete Rate über das gesamte Fenster) und irate() (instantane Rate basierend auf den letzten zwei Datenpunkten) gefragt. Die Funktion predict_linear() erlaubt es, auf Basis linearer Regression vorherzusagen, wann eine Ressource erschöpft sein wird -- ein typisches Capacity-Planning-Szenario.

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 (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)

Der zentrale Unterschied liegt im Funktionsumfang: PromQL bietet tiefere Ausdruckskraft für mathematische Operationen und Ad-hoc-Analysen. Datadogs Sprache tauscht einen Teil dieser Flexibilität gegen eingebaute ML-Funktionen wie anomaly() und forecast() ein. Diese Funktionen würden im Prometheus-Stack zusätzliches externes Tooling erfordern. Für Interviews gilt: Wer die rate()-Semantik in PromQL präzise erklären kann und gleichzeitig die Grenzen beider Sprachen kennt, demonstriert echte praktische Erfahrung.

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 wertet Regeln in festen Intervallen aus und leitet Alerts ü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, die in Code Reviews und Audits nachvollzogen werden kann. Der Nachteil ist die sogenannte Threshold Fatigue -- statische Schwellenwerte müssen regelmäßig an saisonale Muster und wachsende Infrastruktur angepasst werden, was bei hunderten von Services zunehmend aufwändig wird.

Grafana Alerting, vereinheitlicht seit Grafana 12+, wertet Abfragen über beliebige verbundene Datenquellen aus und unterstützt mehrdimensionale Alerts mit Notification Policies. Seit Version 13 lassen sich Alert-Definitionen als Code versionieren und über Git Sync verwalten, was Infrastructure-as-Code-Workflows erheblich vereinfacht.

Datadog Monitors kombinieren statische Schwellenwerte mit ML-gestützten Anomalie-, Outlier- und Forecast-Monitoren. Watchdog erkennt Performance-Anomalien automatisch, ohne dass manuelle Regeln erstellt werden müssen. Das reduziert den Konfigurationsaufwand erheblich, geht jedoch auf Kosten geringerer Transparenz in der Erkennungslogik. In regulierten Branchen wie dem Finanzsektor oder dem Gesundheitswesen kann dies problematisch sein, da Auditoren nachvollziehbare und dokumentierte Alerting-Regeln erwarten.

Kosten und Gesamtbetriebskosten (TCO)

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.

| Dimension | Prometheus + Grafana | Datadog | |-----------|---------------------|--------| | Lizenz | Kostenlos (AGPL / Apache 2.0) | 15-31 USD/Host/Monat (jährlich) | | Metrikspeicher | Selbst verwaltet (Mimir/Thanos) | Inklusive, Retention-basiert | | Log-Management | Loki (Self-hosted) | 0,10 USD/GB Ingestion + Indexierung | | APM / Traces | Tempo (Self-hosted) | 31 USD/Host/Monat | | Infrastrukturkosten | Compute + Storage für den Stack | Keine (SaaS) | | Operativer Aufwand | Hoch (Upgrades, Skalierung, HA) | Minimal | | Typische Jahreskosten (50 Hosts) | 20.000-60.000 USD (Infra + Engineering) | 50.000-150.000 USD | | Vendor-Lock-in-Risiko | Niedrig (OpenTelemetry, PromQL) | Höher (proprietäre Abfragesprache) |

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

Ein oft übersehener Aspekt ist Datadogs High-Watermark-Abrechnung: Die Host-Anzahl wird stündlich gemessen, das obere ein Prozent der Stunden wird verworfen und der 99. Perzentil-Peak wird als Abrechnungsgrundlage verwendet. Temporäre Auto-Scaling-Spitzen -- etwa während Black-Friday-Traffic -- erhöhen die monatliche Rechnung, selbst nachdem die Instanzen bereits terminiert wurden.

Kubernetes-Monitoring: Integrationstiefe im Vergleich

Über 80 Prozent aller Kubernetes-Cluster setzen Prometheus für die Metrikerfassung ein. Damit ist dieses Thema in Interviews zum Bereich Container-Orchestrierung praktisch unvermeidlich.

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. Teams können eigenständig Monitoring-Konfigurationen für ihre Services erstellen, ohne Zugriff auf die zentrale Prometheus-Konfiguration zu benötigen -- ein erheblicher organisatorischer Vorteil in großen Unternehmen.

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. Der Einrichtungsaufwand ist geringer, allerdings entsteht eine Abhängigkeit von einem externen SaaS-Dienst.

Für Teams, die bereits tief 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 oder Grafana Cloud.

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.0+ akzeptiert OTLP-Metriken nativ, ohne dass ein separater Collector als Zwischenschicht benötigt wird. 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. Wer erklären kann, warum OTLP gegenüber proprietären Integrationen vorzuziehen ist, demonstriert architektonischen Weitblick.

Häufige DevOps-Interviewfragen zu Monitoring und Observability

Die folgenden Fragen tauchen regelmäßig in DevOps- und SRE-Interviews auf. Jede Antwort hebt die Konzepte hervor, die Interviewer gezielt prüfen.

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, die 100-prozentige Genauigkeit erfordern (Prometheus kann unter Last Samples verwerfen), und Event-basierte Systeme, die Push-basierte Erfassung benötigen (obwohl das Pushgateway als Workaround existiert).

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: 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 -- der Multi-Window-, Multi-Burn-Rate-Ansatz aus Googles SRE-Buch. 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.

F: Welche Rolle spielt Cardinality im Prometheus-Kontext und warum ist sie problematisch?

Cardinality bezeichnet die Anzahl einzigartiger Zeitreihen in Prometheus. Jede Kombination aus Metrikname und Label-Werten erzeugt eine separate Zeitreihe. Labels mit hoher Kardinalität -- etwa Benutzer-IDs oder Request-IDs -- können die Anzahl der Zeitreihen exponentiell steigern und sowohl Speicher als auch Query-Performance massiv beeinträchtigen. Best Practices umfassen die Begrenzung von Label-Werten, den Einsatz von Recording Rules zur Voraggregation und das Monitoring der eigenen Prometheus-TSDB über prometheus_tsdb_head_series.

Für eine vertiefte Vorbereitung auf Monitoring-Themen bietet das Prometheus-Monitoring-Interviewmodul weitere Szenarien mit ausführlichen Erklärungen.

Entscheidungs-Framework: Den richtigen Stack wählen

| Szenario | Empfohlener Stack | Begründung | |----------|------------------|------------| | Startup mit weniger als 10 Ingenieuren | Datadog oder Grafana Cloud | Operativen Aufwand minimieren | | Große Organisation mit Platform Team | Prometheus + Grafana + Loki | Volle Kontrolle, niedrigere Stückkosten bei Skalierung | | Multi-Cloud / Hybrid | Prometheus + Grafana | Herstellerneutral, konsistent über Umgebungen hinweg | | Compliance-intensive Branche | Self-hosted Prometheus + Grafana | Daten bleiben im eigenen Rechenzentrum | | Schnelles Wachstum, unvorhersehbare Skalierung | Grafana Cloud (verwaltetes Mimir) | Skaliert ohne Infrastrukturmanagement | | ML-gestützte Anomalieerkennung erforderlich | Datadog | Watchdog erfordert keine manuelle Konfiguration |

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.

Fazit

• Prometheus ist der De-facto-Standard für Metrikerfassung in Kubernetes-Umgebungen; Version 3.x bringt 2026 nativen OTLP-Support und stabile native Histogramme
• Grafana ist eine Visualisierungsschicht und keine Metrik-Datenbank -- der LGTM-Stack (Loki, Grafana, Tempo, Mimir) bildet eine vollständige Open-Source-Observability-Plattform mit über 100 Datenquellen-Integrationen
• Datadog bietet den schnellsten Weg zur Full-Stack-Observability mit ML-gestütztem Alerting, 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
• Cardinality-Management ist ein kritischer operativer Aspekt in Prometheus-Umgebungen und ein häufiges Interviewthema
• In Vorstellungsgesprächen gilt es, die Fähigkeit zu demonstrieren, Trade-offs zwischen Kosten, Kontrolle und Komplexität systematisch abzuwägen, anstatt ein einzelnes Tool als Allheilmittel darzustellen
• Zur praktischen Vorbereitung empfiehlt sich das DevOps-Interviewfragen-Modul sowie die Vertiefung angrenzender Themen wie CI/CD-Pipeline-Konzepte