Recraftory

Alerting

Konfigurasi alert dan incident response

Prinsip Alerting yang Baik

Alert pada Symptom, Bukan Cause

  • Symptom: Request lambat, banyak error
  • Cause: Disk penuh, CPU tinggi
  • Alert pada symptom lebih relevan untuk pengguna

Actionable Alert

  • Setiap alert harus memiliki tindakan yang jelas
  • Jika tidak ada yang bisa dilakukan, jangan alert
  • Contoh baik: "Error rate > 5%, cek database connection"

Severity Levels

  • Critical: Service down, butuh aksi segera
  • Warning: Degradasi, butuh perhatian segera
  • Info: Informasi, tidak butuh aksi langsung

Prometheus Alertmanager

Konfigurasi Alert Rule

groups:
  - name: api-alerts
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m])) 
          / sum(rate(http_requests_total[5m])) > 0.05
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "High error rate detected"
          description: "Error rate is {{ $value }} for {{ $labels.job }}"

      - alert: HighLatency
        expr: |
          histogram_quantile(0.99, 
            sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
          ) > 0.5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High latency detected"

Konfigurasi Alertmanager

global:
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alerts@example.com'

route:
  group_by: ['alertname', 'job']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'slack'

receivers:
  - name: 'slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/xxx'
        channel: '#alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.summary }}{{ end }}'

  - name: 'pagerduty'
    pagerduty_configs:
      - service_key: '<integration-key>'

Routing Alert

route:
  routes:
    - match:
        severity: critical
      receiver: pagerduty
    - match:
        severity: warning
      receiver: slack

Alert Fatigue

Masalah

  • Terlalu banyak alert mengakibatkan alert diabaikan
  • Team burnout dan desensitisasi
  • Alert yang benar-benar penting terlewat

Solusi

  • Review dan kurangi alert yang tidak actionable
  • Gunakan rate limiting dan grouping
  • Set appropriate repeat interval
  • Gunakan alert aggregation

Runbook

Apa itu Runbook

  • Dokumen step-by-step untuk menangani alert
  • Dipasangkan dengan setiap alert
  • Memudahkan on-call engineer

Contoh Runbook

Alert: HighErrorRate
Severity: Critical

Tindakan:
1. Cek error rate di Grafana: [link dashboard]
2. Cek status upstream service
3. Cek database connection pool
4. Cek recent deployment
5. Jika tidak dapat di-resolve dalam 15 menit, eskalasi ke tim backend

On-Call

Rotasi

  • Jadwal bergantian antar anggota tim
  • Primary dan secondary on-call
  • Coverage 24/7 untuk service critical

Tools On-Call

  • PagerDuty
  • OpsGenie
  • VictorOps
  • Grafana OnCall

Post-Incident Review

  • Dokumentasi root cause
  • Timeline kejadian
  • Tindakan yang diambil
  • Action items untuk mencegah kejadian serupa
  • Tidak untuk menyalahkan, tapi untuk belajar

SLO-Based Alerting

Burn Rate

  • Kecepatan error budget terpakai
  • Burn rate 1x = error budget habis tepat waktu
  • Burn rate 10x = error budget habis dalam 3 hari

Multi-Window Alerting

Fast burn (high rate):
- Kondisi: Error rate > 14.4x SLO threshold
- Window: 1 jam
- Page immediately

Slow burn (moderate rate):
- Kondisi: Error rate > 2x SLO threshold  
- Window: 6 jam
- Page during business hours

Health Check Pattern

Liveness Probe

  • Container masih berjalan
  • Jika gagal, Kubernetes restart container

Readiness Probe

  • Container siap menerima traffic
  • Jika gagal, pod dikeluarkan dari load balancer

Startup Probe

  • Container baru selesai startup
  • Berguna untuk aplikasi dengan startup lambat

Best Practice Alerting

  • Gunakan SLO sebagai basis alert
  • Page hanya untuk symptom yang visible ke user
  • Alert harus actionable dengan runbook
  • Review alert secara berkala
  • Metric error budget consumption
  • Gunakan correlation untuk mengurangi noise