Alerting #

Alert yang baik membangunkan kamu pukul tiga pagi karena ada masalah nyata yang mempengaruhi pengguna. Alert yang buruk membangunkan kamu pukul tiga pagi karena CPU spike sesaat yang menghilang sendiri dalam 30 detik. Perbedaan ini bukan hanya soal kenyamanan — alert yang terlalu banyak dan terlalu sering menyebabkan alert fatigue, di mana tim mulai mengabaikan alert karena sebagian besar tidak actionable. Ironisnya, alert fatigue membuat alert yang benar-benar penting akhirnya diabaikan juga. Merancang alerting yang baik adalah tentang menemukan signal di antara noise.

Masalah Alert yang Buruk #

Tanda-tanda sistem alerting yang bermasalah:

  Alert fatigue:
  ✗ Tim mendapat 50+ alert per hari
  ✗ Sebagian besar alert "dismissed" tanpa investigasi
  ✗ Alert yang benar-benar serius tenggelam dalam noise
  ✗ "Oh itu pasti false alarm lagi" sebagai respons default

  Alert yang tidak actionable:
  ✗ "CPU usage naik ke 75%" — dan?  Harus ngapain?
  ✗ Alert yang tidak ada yang bisa dilakukan on-call engineer
    pada jam 3 pagi
  ✗ Alert yang sering false positive

  Alert yang terlalu sensitif:
  ✗ Trigger saat ada lonjakan sesaat (1 menit) yang tidak signifikan
  ✗ Alert yang fire lalu self-resolve tanpa intervensi
  ✗ Alert untuk metric yang tidak berhubungan dengan user experience

Konsekuensi:
  → Tim mulai disable atau mute alert
  → Insiden nyata tidak terdeteksi karena alert sudah di-mute
  → Kepercayaan pada sistem monitoring menurun

Symptom-Based vs Cause-Based Alerting #

Ini adalah salah satu konsep paling penting dalam merancang alert yang baik.

Cause-Based Alert (alert pada penyebab):
  "CPU usage > 80%"
  "Memory usage > 90%"
  "Disk write latency > 100ms"
  "Database connection count > 80%"

  Masalah:
  ✗ CPU 85% mungkin tidak menyebabkan masalah apapun bagi user
  ✗ Kamu harus tahu: "high CPU → symptom apa?"
  ✗ Banyak cause yang mungkin tidak langsung terasa oleh user

Symptom-Based Alert (alert pada gejala yang terasa user):
  "Error rate > 1% selama 5 menit"
  "P99 latency > 3 detik selama 5 menit"
  "Checkout success rate turun di bawah 95%"
  "Availability di bawah 99.9%"

  Keuntungan:
  ✓ Setiap alert berarti ada yang terasa oleh pengguna
  ✓ Lebih sedikit false positive
  ✓ Clear impact: "1% user mengalami error"
  ✓ Lebih actionable: prioritas jelas

  Cause-based alert masih berguna untuk:
  ✓ Prediktif: disk akan penuh dalam 2 jam
  ✓ Diagnosa setelah symptom alert trigger
  ✓ Sebagai informasi tambahan dalam dashboard, bukan pager alert

Prinsip:
  Bangunkan on-call karena PENGGUNA terdampak,
  bukan karena metric teknis bergerak.

SLO-Based Alerting — Cara Paling Efektif #

Service Level Objective (SLO) adalah target performa yang kamu definisikan untuk layanan. Alerting berbasis SLO menghubungkan alert langsung ke commitment kamu terhadap pengguna.

Definisikan SLO terlebih dahulu:

  SLO: 99.9% request sukses dalam rolling 30 hari
  
  Ini berarti: dari 100 request, boleh gagal < 0.1%
  Error budget per 30 hari: 100% - 99.9% = 0.1% = 43.8 menit downtime

Error Budget Burn Rate Alert:

  Jika burn rate terlalu tinggi → error budget akan habis sebelum 30 hari

  Alert 1 (critical, pager): burn rate > 14.4x dalam 1 jam
  → Error budget habis dalam < 2 hari jika terus di rate ini
  → Butuh respons segera

  Alert 2 (warning, ticket): burn rate > 6x dalam 6 jam
  → Error budget habis dalam < 5 hari jika terus di rate ini
  → Butuh perhatian tapi tidak harus tengah malam

  Alert 3 (info): burn rate > 3x dalam 72 jam
  → Error budget habis dalam < 10 hari
  → Perlu diinvestigasi selama jam kerja

  Keuntungan SLO-based alerting:
  ✓ Alert hanya trigger jika reliabilitas yang dijanjikan terancam
  ✓ Urgency proporsional dengan seberapa cepat error budget terbakar
  ✓ Tidak alert untuk error kecil yang tidak mengancam SLO
  ✓ Satu framework yang menghubungkan teknis dan komitmen bisnis

