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

Prometheus mülakat soruları neredeyse her DevOps ve SRE mülakat sürecinde karşıya çıkar ve genellikle ardından "neden Grafana ya da Datadog değil?" sorusu gelir. Adayın, Prometheus'un metrikleri nasıl scrape edip sakladığını açıklaması, doğru PromQL yazması ve yönetilen bir platforma karşı ödünleşimleri savunması beklenir. Mülakatçılar bu konuyla gerçek operasyonel deneyimi ders kitabı bilgisinden ayırır. Prometheus ve monitoring mülakat modülü aynı konuları alıştırma soruları olarak içerir.

DevOps ve SRE Mülakatlarında Sorulan Prometheus Soruları

Aşağıda en sık karşılaşılan Prometheus'a özgü sorular, kendinden emin bir adayın vereceği yanıtla birlikte yer alır. Sorular Prometheus 3.x'i esas alır: güncel kararlı sürüm 3.15'tir (Eylül 2026), 3.16 ise release candidate aşamasındadır.

S: Prometheus neden metrikleri push ile almak yerine pull ile çeker?

Pull modeli hedeflerin sağlığını gözlemlenebilir kılar: her scrape bir up serisi üretir, böylece çökmüş bir hedef sessizlik olarak değil up == 0 olarak görünür. Scrape hızını sunucu kontrol eder, bu da onu hatalı davranan bir istemciden korur. Bir hedef, /metrics uç noktası tarayıcıda açılarak elle de kontrol edilebilir. Bedeli, Prometheus'un her hedefe ağ üzerinden erişebilmesi gerekmesidir. Kısa ömürlü batch job'ların Pushgateway'e ihtiyaç duymasının ve ağlar arası kurulumların remote write kullanmasının nedeni budur.

S: Dört metrik türü nedir ve summary hangi durumda yanlış seçimdir?

Counter (yalnızca artar, yeniden başlatmada sıfırlanır), gauge (artar ve azalır), histogram (gözlemler bucket'lara sayılır) ve summary (quantile'lar istemcide hesaplanır). Summary quantile'ları birleştirilemez: on pod'un p99 değerlerinin ortalaması servisin p99 değerini vermez. Histogramlar ise önce instance'lar arasında toplanıp ardından sunucu tarafında quantile'a dönüştürülebilir. Gecikme ölçümünde varsayılan seçim olmalarının nedeni budur.

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

Klasik biçimde by ifadesine le eklemeyi unutmak, canlı kodlama turlarında en sık yapılan PromQL hatasıdır: sorgu kullanılabilir hiçbir sonuç döndürmez.

S: rate(), irate() ve increase() arasındaki fark nedir?

rate() tüm aralık boyunca saniye başına ortalamayı döndürür ve counter sıfırlanmalarını ele alır. irate() aralıktaki yalnızca son iki örneği kullanır; hızlı tepki verir ama gürültülüdür, bu yüzden yakınlaştırılmış bir grafik için uygundur, alerting için yanlıştır. increase(), rate() değerinin aralık süresiyle çarpımıdır. Prometheus pencere sınırlarına doğru ekstrapolasyon yaptığı için tam sayı bir counter üzerinde increase() tam sayı olmayan bir değer döndürebilir ve mülakatçılar bunun nedenini sormayı sever.

S: Cardinality nedir ve cardinality patlaması nasıl teşhis edilir?

Metrik adı ile label değerlerinin her benzersiz kombinasyonu, bellekte tutulan ayrı bir zaman serisidir. user_id, email ya da ID içeren ham bir URL yolu gibi bir label, sunucunun belleği tükenene kadar seri sayısını katlar. Teşhis TSDB durum sayfasında (/tsdb-status) ya da bir sorguyla başlar:

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

Çözüm kaynaktadır: label, metric_relabel_configs ile kaldırılır veya yeniden yazılır ya da tek bir hatalı deployment'ın sunucuyu çökertmemesi için scrape job'ına sample_limit tanımlanır.

