Pertanyaan Wawancara Prometheus 2026: Perbandingan Prometheus vs Grafana vs Datadog

Pertanyaan wawancara Prometheus muncul di hampir setiap rangkaian wawancara DevOps dan SRE, biasanya disusul dengan "mengapa tidak Grafana atau Datadog?" Kandidat perlu menjelaskan bagaimana Prometheus melakukan scraping dan menyimpan metrik, menulis PromQL yang benar, serta memaparkan trade-off-nya dibandingkan platform terkelola. Pewawancara memakai topik ini untuk membedakan pengalaman operasional yang nyata dari sekadar pengetahuan buku teks. Modul wawancara Prometheus dan monitoring menyajikan topik yang sama dalam bentuk soal latihan.

Pertanyaan Wawancara Prometheus di Sesi DevOps dan SRE

Berikut pertanyaan khusus Prometheus yang paling sering muncul, beserta jawaban yang diberikan kandidat yang menguasai materinya. Semua jawaban mengacu pada Prometheus 3.x: rilis stabil terbaru adalah 3.15 (September 2026), sementara 3.16 masih berstatus release candidate.

T: Mengapa Prometheus menarik (pull) metrik alih-alih menerima kiriman (push)?

Model pull membuat kesehatan target dapat diamati: setiap scrape menghasilkan series up, sehingga target yang mati terlihat sebagai up == 0, bukan sekadar tidak ada data. Server mengendalikan laju scrape, yang melindunginya dari klien yang bermasalah, dan sebuah target dapat diperiksa secara manual dengan membuka endpoint /metrics di browser. Konsekuensinya, Prometheus harus dapat menjangkau setiap target melalui jaringan. Itulah sebabnya batch job berumur pendek memerlukan Pushgateway dan arsitektur lintas jaringan memakai remote write.

T: Apa saja empat tipe metrik, dan kapan summary menjadi pilihan yang keliru?

Counter (hanya naik, kembali ke nol saat restart), gauge (bisa naik dan turun), histogram (observasi dihitung ke dalam bucket) dan summary (kuantil dihitung di sisi klien). Kuantil dari summary tidak dapat diagregasi: rata-rata p99 dari sepuluh pod tidak menghasilkan p99 layanan. Histogram dapat dijumlahkan lintas instance terlebih dahulu lalu diubah menjadi kuantil di sisi server, sehingga histogram menjadi pilihan default untuk latensi.

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

Lupa mencantumkan le di klausa by pada bentuk klasik adalah kesalahan PromQL paling umum dalam sesi live coding: query tersebut tidak mengembalikan hasil yang dapat dipakai.

T: Apa perbedaan rate(), irate() dan increase()?

rate() mengembalikan rata-rata per detik selama seluruh rentang dan menangani reset counter. irate() hanya memakai dua sampel terakhir dalam rentang, sehingga cepat bereaksi tetapi berisik: cocok untuk grafik yang diperbesar, keliru untuk alerting. increase() adalah rate() dikalikan durasi rentang. Karena Prometheus mengekstrapolasi hingga batas jendela waktu, increase() pada counter bilangan bulat dapat mengembalikan angka desimal, dan pewawancara senang menanyakan alasannya.

T: Apa itu cardinality, dan bagaimana cardinality explosion didiagnosis?

Setiap kombinasi unik dari nama metrik dan nilai label merupakan time series tersendiri yang disimpan di memori. Label seperti user_id, email atau path URL mentah yang mengandung ID melipatgandakan jumlah series hingga memori server habis. Diagnosis dimulai dari halaman status TSDB (/tsdb-status) atau dengan query:

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

Perbaikannya dilakukan di sumber: hapus atau tulis ulang label dengan metric_relabel_configs, atau tetapkan sample_limit pada scrape job agar satu deployment yang bermasalah tidak menjatuhkan server.

T: Untuk apa recording rules?

Recording rules menghitung ekspresi yang mahal di setiap interval evaluasi dan menyimpan hasilnya sebagai series baru. Dashboard dan alert kemudian melakukan query ke series hasil pre-komputasi yang murah tersebut. Konvensi penamaannya adalah level:metric:operations:

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

