KodelokaMasalah yang Diselesaikan Prometheus
Ketika sistem Anda hanya satu server, htop sudah cukup. Ketika menjadi 40 container yang datang dan pergi otomatis, Anda butuh sesuatu yang: mengumpulkan angka dari semua tempat, menyimpannya berurut waktu, dan bisa ditanyai "apa yang terjadi pada pukul 14:32 kemarin?".
Prometheus adalah sistem monitoring dan basis data time-series yang lahir di SoundCloud (2012), kini menjadi proyek CNCF dan standar de facto untuk monitoring infrastruktur modern — terutama di ekosistem Kubernetes.
Anatomi Satu Time Series
Ini konsep paling mendasar. Satu time series di Prometheus adalah kombinasi unik dari nama metrik dan seluruh labelnya.
http_requests_total{method="POST", handler="/api/pesanan", status="200", instance="10.0.0.5:8080", job="api"}
└────── nama metrik ──────┘└─────────────────── label ───────────────────┘
Nilai: 1523 @ 14:30:00
1547 @ 14:30:15
1571 @ 14:30:30 ← counter, terus naikBila handler punya 20 nilai, method 5 nilai, status 8 nilai, dan Anda punya 30 instance, maka dari satu nama metrik lahir 20 × 5 × 8 × 30 = 24.000 time series.
Tambahkan satu label user_id dengan 100.000 nilai, dan angkanya menjadi 2,4 miliar — Prometheus Anda akan mati. Fenomena ini disebut cardinality explosion, dan merupakan penyebab nomor satu kegagalan Prometheus di produksi.
Model Pull, Bukan Push
Prometheus mendatangi aplikasi Anda dan membaca endpoint /metrics secara berkala (default tiap 15 detik). Aplikasi tidak mengirim apa pun.
| Aspek | Pull (Prometheus) | Push (StatsD, Graphite) |
|---|---|---|
| Siapa yang inisiatif | Server monitoring | Aplikasi |
| Deteksi target mati | Otomatis — metrik up=0 | Sulit: diam bisa berarti mati atau memang idle |
| Konfigurasi | Terpusat di Prometheus | Tersebar di setiap aplikasi |
| Uji manual | Cukup curl /metrics | Harus menunggu aplikasi mengirim |
| Job berumur pendek | Sulit — butuh Pushgateway | Mudah |
| Melalui NAT/firewall | Sulit — Prometheus harus bisa menjangkau target | Mudah |
Karena Prometheus yang mendatangi, ia otomatis tahu daftar lengkap yang seharusnya ada. Bila sebuah instance tidak merespons, metrik up untuk instance itu bernilai 0 — dan Anda bisa langsung membuat alert dari situ. Pada sistem push, aplikasi yang mati hanya berhenti mengirim, dan diam itu ambigu.
Arsitektur Ekosistem
┌──────────────┐ scrape ┌──────────────────┐
│ Aplikasi │◀──────────│ │
│ /metrics │ │ │ ┌─────────────┐
└──────────────┘ │ PROMETHEUS │──▶│ Grafana │
┌──────────────┐ scrape │ │ │ (visualisasi)│
│ node_exporter│◀──────────│ - scrape │ └─────────────┘
│ :9100 │ │ - TSDB lokal │
└──────────────┘ │ - PromQL │ ┌─────────────┐
┌──────────────┐ scrape │ - rule eval │──▶│Alertmanager │
│ postgres_exp │◀──────────│ │ │ (notifikasi)│
│ :9187 │ └──────────────────┘ └──────┬──────┘
└──────────────┘ │ │
│ remote_write ▼
▼ Slack / Email
Thanos / Mimir / Cortex PagerDuty / WA
(penyimpanan jangka panjang)Format Teks Exposition
Endpoint /metrics hanyalah teks biasa. Anda bisa membacanya dengan curl.
# HELP http_requests_total Jumlah total request HTTP yang diterima.
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 18493
http_requests_total{method="POST",status="201"} 2841
http_requests_total{method="POST",status="500"} 17
# HELP process_resident_memory_bytes Memori residen proses dalam byte.
# TYPE process_resident_memory_bytes gauge
process_resident_memory_bytes 8.4152e+07- Bukan untuk logging. Gunakan Loki, Elasticsearch, atau OpenSearch.
- Bukan untuk tracing. Gunakan Tempo, Jaeger, atau Zipkin.
- Bukan untuk data yang harus 100% akurat seperti penagihan. Prometheus mengambil sampel berkala dan bisa kehilangan data saat scrape gagal — ia dirancang untuk keandalan operasional, bukan akuntansi.
- Bukan untuk event individual. Prometheus menyimpan agregat, bukan "request nomor 12345 dari user Budi".