S: Recording rule'lar ne işe yarar?

Pahalı bir ifadeyi her değerlendirme aralığında önceden hesaplar ve sonucu yeni bir seri olarak saklar. Dashboard'lar ve alert'ler bundan sonra önceden hesaplanmış ucuz seriyi sorgular. Adlandırma kuralı level:metric:operations biçimindedir:

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

S: Bir alerting rule'daki for ifadesi ne yapar?

İfadesi doğru hale gelen bir alert inactive durumundan pending durumuna geçer ve koşul for süresi boyunca devam ettiğinde ancak firing durumuna ulaşır. Bu, tek scrape'lik anlık sıçramaları filtreler. keep_firing_for bunun tersini yapar: koşul ortadan kalktıktan sonra alert'i bir süre daha firing durumunda tutar ve böylece kararsız bir alert'in iki kez çağrı göndermesini önler.

S: Prometheus yüksek erişilebilir hale nasıl getirilir?

Aynı hedefleri scrape eden iki özdeş replika, her biri farklı bir replica external label'ı ile çalıştırılır. İkisi de alert'leri bir Alertmanager cluster'ına gönderir; Alertmanager, gossip protokolü sayesinde bildirimleri tekilleştirir. Sorgular tarafında Thanos Query veya Mimir, replica label'ını yok sayarak iki seriyi tekilleştirir. Prometheus'un kendisinde clustering yoktur: tek bir sunucunun yerel TSDB'si replike edilmez.

S: Çoklu cluster kurulumlarında federation mı, remote write mı?

Federation, global bir Prometheus'un her cluster'daki Prometheus'un /federate uç noktasından seçilmiş, genellikle toplulaştırılmış serileri scrape etmesini sağlar. Küçük bir özet seti için uygundur. Remote write ise her örneği Mimir, Thanos Receive veya bir sağlayıcı backend'i gibi merkezi bir depoya akıtır ve global sorgulama ile uzun süreli retention için standart yanıttır.

S: Service discovery'den kaybolan bir hedef nasıl tespit edilir?

up == 0 yalnızca hedef hâlâ keşfediliyorken tetiklenir. Pod veya service discovery kaydı ortadan kalktıysa seri artık var olmaz ve alert hiçbir zaman tetiklenmez. Bu durumu absent(up{job="api-server"}) karşılar.

S: Prometheus 3'te neler değişti?

Prometheus 3.0 (Kasım 2024) yeni bir arayüz getirdi, metrik ve label adlarında UTF-8 karakterlere izin verdi ve --web.enable-otlp-receiver ile etkinleştirilen, /api/v1/otlp/v1/metrics adresinde yerleşik bir OTLP alıcısı ekledi. Native histogram'lar 3.8'de kararlı hale geldi. 3.9'dan itibaren eski feature flag hiçbir şey yapmaz ve ingestion için scrape veya global yapılandırmada scrape_native_histograms: true gerekir. 3.15, XOR2 float chunk kodlamasını kararlı hale getirdi ve OpenMetrics 2.0 scraping desteği ekledi.

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

Prometheus temelleri ele alındıktan sonra mülakatçılar genellikle üç aracın mimari açıdan nasıl ayrıştığına geçer.

Prometheus pull tabanlı bir model kullanır. Yapılandırılmış aralıklarla HTTP uç noktalarını (genellikle /metrics) scrape eder ve zaman serisi verilerini kendine ait yerel bir TSDB'de saklar. Her zaman serisi, bir metrik adı ve bir dizi anahtar-değer etiketiyle (label) tanımlanır. 3.x serisi kararlı native histogram desteği, bir OTLP alıcısı ve örnekleri merkezi depolamaya göndermek için Remote Write 2.0 ekler.

