Prometheus vs Grafana vs Datadog 2026: Monitoring Karşılaştırması ve DevOps Mülakat Soruları

Prometheus, Grafana ve Datadog arasındaki fark, hemen her DevOps ve SRE mülakatında er ya da geç sorulan konulardan biridir. Bu üç aracı yalnızca yüzeysel olarak değil; mimarilerini, güçlü yönlerini ve ödünleşimlerini derinlemesine açıklayabilen adaylar, işe alım sürecinde diğerlerinden belirgin biçimde ayrışır. Bu yazı, üç aracın temel farklarını karşılaştırır, sorgu dillerini ve alerting yaklaşımlarını analiz eder ve en sık karşılaşılan monitoring mülakat sorularına hazırlar.

Mimari ve Veri Modeli: Her Araç Metrikleri Nasıl Ele Alır?

Bu üç araç arasındaki mimari farklar temeldir ve işe alım sorumluları, adayların teknik anlayış derinliğini ölçmek için bu konuyu sıkça sorar.

Prometheus pull tabanlı bir model kullanır. Sunucu, yapılandırılabilir aralıklarla HTTP uç noktalarını (genellikle /metrics) sorgular ve zaman serisi verilerini kendine ait yerel bir Time Series Database'de (TSDB) saklar. Her zaman serisi, bir metrik adı ve bir dizi anahtar-değer etiketiyle (label) tanımlanır. Kasım 2024'te yayımlanan Prometheus 3.0, v3.8 ile birlikte kararlı native histogram desteğini, yerleşik OTLP ingestion'ı ve cluster federation'ı iyileştiren Remote Write 2.0'ı beraberinde getirdi.

Grafana metrikleri kendisi toplamaz veya saklamaz. Bunun yerine veri kaynaklarına -- Prometheus, Loki, Tempo, InfluxDB, Elasticsearch ve 100'den fazlasına -- bağlanır ve dashboard'ları bu verilerden oluşturur. Grafana Labs ayrıca Mimir (uzun vadeli metrik depolama), Loki (log toplama) ve Tempo (distributed tracing) araçlarını da geliştirir. Bu bileşenler birlikte, LGTM stack olarak bilinen eksiksiz bir açık kaynak observability platformunu oluşturur. Mayıs 2026'da çıkan sürüm 13; observability-as-code araçlarını, dashboard'lar için Git Sync'i ve kaynaklar arası sorgular için SQL Expressions özelliğini tanıttı.

Datadog push tabanlı bir SaaS hizmeti olarak çalışır. Host'lara kurulan agent'lar metrikleri, log'ları ve trace'leri bulut backend'ine gönderir. Ingestion, depolama, sorgulama, alerting ve dashboarding gibi tüm işlevler tek bir yönetilen platform içinde yer alır. Watchdog ML motoru, manuel eşik değerleri tanımlamaya gerek kalmadan otomatik anomali tespiti gerçekleştirir.

Aşağıdaki Prometheus yapılandırması, pull modelini bir Kubernetes entegrasyonu üzerinden gösterir:

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

Bu YAML yapılandırması pull modelini gösterir: Kubernetes pod'ları Service Discovery aracılığıyla otomatik olarak keşfedilir ve /metrics uç noktaları her 15 saniyede bir sorgulanır. relabel_configs bölümü, hangi pod'ların scrape edileceğini ve metriklerin hangi portta yer aldığını belirler. Buna karşılık Datadog yalnızca bir agent'ın DaemonSet olarak kurulmasını gerektirir; yapılandırma merkezî olarak web arayüzü üzerinden yapılır.

PromQL ve Datadog Sorgu Dili: Sözdizimi ve Yetenekler

Sorgu dilleri, monitoring alanında en sık karşılaşılan teknik mülakat konularından biridir. Adaylardan en az bir dile akıcı biçimde hâkim olmaları ve iki dil arasındaki ödünleşimleri açıklayabilmeleri beklenir.

