Cara Memantau Kinerja PostgreSQL 12 dengan OmniDB – Bagian 2

Dalam artikel sebelumnya dari seri ini, kami membuat kluster PostgreSQL 12 dua simpul di cloud AWS. Kami juga menginstal dan mengonfigurasi 2ndQuadrant OmniDB di node ketiga. Gambar di bawah menunjukkan arsitekturnya:

Kami dapat terhubung ke node utama dan node siaga dari antarmuka pengguna berbasis web OmniDB. Kami kemudian memulihkan database sampel yang disebut “dvdrental” di node utama yang mulai mereplikasi ke standby.

Di bagian seri ini, kita akan mempelajari cara membuat dan menggunakan dasbor pemantauan di OmniDB. DBA dan tim operasi sering kali lebih memilih alat grafis daripada kueri kompleks untuk memeriksa kesehatan database secara visual. OmniDB hadir dengan sejumlah widget penting yang dapat dengan mudah digunakan di dasbor pemantauan. Seperti yang akan kita lihat nanti, ini juga memungkinkan pengguna untuk menulis widget pemantauan mereka sendiri.

Membuat Dasbor Pemantauan Kinerja

Mari kita mulai dengan dasbor default yang disertakan dengan OmniDB.

Pada gambar di bawah, kita terhubung ke node utama (PG-Node1). Kami mengklik kanan nama instance, lalu dari menu pop-up pilih “Monitor” lalu pilih “Dashboard”.

Ini akan membuka dasbor dengan beberapa widget di dalamnya.

Dalam istilah OmniDB, widget persegi panjang di dasbor disebut Unit Pemantauan . Masing-masing unit ini menunjukkan metrik tertentu dari instance PostgreSQL yang terhubung dengannya dan memperbarui datanya secara dinamis.

Memahami Unit Pemantauan

OmniDB hadir dengan empat jenis Unit Pemantauan:

• Sebuah Kisi adalah struktur tabel yang menunjukkan hasil kueri. Misalnya, ini dapat berupa output dari SELECT * FROM pg_stat_replication. Kotak terlihat seperti ini:

• A Bagan menunjukkan data dalam format grafis, seperti garis atau diagram lingkaran. Saat disegarkan, seluruh bagan digambar ulang di layar dengan nilai baru, dan nilai lama hilang. Dengan Unit Pemantauan ini, kami hanya dapat melihat nilai metrik saat ini. Berikut adalah contoh Bagan:

• A Tambahkan Bagan juga merupakan Unit Pemantauan tipe Bagan, kecuali saat disegarkan, ia menambahkan nilai baru ke rangkaian yang ada. Dengan Chart-Append, kita dapat dengan mudah melihat tren dari waktu ke waktu. Ini contohnya:

• A Grafik menunjukkan hubungan antara instance cluster PostgreSQL dan metrik terkait. Seperti Unit Pemantau Grafik, Unit Pemantau Grafik juga memperbarui nilai lama dengan yang baru. Gambar di bawah menunjukkan node saat ini (PG-Node1) sedang mereplikasi ke PG-Node2:

Setiap Unit Pemantauan memiliki sejumlah elemen umum:

• Nama Unit Pemantau
• Tombol “segarkan” untuk menyegarkan unit secara manual
• Tombol “jeda” untuk menghentikan sementara Unit Pemantauan agar tidak menyegarkan
• Kotak teks yang menunjukkan interval penyegaran saat ini. Ini bisa diubah
• Tombol “tutup” (tanda silang merah) untuk menghapus Unit Pemantauan dari dasbor
• Area gambar sebenarnya dari Pemantauan

Unit Pemantauan Pra-bangun

OmniDB hadir dengan sejumlah Unit Pemantauan untuk PostgreSQL yang dapat kita tambahkan ke dasbor kita. Untuk mengakses unit ini, kami mengklik tombol “Kelola Unit” di bagian atas dasbor:

Ini akan membuka daftar “Kelola Unit”:

