ClusterControl 1.7.0 memperkenalkan fitur baru yang berani - integrasi dengan Prometheus untuk pemantauan berbasis agen. Kami menyebutnya SCUMM (Severalnines ClusterControl Unified Management and Monitoring). Di versi sebelumnya, tugas pemantauan hanya dilakukan tanpa agen. Jika Anda bertanya-tanya bagaimana ClusterControl menjalankan fungsi pemantauannya, lihat halaman dokumentasi ini.
ProxySQL, proksi terbalik berkinerja tinggi yang memahami protokol MySQL, biasanya berada di atas Replikasi MySQL dan Galera Cluster untuk bertindak sebagai gerbang ke layanan MySQL backend. Ini dapat dikonfigurasi sebagai router kueri, firewall kueri, caching kueri, operator lalu lintas, dan banyak lagi. ProxySQL juga mengumpulkan dan memaparkan metrik kunci melalui skema STATS yang sangat berguna untuk menganalisis kinerja dan memahami apa yang sebenarnya terjadi di balik layar. Kunjungi tutorial komprehensif kami untuk ProxySQL untuk mempelajari lebih lanjut tentangnya.
Dalam posting blog ini, kita akan melihat pemantauan instance ProxySQL secara mendalam dengan pendekatan baru ini. Dalam contoh ini, kami memiliki instance ProxySQL di atas Replikasi MySQL dua simpul kami (1 master, 1 slave), yang disebarkan melalui ClusterControl. Arsitektur tingkat tinggi kami terlihat seperti ini:
Kami juga memiliki aturan kueri berikut yang ditentukan dalam instance ProxySQL (hanya untuk referensi, untuk memahami metrik pemantauan yang dikumpulkan lebih jauh):
Mengaktifkan Prometheus
Pemantauan berbasis agen ClusterControl diaktifkan per cluster. ClusterControl dapat menggunakan server Prometheus baru untuk Anda, atau menggunakan server Prometheus yang ada (digunakan oleh ClusterControl untuk cluster lain). Mengaktifkan Prometheus cukup mudah. Cukup buka ClusterControl -> pilih cluster -> Dasbor -> Aktifkan Pemantauan Berbasis Agen:
Kemudian, tentukan alamat IP atau nama host server Prometheus baru, atau pilih saja host Prometheus yang ada dari menu tarik-turun:
ClusterControl akan menginstal dan mengonfigurasi paket yang diperlukan (Prometheus di server Prometheus, eksportir di database dan node ProxySQL), terhubung ke Prometheus sebagai sumber data dan mulai memvisualisasikan data pemantauan di UI.
Setelah tugas penerapan selesai, Anda seharusnya dapat mengakses tab Dasbor seperti yang ditunjukkan di bagian berikutnya.
Dasbor ProxySQL
Anda dapat mengakses Dasbor ProxySQL dengan masuk ke masing-masing cluster di bawah tab Dasbor. Mengklik dropdown Dasbor akan mencantumkan dasbor yang terkait dengan cluster kami (Replikasi MySQL). Anda dapat menemukan dasbor Ikhtisar ProxySQL di bawah bagian "Load Balancers":
Ada sejumlah panel untuk ProxySQL, beberapa di antaranya cukup jelas. Namun demikian, mari kita kunjungi satu per satu.
Ukuran Grup Host
Ukuran grup host hanyalah jumlah total host di semua grup host:
Dalam hal ini, kami memiliki dua grup host - 10 (penulis) dan 20 (pembaca). Hostgroup 10 terdiri dari satu host (master) sedangkan hostgroup 20 memiliki dua host (master dan slave), yang berjumlah total tiga host.
Kecuali jika Anda mengubah konfigurasi hostgroup (memperkenalkan host baru, menghapus host yang ada) dari ProxySQL, Anda seharusnya berharap tidak ada yang berubah dalam grafik ini.
Koneksi Klien
Jumlah koneksi klien yang diproses oleh ProxySQL untuk semua grup host:
Grafik di atas hanya memberi tahu kita bahwa secara konsisten ada 8 klien MySQL yang terhubung ke instans ProxySQL kita pada port 6033 selama 45 menit terakhir (Anda dapat mengubahnya di bawah opsi "Range Selection"). Jika Anda berhenti menghubungkan aplikasi Anda ke ProxySQL (atau mengabaikannya), nilainya akan turun menjadi 0.
Pertanyaan Klien
Grafik memvisualisasikan jumlah Pertanyaan yang diproses oleh ProxySQL untuk semua hostgroup:
Menurut dokumentasi MySQL, Pertanyaan hanyalah jumlah pernyataan yang dieksekusi oleh server. Ini hanya mencakup pernyataan yang dikirim ke server oleh klien dan bukan pernyataan yang dieksekusi dalam program yang disimpan, tidak seperti variabel Kueri. Variabel ini tidak menghitung perintah COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE, atau COM_STMT_RESET. Sekali lagi, jika Anda berhenti menghubungkan aplikasi Anda ke ProxySQL (atau mengabaikannya), nilainya akan turun menjadi 0.
Koneksi Backend Aktif
Jumlah koneksi yang dikelola ProxySQL ke server MySQL backend per host:
Ini hanya memberi tahu kita berapa banyak koneksi yang saat ini digunakan oleh ProxySQL untuk mengirim kueri ke server backend. Selama nilai maks tidak mendekati batas koneksi untuk server tertentu (ditetapkan melalui max_connections ketika server ditambahkan ke grup host ProxySQL), kami berada dalam kondisi yang baik.
Koneksi Backend Gagal
Jumlah koneksi yang tidak berhasil dibuat oleh ProxySQL:
Contoh di atas hanya menunjukkan bahwa tidak ada kegagalan koneksi backend yang terjadi dalam 45 menit terakhir.
Kueri Dirutekan
Grafik ini memberikan wawasan tentang distribusi pernyataan masuk ke server backend:
Seperti yang Anda lihat, sebagian besar pembacaan masuk ke grup host pembaca (HG20). Dari sini kita dapat memahami pola penyeimbangan yang dilakukan oleh ProxySQL yang cocok dengan aturan kueri kita dalam beban kerja intensif baca ini.
Koneksi Gratis
Grafik menunjukkan berapa banyak koneksi yang saat ini gratis:
Koneksi tetap terbuka untuk meminimalkan biaya waktu pengiriman kueri ke server backend.
Latensi
Waktu ping saat ini dalam mikrodetik, seperti yang dilaporkan dari utas pemantauan ProxySQL:
Ini hanya memberi tahu kita seberapa stabil koneksi dari ProxySQL ke server MySQL backend. Nilai tinggi untuk waktu yang konsisten lama sebagian besar menunjukkan masalah jaringan di antara mereka.
Memori Cache Kueri
Grafik ini memvisualisasikan konsumsi memori kueri yang sedang di-cache oleh ProxySQL:
Dari grafik di atas, kita dapat mengetahui bahwa ProxySQL menghabiskan total memori sebesar 8MB oleh cache kueri. Setelah mencapai batas 8MB (dapat dikonfigurasi melalui mysql-query_cache_size_MB variabel), memori akan dibersihkan oleh utas pembersihan ProxySQL. Grafik ini tidak akan diisi jika Anda tidak menetapkan aturan cache kueri.
Omong-omong, caching kueri di ProxySQL dapat dilakukan hanya dalam dua klik dengan ClusterControl. Buka halaman Kueri Teratas ProxySQL, putar kueri, klik Cache Kueri dan klik "Tambah Aturan":
Efisiensi Tembolok Kueri
Grafik ini memvisualisasikan efisiensi kueri yang di-cache:
Garis biru memberi tahu kita rasio sukses permintaan GET yang dieksekusi terhadap Cache Kueri di mana resultet ada dan tidak kedaluwarsa. Garis merah muda menunjukkan rasio data yang ditulis (dimasukkan) ke dalam atau dibaca dari Query Cache. Dalam hal ini, data yang kami baca dari Query Cache lebih tinggi dari data tertulis yang menunjukkan konfigurasi cache yang efisien.
Grafik ini tidak akan diisi jika Anda tidak menetapkan aturan cache kueri.
Lalu Lintas Jaringan
Grafik ini memvisualisasikan lalu lintas jaringan (data diterima + data terkirim) dari/ke server MySQL backend, per host:
Tangkapan layar di atas memberi tahu kita bahwa sejumlah besar lalu lintas sedang diteruskan/diterima dari/ke grup host pembaca (HG20). Dalam beban kerja intensif baca ini, operasi baca biasanya menghabiskan lalu lintas yang jauh lebih tinggi terutama karena ukuran set hasil dari pernyataan SELECT.
Hanya rasio lalu lintas yang lebih kecil yang diteruskan/diterima dari/ke grup host tulis (HG10), yang diharapkan karena operasi tulis biasanya menggunakan lebih sedikit lalu lintas jaringan dengan kumpulan hasil yang secara signifikan kecil dikembalikan ke klien.
Efisiensi Pencerminan
Grafik hanya menunjukkan status terkait mirroring lalu lintas seperti Mirror_concurrency vs Mirror_queue_length:
Grafik hanya diisi jika Anda telah mengonfigurasi pencerminan lalu lintas (mirror_hostgroup di dalam aturan kueri). Jika antrian mirror meningkat, mengurangi batas konkurensi mirroring akan meningkatkan efisiensi mirroring, yang dapat dikontrol melalui mysql-mirror_max_concurrency variabel. Dengan kata sederhana, entri antrean nol adalah cerminan paling efisien.
Penggunaan Memori
Grafik menggambarkan penggunaan memori oleh komponen utama di dalam ProxySQL - kumpulan koneksi, cache kueri, dan penyimpanan persisten (SQLite):
Tangkapan layar di atas memberi tahu kita bahwa jejak memori ProxySQL agak kecil yang totalnya kurang dari 12 MB. Kumpulan koneksi hanya menggunakan 1,3 MB untuk mengakomodasi beban kerja 8-utas (klien) kami. Dengan lebih banyak RAM gratis yang tersedia di host, kami seharusnya dapat meningkatkan jumlah koneksi klien ke ProxySQL tiga kali lipat menjadi empat kali lipat atau menyimpan lebih banyak kueri panas di dalam ProxySQL untuk membongkar server backend MySQL kami.
Fitur Bonus - Performa Node
ClusterControl 1.7.0 sekarang menyertakan metrik kinerja host untuk instans ProxySQL. Di versi sebelumnya, ClusterControl hanya memantau metrik terkait ProxySQL seperti yang diekspos oleh skema statistik ProxySQL. Fitur baru ini dapat diakses di bawah tab Node -> Instance ProxySQL -> Kinerja Node:
Histogram memberikan wawasan tentang metrik host utama, mirip dengan apa yang diambil sampelnya untuk node database di bawah Nodes -> bagian Ikhtisar. Jika instance ProxySQL Anda ditempatkan bersama di server yang sama dengan aplikasi, Anda benar-benar menggunakan ClusterControl untuk memantau server aplikasi juga. Keren banget kan?!
Pemikiran Akhir
Integrasi ClusterControl dengan Prometheus menawarkan cara alternatif untuk memantau dan menganalisis tumpukan database Anda, hingga tingkat reverse-proxy. Anda sekarang memiliki pilihan untuk memindahkan tugas pemantauan ke Prometheus, atau tetap menggunakan pendekatan pemantauan tanpa agen ClusterControl default untuk infrastruktur database Anda.