PromQL (Prometheus Query Language), tüm Prometheus ve Grafana ekosisteminde metrik sorgularının standardıdır. Dil; instant vector, range vector, aggregation operatörleri ve recording rule'ları destekler. İfade gücü karmaşık ad-hoc analizlere olanak tanır, ancak belirgin bir öğrenme süresi gerektirir.

# 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

rate() fonksiyonu, bir counter'ın belirli bir zaman penceresindeki ortalama değişim oranını hesaplar. Mülakatlarda düzenli olarak rate() (tüm pencere boyunca yumuşatılmış oran) ile irate() (son iki veri noktasına dayalı anlık oran) arasındaki fark sorulur. predict_linear() fonksiyonu, doğrusal regresyona dayanarak bir kaynağın ne zaman tükeneceğini öngörmeyi sağlar; bu, tipik bir kapasite planlama senaryosudur.

Datadog'un sorgu dili ise fonksiyon çağrılarına ve scoping'e dayanan farklı bir yaklaşım izler:

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

Temel fark işlev kapsamında yatar: PromQL, matematiksel işlemler ve ad-hoc analizler için daha derin bir ifade gücü sunar. Datadog'un dili ise bu esnekliğin bir kısmını anomaly() ve forecast() gibi yerleşik ML fonksiyonlarıyla değiştirir. Bu fonksiyonlar bir Prometheus stack'inde ek harici araçlar gerektirir. Mülakatlar açısından şu geçerlidir: PromQL'deki rate() semantiğini net biçimde açıklayabilen ve aynı zamanda her iki dilin sınırlarını bilen aday, gerçek pratik deneyime sahip olduğunu gösterir.

Alerting Stratejileri: Kural Tabanlı mı, ML Destekli mi?

Alerting felsefesi araçlar arasında köklü biçimde farklılaşır. Bu farkları anlamak, mülakatlarda operasyonel olgunluğun bir işaretidir.

Prometheus Alertmanager, kuralları sabit aralıklarla değerlendirir ve alert'leri grouping, silencing ve inhibition özelliklerine sahip yapılandırılabilir bir pipeline üzerinden yönlendirir:

# 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

Bu yaklaşım eşik değerlerinin açıkça tanımlanmasını gerektirir. Avantajı tam şeffaflıktır: Her alert'in, code review'larda ve denetimlerde izlenebilen doğrulanabilir bir expression'ı vardır. Dezavantajı ise threshold fatigue olarak adlandırılan durumdur; statik eşik değerlerinin mevsimsel örüntülere ve büyüyen altyapıya düzenli olarak uyarlanması gerekir, bu da yüzlerce servis söz konusu olduğunda giderek daha fazla emek gerektirir.

Grafana Alerting, Grafana 12+ ile birleştirilmiş haliyle, bağlı herhangi bir veri kaynağı üzerinden sorguları değerlendirir ve notification policy'lerle çok boyutlu alert'leri destekler. Sürüm 13'ten itibaren alert tanımları kod olarak versiyonlanabilir ve Git Sync üzerinden yönetilebilir; bu da Infrastructure-as-Code iş akışlarını önemli ölçüde kolaylaştırır.

Datadog Monitors, statik eşik değerlerini ML destekli anomali, outlier ve forecast monitor'leriyle birleştirir. Watchdog, manuel kural oluşturmaya gerek kalmadan performans anomalilerini otomatik olarak işaretler. Bu, yapılandırma yükünü belirgin biçimde azaltır ancak tespit mantığındaki şeffaflığın azalması pahasına gelir. Finans veya sağlık gibi düzenlemeye tabi sektörlerde bu durum sorun yaratabilir; çünkü denetçiler izlenebilir ve belgelenmiş alerting kuralları bekler.

Fiyatlandırma ve Toplam Sahip Olma Maliyeti (TCO)

Fiyatlandırma, pratikte araç seçiminde belirleyici bir faktördür ve system design mülakatlarında düzenli olarak gündeme gelir. Maliyet yapılarını anlayan ve ifade edebilen adaylar ticari farkındalık gösterir.

