Belajar HAProxy - SLOs, SLIs & Operational Metrics

#Pendahuluan

Metrik tanpa target hanyalah angka. Episode 21 memberi angka-angka itu makna melalui SLO (Service Level Objectives) dan SLI (Service Level Indicators), lalu menghubungkannya ke alerting dan runbook.

Kalian akan mendefinisikan SLI untuk trafik HAProxy, menyusun aturan alert untuk error rate, latensi, dan saturasi, serta menulis runbook yang membuat insiden trafik bisa ditangani dengan tenang.

#Mendefinisikan SLI dan SLO

#Memilih SLI yang Tepat

SLI adalah pengukuran kualitas yang dipilih. Untuk trafik HTTP melalui HAProxy, SLI yang paling umum:

• Availability: persentase request yang berhasil (status bukan 5xx).
• Latency: persentase request yang selesai dalam batas waktu tertentu.
• Throughput: request per detik yang dilayani.

Rumus availability dalam PromQL:

1 - (
  sum(rate(haproxy_frontend_http_responses_total{code=~"5.."}[5m]))
  /
  sum(rate(haproxy_frontend_http_requests_total[5m]))
)

Rumus di atas menghitung proporsi respons 5xx terhadap total request dalam 5 menit. Kode code=~"5.." memakai label matcher untuk mengambil semua respons 5xx.

#Menetapkan SLO

SLO menetapkan target pada SLI:

• Availability SLO: 99.9 persen request sukses per bulan.
• Latency SLO: 95 persen request selesai di bawah 200 milidetik.
• Error budget: sisa kegagalan yang diperbolehkan, misalnya 0.1 persen.

Prinsipnya: SLO harus realistis dan disepakati bersama tim serta pemilik layanan. Jangan menetapkan target yang membuat tim malu untuk mengakuinya.

#Mengukur dengan Dashboard

Visualkan SLO dengan panel Grafana: bagan waktu untuk error rate dan garis target SLO. Ketika kurva mendekati garis, kalian sedang menghabiskan error budget.

#Alerting Berbasis Metrik Operasional

#Alert untuk Error Rate

Alert harus membangunkan manusia hanya saat benar-benar perlu:

groups:
  - name: haproxy.rules
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(haproxy_frontend_http_responses_total{code=~"5.."}[5m]))
          / sum(rate(haproxy_frontend_http_requests_total[5m])) > 0.05
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "Error rate melebihi 5 persen selama 10 menit"

for: 10m memastikan alert hanya menyala jika kondisi bertahan 10 menit, menghindari alarm palsu dari lonjakan sesaat. Severity critical menandakan tindakan segera.

#Alert untuk Latensi dan Saturasi

Dua kategori berikutnya:

groups:
  - name: haproxy.latency
    rules:
      - alert: HighLatency
        expr: |
          histogram_quantile(0.95,
            rate(haproxy_frontend_http_request_duration_seconds_bucket[5m])) > 0.5
        for: 15m
        labels:
          severity: warning
 
      - alert: ConnSaturation
        expr: haproxy_frontend_current_sessions / haproxy_frontend_max_sessions > 0.9
        for: 10m
        labels:
          severity: warning

histogram_quantile(0.95, ...) > 0.5 memicu alert jika 95 persen request lebih lambat dari setengah detik. ConnSaturation menyala ketika penggunaan koneksi mendekati batas maxconn.

#Membedakan Paging dan Issue

Tidak semua peringatan harus membangunkan:

• Page: error rate 5xx dan saturasi koneksi — manusia segera.
• Issue: latensi meningkat tanpa error — tiket, bukan panggilan.
• Info: metrik menjauh dari baseline — dashboard, bukan alert.

Pembagian ini menjaga tim tetap responsif tanpa kelelahan alert.

#Runbook untuk Insiden Trafik

#Runbook Failover Node

Runbook adalah langkah berurutan yang sudah teruji. Contoh untuk node HAProxy mati:

1. Konfirmasi node mati: cek journalctl -u haproxy dan systemctl status haproxy.
2. Verifikasi VIP pindah ke node pasif: ip addr show.
3. Uji layanan lewat VIP dengan curl.
4. Mulai perbaikan node aktif, kembali join, dan amati VIP.

systemctl status haproxy --no-pager
ip addr show eth0 | grep 10.0.0.10
curl -s -o /dev/null -w "%{http_code}\n" http://10.0.0.10/

systemctl status haproxy --no-pager memastikan kondisi proses sebelum bertindak, dan curl ... http://10.0.0.10/ mengonfirmasi layanan masih hidup lewat VIP.

#Runbook Trafik Tinggi

Saat error rate melonjak karena trafik:

1. Identifikasi arah: semua backend atau satu backend? Lihat dashboard per server.
2. Cek kapasitas: koneksi vs maxconn, CPU backend.
3. Tindakan darurat: naikkan server backend, atau tambah node HAProxy.
4. Jika perlu, aktifkan rate limiting lebih ketat di episode 10 untuk meredam beban.
5. Dokumentasikan semua langkah setelah insiden.

#Runbook DNS dan Service Discovery

Ketika backend menghilang karena service discovery:

1. Cek resolusi nama: dig users-svc.internal.
2. Cek status server di HAProxy: show servers state.
3. Pastikan resolvers dan hold valid sesuai.
4. Jika resolusi macet, periksa server DNS dan kebijakan cache.

#Menjaga Runbook Tetap Hidup

Runbook yang tidak diuji adalah omong kosong. Praktik yang menjaga runbook tetap relevan:

• Uji setiap runbook secara berkala lewat game day.
• Perbarui runbook saat konfigurasi berubah.
• Simpan runbook dekat dengan tim: wiki, repo, atau sistem incident.

curl -s -o /dev/null -w "%{http_code}\n" http://localhost/ 

curl -s -o /dev/null -w "%{http_code}\n" adalah cara tercepat memverifikasi kesehatan saat melakukan drill atau insiden nyata.

#Penutup

Episode 21 mengubah metrik menjadi janji yang terukur: SLI yang dipilih dengan sadar, SLO yang disepakati, alerting yang disaring agar tidak bising, dan runbook yang membuat insiden menjadi rutinitas yang bisa dieksekusi.

Inti yang harus dibawa pulang:

• SLI mengukur; SLO menargetkan; error budget mencatat sisa kegagalan.
• Alert error rate butuh for untuk menghindari alarm palsu.
• Latensi dan saturasi adalah SLI yang melengkapi availability.
• Page untuk darurat; issue untuk tiket; info untuk dashboard.
• Runbook wajib diuji berkala agar tetap valid.

Di episode 22 selanjutnya, episode terakhir, kita akan membahas production hardening & best practices — checklist produksi untuk keamanan, ketersediaan, observability, dan kesiapan operasional, strategi disaster recovery dan backup konfigurasi, serta cara mendokumentasikan konvensi dan batas dukungan.