Seperti yang bisa kita lihat, ada beberapa Unit Pemantauan yang dibuat sebelumnya di sini. Kode untuk Unit Pemantauan ini dapat diunduh secara bebas dari repo GitHub 2ndQuadrant. Setiap unit yang tercantum di sini menunjukkan nama, jenisnya (Bagan, Penambahan Bagan, Grafik, atau Kisi), dan kecepatan penyegaran default.

Untuk menambahkan Unit Pemantauan ke dasbor, kita hanya perlu mengklik tanda centang hijau di bawah kolom “Tindakan” untuk unit tersebut. Kami dapat mencampur dan mencocokkan Unit Pemantauan yang berbeda untuk membuat dasbor yang kami inginkan.

Pada gambar di bawah, kami telah menambahkan unit berikut untuk dasbor pemantauan kinerja kami dan menghapus yang lainnya:

TPS (transaksi per detik):

Jumlah Kunci:

Jumlah Backend:

Karena instance kita dalam keadaan idle, kita dapat melihat nilai TPS, Locks, dan Backends minimal.

Menguji Dasbor Pemantauan

Kami sekarang akan menjalankan pgbench di node utama kami (PG-Node1). pgbench adalah alat pembandingan sederhana yang disertakan dengan PostgreSQL. Seperti kebanyakan alat lain dari jenisnya, pgbench membuat contoh skema dan tabel sistem OLTP dalam database saat inisialisasi. Setelah itu, dapat mengemulasi beberapa koneksi klien, masing-masing menjalankan sejumlah transaksi di database. Dalam hal ini, kami tidak akan membandingkan node utama PostgreSQL; kami hanya akan membuat database untuk pgbench dan melihat apakah Unit Pemantauan dasbor kami mengambil perubahan dalam kondisi sistem.

Pertama, kita membuat database untuk pgbench di node utama:

[[email protected] ~]$ psql -h PG-Node1 -U postgres -c "CREATE DATABASE testdb";CREATE DATABASE

Selanjutnya, kita menginisialisasi database “testdb” untuk pgbench:

[[email protected] ~]$ /usr/pgsql-12/bin/pgbench -h PG-Node1 -p 5432  -I dtgvp -i -s 20 testdbmenjatuhkan tabel lama...membuat tabel...membuat data...100000 dari 2000000 tupel (5%) selesai (berlalu 0,02 detik, sisa 0,43 detik)2000000 dari 2000000 tupel (10%) selesai (berlalu 0,05 detik, tersisa 0,41 detik)……2000000 dari 2000000 tupel (100%) selesai (berlalu 1,84 d, tersisa 0,00 d)vakum...membuat kunci utama...selesai.

Dengan database diinisialisasi, kita sekarang memulai proses pemuatan yang sebenarnya. Dalam cuplikan kode di bawah ini, kami meminta pgbench untuk memulai dengan 50 koneksi klien bersamaan terhadap database testdb, setiap koneksi menjalankan 100.000 transaksi di tabelnya. Uji beban akan berjalan di dua utas.

[[email protected] ~]$ /usr/pgsql-12/bin/pgbench -h PG-Node1 -p 5432  -c 50 -j 2 -t 100000 testdbstarting vacuum...end.…… 

 Jika sekarang kita kembali ke dasbor OmniDB, kita melihat Unit Pemantauan menunjukkan beberapa hasil yang sangat berbeda.
 

 Metrik TPS menunjukkan nilai yang cukup tinggi. Ada lompatan mendadak dari kurang dari 2 menjadi lebih dari 2000:
 

 
 

 Jumlah backend telah meningkat. Seperti yang diharapkan, testdb memiliki 50 koneksi saat database lain tidak digunakan:
 

 
 

 Dan akhirnya, jumlah kunci eksklusif baris dalam database testdb juga tinggi:
 

 
 

 
 

 Sekarang bayangkan ini. Anda adalah DBA dan Anda menggunakan OmniDB untuk mengelola armada instans PostgreSQL. Anda mendapat panggilan untuk menyelidiki kinerja yang lambat di salah satu instance.
 

 Menggunakan dasbor seperti yang baru saja kita lihat (walaupun sangat sederhana), Anda dapat dengan mudah menemukan akar masalahnya. Anda dapat memeriksa jumlah backend, kunci, memori yang tersedia, dll. untuk melihat apa yang menyebabkan masalah.
 

 Dan di situlah OmniDB dapat menjadi alat yang sangat membantu.
 