Grafana metrikleri kendisi toplamaz veya saklamaz. Prometheus, Loki, Tempo, InfluxDB, Elasticsearch ve 100'den fazla başka veri kaynağı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; bunlar Grafana ile birlikte açık kaynak LGTM stack'ini oluşturur. Nisan 2026'da GrafanaCON'da duyurulan Grafana 13, dashboard'lar için Git Sync'i genel kullanıma (GA) açtı, dinamik dashboard'ları varsayılan hale getirdi ve grafana-cli ile grafana-server komutlarını kaldırdı.

Datadog push tabanlı bir SaaS hizmeti olarak çalışır. Host'lara kurulan agent'lar metrikleri, log'ları ve trace'leri Datadog'un 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 motoru, manuel eşik değerleri tanımlamaya gerek kalmadan anomalileri otomatik olarak işaretler.

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

Bu YAML, Prometheus'un pull modelini tanımlar: Kubernetes pod'ları service discovery ile keşfedilir, yalnızca prometheus.io/scrape: "true" annotation'ına sahip olanlar tutulur, adres annotation'daki porta göre yeniden yazılır ve /metrics her 15 saniyede bir scrape edilir. İkinci kural iki kaynak label'ı ; ile birleştirir; regex'in host:port;port biçimini eşlemesinin nedeni budur.

PromQL ve Datadog Sorgu Dili: Sözdizimi ve Yetenekler

Sorgu dilleri sık karşılaşılan bir mülakat konusudur. Adaylardan en az bir dile akıcı biçimde hâkim olmaları ve diller 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.

# 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

Datadog'un sorgu dili ise fonksiyonlara ve scoping'e dayanan farklı bir sözdizimi kullanır:

# 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, ad-hoc analiz için daha derin bir ifade gücü sunar. Datadog'un sorgu dili ise bu esnekliğin bir kısmını, bir Prometheus stack'inde harici araç gerektirecek anomalies() (basic, agile, robust algoritmaları) ve forecast() (linear, seasonal) gibi yerleşik algoritmik fonksiyonlarla takas eder.

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, Prometheus'un sabit aralıklarla değerlendirdiği kurallardan gelen alert'leri alır ve bunları 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 incelenebilir bir expression'ı vardır. Dezavantajı ise threshold fatigue olarak adlandırılan durumdur, çünkü statik değerlerin çoğu zaman mevsimsel olarak ayarlanması gerekir.

Grafana Alerting (Grafana 9'dan beri varsayılan olan unified alerting sistemi), bağlı herhangi bir veri kaynağı üzerinden sorguları değerlendirir ve notification policy'lerle çok boyutlu alert'leri destekler.

Datadog Monitors, statik eşik değerlerini 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ü azaltır ancak tespit mantığındaki şeffaflığın azalması pahasına gelir.

2026'da 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 sıkça gündeme gelir. Maliyet yapılarını anlamak ticari farkındalık gösterir. Aşağıdaki Datadog rakamları, yıllık faturalandırmadaki liste fiyatlarıdır.

Açık kaynak stack kâğıt üzerinde daha ucuz görünür, ancak 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. Altyapıyı beşten az mühendisle yöneten ekipler için mühendislik zamanı da hesaba katıldığında yönetilen çözümler çoğu zaman daha düşük toplam maliyete sahiptir.

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

Prometheus, Kubernetes ekosisteminin varsayılan metrik sistemidir; bu da konuyu container orkestrasyonu izlemesiyle ilgili mülakatların baskın teması haline getirir.

Prometheus + Grafana, kube-prometheus-stack Helm chart'ı üzerinden Kubernetes ile 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. Chart değerlerini bu şekilde geçersiz kılma konusu Helm chart mülakat rehberinde daha ayrıntılı ele alını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.

Halihazırda Kubernetes ekosistemine yatırım yapmış ekipler için Prometheus-nativ yaklaşım, harici bir bağımlılık eklemekten kaçınır. Daha az operasyonel yatırımla hızlı kurulumu önceleyen ekipler ise Datadog'a yönelir.

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

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

Prometheus 3.x, --web.enable-otlp-receiver ayarlandığında OTLP metriklerini doğrudan kabul eder; bu nedenle ara katman olarak bir Collector artık gerekli değildir. 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 benimsenmesi, instrumentation ile backend seçimini birbirinden ayırdığı için önemlidir. 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, uzun vadeli observability stratejisi tartışılırken system design mülakatlarında güçlü bir argümandır.

Üç Aracı Karşılaştıran Observability Mülakat Soruları

Prometheus'un ötesinde, bu sorular adayın araçlar arasında akıl yürütüp yürütemediğini test eder. Her yanıt, mülakatçının kontrol ettiği kavramı ö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 ("üç 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 zorlandığı senaryolar: 30 günün ötesinde uzun vadeli depolama (Thanos, Mimir veya Cortex gerektirir), yüzde 100 doğruluk gerektiren istek bazlı faturalandırma verileri (scrape tabanlı toplama örnekleri kaçırabilir) ve push tabanlı toplama gerektiren event tabanlı sistemler (Pushgateway mevcuttur, ancak yalnızca servis düzeyindeki batch job'lar içindir).

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: Datadog'un high-watermark faturalandırması nedir ve neden önemlidir?