Anatomi Alert yang Baik #

Setiap alert harus bisa menjawab:

  1. Apa yang salah?
     "Error rate di payment-service melebihi 5%"

  2. Siapa yang terdampak?
     "~500 user mencoba checkout per menit, ~25 mengalami error"

  3. Seberapa parah?
     "Error rate: 5.2%, threshold: 1%. Sudah berlangsung: 8 menit"

  4. Apa yang harus dilakukan?
     Runbook link: https://wiki.company.com/runbooks/payment-service-errors

  5. Di mana mencari informasi lebih lanjut?
     Dashboard link: https://grafana.company.com/d/payment-service
     Log query: service=payment-service level=ERROR last 15m

Contoh alert message yang baik:

  🔴 CRITICAL: High Error Rate — payment-service
  
  Error rate: 5.2% (threshold: 1%)
  Berlangsung selama: 8 menit
  Dampak estimasi: ~25 user gagal checkout per menit
  
  Runbook: https://wiki/runbooks/payment-service-high-error-rate
  Dashboard: https://grafana/payment-service
  Recent deployments: https://deploy.company.com/payment-service

Alert Routing dan Escalation #

Tidak semua alert butuh membangunkan seseorang pukul 3 pagi:

  Critical (PagerDuty / on-call rotation):
    → Pengguna terdampak sekarang, layanan degraded atau down
    → Butuh respons dalam 5-15 menit
    → Membangunkan on-call engineer

  Warning (Slack channel + ticket):
    → Potensi masalah yang tidak langsung parah
    → Error budget terbakar tapi tidak dalam bahaya segera
    → Butuh perhatian selama jam kerja berikutnya

  Info (Dashboard + daily digest):
    → Tren yang perlu dipantau
    → Tidak butuh aksi segera
    → Review di standup atau weekly meeting

  Routing yang efektif:
  ✓ Critical: PagerDuty → on-call engineer → escalate ke backup
  ✓ Warning: Slack #alerts → tim yang on-duty
  ✓ Info: Dashboard, tidak mengganggu siapapun

  Escalation policy:
  On-call tidak respons dalam 15 menit → escalate ke backup
  Backup tidak respons dalam 15 menit → escalate ke manager
  → Pastikan selalu ada seseorang yang pasti akan respons

Mengelola Alert Fatigue #

Cara sistematis mengurangi alert noise:

  1. Audit alert yang ada secara berkala:
     → Alert mana yang sering fire?
     → Alert mana yang sering di-dismiss tanpa aksi?
     → Alert mana yang false positive > 30%?
     → Candi atau delete alert tersebut

  2. Naikkan threshold:
     → Alert yang fire terlalu sering mungkin threshold-nya terlalu ketat
     → CPU > 80% → naikkan ke CPU > 90% selama > 10 menit

  3. Tambahkan minimum duration:
     → "CPU > 90% selama 1 menit" → terlalu sensitif
     → "CPU > 90% selama 10 menit berturut-turut" → lebih bermakna

  4. Deduplication dan grouping:
     → 50 instance mengirim alert bersamaan = satu alert, bukan 50
     → Alertmanager (Prometheus) atau PagerDuty dapat melakukan ini

  5. Business hours routing:
     → Alert severity lebih rendah → kirim ke Slack, bukan pager
     → Hanya pada jam kerja, bukan tengah malam

  6. Post-incident review:
     → Setiap insiden: "apakah alerting bekerja dengan baik?"
     → Alert terlambat? Terlalu banyak noise? Missing signal?
     → Update alerting berdasarkan temuan ini

Ringkasan #

Alert fatigue membunuh efektivitas alerting — terlalu banyak alert menyebabkan semua alert diabaikan, termasuk yang penting.
Symptom-based alert lebih baik dari cause-based — bangunkan on-call karena pengguna terdampak, bukan karena metric teknis bergerak.
SLO-based alerting menghubungkan alert ke komitmen bisnis — burn rate yang terlalu tinggi adalah sinyal yang paling bermakna untuk prioritas respons.
Setiap alert harus actionable — jika tidak ada yang bisa dilakukan on-call engineer, alert tersebut seharusnya tidak membangunkan siapapun.
Sertakan konteks dan runbook di setiap alert — what, who impacted, how severe, dan apa yang harus dilakukan.
Audit dan prune alert secara berkala — alerting bukan set-and-forget; review setelah setiap insiden dan secara rutin setiap kuartal.

← Sebelumnya: Tracing Berikutnya: Observability vs Monitoring →