Prometheus vs Grafana vs Datadog w 2026: porównanie monitoringu i pytania rekrutacyjne DevOps

Pytanie o różnice między Prometheusem, Grafaną i Datadogiem pojawia się niemal w każdej rozmowie kwalifikacyjnej na stanowisko DevOps lub SRE. Kandydat, który zna te trzy narzędzia nie tylko powierzchownie, lecz potrafi rzeczowo wyjaśnić ich architekturę, mocne strony i kompromisy, wyraźnie wyróżnia się na tle pozostałych. Ten artykuł zestawia kluczowe różnice, analizuje języki zapytań oraz podejścia do alertowania, a także przygotowuje do najczęstszych pytań rekrutacyjnych dotyczących monitoringu.

Architektura i model danych

Fundamenty architektoniczne tych trzech narzędzi różnią się zasadniczo, a rekruterzy chętnie wykorzystują ten temat, aby sprawdzić głębokość technicznego zrozumienia kandydata.

Prometheus opiera się na modelu pull. Serwer odpytuje endpointy HTTP (zwykle /metrics) w konfigurowalnych odstępach czasu i zapisuje dane szeregów czasowych we własnej, lokalnej bazie TSDB (Time Series Database). Każdy szereg czasowy identyfikowany jest przez nazwę metryki oraz zbiór etykiet w formacie klucz-wartość. Prometheus 3.0, wydany w listopadzie 2024 roku, wprowadził w wersji 3.8 stabilne natywne histogramy, wbudowaną ingestię OTLP oraz Remote Write 2.0 usprawniający federację między klastrami.

Grafana sama nie zbiera ani nie przechowuje metryk. Zamiast tego łączy się ze źródłami danych -- między innymi Prometheusem, Loki, Tempo, InfluxDB, Elasticsearch oraz ponad setką innych -- i na ich podstawie renderuje dashboardy. Grafana Labs rozwija dodatkowo Mimir (długoterminowe przechowywanie metryk), Loki (agregację logów) oraz Tempo (rozproszony tracing). Razem komponenty te tworzą tzw. stos LGTM, kompletną platformę observability o otwartym kodzie źródłowym. Wersja 13, wydana w maju 2026 roku, wprowadziła narzędzia observability-as-code, Git Sync dla dashboardów oraz SQL Expressions umożliwiające zapytania łączące wiele źródeł.

Datadog działa jako usługa SaaS w modelu push. Agenci zainstalowani na hostach wysyłają metryki, logi i ślady do chmurowego backendu. Wszystkie funkcje -- ingestia, przechowywanie, odpytywanie, alertowanie oraz tworzenie dashboardów -- znajdują się w obrębie jednej zarządzanej platformy. Silnik ML o nazwie Watchdog automatycznie wykrywa anomalie, bez konieczności ręcznego definiowania progów.

Poniższa konfiguracja Prometheusa ilustruje model pull na przykładzie integracji z Kubernetesem:

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

Ta konfiguracja YAML pokazuje model pull: pody Kubernetes są automatycznie wykrywane przez mechanizm service discovery, a ich endpointy /metrics odpytywane co 15 sekund. Sekcja relabel_configs decyduje, które pody są scrapowane i na jakim porcie udostępniane są metryki. Dla porównania, Datadog wymaga jedynie instalacji agenta jako DaemonSet -- konfiguracja odbywa się centralnie przez interfejs webowy.

PromQL vs język zapytań Datadoga

Języki zapytań należą do najczęstszych tematów technicznych w rozmowach kwalifikacyjnych z obszaru monitoringu. Od kandydatów oczekuje się biegłej znajomości przynajmniej jednego z nich oraz umiejętności wyjaśnienia związanych z nimi kompromisów.

PromQL (Prometheus Query Language) jest standardem w całym ekosystemie Prometheusa i Grafany. Język obsługuje instant vectors, range vectors, operatory agregujące oraz recording rules. Jego siła wyrazu umożliwia złożone analizy ad-hoc, wymaga jednak zauważalnego czasu na naukę.