T: Apa fungsi klausa for pada alerting rule?

Alert yang ekspresinya bernilai true berpindah dari inactive ke pending, dan baru mencapai firing setelah kondisi bertahan selama durasi for. Mekanisme ini menyaring lonjakan sesaat yang hanya terjadi pada satu scrape. keep_firing_for bekerja sebaliknya: alert tetap berstatus firing selama beberapa waktu setelah kondisi pulih, sehingga alert yang naik-turun tidak memicu page dua kali.

T: Bagaimana Prometheus dibuat highly available?

Jalankan dua replika identik yang melakukan scraping pada target yang sama, masing-masing dengan external label replica yang berbeda. Keduanya mengirim alert ke cluster Alertmanager, yang menghapus duplikasi notifikasi melalui protokol gossip. Untuk query, Thanos Query atau Mimir menghapus duplikasi kedua series dengan mengabaikan label replica. Prometheus sendiri tidak memiliki clustering: TSDB lokal milik satu server tidak direplikasi.

T: Federation atau remote write untuk arsitektur multi-cluster?

Federation memungkinkan Prometheus global melakukan scraping terhadap series tertentu, umumnya yang sudah diagregasi, dari endpoint /federate milik Prometheus di setiap cluster. Pendekatan ini cocok untuk sejumlah kecil rollup. Remote write mengalirkan setiap sampel ke penyimpanan terpusat seperti Mimir, Thanos Receive atau backend vendor, dan menjadi jawaban standar untuk query global serta retensi jangka panjang.

T: Bagaimana mendeteksi target yang hilang dari service discovery?

up == 0 hanya terpicu selama target masih ditemukan oleh service discovery. Jika pod atau entri service discovery sudah hilang, series tersebut berhenti ada dan alert tidak pernah terpicu. absent(up{job="api-server"}) menangani kasus tersebut.

T: Apa yang berubah di Prometheus 3?

Prometheus 3.0 (November 2024) menghadirkan UI baru, mengizinkan karakter UTF-8 pada nama metrik dan label, serta menambahkan OTLP receiver bawaan di /api/v1/otlp/v1/metrics yang diaktifkan dengan --web.enable-otlp-receiver. Native histograms menjadi stabil di versi 3.8. Sejak 3.9, feature flag lama tidak lagi berpengaruh dan ingestion mensyaratkan scrape_native_histograms: true pada konfigurasi scrape atau global. Versi 3.15 menstabilkan encoding chunk float XOR2 dan menambahkan scraping OpenMetrics 2.0.

Arsitektur dan Model Data: Cara Setiap Tools Menangani Metrik

Setelah dasar-dasar Prometheus terbahas, pewawancara biasanya beralih ke perbedaan arsitektur ketiga tools ini.

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 lokal khusus. Setiap time series diidentifikasi berdasarkan nama metrik beserta sekumpulan label key-value. Lini 3.x menambahkan native histograms yang stabil, OTLP receiver, serta Remote Write 2.0 untuk mengirim sampel ke penyimpanan terpusat.

Grafana tidak mengumpulkan maupun menyimpan metrik. Tools ini terhubung ke berbagai sumber data, yaitu Prometheus, Loki, Tempo, InfluxDB, Elasticsearch dan 100+ sumber data lainnya, kemudian merender dashboard dari data tersebut. Grafana Labs juga mengelola Mimir (penyimpanan metrik jangka panjang), Loki (agregasi log) dan Tempo (distributed tracing), yang bersama Grafana membentuk stack open-source LGTM. Grafana 13, yang diumumkan di GrafanaCON pada April 2026, menjadikan Git Sync untuk dashboard berstatus generally available, mengaktifkan dynamic dashboards secara default, serta menghapus perintah grafana-cli dan grafana-server.

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

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

