Kardinalitas, Performa & Troubleshooting — Belajar Prometheus

Penyebab Nomor Satu Prometheus Mati: Kardinalitas

Hampir semua masalah performa Prometheus berujung pada satu hal: terlalu banyak time series. Memori yang dipakai kira-kira sebanding dengan jumlah series aktif, bukan dengan jumlah sampel.

Aturan Praktis Kapasitas

Time series aktif	RAM yang disarankan	Catatan
< 100.000	2–4 GB	Nyaman
100.000 – 500.000	8–16 GB	Perlu recording rule
500.000 – 2.000.000	32–64 GB	Perlu tuning serius
> 2.000.000	—	Pertimbangkan sharding atau Mimir/Thanos

Menemukan Biang Kerok Kardinalitas

berburu-kardinalitaspromql

# 1. Berapa total series aktif?
prometheus_tsdb_head_series

# 2. Metrik mana yang paling banyak series-nya?
topk(20, count by (__name__)({__name__=~".+"}))

# 3. Job mana yang paling boros?
topk(10, count by (job)({__name__=~".+"}))

# 4. Berapa nilai unik dari sebuah label? (calon tersangka)
count(count by (user_id)(http_requests_total))

# 5. Target mana yang mengekspos paling banyak sampel?
topk(10, scrape_samples_scraped)

# 6. Apakah kardinalitas sedang melonjak?
deriv(prometheus_tsdb_head_series[1h]) > 0

💡 Halaman TSDB Status — jalur tercepat

Buka http://prometheus:9090/tsdb-status. Halaman ini langsung menampilkan:

Nama label dengan jumlah nilai unik terbanyak.
Metrik dengan jumlah series terbanyak.
Pasangan label-nilai yang paling banyak muncul.

Dalam 30 detik Anda biasanya sudah menemukan pelakunya.

Gejala dan Diagnosisnya

Gejala	Kemungkinan penyebab	Langkah pertama
OOM-killed berulang	Kardinalitas terlalu tinggi	Buka `/tsdb-status`, cari label pelakunya
Query timeout	Rentang terlalu panjang / terlalu banyak series	Buat recording rule
Dashboard lambat	Query berat diulang tiap refresh	Recording rule + kurangi panel
Alert terlambat berbunyi	Evaluasi rule tertinggal	Cek `rule_group_last_duration`
Target sering DOWN	Scrape timeout / exporter lambat	Naikkan `scrape_timeout`, cek exporter
Data bolong-bolong	Scrape gagal berkala	Cek `scrape_duration_seconds`
Startup sangat lama	WAL besar sedang di-replay	Normal; kurangi kardinalitas untuk mempercepat

⛔ Prometheus OOM: yang harus dilakukan dan urutannya

Jangan langsung menaikkan RAM. Itu menunda masalah, bukan menyelesaikannya — kardinalitas akan terus tumbuh.
Buka /tsdb-status dan temukan label atau metrik pelakunya.
Tambahkan metric_relabel_configs dengan drop atau labeldrop untuk memangkasnya.
Beri tahu tim pemilik aplikasi agar memperbaiki instrumentasinya di sumber.
Pasang sample_limit pada job tersebut agar kejadian serupa tidak terulang.
Baru setelah itu, sesuaikan kapasitas RAM bila memang masih perlu.

Optimasi Query

❌ Lambat

promql

# Memindai semua metrik
{__name__=~".+", job="api"}

# Regex mahal di depan
{job=~".*api.*"}

# Rentang panjang di alerting rule
rate(http_requests_total[7d])

# Agregasi setelah rate atas banyak series
sum(rate(container_cpu_usage_seconds_total[5m]))

✅ Cepat

promql

# Sebutkan nama metrik
http_requests_total{job="api"}

# Matcher eksak lebih dulu
{job="api-produksi"}

# Pakai recording rule
job:http_requests:rate7d

# Batasi lebih dulu dengan label selektif
sum(rate(container_cpu_usage_seconds_total{namespace="produksi"}[5m]))

Perintah Diagnostik

diagnostikbash

# Analisis blok TSDB — apa yang sebenarnya memakan tempat
promtool tsdb analyze /prometheus

# Melihat isi blok tertentu
promtool tsdb list /prometheus

# Menguji query dari CLI
promtool query instant http://localhost:9090 'up == 0'
promtool query range http://localhost:9090 'rate(http_requests_total[5m])' \
  --start=2026-07-27T00:00:00Z --end=2026-07-27T06:00:00Z --step=1m

# Profil memori dan CPU (butuh Go pprof)
curl -s http://localhost:9090/debug/pprof/heap > heap.out
go tool pprof -top heap.out

# Statistik runtime
curl -s http://localhost:9090/api/v1/status/runtimeinfo | jq
curl -s http://localhost:9090/api/v1/status/tsdb | jq '.data.seriesCountByMetricName[:10]'

Batas Pengaman yang Wajib Dipasang

flag-pengamanbash

prometheus \
  --query.max-samples=50000000 \
  --query.timeout=2m \
  --query.max-concurrency=20 \
  --storage.tsdb.retention.size=200GB \
  --web.max-connections=512

Tanpa batas ini, satu query buruk dari seseorang di Grafana bisa merobohkan Prometheus untuk seluruh organisasi.