# 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

Funkcja rate() oblicza średnią szybkość zmian licznika w zadanym oknie czasowym. Podczas rozmów regularnie pada pytanie o różnicę między rate() (wygładzona szybkość liczona dla całego okna) a irate() (chwilowa szybkość obliczana na podstawie dwóch ostatnich punktów pomiarowych). Funkcja predict_linear() pozwala, na bazie regresji liniowej, przewidzieć moment wyczerpania zasobu -- to typowy scenariusz planowania pojemności (capacity planning).

Język zapytań Datadoga przyjmuje odmienne podejście, oparte na wywołaniach funkcji oraz mechanizmie scopingu:

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

Zasadnicza różnica dotyczy zakresu funkcjonalnego: PromQL oferuje większą siłę wyrazu w operacjach matematycznych i analizach ad-hoc. Język Datadoga wymienia część tej elastyczności na wbudowane funkcje ML, takie jak anomaly() oraz forecast(). W stosie Prometheusa funkcje te wymagałyby dodatkowego, zewnętrznego oprogramowania. W rozmowach kwalifikacyjnych obowiązuje zasada: kto potrafi precyzyjnie wyjaśnić semantykę rate() w PromQL, a jednocześnie zna ograniczenia obu języków, dowodzi realnego doświadczenia praktycznego.

Strategie alertowania: reguły vs wykrywanie oparte na ML

Filozofia alertowania różni się zasadniczo pomiędzy narzędziami. Zrozumienie tych różnic świadczy w rozmowie o dojrzałości operacyjnej kandydata.

Prometheus Alertmanager wylicza reguły w stałych odstępach czasu i kieruje alerty przez konfigurowalny potok obsługujący grupowanie (grouping), wyciszanie (silencing) oraz tłumienie (inhibition):

# 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

Podejście to wymaga jawnego zdefiniowania progów. Zaletą jest pełna przejrzystość: każdy alert ma weryfikowalne wyrażenie, które można prześledzić podczas code review i audytów. Wadą jest tzw. threshold fatigue -- statyczne progi trzeba regularnie dostosowywać do wzorców sezonowych i rosnącej infrastruktury, co przy setkach usług staje się coraz bardziej pracochłonne.

Grafana Alerting, ujednolicone od wersji Grafana 12+, wylicza zapytania na dowolnych podłączonych źródłach danych i obsługuje wielowymiarowe alerty z politykami powiadomień (notification policies). Od wersji 13 definicje alertów można wersjonować jako kod i zarządzać nimi poprzez Git Sync, co znacząco upraszcza przepływy pracy w duchu infrastructure-as-code.

Datadog Monitors łączą statyczne progi z monitorami wspieranymi przez ML -- typu anomaly, outlier oraz forecast. Watchdog wykrywa anomalie wydajnościowe automatycznie, bez konieczności tworzenia ręcznych reguł. Znacząco redukuje to nakład konfiguracyjny, odbywa się jednak kosztem mniejszej przejrzystości logiki wykrywania. W regulowanych branżach, takich jak sektor finansowy czy ochrona zdrowia, może to stanowić problem, ponieważ audytorzy oczekują zrozumiałych i udokumentowanych reguł alertowania.

Koszty i całkowity koszt posiadania (TCO)

Wycena jest w praktyce decydującym czynnikiem przy wyborze narzędzia i regularnie pojawia się w rozmowach dotyczących projektowania systemów (system design). Kandydaci, którzy rozumieją i potrafią przedstawić strukturę kosztów, dowodzą świadomości biznesowej.

