Pytania rekrutacyjne o Prometheusa 2026: Prometheus vs Grafana vs Datadog w porównaniu

Pytania o Prometheusa padają niemal w każdej rekrutacji na stanowisko DevOps lub SRE, a zaraz po nich pojawia się kolejne: "dlaczego nie Grafana albo Datadog?". Kandydat musi wyjaśnić, jak Prometheus scrapuje i przechowuje metryki, napisać poprawne zapytanie PromQL i uzasadnić kompromisy względem platformy zarządzanej. Rekruterzy odróżniają w ten sposób realne doświadczenie operacyjne od wiedzy podręcznikowej. Te same tematy w formie pytań treningowych zawiera moduł rekrutacyjny o Prometheusie i monitoringu.

Pytania rekrutacyjne o Prometheusa w rozmowach DevOps i SRE

Poniżej zebrano pytania dotyczące samego Prometheusa, które padają najczęściej, wraz z odpowiedzią pewnego siebie kandydata. Zakładają one Prometheusa 3.x: aktualna stabilna linia to 3.15 (wrzesień 2026), a 3.16 jest na etapie release candidate.

P: Dlaczego Prometheus pobiera metryki (pull), zamiast przyjmować je w modelu push?

Model pull sprawia, że stan celów jest obserwowalny: każdy scrape tworzy szereg up, więc martwy cel widać jako up == 0, a nie jako ciszę. To serwer kontroluje częstotliwość scrapowania, co chroni go przed źle działającym klientem, a cel można sprawdzić ręcznie, otwierając jego endpoint /metrics w przeglądarce. Ceną jest to, że Prometheus musi mieć sieciowy dostęp do każdego celu. Dlatego krótkotrwałe zadania wsadowe wymagają Pushgatewaya, a konfiguracje obejmujące wiele sieci korzystają z remote write.

P: Jakie są cztery typy metryk i kiedy summary to zły wybór?

Counter (tylko rośnie, zeruje się po restarcie), gauge (rośnie i maleje), histogram (obserwacje zliczane w kubełkach) oraz summary (kwantyle liczone po stronie klienta). Kwantyli z summary nie da się agregować: średnia z p99 dziesięciu podów nie daje p99 całej usługi. Histogramy można najpierw zsumować między instancjami, a dopiero potem zamienić w kwantyl po stronie serwera, dlatego są domyślnym wyborem dla opóźnień.

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

Pominięcie le w klauzuli by w klasycznej wersji to najczęstszy błąd PromQL podczas live codingu: zapytanie nie zwraca nic użytecznego.

P: Czym różnią się rate(), irate() i increase()?

rate() zwraca średnią szybkość na sekundę w całym zakresie i obsługuje zerowanie liczników. irate() korzysta tylko z dwóch ostatnich próbek w zakresie, więc reaguje szybko, ale jest zaszumiona: nadaje się do przybliżonego wykresu, a nie do alertowania. increase() to rate() pomnożone przez długość zakresu. Ponieważ Prometheus ekstrapoluje wartości do granic okna, increase() na liczniku całkowitoliczbowym może zwrócić wartość niecałkowitą, a rekruterzy chętnie pytają dlaczego.

P: Czym jest kardynalność i jak diagnozuje się jej eksplozję?

Każda unikalna kombinacja nazwy metryki i wartości etykiet to osobny szereg czasowy przechowywany w pamięci. Etykieta typu user_id, email albo surowa ścieżka URL zawierająca identyfikatory mnoży liczbę szeregów, aż serwerowi zabraknie pamięci. Diagnozę zaczyna się od strony statusu TSDB (/tsdb-status) albo od zapytania:

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

Naprawa odbywa się u źródła: etykietę usuwa się lub przepisuje za pomocą metric_relabel_configs albo ustawia sample_limit w zadaniu scrapowania, aby jedno wadliwe wdrożenie nie mogło położyć serwera.

P: Do czego służą recording rules?

Wyliczają kosztowne wyrażenie w każdym interwale ewaluacji i zapisują wynik jako nowy szereg. Dashboardy i alerty odpytują wtedy tani, wcześniej wyliczony szereg. Konwencja nazewnictwa to level:metric:operations:

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

P: Co robi klauzula for w regule alertu?

Alert, którego wyrażenie staje się prawdziwe, przechodzi ze stanu inactive do pending, a do firing trafia dopiero wtedy, gdy warunek utrzymuje się przez czas określony w for. Odfiltrowuje to jednorazowe skoki z pojedynczego scrape'a. keep_firing_for działa odwrotnie: utrzymuje alert w stanie firing jeszcze przez pewien czas po ustąpieniu warunku, dzięki czemu migoczący alert nie budzi dyżurnego dwa razy.

P: Jak zapewnia się wysoką dostępność Prometheusa?

