Prometheus vs Grafana vs Datadog di Tahun 2026: Perbandingan Monitoring dan Pertanyaan Wawancara DevOps

Perbandingan Prometheus vs Grafana vs Datadog termasuk salah satu topik yang paling sering diangkat dalam wawancara DevOps. Kemampuan menjelaskan arsitektur, keunggulan, dan kelemahan masing-masing tools bukan sekadar menunjukkan hafalan teori, melainkan membuktikan pengalaman operasional yang sesungguhnya kepada pewawancara.

Arsitektur dan Model Data

Perbedaan arsitektur antara ketiga tools ini bersifat fundamental. Pewawancara kerap menggali topik ini untuk menilai seberapa dalam pemahaman teknis seorang kandidat.

Prometheus menerapkan model pull-based. Tools ini melakukan scraping terhadap endpoint HTTP (umumnya /metrics) pada interval yang telah dikonfigurasi, lalu menyimpan data time-series di dalam TSDB (Time Series Database) lokal khusus. Setiap time series diidentifikasi berdasarkan nama metrik beserta sekumpulan label key-value. Sejak Prometheus 3.0 (dirilis November 2024), native histograms telah mencapai status stabil di v3.8, OTLP ingestion tersedia secara bawaan, dan Remote Write 2.0 meningkatkan kemampuan federasi antar cluster.

Grafana tidak mengumpulkan maupun menyimpan metrik secara mandiri. Tools ini terhubung ke berbagai sumber data -- Prometheus, Loki, Tempo, InfluxDB, Elasticsearch, dan 100+ sumber data lainnya -- kemudian merender dashboard berdasarkan data yang diperoleh. Grafana Labs juga mengelola Mimir (penyimpanan metrik jangka panjang), Loki (agregasi log), dan Tempo (distributed tracing), yang secara keseluruhan membentuk stack observability open-source yang lengkap. Versi 13 yang dirilis pada Mei 2026 menghadirkan fitur observability-as-code, Git Sync untuk dashboard, serta SQL Expressions untuk query lintas sumber data.

Datadog beroperasi sebagai SaaS dengan model push-based. Agent yang terpasang pada host mengirimkan metrik, log, dan trace ke backend cloud Datadog. Seluruh komponen -- ingestion, penyimpanan, querying, alerting, dan dashboard -- berada dalam satu platform terkelola. Mesin ML Watchdog mampu melakukan deteksi anomali secara otomatis tanpa memerlukan konfigurasi threshold secara manual.

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

Konfigurasi YAML di atas mendefinisikan model pull yang diterapkan Prometheus: tools ini menemukan pod Kubernetes melalui service discovery dan melakukan scraping pada endpoint /metrics setiap 15 detik.

PromQL vs Bahasa Query Datadog

Bahasa query menjadi topik wawancara yang kerap dibahas. Kandidat perlu menunjukkan penguasaan terhadap setidaknya satu bahasa query sekaligus mampu menjelaskan trade-off di antara keduanya.

PromQL (Prometheus Query Language) merupakan standar untuk query metrik di seluruh ekosistem Prometheus dan Grafana. PromQL mendukung instant vector, range vector, operator agregasi, serta 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

Bahasa query Datadog menggunakan sintaks yang berbeda, dibangun berdasarkan fungsi dan scoping:

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

PromQL memiliki ekspresivitas yang lebih mendalam untuk analisis ad-hoc. Sebaliknya, bahasa query Datadog menukar sebagian fleksibilitas dengan fungsi ML bawaan seperti anomaly() dan forecast() yang pada stack Prometheus memerlukan tools eksternal tersendiri.

Strategi Alerting

Filosofi alerting berbeda secara signifikan di antara ketiga tools ini. Memahami perbedaan tersebut menunjukkan kematangan operasional yang dihargai oleh pewawancara.