| Wymiar | Prometheus + Grafana | Datadog | |-----------|---------------------|--------| | Licencja | Bezpłatna (AGPL / Apache 2.0) | 15-31 USD/host/miesiąc (rocznie) | | Przechowywanie metryk | Samodzielnie zarządzane (Mimir/Thanos) | W cenie, wycena zależna od retencji | | Zarządzanie logami | Loki (self-hosted) | 0,10 USD/GB ingestii + indeksowanie | | APM / Traces | Tempo (self-hosted) | 31 USD/host/miesiąc | | Koszty infrastruktury | Compute + storage dla stosu | Brak (SaaS) | | Nakład operacyjny | Wysoki (aktualizacje, skalowanie, HA) | Minimalny | | Typowy koszt roczny (50 hostów) | 20 000-60 000 USD (infra + engineering) | 50 000-150 000 USD | | Ryzyko vendor lock-in | Niskie (OpenTelemetry, PromQL) | Wyższe (zastrzeżony język zapytań) |

Stos open source wydaje się na papierze tańszy, wymaga jednak dedykowanego czasu inżynierów na utrzymanie, aktualizacje, planowanie pojemności oraz konfigurację wysokiej dostępności (HA). Zarządzany model Datadoga przenosi ten ciężar na dostawcę. Z doświadczenia wynika, że dla zespołów liczących mniej niż pięciu inżynierów infrastruktury rozwiązania zarządzane mają często niższy koszt całkowity, gdy uwzględni się czas pracy inżynierów.

Często pomijanym aspektem jest rozliczanie Datadoga w modelu high-watermark: liczba hostów mierzona jest co godzinę, górny jeden procent godzin zostaje odrzucony, a jako podstawę rozliczenia przyjmuje się szczyt na poziomie 99. percentyla. Chwilowe skoki auto-skalowania -- na przykład podczas ruchu w Black Friday -- podnoszą miesięczny rachunek nawet po tym, jak instancje zostały już wyłączone.

Monitoring Kubernetes: porównanie głębokości integracji

Ponad 80 procent klastrów Kubernetes wykorzystuje Prometheusa do zbierania metryk. Czyni to ten temat praktycznie nieuniknionym w rozmowach dotyczących orkiestracji kontenerów.

Prometheus + Grafana integruje się natywnie za pośrednictwem Helm charta kube-prometheus-stack. Chart ten wdraża Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics oraz gotowe dashboardy Grafany w ramach jednej instalacji:

# 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

Polecenie to wdraża gotowy do produkcji stos monitoringu z trwałym magazynem danych (persistent storage) oraz 30-dniową retencją. Prometheus Operator wykorzystuje Custom Resource Definitions (ServiceMonitor, PodMonitor), aby deklaratywnie konfigurować cele scrapowania. Zespoły mogą samodzielnie tworzyć konfiguracje monitoringu dla swoich usług, bez konieczności dostępu do centralnej konfiguracji Prometheusa -- to istotna zaleta organizacyjna w dużych przedsiębiorstwach.

Datadog wdraża DaemonSet z agentem oraz Cluster Agent. Cluster Agent centralnie obsługuje komunikację z serwerem API Kubernetes, redukując tym samym obciążenie API. Widok Live Containers zapewnia wgląd w czasie rzeczywistym w stany podów, a Orchestrator Explorer wizualizuje zależności między deploymentami, usługami i podami. Nakład na wdrożenie jest mniejszy, powstaje jednak zależność od zewnętrznej usługi SaaS.

Dla zespołów już głęboko zakorzenionych w ekosystemie Kubernetes podejście natywne dla Prometheusa pozwala uniknąć wprowadzania zewnętrznej zależności. Zespoły stawiające na szybkie wdrożenie i mniejszy nakład operacyjny częściej skłaniają się ku Datadogowi lub Grafana Cloud.

OpenTelemetry i neutralność względem dostawcy

OpenTelemetry (OTel) stało się standardem branżowym w zakresie instrumentacji aplikacji. W rozmowach kwalifikacyjnych coraz częściej pada pytanie o rolę OTel w kontekście porównań narzędzi monitoringu.