Konfigurasi YAML di atas mendefinisikan model pull Prometheus: tools ini menemukan pod Kubernetes melalui service discovery, hanya mempertahankan pod yang memiliki anotasi prometheus.io/scrape: "true", menulis ulang alamat ke port yang dianotasikan, lalu melakukan scraping pada /metrics setiap 15 detik. Rule kedua menggabungkan kedua source label dengan ;, itulah sebabnya regex mencocokkan host:port;port.

PromQL vs Bahasa Query Datadog: Sintaks dan Kemampuan

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 (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 memiliki ekspresivitas yang lebih dalam untuk analisis ad-hoc. Bahasa query Datadog menukar sebagian fleksibilitas dengan fungsi algoritmik bawaan seperti anomalies() (algoritma basic, agile, robust) dan forecast() (linear, seasonal) yang pada stack Prometheus memerlukan tools eksternal.

Strategi Alerting: Berbasis Rules vs Deteksi Berbasis ML

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

Prometheus Alertmanager menerima alert dari rules yang dievaluasi Prometheus pada interval tetap, lalu mengarahkannya 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, karena nilai statis sering kali memerlukan penyesuaian sesuai perubahan musiman atau pola traffic.

Grafana Alerting (sistem unified alerting, default sejak Grafana 9) mengevaluasi query dari seluruh sumber data yang terhubung dan mendukung alert multi-dimensi dengan notification policies.

Datadog Monitors menggabungkan threshold statis dengan monitor 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 di Tahun 2026

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. Angka Datadog di bawah ini merupakan harga daftar dengan penagihan tahunan.

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: Perbandingan Kedalaman Integrasi

Prometheus adalah sistem metrik default di ekosistem Kubernetes, 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. Cara meng-override values chart seperti ini dibahas lebih rinci dalam panduan wawancara Helm charts.

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.x menerima metrik OTLP secara langsung setelah --web.enable-otlp-receiver diaktifkan, sehingga Collector tidak lagi wajib menjadi 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 Observability yang Membandingkan Ketiga Tools

Di luar Prometheus itu sendiri, pertanyaan-pertanyaan berikut menguji apakah kandidat mampu bernalar lintas tools. 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% (pengumpulan berbasis scrape dapat melewatkan sampel), serta sistem event-based yang memerlukan push-based collection (Pushgateway memang ada, tetapi hanya untuk batch job tingkat layanan).

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.

Framework Keputusan: Memilih Stack yang Tepat

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.

Sumber

• Rilis Prometheus: 3.15.0 (September 2026) menstabilkan encoding chunk XOR2, menambahkan scraping OpenMetrics 2.0 dan menandai --log.level sebagai deprecated
• Spesifikasi native histograms Prometheus: stabil sejak 3.8, scrape_native_histograms wajib sejak 3.9
• What's new in Grafana 13.0: Git Sync GA, dynamic dashboards secara default, breaking changes
• Harga daftar Datadog: harga infrastructure, APM dan log yang dipakai pada tabel biaya
• Fungsi algoritmik Datadog: sintaks anomalies() dan forecast()

Yang Perlu Diingat untuk Wawancara Prometheus dan Observability

• Prometheus adalah standar pengumpulan metrik di lingkungan Kubernetes; kuasai pull vs push, empat tipe metrik, rate() vs irate(), cardinality dan HA di luar kepala
• Di Prometheus 3.9 dan versi setelahnya, native histograms hanya di-ingest jika scrape_native_histograms: true ditetapkan
• Grafana adalah lapisan visualisasi, 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 lengkap
• Datadog menyediakan jalur tercepat menuju observability full-stack dengan deteksi anomali bawaan, dengan konsekuensi biaya yang lebih tinggi dan risiko vendor lock-in
• Adopsi OpenTelemetry menjadikan pilihan backend tidak lagi permanen: instrumentasi tetap sama, apa pun tools yang menyimpan dan melakukan query terhadap data
• Dalam sesi wawancara, tunjukkan kemampuan bernalar tentang trade-off (biaya, kontrol, kompleksitas) daripada sekadar membela satu tools tertentu
• Untuk persiapan yang lebih luas, panduan pertanyaan wawancara DevOps esensial membahas topik-topik terkait yang biasanya disambungkan pewawancara setelah pembahasan monitoring