Uruchamia się dwie identyczne repliki scrapujące te same cele, każdą z inną etykietą zewnętrzną replica. Obie wysyłają alerty do klastra Alertmanagera, który deduplikuje powiadomienia dzięki protokołowi gossip. Po stronie zapytań Thanos Query lub Mimir deduplikują oba szeregi, ignorując etykietę repliki. Sam Prometheus nie ma klastrowania: lokalna baza TSDB pojedynczego serwera nie jest replikowana.

P: Federacja czy remote write w środowisku wieloklastrowym?

Federacja pozwala globalnemu Prometheusowi scrapować wybrane, zwykle zagregowane szeregi z endpointu /federate Prometheusa w każdym klastrze. Sprawdza się przy niewielkim zestawie agregatów. Remote write przesyła każdą próbkę do centralnego magazynu, takiego jak Mimir, Thanos Receive lub backend dostawcy, i jest standardową odpowiedzią, gdy potrzebne są globalne zapytania i długoterminowa retencja.

P: Jak wykryć cel, który zniknął z service discovery?

up == 0 wyzwala alert tylko wtedy, gdy cel jest nadal wykrywany. Jeśli pod lub wpis w service discovery zniknął, szereg przestaje istnieć i alert nigdy się nie uruchomi. Ten przypadek pokrywa absent(up{job="api-server"}).

P: Co zmieniło się w Prometheusie 3?

Prometheus 3.0 (listopad 2024) wprowadził nowy interfejs, dopuścił znaki UTF-8 w nazwach metryk i etykiet oraz dodał wbudowany odbiornik OTLP pod adresem /api/v1/otlp/v1/metrics, włączany flagą --web.enable-otlp-receiver. Natywne histogramy stały się stabilne w 3.8. Od wersji 3.9 dawna flaga funkcji nic nie robi, a ingestia wymaga ustawienia scrape_native_histograms: true w konfiguracji scrapowania lub globalnej. Wersja 3.15 ustabilizowała kodowanie chunków float XOR2 i dodała scrapowanie w formacie OpenMetrics 2.0.

Architektura i model danych: jak każde z narzędzi obsługuje metryki

Po omówieniu podstaw Prometheusa rekruterzy zwykle przechodzą do różnic architektonicznych między trzema narzędziami.

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. Każdy szereg czasowy identyfikowany jest przez nazwę metryki oraz zbiór etykiet w formacie klucz-wartość. Linia 3.x wnosi stabilne natywne histogramy, odbiornik OTLP oraz Remote Write 2.0 do przesyłania próbek do centralnego magazynu.

Grafana sama nie zbiera ani nie przechowuje metryk. Łączy się ze źródłami danych, między innymi z 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), które razem z Grafaną tworzą otwartoźródłowy stos LGTM. Grafana 13, zapowiedziana na GrafanaCON w kwietniu 2026 roku, udostępniła Git Sync dla dashboardów w wersji GA, domyślnie włączyła dynamiczne dashboardy i usunęła polecenia grafana-cli oraz grafana-server.

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

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

Ta konfiguracja YAML definiuje model pull Prometheusa: pody Kubernetes są wykrywane przez service discovery, zachowywane są tylko te z adnotacją prometheus.io/scrape: "true", adres jest przepisywany na port z adnotacji, a endpoint /metrics odpytywany co 15 sekund. Druga reguła łączy obie etykiety źródłowe znakiem ;, dlatego wyrażenie regularne dopasowuje postać host:port;port.

PromQL vs język zapytań Datadoga: składnia i możliwości

Języki zapytań należą do najczęstszych tematów w rozmowach kwalifikacyjnych. 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 zapytań o metryki w całym ekosystemie Prometheusa i Grafany. Język obsługuje instant vectors, range vectors, operatory agregujące oraz 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

Język zapytań Datadoga przyjmuje odmienną składnię, opartą na funkcjach oraz mechanizmie scopingu:

# 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 oferuje większą siłę wyrazu w analizach ad-hoc. Język Datadoga wymienia część tej elastyczności na wbudowane funkcje algorytmiczne, takie jak anomalies() (algorytmy basic, agile, robust) oraz forecast() (linear, seasonal), które w stosie Prometheusa wymagałyby zewnętrznych narzędzi.

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 odbiera alerty z reguł, które Prometheus wylicza w stałych odstępach czasu, i kieruje je 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. Wadą jest tzw. threshold fatigue, ponieważ statyczne progi często trzeba dostosowywać do wzorców sezonowych.

Grafana Alerting (ujednolicony system alertowania, domyślny od Grafany 9) wylicza zapytania na dowolnych podłączonych źródłach danych i obsługuje wielowymiarowe alerty z politykami powiadomień (notification policies).

Datadog Monitors łączą statyczne progi z monitorami typu anomaly, outlier oraz forecast. Watchdog wykrywa anomalie wydajnościowe automatycznie, bez konieczności tworzenia ręcznych reguł. Redukuje to nakład konfiguracyjny, odbywa się jednak kosztem mniejszej przejrzystości logiki wykrywania.

