Sudah hampir dua bulan sejak kami merilis SCUMM (Severalnines ClusterControl Unified Management and Monitoring). SCUMM menggunakan Prometheus sebagai metode dasar untuk mengumpulkan data deret waktu dari eksportir yang berjalan pada instans database dan penyeimbang beban. Blog ini akan menunjukkan kepada Anda cara memperbaiki masalah saat eksportir Prometheus tidak berjalan, atau jika grafik tidak menampilkan data, atau menampilkan “Tidak Ada Poin Data”.
Apa itu Prometheus?
Prometheus adalah sistem pemantauan sumber terbuka dengan model data dimensi, bahasa kueri yang fleksibel, basis data deret waktu yang efisien, dan pendekatan peringatan modern. Ini adalah platform pemantauan yang mengumpulkan metrik dari target yang dipantau dengan menggores titik akhir HTTP metrik pada target ini. Ini menyediakan data dimensional, kueri yang kuat, visualisasi yang hebat, penyimpanan yang efisien, pengoperasian yang sederhana, peringatan yang tepat, banyak pustaka klien, dan banyak integrasi.
Prometheus beraksi untuk Dasbor SCUMM
Prometheus mengumpulkan data metrik dari eksportir, dengan masing-masing eksportir berjalan di database atau host penyeimbang beban. Diagram di bawah ini menunjukkan kepada Anda bagaimana eksportir ini terhubung dengan server yang menghosting proses Prometheus. Ini menunjukkan bahwa node ClusterControl menjalankan Prometheus di mana ia juga menjalankan process_exporter dan node_exporter.
Diagram menunjukkan bahwa Prometheus berjalan di host ClusterControl dan eksportir process_exporter dan node_exporter berjalan juga untuk mengumpulkan metrik dari simpulnya sendiri. Opsional, Anda dapat menjadikan host ClusterControl Anda sebagai target juga di mana Anda dapat mengatur HAProxy atau ProxySQL.
Untuk node cluster di atas (node1, node2, dan node3), ia dapat menjalankan mysqld_exporter atau postgres_exporter yang merupakan agen yang mengikis data secara internal di node itu dan meneruskannya ke server Prometheus dan menyimpannya di penyimpanan datanya sendiri. Anda dapat menemukan data fisiknya melalui /var/lib/prometheus/data di dalam host tempat Prometheus disiapkan.
Saat Anda mengatur Prometheus, misalnya, di host ClusterControl, port berikut harus dibuka. Lihat di bawah:
[[email protected] share]# netstat -tnvlp46|egrep 'ex[p]|prometheu[s]'
tcp6 0 0 :::9100 :::* LISTEN 16189/node_exporter
tcp6 0 0 :::9011 :::* LISTEN 19318/process_expor
tcp6 0 0 :::42004 :::* LISTEN 16080/proxysql_expo
tcp6 0 0 :::9090 :::* LISTEN 31856/prometheusBerdasarkan output, saya juga menjalankan ProxySQL di host testccnode tempat ClusterControl di-host.
Masalah Umum dengan Dasbor SCUMM menggunakan Prometheus
Ketika Dasbor diaktifkan, ClusterControl akan menginstal dan menyebarkan binari dan eksportir seperti node_exporter, process_exporter, mysqld_exporter, postgres_exporter, dan daemon. Ini adalah kumpulan paket umum ke node database. Ketika ini diatur dan diinstal, perintah daemon berikut dijalankan dan dijalankan seperti yang terlihat di bawah ini:
[[email protected] bin]# ps axufww|egrep 'exporte[r]'
prometh+ 3604 0.0 0.0 10828 364 ? S Nov28 0:00 daemon --name=process_exporter --output=/var/log/prometheus/process_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/process_exporter.pid --user=prometheus -- process_exporter
prometh+ 3605 0.2 0.3 256300 14924 ? Sl Nov28 4:06 \_ process_exporter
prometh+ 3838 0.0 0.0 10828 564 ? S Nov28 0:00 daemon --name=node_exporter --output=/var/log/prometheus/node_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/node_exporter.pid --user=prometheus -- node_exporter
prometh+ 3839 0.0 0.4 44636 15568 ? Sl Nov28 1:08 \_ node_exporter
prometh+ 4038 0.0 0.0 10828 568 ? S Nov28 0:00 daemon --name=mysqld_exporter --output=/var/log/prometheus/mysqld_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/mysqld_exporter.pid --user=prometheus -- mysqld_exporter --collect.perf_schema.eventswaits --collect.perf_schema.file_events --collect.perf_schema.file_instances --collect.perf_schema.indexiowaits --collect.perf_schema.tableiowaits --collect.perf_schema.tablelocks --collect.info_schema.tablestats --collect.info_schema.processlist --collect.binlog_size --collect.global_status --collect.global_variables --collect.info_schema.innodb_metrics --collect.slave_status
prometh+ 4039 0.1 0.2 17368 11544 ? Sl Nov28 1:47 \_ mysqld_exporter --collect.perf_schema.eventswaits --collect.perf_schema.file_events --collect.perf_schema.file_instances --collect.perf_schema.indexiowaits --collect.perf_schema.tableiowaits --collect.perf_schema.tablelocks --collect.info_schema.tablestats --collect.info_schema.processlist --collect.binlog_size --collect.global_status --collect.global_variables --collect.info_schema.innodb_metrics --collect.slave_statusUntuk simpul PostgreSQL,
[[email protected] vagrant]# ps axufww|egrep 'ex[p]'
postgres 1901 0.0 0.4 1169024 8904 ? Ss 18:00 0:04 \_ postgres: postgres_exporter postgres ::1(51118) idle
prometh+ 1516 0.0 0.0 10828 360 ? S 18:00 0:00 daemon --name=process_exporter --output=/var/log/prometheus/process_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/process_exporter.pid --user=prometheus -- process_exporter
prometh+ 1517 0.2 0.7 117032 14636 ? Sl 18:00 0:35 \_ process_exporter
prometh+ 1700 0.0 0.0 10828 572 ? S 18:00 0:00 daemon --name=node_exporter --output=/var/log/prometheus/node_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/node_exporter.pid --user=prometheus -- node_exporter
prometh+ 1701 0.0 0.7 44380 14932 ? Sl 18:00 0:10 \_ node_exporter
prometh+ 1897 0.0 0.0 10828 568 ? S 18:00 0:00 daemon --name=postgres_exporter --output=/var/log/prometheus/postgres_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --env=DATA_SOURCE_NAME=postgresql://postgres_exporter:[email protected]:5432/postgres?sslmode=disable --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/postgres_exporter.pid --user=prometheus -- postgres_exporter
prometh+ 1898 0.0 0.5 16548 11204 ? Sl 18:00 0:06 \_ postgres_exporterIni memiliki eksportir yang sama seperti untuk node MySQL, tetapi hanya berbeda pada postgres_exporter karena ini adalah node database PostgreSQL.
Namun, ketika sebuah node mengalami gangguan daya, sistem crash, atau sistem reboot, eksportir ini akan berhenti berjalan. Prometheus akan melaporkan bahwa eksportir sedang down. ClusterControl mengambil sampel Prometheus itu sendiri, dan menanyakan status eksportir. Jadi ia bertindak berdasarkan informasi ini, dan akan memulai kembali eksportir jika tidak aktif.
Namun, perhatikan bahwa untuk eksportir yang belum diinstal melalui ClusterControl, mereka tidak akan direstart setelah crash. Alasannya adalah bahwa mereka tidak dipantau oleh systemd atau daemon yang bertindak sebagai skrip keamanan yang akan memulai ulang proses saat crash atau shutdown yang tidak normal. Oleh karena itu, tangkapan layar di bawah ini akan menunjukkan bagaimana tampilannya saat eksportir tidak berjalan. Lihat di bawah:
dan di Dasbor PostgreSQL, akan memiliki ikon pemuatan yang sama dengan label "Tidak ada titik data" di grafik. Lihat di bawah:
Oleh karena itu, masalah ini dapat dipecahkan melalui berbagai teknik yang akan mengikuti di bagian berikut.
Memecahkan Masalah Dengan Prometheus
Agen Prometheus, yang dikenal sebagai eksportir, menggunakan port berikut:9100 (node_exporter), 9011 (process_exporter), 9187 (postgres_exporter), 9104 (mysqld_exporter), 42004 (proxysql_exporter), dan 9090 milik sendiri yang dimiliki oleh prometheus proses. Ini adalah port untuk agen ini yang digunakan oleh ClusterControl.
Untuk mulai memecahkan masalah Dasbor SCUMM, Anda dapat mulai dengan memeriksa port yang terbuka dari node database. Anda dapat mengikuti daftar di bawah ini:
-
Periksa apakah port terbuka
misalnya
## Use netstat and check the ports [[email protected] vagrant]# netstat -tnvlp46|egrep 'ex[p]' tcp6 0 0 :::9100 :::* LISTEN 5036/node_exporter tcp6 0 0 :::9011 :::* LISTEN 4852/process_export tcp6 0 0 :::9187 :::* LISTEN 5230/postgres_exporAda kemungkinan port tidak terbuka karena firewall (seperti iptables atau firewalld) memblokirnya untuk membuka port atau daemon proses itu sendiri tidak berjalan.
-
Gunakan curl dari monitor host dan verifikasi apakah port dapat dijangkau dan terbuka.
misalnya
## Using curl and grep mysql list of available metric names used in PromQL. [[email protected] prometheus]# curl -sv mariadb_g01:9104/metrics|grep 'mysql'|head -25 * About to connect() to mariadb_g01 port 9104 (#0) * Trying 192.168.10.10... * Connected to mariadb_g01 (192.168.10.10) port 9104 (#0) > GET /metrics HTTP/1.1 > User-Agent: curl/7.29.0 > Host: mariadb_g01:9104 > Accept: */* > < HTTP/1.1 200 OK < Content-Length: 213633 < Content-Type: text/plain; version=0.0.4; charset=utf-8 < Date: Sat, 01 Dec 2018 04:23:21 GMT < { [data not shown] # HELP mysql_binlog_file_number The last binlog file number. # TYPE mysql_binlog_file_number gauge mysql_binlog_file_number 114 # HELP mysql_binlog_files Number of registered binlog files. # TYPE mysql_binlog_files gauge mysql_binlog_files 26 # HELP mysql_binlog_size_bytes Combined size of all registered binlog files. # TYPE mysql_binlog_size_bytes gauge mysql_binlog_size_bytes 8.233181e+06 # HELP mysql_exporter_collector_duration_seconds Collector time duration. # TYPE mysql_exporter_collector_duration_seconds gauge mysql_exporter_collector_duration_seconds{collector="collect.binlog_size"} 0.008825006 mysql_exporter_collector_duration_seconds{collector="collect.global_status"} 0.006489491 mysql_exporter_collector_duration_seconds{collector="collect.global_variables"} 0.00324821 mysql_exporter_collector_duration_seconds{collector="collect.info_schema.innodb_metrics"} 0.008209824 mysql_exporter_collector_duration_seconds{collector="collect.info_schema.processlist"} 0.007524068 mysql_exporter_collector_duration_seconds{collector="collect.info_schema.tables"} 0.010236411 mysql_exporter_collector_duration_seconds{collector="collect.info_schema.tablestats"} 0.000610684 mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.eventswaits"} 0.009132491 mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.file_events"} 0.009235416 mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.file_instances"} 0.009451361 mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.indexiowaits"} 0.009568397 mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.tableiowaits"} 0.008418406 mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.tablelocks"} 0.008656682 mysql_exporter_collector_duration_seconds{collector="collect.slave_status"} 0.009924652 * Failed writing body (96 != 14480) * Closing connection 0Idealnya, saya secara praktis menemukan pendekatan ini layak untuk saya karena saya dapat mengambil dan men-debug dari terminal dengan mudah.
-
Mengapa tidak menggunakan UI Web?
-
Prometheus mengekspos port 9090 yang digunakan oleh ClusterControl di Dasbor SCUMM kami. Selain itu, port yang diekspos oleh eksportir juga dapat digunakan untuk memecahkan masalah dan menentukan nama metrik yang tersedia menggunakan PromQL. Di server tempat Prometheus berjalan, Anda dapat mengunjungi http://
:9090/targets . Tangkapan layar di bawah menunjukkan aksinya:
dan mengeklik “Titik akhir”, Anda dapat memverifikasi metrik serta seperti tangkapan layar di bawah:
Alih-alih menggunakan alamat IP, Anda juga dapat memeriksa ini secara lokal melalui localhost pada node tertentu seperti mengunjungi http://localhost:9104/metrics baik di antarmuka UI Web atau menggunakan cURL.
Sekarang, jika kita kembali ke “Target ”, Anda dapat melihat daftar node di mana ada masalah dengan port. Alasan yang dapat menyebabkan hal ini tercantum di bawah ini:
- Server mati
- Jaringan tidak dapat dijangkau atau port tidak dibuka karena firewall berjalan
- Daemon tidak berjalan di tempat
_exporter tidak berjalan. Misalnya, mysqld_exporter tidak berjalan.
-
Saat eksportir ini berjalan, Anda dapat menjalankan dan menjalankan prosesnya menggunakan daemon memerintah. Anda dapat merujuk ke proses berjalan yang tersedia yang telah saya gunakan dalam contoh di atas, atau disebutkan di bagian sebelumnya dari blog ini.
Bagaimana Dengan Grafik “Tidak Ada Poin Data” Di Dasbor Saya?
Dasbor SCUMM hadir dengan skenario kasus penggunaan umum yang biasa digunakan oleh MySQL. Namun, ada beberapa variabel saat menjalankan metrik tersebut mungkin tidak tersedia di versi MySQL tertentu atau vendor MySQL, seperti MariaDB atau Server Percona.
Mari saya tunjukkan contoh di bawah ini:
Grafik ini diambil pada server database yang berjalan pada Server MariaDB versi 10.3.9-MariaDB-log dengan wsrep_patch_version dari instance wsrep_25.23. Sekarang pertanyaannya adalah, mengapa tidak ada titik data yang dimuat? Nah, saat saya menanyakan node untuk status usia pos pemeriksaan, itu mengungkapkan bahwa itu kosong atau tidak ada variabel yang ditemukan. Lihat di bawah:
MariaDB [(none)]> show global status like 'Innodb_checkpoint_max_age';
Empty set (0.000 sec)Saya tidak tahu mengapa MariaDB tidak memiliki variabel ini (beri tahu kami di bagian komentar blog ini jika Anda memiliki jawabannya). Ini berbeda dengan Server Cluster Percona XtraDB di mana variabel Innodb_checkpoint_max_age memang ada. Lihat di bawah:
mysql> show global status like 'Innodb_checkpoint_max_age';
+---------------------------+-----------+
| Variable_name | Value |
+---------------------------+-----------+
| Innodb_checkpoint_max_age | 865244898 |
+---------------------------+-----------+
1 row in set (0.00 sec)Apa artinya ini adalah bahwa, mungkin ada grafik yang tidak memiliki titik data yang dikumpulkan karena tidak ada data yang diambil pada metrik tertentu saat kueri Prometheus dijalankan.
Namun, grafik yang tidak memiliki titik data tidak berarti bahwa versi MySQL Anda saat ini atau variannya tidak mendukungnya. Misalnya, ada grafik tertentu yang memerlukan variabel tertentu yang perlu diatur atau diaktifkan dengan benar.
Bagian berikut akan menunjukkan apa itu grafik.
Grafik Penurunan Kondisi Indeks (ICP)
Grafik ini telah disebutkan di blog saya sebelumnya. Itu bergantung pada variabel global MySQL bernama innodb_monitor_enable. Variabel ini dinamis sehingga Anda dapat mengatur ini tanpa hard restart database MySQL Anda. Itu juga membutuhkan innodb_monitor_enable =module_icp atau Anda dapat mengatur variabel global ini ke innodb_monitor_enable =all. Biasanya, untuk menghindari kasus seperti itu dan kebingungan tentang mengapa grafik tersebut tidak menunjukkan titik data apa pun, Anda mungkin harus menggunakan semua kecuali dengan hati-hati. Mungkin ada overhead tertentu saat variabel ini diaktifkan dan disetel ke semua.
Grafik Skema Kinerja MySQL
Jadi mengapa grafik ini menunjukkan "Tidak ada titik data"? Ketika Anda membuat sebuah cluster menggunakan ClusterControl menggunakan template kami, secara default akan mendefinisikan variabel performance_schema. Misalnya, variabel di bawah ini ditetapkan:
performance_schema = ON
performance-schema-max-mutex-classes = 0
performance-schema-max-mutex-instances = 0Namun, jika performance_schema =OFF, maka itulah alasan mengapa grafik terkait akan menampilkan “Tidak ada titik data”.
Tetapi saya telah mengaktifkan performance_schema, mengapa grafik lain masih menjadi masalah?
Nah, masih ada grafik yang membutuhkan banyak variabel yang perlu diatur. Ini sudah dibahas di blog kami sebelumnya. Jadi, Anda perlu mengatur innodb_monitor_enable =all dan userstat=1. Hasilnya akan terlihat seperti ini:
Namun, saya perhatikan bahwa dalam versi MariaDB 10.3 (khususnya 10.3.11), pengaturan performance_schema=ON akan mengisi metrik yang diperlukan untuk Dashboard Skema Kinerja MySQL. Ini adalah keuntungan besar karena tidak harus menyetel innodb_monitor_enable=ON yang akan menambah overhead tambahan pada server database.
Pemecahan Masalah Lanjutan
Apakah ada pemecahan masalah lanjutan yang dapat saya rekomendasikan? Ya ada! Namun, Anda memerlukan beberapa keterampilan JavaScript, setidaknya. Karena Dasbor SCUMM menggunakan Prometheus bergantung pada grafik tinggi, cara metrik yang digunakan untuk permintaan PromQL dapat ditentukan melalui skrip app.js yang ditunjukkan di bawah ini:
Jadi dalam hal ini, saya menggunakan DevTools Google Chrome dan mencoba mencari Performance Schema Waits (Events) . Bagaimana ini bisa membantu? Nah, jika Anda melihat targetnya, Anda akan melihat:
targets: [{
expr: 'topk(5, rate(mysql_perf_schema_events_waits_total{instance="$instance"}[$interval])>0) or topk(5, irate(mysql_perf_schema_events_waits_total{instance="$instance"}[5m])>0)',
legendFormat: "{{event_name}} "
}]
Sekarang, Anda dapat menggunakan metrik yang diminta yaitu mysql_perf_schema_events_waits_total. Anda dapat memeriksanya, misalnya, dengan membuka http://
Pemulihan Otomatis ClusterControl untuk menyelamatkan!
Terakhir, pertanyaan utamanya adalah, apakah ada cara mudah untuk memulai kembali eksportir yang gagal? Ya! Kami menyebutkan sebelumnya bahwa ClusterControl mengawasi status ekspor dan memulai ulang jika diperlukan. Jika Anda melihat bahwa Dasbor SCUMM tidak memuat grafik secara normal, pastikan Anda mengaktifkan Pemulihan Otomatis. Lihat gambar di bawah ini:
Jika ini diaktifkan, ini akan memastikan bahwa
Anda juga dapat menginstal ulang atau mengkonfigurasi ulang eksportir.
Kesimpulan
Di blog ini, kami melihat bagaimana ClusterControl menggunakan Prometheus untuk menawarkan Dasbor SCUMM. Ini menyediakan serangkaian fitur yang kuat, dari data pemantauan resolusi tinggi dan grafik yang kaya. Anda telah mempelajari bahwa dengan PromQL, Anda dapat menentukan dan memecahkan masalah Dasbor SCUMM kami yang memungkinkan Anda untuk menggabungkan data deret waktu secara real time. Anda juga dapat membuat grafik atau tampilan melalui Konsol untuk semua metrik yang telah dikumpulkan.
Anda juga mempelajari cara men-debug Dasbor SCUMM kami terutama saat tidak ada titik data yang dikumpulkan.
Jika Anda memiliki pertanyaan, tambahkan di komentar Anda atau beri tahu kami melalui Forum Komunitas kami.