| Boyut | Prometheus + Grafana | Datadog | |-----------|---------------------|--------| | Lisans | Ücretsiz (AGPL / Apache 2.0) | 15-31 USD/host/ay (yıllık) | | Metrik depolama | Kendi yönetiminde (Mimir/Thanos) | Dahil, retention'a dayalı | | Log yönetimi | Loki (self-hosted) | 0,10 USD/GB ingestion + indeksleme | | APM / Trace | Tempo (self-hosted) | 31 USD/host/ay | | Altyapı maliyeti | Stack için compute + storage | Yok (SaaS) | | Operasyonel yük | Yüksek (upgrade, ölçekleme, HA) | Minimum | | Tipik yıllık maliyet (50 host) | 20.000-60.000 USD (altyapı + mühendislik) | 50.000-150.000 USD | | Vendor lock-in riski | Düşük (OpenTelemetry, PromQL) | Daha yüksek (tescilli sorgu dili) |

Açık kaynak stack kâğıt üzerinde daha ucuz görünür, ancak bakım, upgrade, kapasite planlama ve yüksek erişilebilirlik (HA) yapılandırması için adanmış mühendislik zamanı gerektirir. Datadog'un yönetilen modeli bu yükü sağlayıcıya devreder. Deneyimler, beşten az altyapı mühendisiyle çalışan ekipler için mühendislik zamanı da hesaba katıldığında yönetilen çözümlerin çoğu zaman daha düşük toplam maliyete sahip olduğunu gösterir.

Sıklıkla göz ardı edilen bir nokta ise Datadog'un high-watermark faturalandırmasıdır: Host sayısı saatlik olarak ölçülür, saatlerin en yüksek yüzde biri atılır ve 99. yüzdelik dilimdeki tepe değer faturalandırma temeli olarak kullanılır. Geçici auto-scaling zirveleri -- örneğin Black Friday trafiği sırasında -- örnekler sonlandırıldıktan sonra bile aylık faturayı yükseltir.

Kubernetes İzleme: Entegrasyon Derinliği Karşılaştırması

Tüm Kubernetes cluster'larının yüzde 80'inden fazlası metrik toplama için Prometheus kullanır. Bu da konuyu, container orkestrasyonu izlemesiyle ilgili mülakatlarda pratikte kaçınılmaz kılar.

Prometheus + Grafana, kube-prometheus-stack Helm chart'ı üzerinden nativ olarak entegre olur. Bu chart; Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics ve önceden yapılandırılmış Grafana dashboard'larını tek bir kurulumda deploy eder:

# 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

Bu komut, kalıcı depolama ve 30 günlük veri retention'ı olan üretime hazır bir monitoring stack'i deploy eder. Prometheus Operator, scrape target'larını deklaratif biçimde yapılandırmak için Custom Resource Definition'ları (ServiceMonitor, PodMonitor) kullanır. Ekipler, merkezî Prometheus yapılandırmasına erişime gerek kalmadan kendi servisleri için monitoring yapılandırmaları oluşturabilir; bu da büyük organizasyonlarda önemli bir organizasyonel avantajdır.

Datadog, bir agent DaemonSet'i ve bir Cluster Agent deploy eder. Cluster Agent, Kubernetes API sunucusuyla iletişimi merkezî olarak üstlenir ve böylece API üzerindeki yükü azaltır. Live Containers görünümü pod durumlarına gerçek zamanlı görünürlük sağlar; Orchestrator Explorer ise deployment, servis ve pod'lar arasındaki ilişkileri görselleştirir. Kurulum yükü daha düşüktür, ancak harici bir SaaS hizmetine bağımlılık ortaya çıkar.

Halihazırda Kubernetes ekosistemine derinlemesine yerleşmiş ekipler için Prometheus-nativ yaklaşım, harici bir bağımlılık eklemekten kaçınır. Hızlı kurulumu ve düşük operasyonel yatırımı önceleyen ekipler ise daha çok Datadog veya Grafana Cloud'a yönelir.

