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: slackAlert 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 backendOn-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 hoursHealth 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