Datadog host sayısını saatlik olarak ölçer, saatlerin en yüksek yüzde birini atar ve 99. yüzdelik dilimdeki tepe değere göre faturalandırır. Bu, geçici auto-scaling zirvelerinin (örneğin Black Friday trafiği) instance'lar sonlandırıldıktan sonra bile aylık faturayı şişirdiği anlamına gelir. Bundan söz eden adaylar, SRE rollerinin giderek daha fazla talep ettiği maliyet yönetimi konusunda gerçek operasyonel deneyim gösterir.

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.

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

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.

Kaynaklar

• Prometheus sürümleri: 3.15.0 (Eylül 2026) XOR2 chunk kodlamasını kararlı hale getirir, OpenMetrics 2.0 scraping ekler ve --log.level seçeneğini kullanımdan kaldırılmış (deprecated) olarak işaretler
• Prometheus native histogram spesifikasyonu: 3.8'den beri kararlı, 3.9'dan beri scrape_native_histograms zorunlu
• What's new in Grafana 13.0: Git Sync GA, varsayılan dinamik dashboard'lar, geriye dönük uyumsuz değişiklikler
• Datadog liste fiyatları: maliyet tablosunda kullanılan altyapı, APM ve log fiyatları
• Datadog algoritmik fonksiyonları: anomalies() ve forecast() sözdizimi

Prometheus ve Observability Mülakatı İçin Akılda Tutulması Gerekenler

• Prometheus, Kubernetes ortamlarında metrik toplamanın standardıdır; pull ve push farkı, dört metrik türü, rate() ve irate() farkı, cardinality ve HA ezbere bilinmelidir
• Prometheus 3.9 ve sonrasında native histogram'lar yalnızca scrape_native_histograms: true ayarlandığında alınır
• Grafana bir görselleştirme katmanıdır, metrik veritabanı değildir: Prometheus dahil 100'den fazla veri kaynağına bağlanır ve LGTM stack (Loki, Grafana, Tempo, Mimir) eksiksiz bir açık kaynak observability platformu oluşturur
• Datadog, yerleşik anomali tespitiyle full-stack observability'ye en hızlı yolu sunar; bedeli daha yüksek fiyat ve vendor lock-in'dir
• OpenTelemetry'nin benimsenmesi backend seçimini daha az kalıcı hale getirir: veriyi hangi araç saklayıp sorgularsa sorgulasın instrumentation aynı kalır
• Mülakatlarda tek bir aracı savunmak yerine ödünleşimler (maliyet, kontrol, karmaşıklık) üzerine akıl yürütebildiğini göstermek gerekir
• Daha geniş bir hazırlık için temel DevOps mülakat soruları rehberi, mülakatçıların monitoring'e bağladığı komşu konuları ele alır