OpenTelemetry ve Sağlayıcı Bağımsızlığı

OpenTelemetry (OTel), uygulamaların instrumentation'ı için endüstri standardı haline gelmiştir. Mülakatlarda, monitoring aracı karşılaştırmaları bağlamında OTel'in rolü giderek daha sık sorulmaktadır.

Prometheus 3.0+, ara katman olarak ayrı bir Collector'a gerek kalmadan OTLP metriklerini nativ olarak kabul eder. Grafana Agent'ın halefi olan Grafana Alloy, hem OTel Collector hem de Prometheus scraper olarak işlev görür. Datadog OTLP ingestion'ı destekler, ancak "tam özellik erişimi" için kendi tescilli agent'larını önerir; bu da yumuşak bir vendor lock-in biçimidir.

OTel'in stratejik önemi, instrumentation ile backend seçimini birbirinden ayırmasında yatar. OTel SDK'larıyla instrument edilmiş uygulama kodu; telemetri verilerini Prometheus, Grafana Cloud, Datadog veya uyumlu herhangi bir backend'e kod değişikliği yapmadan gönderebilir. Bu esneklik, özellikle uzun vadeli observability stratejileri söz konusu olduğunda system design mülakatlarında güçlü bir argümandır. OTLP'nin tescilli entegrasyonlara neden tercih edilmesi gerektiğini açıklayabilen aday, mimari öngörü sergiler.

Monitoring ve Observability Üzerine DevOps Mülakat Soruları

Aşağıdaki sorular DevOps ve SRE mülakatlarında düzenli olarak karşımıza çıkar. Her yanıt, işe alım sorumlularının özellikle test ettiği kavramları öne çıkarır.

S: Monitoring, observability ve alerting arasındaki fark nedir?

Monitoring önceden tanımlanmış metrikleri izler ve bilinen hata modlarını kontrol eder. Observability, metrik, log ve trace'ler -- yani "üç sütun" -- aracılığıyla bilinmeyen hata modlarının incelenmesini mümkün kılar. Alerting, koşullar tanımlı eşik değerlerini veya anomali baseline'larını aştığında bildirimleri tetikler. Monitoring "Sistem sağlıklı mı?" sorusunu yanıtlarken, observability "Sistem neden sağlıksız?" sorusunu ele alır.

S: Prometheus hangi senaryolarda kötü bir tercih olur?

Prometheus dayanıklılıktan (durability) çok güvenilirlik için optimize edilmiştir; öncelik, monitoring sisteminin kendi erişilebilirliğidir. Prometheus'un sınırlarına ulaştığı senaryolar: 30 günün ötesinde uzun vadeli depolama (Thanos, Mimir veya Cortex gerektirir), yüzde 100 doğruluk gerektiren faturalandırmayla ilgili veriler (Prometheus yük altında sample'ları düşürebilir) ve push tabanlı toplama gerektiren event tabanlı sistemler (Pushgateway bir geçici çözüm olarak mevcut olsa da).

S: Grafana'nın "Big Tent" felsefesi observability mimarisini nasıl etkiler?

Grafana, veri taşımaya gerek kalmadan her veri kaynağına bağlanır. Ekipler Prometheus, Elasticsearch, CloudWatch ve Datadog'u tek bir dashboard'da birleştirebilir. Ödünleşim operasyonel karmaşıklıkta yatar: Birden fazla backend'in bakımı, tek sağlayıcılı bir yaklaşıma kıyasla daha fazla altyapı uzmanlığı gerektirir. İşe alım sorumluları, adayların bu ödünleşimi net biçimde ifade edip edemediğini test eder.

S: SLO tabanlı alerting Prometheus ve Datadog arasında nasıl farklılaşır?