Ceny i całkowity koszt posiadania (TCO) w 2026 roku

Wycena jest w praktyce decydującym czynnikiem przy wyborze narzędzia i regularnie pojawia się w rozmowach dotyczących projektowania systemów (system design). Zrozumienie struktury kosztów świadczy o świadomości biznesowej. Kwoty dla Datadoga poniżej to ceny katalogowe przy rozliczeniu rocznym.

Stos open source wydaje się na papierze tańszy, wymaga jednak dedykowanego czasu inżynierów na aktualizacje, planowanie pojemności oraz konfigurację wysokiej dostępności (HA). Zarządzany model Datadoga przenosi ten ciężar na dostawcę. 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.

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

Prometheus jest domyślnym systemem metryk w ekosystemie Kubernetes, co czyni ten temat dominującym w rozmowach o monitoringu orkiestracji kontenerów.

Prometheus + Grafana integruje się natywnie z Kubernetesem 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. Nadpisywanie wartości charta w ten sposób szerzej omawia przewodnik rekrutacyjny o Helm chartach.

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.

Dla zespołów już 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 skłaniają się ku Datadogowi.

OpenTelemetry i neutralność względem dostawcy

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

Prometheus 3.x przyjmuje metryki OTLP bezpośrednio po ustawieniu --web.enable-otlp-receiver, więc Collector nie jest już wymagany jako warstwa pośrednia. 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", co jest formą miękkiego vendor lock-in.

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, gdy dyskusja obejmuje długoterminową strategię observability.

Pytania rekrutacyjne o observability porównujące trzy narzędzia

Poza samym Prometheusem poniższe pytania sprawdzają, czy kandydat potrafi rozumować na poziomie kilku narzędzi. Każda odpowiedź uwypukla koncepcję, którą sprawdza rekruter.

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 dla pojedynczych żądań wymagające stuprocentowej dokładności (zbieranie oparte na scrapowaniu może gubić próbki) oraz systemy zdarzeniowe wymagające zbierania danych w modelu push (Pushgateway istnieje, ale wyłącznie dla zadań wsadowych na poziomie usługi).

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: Czym jest rozliczanie high-watermark w Datadogu i dlaczego ma znaczenie?

Datadog mierzy liczbę hostów co godzinę, odrzuca górny jeden procent godzin i nalicza opłatę według szczytu na poziomie 99. percentyla. Chwilowe skoki auto-skalowania, na przykład podczas ruchu w Black Friday, podnoszą miesięczny rachunek nawet po wyłączeniu instancji. Kandydat, który o tym wspomina, pokazuje realne doświadczenie w zarządzaniu kosztami, czego role SRE wymagają coraz częściej.

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.

Framework decyzyjny: wybór odpowiedniego stosu

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ę.

Źródła

• Wydania Prometheusa: 3.15.0 (wrzesień 2026) stabilizuje kodowanie chunków XOR2, dodaje scrapowanie OpenMetrics 2.0 i oznacza --log.level jako przestarzałe
• Specyfikacja natywnych histogramów Prometheusa: stabilne od 3.8, scrape_native_histograms wymagane od 3.9
• What's new in Grafana 13.0: Git Sync w wersji GA, domyślnie dynamiczne dashboardy, zmiany niekompatybilne wstecz
• Cennik katalogowy Datadoga: ceny infrastruktury, APM i logów użyte w tabeli kosztów
• Funkcje algorytmiczne Datadoga: składnia anomalies() i forecast()

Co zapamiętać przed rozmową o Prometheusie i observability

• Prometheus jest standardem zbierania metryk w środowiskach Kubernetes; pull vs push, cztery typy metryk, rate() vs irate(), kardynalność i HA trzeba znać na pamięć
• W Prometheusie 3.9 i nowszym natywne histogramy są przyjmowane tylko po ustawieniu scrape_native_histograms: true
• Grafana to warstwa wizualizacji, a nie baza danych metryk: łączy się z ponad 100 źródłami danych, w tym z Prometheusem, a stos LGTM (Loki, Grafana, Tempo, Mimir) tworzy kompletną platformę observability o otwartym kodzie źródłowym
• Datadog zapewnia najszybszą drogę do pełnej observability z wbudowanym wykrywaniem anomalii, kosztem wyższej ceny i vendor lock-in
• OpenTelemetry sprawia, że wybór backendu jest mniej ostateczny: instrumentacja pozostaje taka sama niezależnie od tego, które narzędzie przechowuje i odpytuje dane
• Podczas rozmów kwalifikacyjnych liczy się umiejętność ważenia kompromisów (koszt, kontrola, złożoność), a nie promowanie jednego narzędzia
• W ramach szerszego przygotowania przewodnik po kluczowych pytaniach rekrutacyjnych DevOps omawia sąsiednie tematy, które rekruterzy łączą z monitoringiem