Recording Rules: Mempercepat Query & Menstabilkan Dashboard — Belajar Prometheus

Masalah: Query yang Sama Dihitung Ribuan Kali

Sebuah dashboard dengan 12 panel, dibuka 20 orang, dengan auto-refresh 10 detik, akan menjalankan query berat berulang-ulang. Bila salah satunya memindai 30 hari data, Prometheus Anda akan tersengal.

Recording rule menghitung ekspresi secara berkala di belakang layar dan menyimpan hasilnya sebagai time series baru. Dashboard tinggal membaca hasilnya — instan.

Bentuk Dasar

rules/recording.ymlyaml

groups:
  - name: agregasi-http
    interval: 30s          # seberapa sering dihitung (default: evaluation_interval)
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

      - record: job:http_errors:rate5m
        expr: sum by (job) (rate(http_requests_total{status=~"5.."}[5m]))

      - record: job:http_error_ratio:rate5m
        expr: job:http_errors:rate5m / job:http_requests:rate5m

      - record: job_route:http_latency_p95:5m
        expr: |
          histogram_quantile(0.95,
            sum by (le, job, route) (rate(http_request_duration_seconds_bucket[5m])))

📌 Konvensi penamaan resmi: level:metrik:operasi

level — label yang dipertahankan setelah agregasi (job, instance, job_route).
metrik — nama metrik asal, tanpa _total.
operasi — apa yang dilakukan (rate5m, sum, p95).

Contoh: job:http_requests:rate5m langsung memberi tahu pembaca bahwa ini adalah laju request 5 menit yang diagregasi per job. Tanpa konvensi, dalam enam bulan tidak akan ada yang tahu isi metrik hasil_query_3.

Aturan Berlapis (Rule Chaining)

Recording rule boleh memakai hasil rule lain — selama berada dalam grup yang sama, karena rule dalam satu grup dievaluasi berurutan.

berlapisyaml

groups:
  - name: slo-checkout
    interval: 30s
    rules:
      # Lapis 1: angka dasar
      - record: checkout:requests:rate5m
        expr: sum(rate(http_requests_total{job="checkout"}[5m]))

      - record: checkout:errors:rate5m
        expr: sum(rate(http_requests_total{job="checkout", status=~"5.."}[5m]))

      # Lapis 2: memakai hasil lapis 1
      - record: checkout:error_ratio:rate5m
        expr: checkout:errors:rate5m / checkout:requests:rate5m

      # Lapis 3: burn rate terhadap SLO 99,9%
      - record: checkout:burn_rate:1h
        expr: |
          (
            sum(rate(http_requests_total{job="checkout", status=~"5.."}[1h]))
            / sum(rate(http_requests_total{job="checkout"}[1h]))
          ) / 0.001

⛔ Rule di grup berbeda TIDAK dijamin urut

Grup dievaluasi secara paralel. Bila rule di grup B memakai hasil rule di grup A, ada kemungkinan grup B berjalan sebelum grup A selesai — sehingga ia membaca nilai lama atau tidak menemukan apa pun.

Aturan: rule yang saling bergantung harus berada dalam group yang sama, dan ditulis dalam urutan yang benar.

Kapan Membuat Recording Rule

Buat recording rule bila…	Jangan buat bila…
Query dipakai di banyak panel/alert	Query hanya dipakai sekali untuk investigasi
Query memakan waktu > 1 detik	Query sudah cepat
Query memakai rentang panjang (`[7d]`, `[30d]`)	Ekspresinya sering berubah-ubah
Dipakai di alerting rule	—
Dashboard terasa lambat dibuka	—

⚠️ Recording rule juga memakan tempat

Setiap rule menciptakan time series baru yang ikut disimpan dan dihitung dalam kardinalitas. Rule sum by (pod) pada klaster dengan 5.000 pod akan menambah 5.000 series baru.

Agregasi ke level yang lebih tinggi (per job, bukan per pod) biasanya justru mengurangi total series — itulah tujuan yang ideal.