Prometheus'ta SLO tabanlı alerting, error budget'ları ve burn-rate alert'lerini önceden hesaplamak için recording rule'ları kullanır; bu, Google'ın SRE kitabındaki multi-window, multi-burn-rate yaklaşımıdır. Datadog ise burn rate'i otomatik olarak takip eden yerleşik SLO widget'ları ve monitor'ları sunar. Her iki yaklaşım da aynı kavramı uygular, ancak Prometheus daha fazla manuel yapılandırma gerektirirken Datadog yönetilen bir iş akışı sağlar. İyi bir mülakat yanıtında burn-rate pencereleri (1h, 6h, 3d) ve error budget tüketim oranları somut biçimde adlandırılmalıdır.

S: Prometheus bağlamında cardinality nedir ve neden sorunludur?

Cardinality, Prometheus'taki benzersiz zaman serilerinin sayısını ifade eder. Metrik adı ile label değerlerinin her kombinasyonu ayrı bir zaman serisi oluşturur. Yüksek cardinality'ye sahip label'lar -- örneğin kullanıcı ID'leri veya request ID'leri -- zaman serilerinin sayısını üstel biçimde artırabilir ve hem belleği hem de sorgu performansını ciddi ölçüde olumsuz etkileyebilir. En iyi uygulamalar; label değerlerinin sınırlanmasını, ön toplama için recording rule kullanımını ve prometheus_tsdb_head_series üzerinden kendi Prometheus TSDB'nizin izlenmesini kapsar.

Monitoring konularında daha derin bir hazırlık için Prometheus monitoring mülakat modülü, ayrıntılı açıklamalarla ek senaryolar sunar.

Karar Çerçevesi: Doğru Stack'i Seçmek

| Senaryo | Önerilen Stack | Gerekçe | |----------|------------------|----------| | Startup, < 10 mühendis | Datadog veya Grafana Cloud | Operasyonel yükü en aza indirmek | | Platform ekibi olan büyük organizasyon | Prometheus + Grafana + Loki | Tam kontrol, ölçekte daha düşük birim maliyet | | Multi-cloud / hibrit | Prometheus + Grafana | Sağlayıcı bağımsız, ortamlar arası tutarlı | | Uyumluluk yoğun sektör (finans, sağlık) | Self-hosted Prometheus + Grafana | Veriler şirket içinde kalır | | Hızlı büyüme, öngörülemeyen ölçekleme | Grafana Cloud (yönetilen Mimir) | Altyapı yönetimi olmadan ölçeklenir | | ML destekli anomali tespiti gereksinimi | Datadog | Watchdog yapılandırma gerektirmez |

Doğru seçim üç değişkene bağlıdır: ekip büyüklüğü, operasyonel olgunluk ve bütçe kısıtları. Evrensel olarak doğru bir yanıt yoktur. İşe alım sorumluları, adayların tek bir kazanan ilan etmek yerine ödünleşimleri sistematik biçimde değerlendirmesini bekler.

Sonuç

• Prometheus, Kubernetes ortamlarında metrik toplamanın fiili standardıdır; sürüm 3.x, 2026'da nativ OTLP desteğini ve kararlı native histogram'ları beraberinde getirir
• Grafana bir görselleştirme katmanıdır, metrik veritabanı değildir -- LGTM stack (Loki, Grafana, Tempo, Mimir), 100'den fazla veri kaynağı entegrasyonuyla eksiksiz bir açık kaynak observability platformu oluşturur
• Datadog, full-stack observability'ye en hızlı yolu ML destekli alerting ile sunar; ancak daha yüksek maliyet ve daha güçlü vendor lock-in pahasına
• OpenTelemetry, instrumentation'ı backend seçiminden ayırır ve belirli bir araca yönelik kararı daha az kalıcı hale getirir
• Cardinality yönetimi, Prometheus ortamlarında kritik bir operasyonel konudur ve sık karşılaşılan bir mülakat temasıdır
• Mülakatlarda önemli olan, tek bir aracı her derde deva gibi sunmak yerine maliyet, kontrol ve karmaşıklık arasındaki ödünleşimleri sistematik biçimde tartabilme yeteneğini göstermektir
• Pratik hazırlık için DevOps mülakat soruları modülü ile CI/CD pipeline kavramları gibi komşu konuların derinleştirilmesi önerilir