Alerting Rules: Menulis Alert yang Layak Dibunyikan

Alert yang Buruk Lebih Berbahaya daripada Tidak Ada Alert

Ketika tim menerima 200 notifikasi sehari, mereka berhenti membacanya. Insiden nyata pun lolos. Ini disebut alert fatigue, dan ia adalah penyebab utama gagalnya sistem monitoring yang secara teknis sempurna.

📌 Satu aturan penyaring: "apakah manusia harus bertindak sekarang?"

Bila jawabannya tidak, itu bukan alert — itu dashboard. Setiap alert yang berbunyi harus punya tindakan jelas yang harus diambil seseorang. Bila tindakannya "lihat sebentar lalu abaikan", hapus alert itu.

Anatomi Alerting Rule

rules/alerts.ymlyaml

groups:
  - name: layanan-api
    rules:
      - alert: ErrorRateTinggi
        expr: job:http_error_ratio:rate5m{job="api"} > 0.05
        for: 10m                       # harus benar selama 10 menit berturut-turut
        keep_firing_for: 5m            # tetap firing 5 menit setelah kondisi hilang
        labels:
          severity: critical           # dipakai Alertmanager untuk routing
          tim: checkout
          layanan: api
        annotations:
          summary: "Error rate {{ $labels.job }} mencapai {{ $value | humanizePercentage }}"
          description: >-
            Job {{ $labels.job }} pada {{ $labels.instance }} mengembalikan
            error di atas 5% selama lebih dari 10 menit.
            Nilai saat ini: {{ $value | humanizePercentage }}.
          runbook_url: "https://wiki.internal/runbook/error-rate-tinggi"
          dashboard_url: "https://grafana.internal/d/api-overview"

`for` — Peredam Kebisingan yang Paling Penting

Tanpa for, satu spike sesaat langsung membangunkan orang di tengah malam. Dengan for: 10m, alert baru berbunyi bila kondisinya bertahan.

Jenis alert	`for` yang disarankan
Target mati (`up == 0`)	`2m–5m` — beri toleransi restart wajar
Error rate tinggi	`5m–15m`
Latency tinggi	`10m–15m`
Disk hampir penuh	`15m–1h` — tidak mendesak
Sertifikat kedaluwarsa	`1h` — sangat tidak mendesak
Layanan pembayaran mati total	`0m–1m` — memang harus segera

Template dalam Annotation

templateyaml

        annotations:
          # $labels — semua label dari series yang memicu alert
          summary: "{{ $labels.instance }} di {{ $labels.region }} bermasalah"

          # $value — nilai ekspresi saat alert aktif
          description: "Nilai saat ini: {{ $value }}"

          # Fungsi bantu pemformatan
          info: >-
            Persentase: {{ $value | humanizePercentage }}
            Byte:       {{ $value | humanize1024 }}B
            Durasi:     {{ $value | humanizeDuration }}
            Dibulatkan: {{ $value | printf "%.2f" }}

          # Kondisional
          catatan: '{{ if gt $value 0.5 }}KRITIS{{ else }}perhatian{{ end }}'

Pola Alert yang Terbukti Berguna

pola-alertyaml

      # 1. Target mati — pasangkan SELALU dengan absent()
      - alert: TargetMati
        expr: up == 0
        for: 3m
        labels: { severity: critical }

      - alert: JobHilangDariKonfigurasi
        expr: absent(up{job="pembayaran"})
        for: 10m
        labels: { severity: critical }

      # 2. Kapasitas prediktif — beri waktu untuk bertindak
      - alert: DiskAkanPenuh
        expr: |
          predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}[6h], 4*3600) < 0
          and node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.3
        for: 30m
        labels: { severity: warning }

      # 3. Aplikasi restart berulang (crash loop)
      - alert: AplikasiCrashLoop
        expr: changes(process_start_time_seconds[15m]) > 3
        for: 5m
        labels: { severity: critical }

      # 4. Metrik bisnis — sering menangkap yang lolos alert teknis
      - alert: PesananAnjlok
        expr: |
          sum(rate(pesanan_dibuat_total[15m]))
            < 0.4 * sum(rate(pesanan_dibuat_total[15m] offset 7d))
        for: 20m
        labels: { severity: critical }
        annotations:
          summary: "Pesanan turun >60% dibanding minggu lalu jam yang sama"

Multi-Window Burn Rate — Pola SLO Modern

Pola dari Google SRE Workbook: alert berbunyi cepat untuk masalah besar, dan lambat untuk masalah kecil yang berkepanjangan. Dua jendela waktu digabung agar tidak berbunyi karena spike sesaat.

burn-rateyaml

      # Cepat: budget 30 hari habis dalam ~2 jam -> bangunkan orang
      - alert: SLOBurnRateCepat
        expr: |
          slo:checkout_burn_rate:5m > 14.4
          and slo:checkout_burn_rate:1h > 14.4
        for: 2m
        labels: { severity: critical, tipe: slo }
        annotations:
          summary: "Error budget checkout habis dalam ~2 jam pada laju ini"

      # Lambat: budget habis dalam ~3 hari -> buat tiket, tidak perlu dibangunkan
      - alert: SLOBurnRateLambat
        expr: |
          slo:checkout_burn_rate:6h > 6
          and slo:checkout_burn_rate:1h > 6
        for: 15m
        labels: { severity: warning, tipe: slo }

💡 Kenapa dua jendela sekaligus?

Jendela panjang (6h) memastikan masalahnya nyata dan berkelanjutan. Jendela pendek (1h) memastikan masalahnya masih berlangsung sekarang — sehingga alert otomatis padam setelah insiden selesai, tanpa harus menunggu jendela panjang bergeser.