Membuat Unit Pemantauan Kustom
 

 Terkadang kita perlu membuat Unit Pemantauan kita sendiri. Untuk menulis Unit Pemantauan baru, kita klik tombol “Unit Baru” di daftar “Kelola Unit”. Ini akan membuka tab baru dengan kanvas kosong untuk menulis kode:
 

 
 

 Di bagian atas layar, kita harus menentukan nama untuk Unit Pemantauan kita, pilih jenisnya, dan tentukan interval penyegaran defaultnya. Kami juga dapat memilih unit yang ada sebagai template. 
 

 Di bawah bagian header, ada dua kotak teks. Editor "Data Script" adalah tempat kami menulis kode untuk mendapatkan data untuk Unit Pemantauan kami. Setiap kali unit di-refresh, kode skrip data akan berjalan. Editor "Chart Script" adalah tempat kita menulis kode untuk menggambar unit yang sebenarnya. Ini dijalankan saat unit diambil pertama kali.
 

 Semua kode skrip data ditulis dengan Python. Untuk Unit Pemantauan tipe Bagan, OmniDB memerlukan skrip bagan untuk ditulis di Chart.js.
 

 Kami sekarang akan membuat Unit Pemantauan untuk menampilkan 5 tabel besar teratas dalam database saat ini. Berdasarkan database yang dipilih di OmniDB, Unit Pemantauan akan mengubah tampilannya untuk mencerminkan nama lima tabel terbesar dalam database tersebut.
 

 Untuk menulis Unit baru, yang terbaik adalah memulai dengan template yang ada dan memodifikasi kodenya. Ini akan menghemat waktu dan tenaga. Pada gambar berikut, kami menamai Unit Pemantau kami “5 Meja Besar Teratas”. Kami telah memilihnya sebagai tipe Bagan (Tanpa Append) dan memberikan kecepatan refresh 30 detik. Kami juga mendasarkan Unit Pemantauan kami pada template Ukuran Basis Data:
 

 
 

 Kotak teks Data Script secara otomatis diisi dengan kode untuk Unit Pemantauan Ukuran Basis Data:
 
