Belajar Vitess - Observability at Scale & SLOs

#Pendahuluan

Di episode 7 kalian belajar melihat cluster; episode 21 menaikkannya ke level janji: berapa cepat, berapa andal, dan berapa kapasitas layanan kalian — secara terukur. SLO (Service Level Objectives) mengubah observability dari "kita pantau" menjadi "kita berkomitmen dan mengukur". Tanpa SLO, diskusi soal performa selalu subjektif.

Roadmap episode 21: mendefinisikan SLO, memantau kesehatan shard, query metrics, lalu membangun alerting yang efektif dan tidak membisingkan.

#Mendefinisikan SLO

SLO adalah target terukur untuk kesehatan layanan. Tiga dimensi yang paling relevan untuk Vitess:

Latency: persentil ke-99 (P99) query dalam milidetik. Contoh: "95% query selesai di bawah 50ms".
Availability: persentase waktu layanan tersedia. Contoh: "99.95% ketersediaan bulanan".
Throughput: jumlah query per detik yang bisa dilayani. Contoh: "mendukung 50.000 QPS puncak".

Contoh definisi SLO

latency_slo:
  target_ms: 50
  threshold_percentile: 95
availability_slo:
  target_percent: 99.95
throughput_slo:
  qps: 50000
replication_lag_slo:
  max_seconds: 30

latency_slo.target_ms: 50 berarti target: 95% query selesai dalam 50ms. SLO harus realistis dan disepakati dengan pemangku kepentingan bisnis — bukan angka yang diharapkan engineer saja.

Info

Mulai dari tiga SLO sederhana: P95 latency, availability, dan replication lag. Tambahkan SLO baru hanya saat kalian benar-benar bisa mengukurnya dengan baik. SLO yang tidak terukur hanyalah tulisan.

#Monitoring Shard Health

Di skala besar, perhatian operator berpindah dari per-tablet ke per-shard. Setiap shard punya kesehatan yang harus dipantau: status primary, lag replikasi, QPS, dan kesalahan query.

Health semua shard

vtctlclient ListShardHealth

vtctlclient ListShardHealth menampilkan status tiap shard. Untuk dashboard otomatis, parse output JSON dan kirim ke Prometheus. Shard yang tidak sehat harus terlihat jelas — karena satu shard bermasalah bisa menguras traffic seluruh keyspace.

Metrik shard yang dipantau rutin:

Seconds_Behind_Source — replication lag (dari SHOW REPLICA STATUS).
QPS dan latency per shard.
Ukuran data dan pertumbuhan storage.
Jumlah kesalahan query per tipe.

#Query Metrics dan Bottleneck

Query metrics mengungkap pola: query mana yang lambat, shard mana yang paling sibuk, dan jenis query mana yang dominan. Di VTGate, metrik query dikelompokkan per keyspace, shard, dan tabel. Kunci untuk menemukan bottleneck:

Latency P99 per query type: menemukan query yang paling sering lambat.
Scatter ratio: proporsi query yang menyentuh banyak shard — sinyal desain skema buruk.
Error rate per shard: menemukan shard dengan masalah.
Connection wait time: indikator pool yang kehabisan koneksi.

Metrik query vtgate teratas

curl -s http://localhost:15001/metrics | grep -E 'vtgate_query_(duration|error|rows)' | head

curl -s ... vtgate_query menampilkan metrik query VTGate — dasar untuk membangun dashboard latency dan error rate.

#Alerting yang Efektif

Alerting adalah jembatan dari metrik ke tindakan. Aturan utamanya: alert harus actionable dan tidak bising. Alert yang terlalu banyak membuat operator mengabaikannya. Beberapa alert yang penting untuk Vitess:

Primary tidak serving — tulis berhenti, tindakan segera.
Replication lag melampaui SLO — data baca mulai basi, atau tanda primary kewalahan.
Error rate query di atas ambang — aplikasi sedang gagal.
Latency P99 melampaui SLO — layanan melambat dari janji.
Backup gagal — jaring pengaman data berlubang.

Contoh alert Prometheus untuk replication lag:

Alert replication lag

groups:
  - name: vitess
    rules:
      - alert: HighReplicationLag
        expr: mysql_replication_seconds_behind_source > 30
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Replication lag melebihi 30 detik"

Rule mysql_replication_seconds_behind_source > 30 memicu alert jika lag melebihi 30 detik selama 5 menit berturut-turut — filter for: 5m mencegah alert dari lonjakan sementara yang tidak berbahaya.

Warning

Setiap alert baru harus menjawab tiga pertanyaan: apa yang harus dilakukan orang yang menerimanya, seberapa cepat, dan apakah alert itu pernah menghasilkan tindakan nyata. Alert yang tidak pernah dipakai adalah noise yang mengubur alert yang penting.

#Penutup

Pada episode 21 ini kalian sudah membawa observability ke level janji: mendefinisikan SLO untuk latency, availability, dan throughput, memantau kesehatan per shard, menggali query metrics untuk menemukan bottleneck, dan membangun alerting yang efektif dan tidak membisingkan.

Inti yang harus dibawa pulang:

SLO harus terukur, realistis, dan disepakati dengan bisnis.
Mulai dari tiga SLO sederhana: P95 latency, availability, dan replication lag.
Pantau kesehatan per shard, bukan hanya per tablet.
Scatter ratio adalah sinyal desain skema yang perlu perhatian.
Alert harus actionable dan filter for mencegah noise.
SLO dan alerting yang baik adalah dasar percaya diri mengubah produksi.

Di episode 22 (terakhir) kita rangkum semua: production hardening dan best practices — checklist keamanan, scaling, dan failover readiness, dokumentasi runbook, serta upgrade Vitess dan MySQL yang aman. Sampai jumpa!