Storage, Retensi, Remote Write, HA & Federation — Belajar Prometheus

Cara Kerja TSDB Prometheus

struktur penyimpanantext

/prometheus/
├── wal/                       ← Write-Ahead Log, data 2 jam terakhir
│   ├── 00000123
│   └── checkpoint.000122/
├── chunks_head/               ← blok yang masih aktif di memori
├── 01HQ8X.../                 ← blok tersegel (immutable), rentang 2 jam
│   ├── chunks/
│   ├── index
│   └── meta.json
└── lock

Sampel masuk ke head block di memori, sekaligus ditulis ke WAL agar tahan crash.
Setiap 2 jam, head block disegel menjadi blok persisten di disk.
Blok-blok lama dipadatkan (compaction) menjadi blok yang lebih besar.
Blok yang melewati retensi dihapus.

Memperkirakan Kebutuhan Disk

📐 Rumus perkiraan

text

disk = retensi_detik × sampel_per_detik × byte_per_sampel

sampel_per_detik = jumlah_time_series / scrape_interval
byte_per_sampel  ≈ 1,5–2 byte (setelah kompresi)

Contoh: 500.000 series, scrape 15 detik, retensi 30 hari
= 2.592.000 × (500.000 / 15) × 2 byte ≈ 172 GB

Sediakan margin 30–50% untuk proses compaction yang butuh ruang sementara.

Retensi

flagbash

prometheus \
  --storage.tsdb.retention.time=30d \
  --storage.tsdb.retention.size=200GB    # yang tercapai lebih dulu yang berlaku

⚠️ Selalu set retention.size juga

Retensi berbasis waktu saja berbahaya: bila jumlah time series tiba-tiba melonjak (misalnya ada developer yang menambahkan label berkardinalitas tinggi), disk bisa penuh sebelum 30 hari terlewati — dan Prometheus akan mati. Batas ukuran adalah jaring pengaman Anda.

Remote Write — Penyimpanan Jangka Panjang

Prometheus dirancang untuk data operasional jangka pendek. Untuk menyimpan bertahun-tahun, kirim data ke sistem lain.

prometheus.ymlyaml

remote_write:
  - url: http://mimir:9009/api/v1/push
    name: mimir-utama
    remote_timeout: 30s

    # Kirim hanya yang perlu disimpan lama -> hemat biaya besar
    write_relabel_configs:
      - source_labels: [__name__]
        action: keep
        regex: "job:.*|slo:.*|instance:.*"    # hanya hasil recording rule

    queue_config:
      capacity: 10000            # antrean per shard
      max_shards: 50             # paralelisme maksimum
      min_shards: 1
      max_samples_per_send: 2000
      batch_send_deadline: 5s
      min_backoff: 30ms
      max_backoff: 5s

    metadata_config:
      send: true
      send_interval: 1m

⛔ Jangan kirim SEMUA metrik lewat remote write

Biaya penyimpanan cloud dihitung per time series per bulan. Mengirim seluruh 2 juta series ke Grafana Cloud atau Mimir bisa menghasilkan tagihan yang mengejutkan.

Gunakan write_relabel_configs dengan action: keep untuk mengirim hanya hasil recording rule dan metrik SLO. Data mentah beresolusi tinggi cukup disimpan lokal selama 15–30 hari.

High Availability

pola HAtext

Pola paling sederhana: dua Prometheus identik, konfigurasi sama,
dibedakan hanya oleh external_labels.replica

  prom-01 (replica: a) ─┐
                        ├─▶ Thanos Query / Mimir ─▶ Grafana
  prom-02 (replica: b) ─┘
                              (deduplikasi otomatis
                               berdasarkan label replica)

Keduanya men-scrape target yang sama dan mengevaluasi rule yang sama.
Bila satu mati, yang lain tetap punya data lengkap.

Solusi	Cocok untuk	Catatan
Thanos	Multi-cluster, arsip di object storage	Sidecar + Query + Store + Compactor
Grafana Mimir	Skala sangat besar, multi-tenant	Menerima remote write, horizontal scalable
VictoriaMetrics	Efisiensi sumber daya	Lebih hemat memori, sebagian kompatibel PromQL
Federation	Agregasi lintas datacenter	Sederhana tapi terbatas, mudah disalahgunakan

Federation — dan Kesalahpahaman yang Umum

federationyaml

  - job_name: federate
    scrape_interval: 60s
    honor_labels: true
    metrics_path: /federate
    params:
      # HANYA ambil hasil recording rule yang sudah teragregasi
      'match[]':
        - '{__name__=~"job:.*"}'
        - '{__name__=~"slo:.*"}'
    static_configs:
      - targets: ["prom-jkt:9090", "prom-sby:9090"]

⛔ Federation BUKAN cara membuat "Prometheus global"

Kesalahan yang sangat umum: memakai match[]: '{__name__=~".+"}' untuk menarik semua metrik dari Prometheus lain. Ini akan gagal karena:

Satu scrape harus mentransfer jutaan series dalam satu request HTTP — timeout hampir pasti.
Prometheus pusat menjadi titik kegagalan tunggal dengan beban yang tak tertanggung.
Resolusi data hilang (scrape 60 detik atas data yang aslinya 15 detik).

Federation hanya cocok untuk menarik sedikit metrik teragregasi (hasil recording rule). Untuk kebutuhan "satu tempat melihat semua", gunakan Thanos atau Mimir.