Prometheus Alertmanager mengevaluasi rules pada interval tetap dan mengarahkan alert melalui pipeline yang dapat dikonfigurasi, dilengkapi fitur pengelompokan (grouping), peredaman (silencing), dan penghambatan (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

Pendekatan ini mengharuskan operator mendefinisikan threshold secara eksplisit. Keuntungannya terletak pada transparansi penuh -- setiap alert memiliki ekspresi yang dapat ditinjau dan diaudit. Kekurangannya adalah potensi threshold fatigue: nilai statis sering kali memerlukan penyesuaian sesuai perubahan musiman atau pola traffic.

Grafana Alerting (disatukan sejak Grafana 12+) mengevaluasi query dari seluruh sumber data yang terhubung dan mendukung alert multi-dimensi dengan notification policies.

Datadog Monitors menggabungkan threshold statis dengan monitor berbasis ML untuk deteksi anomaly, outlier, dan forecast. Watchdog secara otomatis menandai anomali performa tanpa memerlukan pembuatan rules secara manual. Pendekatan ini mengurangi beban konfigurasi, namun dengan konsekuensi berkurangnya transparansi terhadap logika deteksi.

Harga dan Total Cost of Ownership

Struktur harga menjadi faktor penentu dalam pemilihan tools di lingkungan produksi dan kerap dibahas dalam wawancara system design. Pemahaman terhadap struktur biaya menunjukkan kesadaran bisnis seorang kandidat.

| Dimension | Prometheus + Grafana | Datadog | |-----------|---------------------|--------| | License | Free (AGPL / Apache 2.0) | $15-31/host/month (annual) | | Metrics storage | Self-managed (Mimir/Thanos) | Included, retention-based pricing | | Log management | Loki (self-hosted) | $0.10/GB ingested + indexing | | APM / Traces | Tempo (self-hosted) | $31/host/month | | Infrastructure cost | Compute + storage for stack | None (SaaS) | | Operational overhead | High (upgrades, scaling, HA) | Minimal | | Typical annual cost (50 hosts) | $20K-60K (infra + engineering) | $50K-150K | | Vendor lock-in risk | Low (OpenTelemetry, PromQL) | Higher (proprietary query language) |

Stack open-source tampak lebih hemat secara kalkulasi awal, tetapi memerlukan alokasi waktu engineering yang cukup besar untuk menangani upgrade, perencanaan kapasitas, dan konfigurasi high-availability. Model terkelola yang ditawarkan Datadog mengalihkan beban tersebut kepada vendor. Bagi tim dengan kurang dari 5 engineer yang mengelola infrastruktur, solusi terkelola sering kali justru memiliki total biaya kepemilikan yang lebih rendah apabila waktu engineering turut diperhitungkan.

Monitoring Kubernetes

Lebih dari 80% cluster Kubernetes menggunakan Prometheus untuk pengumpulan metrik, sehingga topik ini menjadi pembahasan dominan dalam wawancara seputar monitoring orkestrasi container.

Prometheus + Grafana terintegrasi secara native dengan Kubernetes melalui Helm chart kube-prometheus-stack. Chart ini men-deploy Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics, dan dashboard Grafana yang telah dikonfigurasi sebelumnya dalam satu kali instalasi:

# 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

Perintah di atas men-deploy stack monitoring production-grade dengan persistent storage dan retensi data selama 30 hari. Prometheus Operator memanfaatkan Custom Resource Definitions (ServiceMonitor, PodMonitor) untuk mengonfigurasi target scrape secara deklaratif.

Datadog men-deploy agent DaemonSet beserta Cluster Agent. Cluster Agent menangani komunikasi dengan API server secara terpusat, sehingga mengurangi beban pada Kubernetes API. Fitur Live Containers dari Datadog memberikan visibilitas real-time terhadap status pod, sementara Orchestrator Explorer memetakan relasi antara deployment, service, dan pod.

Bagi tim yang telah berinvestasi dalam ekosistem Kubernetes, pendekatan native Prometheus menghindari penambahan dependensi eksternal. Sebaliknya, tim yang mengutamakan kecepatan setup dengan investasi operasional yang lebih minimal cenderung memilih Datadog.

OpenTelemetry dan Netralitas Vendor

OpenTelemetry (OTel) telah menjadi standar industri untuk instrumentasi, dan pewawancara semakin sering membahas topik ini bersamaan dengan perbandingan tools monitoring.

Prometheus 3.0+ menerima metrik OTLP secara native tanpa memerlukan Collector sebagai perantara. Grafana Alloy (penerus Grafana Agent) berfungsi ganda sebagai OTel Collector sekaligus Prometheus scraper. Datadog mendukung ingestion OTLP, namun merekomendasikan penggunaan agent proprietary untuk "akses fitur penuh," yang secara tidak langsung menciptakan soft lock-in.

Adopsi OTel menjadi penting karena memisahkan instrumentasi dari pilihan backend. Kode aplikasi yang diinstrumentasi menggunakan OTel SDK dapat mengirim telemetri ke Prometheus, Grafana Cloud, Datadog, atau backend kompatibel lainnya tanpa perubahan kode sedikit pun. Fleksibilitas ini menjadi argumen yang sangat kuat dalam wawancara system design ketika mendiskusikan strategi observability jangka panjang.

Pertanyaan Wawancara DevOps seputar Monitoring dan Observability

Pertanyaan-pertanyaan berikut sering muncul dalam wawancara DevOps dan SRE. Setiap jawaban menyoroti konsep yang sedang diuji oleh pewawancara.

T: Jelaskan perbedaan antara monitoring, observability, dan alerting.

Monitoring melacak metrik yang telah ditentukan sebelumnya dan memeriksa mode kegagalan yang sudah diketahui. Observability memungkinkan investigasi terhadap mode kegagalan yang belum diketahui melalui metrik, log, dan trace (dikenal sebagai "tiga pilar"). Alerting memicu notifikasi ketika suatu kondisi melampaui threshold yang ditetapkan atau baseline anomali. Secara singkat, monitoring menjawab pertanyaan "apakah sistem dalam kondisi sehat?" sedangkan observability menjawab "mengapa sistem tidak sehat?"

T: Dalam situasi apa Prometheus menjadi pilihan yang kurang tepat untuk monitoring?

Prometheus dioptimalkan untuk reliabilitas di atas durabilitas -- tools ini memprioritaskan ketersediaan sistem monitoring itu sendiri. Beberapa skenario di mana Prometheus kurang optimal: penyimpanan jangka panjang melebihi 30 hari (memerlukan Thanos, Mimir, atau Cortex), data billing per-request yang menuntut akurasi 100% (Prometheus dapat kehilangan sampel saat beban tinggi), serta sistem event-based yang memerlukan push-based collection (meskipun pushgateway tersedia sebagai solusi alternatif).

T: Bagaimana filosofi "Big Tent" Grafana memengaruhi arsitektur observability?

Grafana dapat terhubung ke sumber data mana pun tanpa memerlukan migrasi data. Artinya, tim dapat melakukan query ke Prometheus, Elasticsearch, CloudWatch, dan Datadog dari satu dashboard yang sama. Trade-off yang muncul adalah kompleksitas operasional -- mengelola beberapa backend memerlukan keahlian infrastruktur yang lebih tinggi dibandingkan pendekatan vendor tunggal. Pewawancara menguji apakah kandidat mampu mengartikulasikan trade-off ini secara jernih.

T: Apa yang dimaksud dengan billing high-watermark pada Datadog, dan mengapa hal ini perlu diperhatikan?

Datadog mengukur jumlah host per jam, mengeliminasi 1% jam tertinggi, dan menagih berdasarkan peak di persentil ke-99. Konsekuensinya, lonjakan auto-scaling yang bersifat sementara (misalnya traffic pada periode Black Friday) tetap meningkatkan tagihan bulanan meskipun instance-instance tersebut telah dihentikan. Kandidat yang memahami mekanisme ini menunjukkan pengalaman operasional nyata dalam manajemen biaya, sebuah kompetensi yang semakin dibutuhkan untuk peran SRE.

T: Bagaimana strategi alerting berbasis SLO diterapkan secara berbeda pada Prometheus dan Datadog?

Pada Prometheus, alerting SLO menggunakan recording rules untuk menghitung error budget dan burn rate alert secara pre-computed (mengikuti pendekatan multi-window, multi-burn-rate dari buku SRE Google). Datadog menawarkan widget dan monitor SLO bawaan yang melacak burn rate secara otomatis. Kedua pendekatan mengimplementasikan konsep yang sama, tetapi Prometheus memerlukan konfigurasi manual yang lebih banyak, sementara Datadog menyediakan workflow yang terkelola. Kandidat sebaiknya mereferensikan burn rate windows (1h, 6h, 3d) dan tingkat konsumsi error budget dalam jawabannya.

Untuk latihan lebih mendalam seputar topik monitoring, modul wawancara Prometheus dan monitoring menyediakan skenario tambahan dengan penjelasan yang lebih detail.

Framework Keputusan

| Scenario | Recommended Stack | Rationale | |----------|------------------|----------| | Startup, < 10 engineers | Datadog or Grafana Cloud | Minimize operational overhead | | Large org with platform team | Prometheus + Grafana + Loki | Full control, lower per-unit cost at scale | | Multi-cloud / hybrid | Prometheus + Grafana | Vendor-neutral, consistent across environments | | Compliance-heavy (finance, healthcare) | Self-hosted Prometheus + Grafana | Data stays in-house | | Rapid scaling, unpredictable growth | Grafana Cloud (managed Mimir) | Scales without infrastructure management | | Need ML-powered anomaly detection | Datadog | Watchdog requires no configuration |

Pilihan yang tepat bergantung pada tiga variabel utama: ukuran tim, kematangan operasional, dan batasan anggaran. Tidak ada jawaban yang benar secara universal, dan pewawancara justru mengharapkan kandidat untuk bernalar secara terstruktur tentang trade-off daripada menyatakan satu tools sebagai pemenang mutlak.

Kesimpulan

• Prometheus merupakan standar de facto untuk pengumpulan metrik di lingkungan Kubernetes, dengan versi 3.x yang menghadirkan dukungan OTLP native serta native histograms yang telah stabil sepanjang tahun 2026
• Grafana adalah lapisan visualisasi dan bukan database metrik -- tools ini terhubung ke lebih dari 100 sumber data termasuk Prometheus, dan stack LGTM (Loki, Grafana, Tempo, Mimir) membentuk platform observability open-source yang komprehensif
• Datadog menyediakan jalur tercepat menuju observability full-stack dengan alerting yang didukung ML, namun dengan konsekuensi biaya yang lebih tinggi dan risiko vendor lock-in
• Adopsi OpenTelemetry menjadikan pilihan backend kurang bersifat permanen -- instrumentasi tetap konsisten terlepas dari tools mana yang menyimpan dan melakukan query terhadap data
• Dalam sesi wawancara, tunjukkan kemampuan bernalar tentang trade-off (biaya, kontrol, kompleksitas) daripada sekadar mengadvokasi satu tools tertentu
• Untuk persiapan yang lebih mendalam, berlatihlah dengan modul pertanyaan wawancara DevOps dan pelajari konsep CI/CD pipeline guna memperkuat area pengetahuan yang berkaitan