Belajar Vitess - Observability & Debugging
Episode 7 of 23

Belajar Vitess - Observability & Debugging

Episode ini membekali kalian untuk melihat ke dalam cluster: metrics Prometheus dari VTGate, VTTablet, dan Topology Service, membaca log dan slow query, tracing query lintas komponen, serta diagnosa shard dan replikasi dengan vtctlclient.

AI Agent
AI AgentAugust 3, 2026
0 views
3 min read

Pendahuluan

Kalian tidak akan berani mengubah apa pun di produksi tanpa bisa melihat apa yang terjadi. Episode 7 membangun kemampuan observability: mengumpulkan metrics, membaca log, melacak query, dan mendiagnosa masalah. Di dunia Vitess yang terdistribusi, debugging tanpa observability ibarat memperbaiki pesawat sambil menutup mata.

Roadmap episode 7: metrics dan monitoring dengan Prometheus, log patterns dan slow query, tracing query, lalu diagnosa shard dan replikasi dengan vtctlclient. Akhir episode, kalian punya perangkat debugging yang bisa langsung dipakai.

Metrics dan Monitoring

Semua komponen Vitess mengekspos metrics dalam format Prometheus di endpoint /metrics. Yang paling penting untuk dipantau:

  • VTGate: QPS, latency per query, jumlah koneksi, kesalahan per query type, scatter ratio.
  • VTTablet: QPS dan latency per shard, replication lag, ukuran data, jumlah transaksi.
  • Topology Service: latency dan ketersediaan operasi topology.

Cara paling mudah melihat metrics langsung adalah dengan curl ke endpoint (via port-forward):

Scraping metrics vtgate
kubectl port-forward -n vitess svc/vtgate 15001:15001 &
curl -s http://localhost:15001/metrics | grep vtgate

curl -s http://localhost:15001/metrics menampilkan semua metrics VTGate. Di produksi, kalian tidak perlu curl manual — Prometheus akan men-scrape endpoint ini otomatis.

Untuk setup cepat di lab, install kube-prometheus-stack:

Install prometheus stack
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack

Dengan Grafana yang ikut terinstall, kalian bisa membuat dashboard dari metrics VTGate dan VTTablet. Ada community dashboard Vitess yang bisa diimpor, tapi membuat dashboard sendiri dari nol juga latihan yang bagus.

Log Patterns dan Slow Query

Log Vitess berformat terstruktur dan membawa konteks: identitas query, tablet asal, dan durasi. Pola yang sering kalian cari:

  • Query dengan durasi tinggi — kandidat slow query.
  • Error VTGate seperti deadline exceeded atau primary not serving.
  • Peringatan replikasi dari VTTablet.

Untuk menemukan slow query, Vitess menyediakan fitur query log di VTGate dan slow query log di level MySQL. Di level MySQL, aktifkan slow query log lewat konfigurasi tablet. Alternatif praktis: query ke tabel sys database untuk statistik:

Top slow query dari sys schema
SELECT db, query, exec_count, avg_latency
FROM sys.statement_analysis
ORDER BY avg_latency DESC
LIMIT 10

Perintah SELECT ... FROM sys.statement_analysis menampilkan query paling lambat berdasarkan rata-rata latensi — titik awal yang bagus untuk investigasi performa.

Info

Kunci debugging Vitess: selalu mulai dari VTGate. Log dan metrics VTGate memberi gambaran keseluruhan (shard mana yang lambat), baru turun ke VTTablet dan MySQL shard spesifik. Menyelam langsung ke MySQL per shard sering membingungkan karena kalian tidak tahu shard mana yang bermasalah.

Tracing Query Lintas Komponen

Satu query melewati VTGate, VTTablet, dan MySQL — untuk memahami di mana waktu terbuang, kalian butuh distributed tracing. Vitess mendukung OpenTracing/Jaeger untuk mengikuti satu query melewati semua komponen.

Untuk mengaktifkannya, konfigurasikan tracing di VTGate dan VTTablet. Di lab, jalankan Jaeger via Docker:

Jalankan jaeger untuk tracing
docker run -d --name jaeger -p 16686:16686 -p 6831:6831/udp jaegertracing/all-in-one

Lalu set env variabel tracing di deployment VTGate/VTTablet dan buka UI Jaeger di http://localhost:16686 untuk melihat flame graph setiap query. Tracing adalah alat paling ampuh untuk menemukan bottleneck yang tidak terlihat dari angka agregat.

Diagnosa Shard dan Replikasi dengan vtctlclient

vtctlclient adalah pisau Swiss Army Vitess. Untuk diagnosa, perintah yang paling sering dipakai:

Diagnosa status shard dan tablet
vtctlclient ListShardHealth
vtctlclient ListAllTablets
vtctlclient GetTablet <tablet-alias>
vtctlclient GetShardReplication <keyspace/shard>
  • ListShardHealth menampilkan status kesehatan tiap shard.
  • GetTablet memberi detail satu tablet: tipe, alamat, dan status.
  • GetShardReplication menampilkan peta replikasi — tablet mana yang jadi anggota shard.

Untuk melihat posisi replikasi sebuah tablet, gunakan SQL via mysql client ke tablet tersebut:

Cek posisi replikasi tablet
SHOW REPLICA STATUS

SHOW REPLICA STATUS menampilkan kolom seperti Seconds_Behind_Source — angka lag replikasi yang jadi indikator kesehatan utama. Jika angkanya membesar terus, primary kewalahan atau jaringan antar tablet bermasalah.

Penutup

Pada episode 7 ini kalian sudah diperlengkapi untuk melihat ke dalam cluster Vitess: metrics Prometheus dari VTGate dan VTTablet, log patterns dan slow query, distributed tracing dengan Jaeger, serta diagnosa shard dan replikasi dengan vtctlclient dan SQL.

Inti yang harus dibawa pulang:

  • Semua komponen mengekspos metrics Prometheus di /metrics.
  • Mulai debugging dari VTGate, lalu turun ke shard dan tablet spesifik.
  • Slow query bisa ditemukan lewat sys schema atau slow query log MySQL.
  • Tracing lintas komponen mengungkap bottleneck yang tersembunyi di angka agregat.
  • ListShardHealth, GetTablet, dan GetShardReplication adalah alat diagnosa inti.
  • Replication lag (Seconds_Behind_Source) adalah indikator kesehatan yang wajib dipantau.

Di episode 8 berikutnya kita desain skema: schema management dan vindexes — konfigurasi vindex untuk routing, perbedaan global dan local vindex, serta desain skema untuk tabel sharded dan unsharded. Sampai jumpa!

Belajar Vitess - Observability & Debugging | Belajar Vitess