Prometheus 3.0+ akceptuje metryki OTLP natywnie, bez potrzeby stosowania osobnego Collectora jako warstwy pośredniej. Grafana Alloy, następca Grafana Agent, pełni jednocześnie rolę OTel Collectora i scrapera Prometheusa. Datadog obsługuje ingestię OTLP, zaleca jednak zastrzeżonych agentów dla "pełnego zakresu funkcji" -- to forma miękkiego vendor lock-in.

Strategiczne znaczenie OTel polega na oddzieleniu instrumentacji od wyboru backendu. Kod aplikacji zinstrumentowany za pomocą SDK OTel może wysyłać dane telemetryczne do Prometheusa, Grafana Cloud, Datadoga lub dowolnego innego zgodnego backendu, bez konieczności wprowadzania zmian w kodzie. Ta elastyczność stanowi mocny argument w rozmowach dotyczących projektowania systemów, zwłaszcza gdy dyskusja obejmuje długoterminowe strategie observability. Kandydat, który potrafi wyjaśnić, dlaczego OTLP jest preferowane względem zastrzeżonych integracji, dowodzi architektonicznej dalekowzroczności.

Częste pytania rekrutacyjne DevOps o monitoring i observability

Poniższe pytania regularnie pojawiają się w rozmowach kwalifikacyjnych DevOps i SRE. Każda odpowiedź uwypukla koncepcje, które rekruterzy celowo sprawdzają.

P: Czym różnią się od siebie monitoring, observability i alerting?

Monitoring śledzi wcześniej zdefiniowane metryki i sprawdza znane tryby awarii. Observability umożliwia badanie nieznanych trybów awarii za pomocą metryk, logów i śladów -- tzw. "trzech filarów". Alerting wyzwala powiadomienia, gdy warunki przekraczają zdefiniowane progi lub bazowe poziomy anomalii. Monitoring odpowiada na pytanie "czy system jest sprawny?", podczas gdy observability adresuje pytanie "dlaczego system nie działa poprawnie?".

P: W jakich scenariuszach Prometheus nie jest dobrym wyborem?

Prometheus jest zoptymalizowany pod kątem niezawodności, a nie trwałości -- priorytetem jest dostępność samego systemu monitoringu. Scenariusze, w których Prometheus dochodzi do swoich granic: długoterminowe przechowywanie danych powyżej 30 dni (wymaga Thanos, Mimir lub Cortex), dane rozliczeniowe wymagające stuprocentowej dokładności (Prometheus może pod obciążeniem odrzucać próbki) oraz systemy zdarzeniowe wymagające zbierania danych w modelu push (choć jako obejście istnieje Pushgateway).

P: Jak filozofia "Big Tent" Grafany wpływa na architekturę observability?

Grafana łączy się z dowolnym źródłem danych bez konieczności migracji danych. Zespoły mogą zestawiać Prometheusa, Elasticsearch, CloudWatch oraz Datadoga w ramach jednego dashboardu. Kompromis leży w złożoności operacyjnej: utrzymanie wielu backendów wymaga większej wiedzy infrastrukturalnej niż podejście oparte na jednym dostawcy. Rekruterzy sprawdzają, czy kandydat potrafi klarownie sformułować ten kompromis.

P: Jak różni się alertowanie oparte na SLO między Prometheusem a Datadogiem?

W Prometheusie alertowanie oparte na SLO wykorzystuje recording rules do wcześniejszego wyliczania budżetów błędów (error budgets) oraz alertów typu burn-rate -- podejście multi-window, multi-burn-rate z książki Google o SRE. Datadog oferuje wbudowane widżety SLO oraz monitory, które automatycznie śledzą burn rate. Oba podejścia realizują tę samą koncepcję, jednak Prometheus wymaga większej ilości ręcznej konfiguracji, podczas gdy Datadog zapewnia zarządzany przepływ pracy. W dobrej odpowiedzi warto konkretnie wskazać okna burn-rate (1h, 6h, 3d) oraz tempo konsumpcji budżetu błędów.