from datetime import datetimefrom random import randintdatabases =connection.Query('''    SELECT d.datname AS datname,          round(pg_catalog.pg_database_size(d.datname)/1048576.0,2) AS size    FROM pg_catalog .pg datname not in ('template0','template1')''')data =[]color =[]label =[]untuk db di database.Baris:   data.append(db["size"])    color.append( "rgb(" + str(randint(125, 225)) + "," + str(randint(125, 225)) + "," + str(randint(125, 225)) + ")")    label.append (db["datname"])total_size =connection.ExecuteScalar('''    SELECT round(sum(pg_catalog.pg_database_size(datname)/1048576.0),2)    FROM pg_catalog.pg_database    WHERE NOT datistemplate''   result" ":label,    "datasets":[        {           "data":data,           "backgroundColor":color,          "label":"Dataset 1"          "backgroundColor":color,          "label":"Dataset 1"      ) (str(total) + ukuran " MB)"}
 

 Dan text box Chart Script juga diisi dengan kode:
 
total_size =koneksi.ExecuteScalar('''    SELECT round(sum(pg_catalog.pg_database_size(datname)/1048576.0),2)    FROM pg_catalog.pg_database    WHERE NOT datistemplate''')result ={    "type" ,    "data":None,    "options":{        "responsive":True,        "title":{           "display":True,           "text":"Ukuran Database" str(Total:"_) }    }}
 

 Kita dapat memodifikasi Data Script untuk mendapatkan 5 tabel besar teratas dalam database. Dalam skrip di bawah ini, kami telah menyimpan sebagian besar kode asli, kecuali pernyataan SQL:
 
from datetime import datetimefrom random import randinttables =connection.Query('''SELECT nspname || '.' || relname AS "tablename",   round(pg_catalog.pg_total_relation_size(c.oid)/1048576.0,2) AS " table_size"  DARI pg_class C  LEFT JOIN pg_namespace N ON (N.oid =C.relnamespace)  WHERE nspname NOT IN ('pg_catalog', 'information_schema')    AND C.relkind <> 'i'    DAN nspname !_toast^' OLEH 2 DESC  LIMIT 5;''')data =[]color =[]label =[]untuk tabel dalam tabel.Baris:   data.append(table["table_size"])    color.append("rgb(" + str (randint(125, 225)) + "," + str(randint(125, 225)) + "," + str(randint(125, 225)) + ")")    label.append(table["tablename" ])result ={    "labels":label,    "datasets":[        {           "data":data,           "backgroundColor":color,           "label":"Top 5" ])result ={    " 

 Di sini, kita mendapatkan ukuran gabungan dari setiap tabel dan indeksnya di database saat ini. Kami mengurutkan hasil dalam urutan menurun dan memilih lima baris teratas.
 

 Selanjutnya, kita mengisi tiga array Python dengan melakukan iterasi di atas resultet.
 

 Terakhir, kami sedang membangun string JSON berdasarkan nilai array.
 

 Di kotak teks Chart Script, kami telah memodifikasi kode untuk menghapus perintah SQL asli. Di sini, kami hanya menentukan aspek kosmetik bagan. Kami mendefinisikan bagan sebagai jenis pai dan memberikan judul untuknya:
 
result ={    "type":"pie",    "data":None,    "options":{        "responsive":True,       "title":{           "display":Benar,     " teks besar Tabel di Database Saat Ini (Ukuran dalam MB)"       }    }}
 

 Sekarang kita dapat menguji unit dengan mengklik ikon petir. Ini akan menampilkan Unit Pemantauan baru di area gambar pratinjau:
 

 
 

 Selanjutnya, kami menyimpan unit dengan mengklik ikon disk. Kotak pesan mengonfirmasi bahwa unit telah disimpan:
 

 
 

 Kami sekarang kembali ke dasbor pemantauan kami dan menambahkan Unit Pemantauan baru:
 

 
 

 Perhatikan bagaimana kami memiliki dua ikon lagi di bawah kolom "Tindakan" untuk Unit Pemantauan khusus kami. Satu untuk mengeditnya, yang lain untuk menghapusnya dari OmniDB.
 

 Unit Pemantauan “5 Tabel Besar Teratas” sekarang menampilkan lima tabel terbesar dalam database saat ini:
 

 
 

 Jika kita menutup dasbor, beralih ke database lain dari panel navigasi, dan membuka dasbor lagi, kita akan melihat Unit Pemantauan telah berubah untuk mencerminkan tabel database tersebut:
 

 
 
Kata Akhir
 

 Ini mengakhiri seri dua bagian kami di OmniDB. Seperti yang kita lihat, OmniDB memiliki beberapa Unit Pemantauan yang bagus yang menurut DBA PostgreSQL berguna untuk pelacakan kinerja. Kami melihat bagaimana kami dapat menggunakan unit ini untuk mengidentifikasi potensi kemacetan di server. Kami juga melihat cara membuat unit kustom kami sendiri. Pembaca didorong untuk membuat dan menguji Unit Pemantauan kinerja untuk beban kerja spesifik mereka. 2ndQuadrant menyambut baik kontribusi apa pun ke repo GitHub Unit Pemantauan OmniDB.