Belajar Observability dengan LGTM Stack - Alerting Strategy & Alert Manager

#Pendahuluan

Observability bukan hanya tentang melihat masalah — tapi juga tentang mendeteksi masalah sebelum pengguna mengeluh. Inilah peran alerting: menghubungkan query telemetry dengan notifikasi yang memicu tindakan.

Episode ini membahas strategi alerting yang sehat, mekanisme Grafana Alerting, konsep routing dan grouping ala AlertManager, recording rules untuk query mahal, serta praktik terbaik agar tim kalian tidak tenggelam dalam alert fatigue.

#Prinsip Alerting

#Alert yang Actionable

Alert yang baik menjawab tiga pertanyaan: apa yang salah, seberapa parah, dan apa yang harus dilakukan. Alert tanpa runbook hanyalah suara bising.

• Actionable: setiap alert harus memicu tindakan yang jelas.
• Alert fatigue prevention: kurangi noise; alert yang sering salah hanya dibuang.
• Severity levels: gunakan kritikal, warning, dan info dengan ambang yang jelas.
• On-call best practices: jangan bangunkan on-call untuk kondisi yang bisa menunggu.

apa yang salah? seberapa parah? apa yang harus dilakukan?

Tiga pertanyaan apa yang salah? seberapa parah? apa yang harus dilakukan? ini adalah filter pertama sebelum membuat alert baru.

#Grafana Alerting

#Membuat Alert Rule

Alert rule di Grafana adalah query yang dievaluasi berkala:

sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m]))

Query di atas menghitung rasio request 5xx. Alert rule mengombinasikannya dengan kondisi, periode for, dan folder tujuan.

#Multi-Dimensional Alerting

Grafana mendukung alert multi-dimensi: satu rule menghasilkan banyak instance alert, satu per kombinasi label. Contoh: rule error rate di atas akan membuat satu alert per service yang melanggar ambang.

#Evaluasi dan State Management

• Alert evaluation: query dievaluasi tiap interval, misalnya tiap 1 menit.
• Pending: kondisi terpenuhi tapi belum melewati for.
• Firing: kondisi terpenuhi selama periode for.
• Resolved: kondisi kembali normal.

conditions:
  - evaluator:
      type: greater_than
      params: [0.05]
for: 10m

Nilai for: 10m mencegah alert flapping — alert hanya menyala bila error rate tinggi selama 10 menit berturut-turut.

#AlertManager

#Routing dan Grouping

Routing menentukan ke mana alert dikirim, grouping menggabungkan alert serupa menjadi satu notifikasi:

route:
  group_by: ["service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
      receiver: on-call-pagerduty
    - match:
        severity: warning
      receiver: slack-alerts

Aturan match: severity: critical mengirim alert kritikal ke PagerDuty on-call, sementara warning cukup ke Slack.

#Inhibition, Silencing, dan Templating

• Inhibition rules: menekan alert yang lebih rendah ketika alert kritikal aktif.
• Silencing: menonaktifkan notifikasi untuk kondisi tertentu saat maintenance.
• Notification channels: email, Slack, PagerDuty, webhook, dan lainnya.
• Templating: menyesuaikan isi notifikasi dengan data alert.

#Recording Rules

#Pre-Computing Query Mahal

Recording rules menghitung query berat di muka dan menyimpannya sebagai metrik baru:

groups:
  - name: error_rate.rules
    rules:
      - record: job:http_errors:ratio5m
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) by (job) /
              sum(rate(http_requests_total[5m])) by (job)

Metrik job:http_errors:ratio5m bisa dipakai alert dan dashboard tanpa menghitung ulang query berat — persis konsep yang kalian lihat di episode 7.

#Best Practices Alert

• Penamaan konsisten: service:condition:severity, misalnya checkout:error-rate:critical.
• Runbook links: setiap alert membawa link ke runbook.
• Informasi kontekstual: sertakan nilai aktual, ambang, dan durasi.
• Alert testing: uji setiap alert baru dengan simulasi.
• Alert review: audit rutin untuk menghapus alert yang tidak lagi berguna.

#Penutup

Di episode 19 ini kalian memahami prinsip alert yang actionable, mekanisme Grafana Alerting dengan evaluasi dan state management, routing dan grouping ala AlertManager, recording rules untuk query mahal, serta praktik terbaik pemeliharaan alert.

Inti yang harus dibawa pulang:

• Setiap alert harus actionable dan membawa runbook.
• Alert rule adalah query dengan kondisi, ambang, dan periode for.
• Routing menentukan tujuan, grouping menggabungkan alert serupa.
• Recording rules memuat query berat menjadi metrik turunan.
• Audit rutin mencegah alert fatigue.

Di episode 20 selanjutnya kita akan membahas SLI, SLO, SLA, dan error budgets — mendefinisikan indikator keandalan, menetapkan target, membuat dashboard SLO dan burn rate alert, serta mengelola error budget sebagai bahan pengambilan keputusan. Alerting tanpa target keandalan hanyalah alarm tanpa arah.