P: Jaką rolę odgrywa kardynalność (cardinality) w kontekście Prometheusa i dlaczego bywa problematyczna?

Kardynalność oznacza liczbę unikalnych szeregów czasowych w Prometheusie. Każda kombinacja nazwy metryki i wartości etykiet tworzy oddzielny szereg czasowy. Etykiety o wysokiej kardynalności -- na przykład identyfikatory użytkowników lub identyfikatory żądań -- mogą wykładniczo zwiększyć liczbę szeregów czasowych i drastycznie pogorszyć zarówno zużycie pamięci, jak i wydajność zapytań. Dobre praktyki obejmują ograniczanie wartości etykiet, stosowanie recording rules do wstępnej agregacji oraz monitorowanie własnej bazy TSDB Prometheusa poprzez metrykę prometheus_tsdb_head_series.

W celu pogłębionego przygotowania do tematów związanych z monitoringiem moduł rekrutacyjny poświęcony Prometheusowi i monitoringowi oferuje kolejne scenariusze wraz ze szczegółowymi wyjaśnieniami.

Framework decyzyjny: wybór odpowiedniego stosu

| Scenariusz | Rekomendowany stos | Uzasadnienie | |----------|------------------|------------| | Startup z mniej niż 10 inżynierami | Datadog lub Grafana Cloud | Minimalizacja nakładu operacyjnego | | Duża organizacja z zespołem platformowym | Prometheus + Grafana + Loki | Pełna kontrola, niższy koszt jednostkowy przy skali | | Multi-cloud / hybryda | Prometheus + Grafana | Neutralność wobec dostawcy, spójność w różnych środowiskach | | Branża o wysokich wymogach compliance | Self-hosted Prometheus + Grafana | Dane pozostają we własnym centrum danych | | Szybki wzrost, nieprzewidywalne skalowanie | Grafana Cloud (zarządzany Mimir) | Skaluje się bez zarządzania infrastrukturą | | Potrzeba wykrywania anomalii opartego na ML | Datadog | Watchdog nie wymaga ręcznej konfiguracji |

Właściwy wybór zależy od trzech zmiennych: wielkości zespołu, dojrzałości operacyjnej oraz ograniczeń budżetowych. Nie istnieje uniwersalnie poprawna odpowiedź. Rekruterzy oczekują, że kandydat będzie systematycznie rozważał kompromisy, zamiast ogłaszać jednego zwycięzcę.

Podsumowanie

• Prometheus jest de facto standardem zbierania metryk w środowiskach Kubernetes; wersja 3.x przynosi w 2026 roku natywne wsparcie OTLP oraz stabilne natywne histogramy
• Grafana to warstwa wizualizacji, a nie baza danych metryk -- stos LGTM (Loki, Grafana, Tempo, Mimir) tworzy kompletną platformę observability o otwartym kodzie źródłowym, z integracjami ponad 100 źródeł danych
• Datadog zapewnia najszybszą drogę do pełnej observability z alertowaniem wspieranym przez ML, jednak kosztem wyższej ceny i silniejszego vendor lock-in
• OpenTelemetry oddziela instrumentację od wyboru backendu i sprawia, że decyzja o konkretnym narzędziu jest mniej ostateczna
• Zarządzanie kardynalnością to krytyczny aspekt operacyjny w środowiskach Prometheusa oraz częsty temat rozmów kwalifikacyjnych
• Podczas rozmów kwalifikacyjnych liczy się umiejętność systematycznego ważenia kompromisów między kosztem, kontrolą a złożonością, zamiast przedstawiania pojedynczego narzędzia jako uniwersalnego rozwiązania
• W ramach praktycznego przygotowania warto skorzystać z modułu pytań rekrutacyjnych DevOps oraz zgłębić powiązane tematy, takie jak koncepcje pipeline'ów CI/CD