Asas pemantauan PostgreSQL. Alexey Lesovsky

Saya cadangkan anda membaca transkrip laporan oleh Alexey Lesovsky dari Data Egret "Asas pemantauan PostgreSQL"

Dalam laporan ini, Alexey Lesovsky akan bercakap tentang perkara utama statistik pasca-gres, maksudnya, dan mengapa ia perlu hadir dalam pemantauan; tentang graf yang sepatutnya ada dalam pemantauan, cara menambahnya dan cara mentafsirnya. Laporan ini akan berguna kepada pentadbir pangkalan data, pentadbir sistem dan pembangun yang berminat dalam penyelesaian masalah Postgres.

Nama saya Alexey Lesovsky, saya mewakili syarikat Data Egret.

Sedikit perkataan tentang diri saya. Saya telah bermula lama dahulu sebagai pentadbir sistem.

Saya mentadbir semua jenis sistem Linux yang berbeza, bekerja pada pelbagai perkara yang berkaitan dengan Linux, iaitu virtualisasi, pemantauan, bekerja dengan proksi, dll. Tetapi pada satu ketika saya mula bekerja lebih dengan pangkalan data, PostgreSQL. Saya sangat menyukainya. Dan pada satu ketika saya mula bekerja pada PostgreSQL kebanyakan masa bekerja saya. Dan secara beransur-ansur saya menjadi PostgreSQL DBA.

Dan sepanjang kerjaya saya, saya sentiasa berminat dengan topik statistik, pemantauan, dan telemetri. Dan semasa saya menjadi pentadbir sistem, saya bekerja sangat rapat dengan Zabbix. Dan saya menulis satu set kecil skrip seperti zabbix-sambungan. Dia cukup popular pada zamannya. Dan di sana adalah mungkin untuk memantau perkara penting yang sangat berbeza, bukan sahaja Linux, tetapi juga pelbagai komponen.

Sekarang saya sedang mengusahakan PostgreSQL. Saya sudah menulis perkara lain yang membolehkan anda bekerja dengan statistik PostgreSQL. Ia dikenali sebagai pgCenter (artikel mengenai Habré - Statistik pasca-gress tanpa saraf dan ketegangan).

Sedikit nota pengenalan. Apakah situasi yang dialami oleh pelanggan kami, pelanggan kami? Terdapat beberapa jenis kemalangan yang berkaitan dengan pangkalan data. Dan apabila pangkalan data telah dipulihkan, ketua jabatan atau ketua pembangunan datang dan berkata: "Kawan, kita perlu memantau pangkalan data, kerana sesuatu yang buruk telah berlaku dan kita perlu mengelakkan perkara ini daripada berlaku pada masa hadapan." Dan di sini bermula proses menarik memilih sistem pemantauan atau menyesuaikan sistem pemantauan sedia ada supaya anda boleh memantau pangkalan data anda - PostgreSQL, MySQL atau beberapa yang lain. Dan rakan sekerja mula mencadangkan: "Saya mendengar bahawa terdapat pangkalan data begitu dan itu. Jom guna." Rakan sekerja mula bertengkar sesama sendiri. Dan pada akhirnya ternyata kami memilih beberapa jenis pangkalan data, tetapi pemantauan PostgreSQL dibentangkan di dalamnya dengan agak buruk dan kami sentiasa perlu menambah sesuatu. Ambil beberapa repositori daripada GitHub, klonkannya, sesuaikan skrip dan entah bagaimana menyesuaikannya. Dan akhirnya ia menjadi semacam kerja manual.

Oleh itu, dalam ceramah ini saya akan cuba memberi anda sedikit pengetahuan tentang cara memilih pemantauan bukan sahaja untuk PostgreSQL, tetapi juga untuk pangkalan data. Dan memberi anda pengetahuan yang akan membolehkan anda melengkapkan pemantauan anda untuk mendapatkan sedikit faedah daripadanya, supaya anda boleh memantau pangkalan data anda dengan manfaat, untuk mengelakkan dengan segera sebarang situasi kecemasan akan datang yang mungkin timbul.

Dan idea-idea yang akan ada dalam laporan ini boleh disesuaikan secara langsung kepada mana-mana pangkalan data, sama ada DBMS atau noSQL. Oleh itu, terdapat bukan sahaja PostgreSQL, tetapi akan terdapat banyak resipi tentang cara melakukan ini dalam PostgreSQL. Akan ada contoh pertanyaan, contoh entiti yang PostgreSQL ada untuk pemantauan. Dan jika DBMS anda mempunyai perkara yang sama yang membolehkan anda meletakkannya dalam pemantauan, anda juga boleh menyesuaikannya, menambahnya dan ia akan menjadi baik.

Saya tidak akan berada dalam laporan
bercakap tentang cara menghantar dan menyimpan metrik. Saya tidak akan mengatakan apa-apa tentang pemprosesan pasca data dan menyampaikannya kepada pengguna. Dan saya tidak akan mengatakan apa-apa tentang memberi amaran.
Tetapi apabila cerita itu berjalan, saya akan menunjukkan tangkapan skrin berbeza pemantauan sedia ada dan entah bagaimana mengkritiknya. Namun begitu, saya akan cuba untuk tidak menamakan jenama supaya tidak mencipta pengiklanan atau anti-pengiklanan untuk produk ini. Oleh itu, semua kebetulan adalah rawak dan diserahkan kepada imaginasi anda.

Mula-mula, mari kita ketahui apa itu pemantauan. Pemantauan adalah perkara yang sangat penting untuk dimiliki. Semua orang faham ini. Tetapi pada masa yang sama, pemantauan tidak berkaitan dengan produk perniagaan dan tidak menjejaskan keuntungan syarikat secara langsung, jadi masa sentiasa diperuntukkan untuk pemantauan secara baki. Jika kami mempunyai masa, maka kami melakukan pemantauan; jika kami tidak mempunyai masa, maka OK, kami akan meletakkannya dalam tunggakan dan suatu hari nanti kami akan kembali kepada tugasan ini.

Oleh itu, daripada amalan kami, apabila kami datang kepada pelanggan, pemantauan selalunya tidak lengkap dan tidak mempunyai apa-apa perkara menarik yang akan membantu kami melakukan kerja yang lebih baik dengan pangkalan data. Dan oleh itu pemantauan sentiasa perlu diselesaikan.

Pangkalan data adalah perkara yang kompleks yang juga perlu dipantau, kerana pangkalan data adalah repositori maklumat. Dan maklumat adalah sangat penting untuk syarikat; ia tidak boleh hilang dalam apa cara sekalipun. Tetapi pada masa yang sama, pangkalan data adalah perisian yang sangat kompleks. Mereka terdiri daripada sejumlah besar komponen. Dan banyak komponen ini perlu dipantau.

Jika kita bercakap secara khusus mengenai PostgreSQL, maka ia boleh diwakili dalam bentuk skema yang terdiri daripada sejumlah besar komponen. Komponen ini berinteraksi antara satu sama lain. Dan pada masa yang sama, PostgreSQL mempunyai subsistem yang dipanggil Stats Collector, yang membolehkan anda mengumpul statistik tentang operasi subsistem ini dan menyediakan beberapa jenis antara muka kepada pentadbir atau pengguna supaya dia boleh melihat statistik ini.

Statistik ini dibentangkan dalam bentuk set fungsi dan pandangan tertentu. Mereka juga boleh dipanggil jadual. Iaitu, menggunakan klien psql biasa, anda boleh menyambung ke pangkalan data, membuat pilihan pada fungsi dan pandangan ini, dan mendapatkan beberapa nombor khusus tentang pengendalian subsistem PostgreSQL.

Anda boleh menambah nombor ini pada sistem pemantauan kegemaran anda, melukis graf, menambah fungsi dan mendapatkan analisis dalam jangka panjang.

Tetapi dalam laporan ini saya tidak akan merangkumi semua fungsi ini sepenuhnya, kerana ia boleh mengambil masa sepanjang hari. Saya benar-benar akan menangani dua, tiga atau empat perkara dan memberitahu anda bagaimana ia membantu menjadikan pemantauan lebih baik.

Dan jika kita bercakap tentang pemantauan pangkalan data, maka apa yang perlu dipantau? Pertama sekali, kita perlu memantau ketersediaan, kerana pangkalan data adalah perkhidmatan yang menyediakan akses kepada data kepada pelanggan dan kita perlu memantau ketersediaan, dan juga menyediakan beberapa ciri kualitatif dan kuantitatifnya.

Kami juga perlu memantau pelanggan yang menyambung ke pangkalan data kami, kerana mereka boleh menjadi pelanggan biasa dan pelanggan berbahaya yang boleh membahayakan pangkalan data. Mereka juga perlu dipantau dan aktiviti mereka dijejaki.

Apabila pelanggan menyambung ke pangkalan data, jelas sekali mereka mula bekerja dengan data kami, jadi kami perlu memantau cara pelanggan bekerja dengan data: dengan jadual yang mana, dan sedikit sebanyak, dengan indeks yang mana. Maksudnya, kita perlu menilai beban kerja yang dibuat oleh pelanggan kita.

Tetapi beban kerja juga terdiri, tentu saja, permintaan. Aplikasi menyambung ke pangkalan data, mengakses data menggunakan pertanyaan, jadi adalah penting untuk menilai pertanyaan yang kami ada dalam pangkalan data, memantau kecukupan mereka, bahawa ia tidak ditulis secara bengkok, bahawa beberapa pilihan perlu ditulis semula dan dibuat supaya ia berfungsi lebih cepat dan dengan prestasi yang lebih baik.

Dan kerana kita bercakap tentang pangkalan data, pangkalan data sentiasa proses latar belakang. Proses latar belakang membantu mengekalkan prestasi pangkalan data pada tahap yang baik, jadi mereka memerlukan sejumlah sumber tertentu untuk beroperasi. Dan pada masa yang sama, mereka boleh bertindih dengan sumber permintaan pelanggan, jadi proses latar belakang yang tamak secara langsung boleh menjejaskan prestasi permintaan pelanggan. Oleh itu, mereka juga perlu dipantau dan dijejaki supaya tidak berlaku penyelewengan dari segi proses latar belakang.

Dan semua ini dari segi pemantauan pangkalan data kekal dalam metrik sistem. Tetapi memandangkan kebanyakan infrastruktur kami bergerak ke awan, metrik sistem hos individu sentiasa pudar ke latar belakang. Tetapi dalam pangkalan data ia masih relevan dan, sudah tentu, ia juga perlu untuk memantau metrik sistem.

Segala-galanya lebih kurang baik dengan metrik sistem, semua sistem pemantauan moden sudah menyokong metrik ini, tetapi secara umum, beberapa komponen masih tidak mencukupi dan beberapa perkara perlu ditambah. Saya juga akan menyentuh tentang mereka, akan ada beberapa slaid tentang mereka.

Perkara pertama pelan adalah kebolehcapaian. Apakah kebolehaksesan? Ketersediaan dalam pemahaman saya ialah keupayaan pangkalan untuk perkhidmatan sambungan, iaitu pangkalan dinaikkan, ia, sebagai perkhidmatan, menerima sambungan daripada pelanggan. Dan kebolehcapaian ini boleh dinilai oleh ciri-ciri tertentu. Ia sangat mudah untuk memaparkan ciri-ciri ini pada papan pemuka.

Semua orang tahu apa itu papan pemuka. Ini adalah apabila anda melihat sekali pada skrin di mana maklumat yang diperlukan diringkaskan. Dan anda boleh segera menentukan sama ada terdapat masalah dalam pangkalan data atau tidak.
Sehubungan itu, ketersediaan pangkalan data dan ciri utama lain hendaklah sentiasa dipaparkan pada papan pemuka supaya maklumat ini tersedia dan sentiasa tersedia untuk anda. Beberapa butiran tambahan yang sudah membantu dalam penyiasatan insiden, apabila menyiasat beberapa situasi kecemasan, butiran tersebut sudah perlu diletakkan pada papan pemuka sekunder atau disembunyikan dalam pautan gerudi turun yang membawa kepada sistem pemantauan pihak ketiga.

Contoh satu sistem pemantauan yang terkenal. Ini adalah sistem pemantauan yang sangat keren. Dia mengumpul banyak data, tetapi dari sudut pandangan saya, dia mempunyai konsep papan pemuka yang pelik. Terdapat pautan untuk "membuat papan pemuka". Tetapi apabila anda membuat papan pemuka, anda membuat senarai dua lajur, senarai graf. Dan apabila anda perlu melihat sesuatu, anda mula mengklik dengan tetikus, menatal, mencari carta yang dikehendaki. Dan ini memerlukan masa, iaitu tiada papan pemuka seperti itu. Terdapat hanya senarai carta.

Apakah yang perlu anda tambahkan pada papan pemuka ini? Anda boleh mulakan dengan ciri seperti masa tindak balas. PostgreSQL mempunyai paparan pg_stat_statements. Ia dilumpuhkan secara lalai, tetapi ia adalah salah satu pandangan sistem penting yang harus sentiasa didayakan dan digunakan. Ia menyimpan maklumat tentang semua pertanyaan yang sedang dijalankan yang telah dilaksanakan dalam pangkalan data.

Sehubungan itu, kita boleh bermula daripada fakta bahawa kita boleh mengambil jumlah masa pelaksanaan semua permintaan dan membahagikannya dengan bilangan permintaan menggunakan medan di atas. Tetapi ini adalah purata suhu di hospital. Kita boleh bermula dari medan lain - masa pelaksanaan pertanyaan minimum, maksimum dan median. Dan kita juga boleh membina persentil; PostgreSQL mempunyai fungsi yang sepadan untuk ini. Dan kami boleh mendapatkan beberapa nombor yang mencirikan masa tindak balas pangkalan data kami untuk permintaan yang telah selesai, iaitu kami tidak melaksanakan permintaan palsu 'pilih 1' dan melihat masa tindak balas, tetapi kami menganalisis masa tindak balas untuk permintaan yang telah selesai dan menarik sama ada angka yang berasingan, atau kami membina graf berdasarkannya.

Ia juga penting untuk memantau bilangan ralat yang sedang dijana oleh sistem. Dan untuk ini anda boleh menggunakan paparan pg_stat_database. Kami menumpukan pada medan xact_rollback. Medan ini menunjukkan bukan sahaja bilangan rollback yang berlaku dalam pangkalan data, tetapi juga mengambil kira bilangan ralat. Secara relatifnya, kami boleh memaparkan angka ini dalam papan pemuka kami dan melihat berapa banyak ralat yang kami ada pada masa ini. Jika terdapat banyak ralat, maka ini adalah sebab yang baik untuk melihat ke dalam log dan melihat jenis ralatnya dan mengapa ia berlaku, dan kemudian melabur dan menyelesaikannya.

Anda boleh menambah perkara seperti Tachometer. Ini ialah bilangan transaksi sesaat dan bilangan permintaan sesaat. Secara relatifnya, anda boleh menggunakan nombor ini sebagai prestasi semasa pangkalan data anda dan memerhati sama ada terdapat kemuncak dalam permintaan, kemuncak dalam urus niaga, atau, sebaliknya, sama ada pangkalan data kurang dimuatkan kerana beberapa bahagian belakang telah gagal. Adalah penting untuk sentiasa melihat angka ini dan ingat bahawa untuk projek kami prestasi seperti ini adalah normal, tetapi nilai di atas dan di bawah sudah agak bermasalah dan tidak dapat difahami, yang bermaksud kita perlu melihat mengapa nombor ini begitu tinggi.

Untuk menganggarkan bilangan transaksi, kita boleh merujuk sekali lagi pada paparan pg_stat_database. Kita boleh menambah bilangan komit dan bilangan pemulangan dan mendapatkan bilangan urus niaga sesaat.

Adakah semua orang faham bahawa beberapa permintaan boleh dimuatkan dalam satu transaksi? Oleh itu TPS dan QPS adalah sedikit berbeza.

Bilangan permintaan sesaat boleh diperolehi daripada pg_stat_statements dan hanya mengira jumlah semua permintaan yang telah lengkap. Adalah jelas bahawa kita membandingkan nilai semasa dengan yang sebelumnya, tolak, dapatkan delta, dan dapatkan kuantiti.

Anda boleh menambah metrik tambahan jika dikehendaki, yang juga membantu menilai ketersediaan pangkalan data kami dan memantau sama ada terdapat sebarang masa henti.

Salah satu metrik ini ialah masa beroperasi. Tetapi masa operasi dalam PostgreSQL agak rumit. Saya akan memberitahu anda mengapa. Apabila PostgreSQL telah bermula, masa operasi mula melaporkan. Tetapi jika pada satu ketika, sebagai contoh, beberapa tugas sedang berjalan pada waktu malam, pembunuh OOM datang dan secara paksa menamatkan proses kanak-kanak PostgreSQL, maka dalam kes ini PostgreSQL menamatkan sambungan semua pelanggan, menetapkan semula kawasan memori yang dipecahkan dan memulakan pemulihan daripada pusat pemeriksaan terakhir. Dan sementara pemulihan dari pusat pemeriksaan ini berlangsung, pangkalan data tidak menerima sambungan, iaitu keadaan ini boleh dinilai sebagai masa henti. Tetapi kaunter masa operasi tidak akan ditetapkan semula, kerana ia mengambil kira masa permulaan jurutulis dari saat pertama. Oleh itu, situasi sedemikian boleh dilangkau.

Anda juga harus memantau bilangan pekerja vakum. Adakah semua orang tahu apa itu autovacuum dalam PostgreSQL? Ini adalah subsistem yang menarik dalam PostgreSQL. Banyak artikel telah ditulis tentang dia, banyak laporan telah dibuat. Terdapat banyak perbincangan tentang vakum dan cara ia harus berfungsi. Ramai menganggapnya sebagai kejahatan yang perlu. Tetapi begitulah keadaannya. Ini adalah sejenis analog pengumpul sampah yang membersihkan versi lapuk baris yang tidak diperlukan oleh sebarang transaksi dan mengosongkan ruang dalam jadual dan indeks untuk baris baharu.

Mengapa anda perlu memantaunya? Sebab hampa kadang-kadang sakit sangat. Ia menggunakan sejumlah besar sumber dan permintaan pelanggan mula menderita akibatnya.

Dan ia harus dipantau melalui paparan pg_stat_activity, yang akan saya bincangkan dalam bahagian seterusnya. Paparan ini menunjukkan aktiviti semasa dalam pangkalan data. Dan melalui aktiviti ini kita boleh menjejaki bilangan vakum yang berfungsi sekarang. Kami boleh menjejaki vakum dan melihat bahawa jika kami telah melebihi had, maka ini adalah sebab untuk melihat ke dalam tetapan PostgreSQL dan entah bagaimana mengoptimumkan operasi vakum.

Satu lagi perkara tentang PostgreSQL ialah PostgreSQL sangat bosan dengan transaksi yang lama. Lebih-lebih lagi daripada urus niaga yang berlegar-legar dalam tempoh yang lama dan tidak melakukan apa-apa. Ini ialah apa yang dipanggil stat melahu-dalam-urus niaga. Urus niaga sedemikian memegang kunci dan menghalang vakum daripada berfungsi. Dan akibatnya, meja membengkak dan bertambah besar. Dan pertanyaan yang berfungsi dengan jadual ini mula berfungsi dengan lebih perlahan, kerana anda perlu menyodok semua versi lama baris dari memori ke cakera dan belakang. Oleh itu, masa, tempoh transaksi terpanjang, permintaan vakum terpanjang juga perlu dipantau. Dan jika kita melihat beberapa proses yang telah berjalan untuk masa yang sangat lama, sudah lebih daripada 10-20-30 minit untuk beban OLTP, maka kita perlu memberi perhatian kepada mereka dan secara paksa menamatkannya, atau mengoptimumkan aplikasi supaya mereka tidak dipanggil dan tidak digantung begitu lama. Untuk beban kerja analisis, 10-20-30 minit adalah perkara biasa; terdapat juga yang lebih lama.

Seterusnya kita mempunyai pilihan dengan pelanggan yang bersambung. Apabila kami telah membuat papan pemuka dan menyiarkan metrik ketersediaan utama pada papan pemuka itu, kami juga boleh menambahkan maklumat tambahan tentang pelanggan yang disambungkan di sana.

Maklumat tentang pelanggan yang disambungkan adalah penting kerana, dari perspektif PostgreSQL, pelanggan adalah berbeza. Ada pelanggan yang baik dan ada pelanggan yang tidak baik.

Contoh mudah. Oleh pelanggan saya memahami permohonan itu. Aplikasi telah disambungkan ke pangkalan data dan serta-merta mula menghantar permintaannya ke sana, pangkalan data memproses dan melaksanakannya, dan mengembalikan hasilnya kepada pelanggan. Ini adalah pelanggan yang baik dan betul.

Terdapat situasi apabila pelanggan telah menyambung, ia memegang sambungan, tetapi tidak melakukan apa-apa. Ia dalam keadaan terbiar.

Tetapi ada pelanggan yang teruk. Sebagai contoh, pelanggan yang sama disambungkan, membuka transaksi, melakukan sesuatu dalam pangkalan data dan kemudian pergi ke kod, sebagai contoh, untuk mengakses sumber luaran atau untuk memproses data yang diterima di sana. Tetapi dia tidak menutup transaksi itu. Dan transaksi itu tergantung dalam pangkalan data dan dipegang dalam kunci pada talian. Ini adalah keadaan yang teruk. Dan jika tiba-tiba aplikasi di suatu tempat di dalam dirinya gagal dengan pengecualian, maka urus niaga boleh kekal terbuka untuk masa yang sangat lama. Dan ini secara langsung mempengaruhi prestasi PostgreSQL. PostgreSQL akan menjadi lebih perlahan. Oleh itu, adalah penting untuk menjejaki pelanggan sedemikian tepat pada masanya dan secara paksa menamatkan kerja mereka. Dan anda perlu mengoptimumkan aplikasi anda supaya situasi sedemikian tidak berlaku.

Pelanggan jahat lain sedang menunggu pelanggan. Tetapi mereka menjadi buruk kerana keadaan. Sebagai contoh, transaksi terbiar mudah: ia boleh membuka transaksi, mengambil kunci pada beberapa baris, kemudian di suatu tempat dalam kod ia akan gagal, meninggalkan transaksi yang tergantung. Pelanggan lain akan datang dan meminta data yang sama, tetapi dia akan menghadapi kunci, kerana transaksi gantung itu sudah memegang kunci pada beberapa baris yang diperlukan. Dan transaksi kedua akan berkeliaran menunggu transaksi pertama selesai atau ditutup secara paksa oleh pentadbir. Oleh itu, transaksi yang belum selesai boleh mengumpul dan mengisi had sambungan pangkalan data. Dan apabila hadnya penuh, aplikasi tidak lagi boleh berfungsi dengan pangkalan data. Ini sudah menjadi situasi kecemasan untuk projek itu. Oleh itu, pelanggan yang tidak baik perlu dijejaki dan dibalas tepat pada masanya.

Satu lagi contoh pemantauan. Dan sudah ada papan pemuka yang baik di sini. Terdapat maklumat mengenai sambungan di atas. Sambungan DB - 8 keping. Dan itu semua. Kami tidak mempunyai maklumat tentang pelanggan mana yang aktif, pelanggan mana yang hanya melahu, tidak melakukan apa-apa. Tiada maklumat tentang urus niaga yang belum selesai dan sambungan yang belum selesai, iaitu angka yang menunjukkan bilangan sambungan dan itu sahaja. Dan kemudian teka sendiri.

Sehubungan itu, untuk menambah maklumat ini pada pemantauan, anda perlu mengakses paparan sistem pg_stat_activity. Jika anda menghabiskan banyak masa dalam PostgreSQL, maka ini adalah pandangan yang sangat baik yang sepatutnya menjadi rakan anda, kerana ia menunjukkan aktiviti semasa dalam PostgreSQL, iaitu apa yang berlaku di dalamnya. Untuk setiap proses terdapat baris berasingan yang menunjukkan maklumat tentang proses ini: dari hos mana sambungan dibuat, di bawah pengguna apa, di bawah nama apa, apabila transaksi dimulakan, permintaan apa yang sedang dijalankan, permintaan apa yang terakhir dilaksanakan. Dan, sewajarnya, kami boleh menilai keadaan pelanggan menggunakan medan statistik. Secara relatifnya, kita boleh mengumpulkan mengikut medan ini dan mendapatkan statistik yang ada dalam pangkalan data dan bilangan sambungan yang mempunyai statistik ini dalam pangkalan data. Dan kami boleh menghantar nombor yang telah diterima ke pemantauan kami dan melukis graf berdasarkannya.
Ia juga penting untuk menilai tempoh transaksi. Saya sudah mengatakan bahawa adalah penting untuk menilai tempoh vakum, tetapi transaksi dinilai dengan cara yang sama. Terdapat medan xact_start dan query_start. Mereka, secara relatifnya, menunjukkan masa mula transaksi dan masa mula permintaan. Kami mengambil fungsi now(), yang menunjukkan cap masa semasa, dan menolak transaksi dan meminta cap masa. Dan kami mendapat tempoh transaksi, tempoh permintaan.

Jika kita melihat urus niaga yang panjang, kita harus menyelesaikannya. Untuk beban OLTP, urus niaga yang lama sudah melebihi 1-2-3 minit. Untuk beban kerja OLAP, urus niaga yang panjang adalah perkara biasa, tetapi jika mereka mengambil masa lebih daripada dua jam untuk diselesaikan, maka ini juga merupakan petanda bahawa kita mempunyai kecondongan di suatu tempat.

Apabila pelanggan telah menyambung ke pangkalan data, mereka mula bekerja dengan data kami. Mereka mengakses jadual, mereka mengakses indeks untuk mendapatkan data daripada jadual. Dan adalah penting untuk menilai cara pelanggan berinteraksi dengan data ini.

Ini adalah perlu untuk menilai beban kerja kami dan secara kasar memahami jadual mana yang "paling hangat" untuk kami. Sebagai contoh, ini diperlukan dalam situasi di mana kita ingin meletakkan jadual "panas" pada beberapa jenis storan SSD yang pantas. Sebagai contoh, beberapa jadual arkib yang telah lama tidak kami gunakan boleh dialihkan ke beberapa jenis arkib "sejuk", ke pemacu SATA dan biarkan mereka tinggal di sana, ia akan diakses mengikut keperluan.

Ini juga berguna untuk mengesan anomali selepas sebarang keluaran dan penggunaan. Katakan projek itu telah mengeluarkan beberapa ciri baharu. Sebagai contoh, kami menambah fungsi baharu untuk bekerja dengan pangkalan data. Dan jika kita memplot graf penggunaan jadual, kita boleh mengesan anomali ini dengan mudah pada graf ini. Contohnya, kemas kini letusan atau memadam letusan. Ia akan sangat kelihatan.

Anda juga boleh mengesan anomali dalam statistik "terapung". Apakah maksudnya? PostgreSQL mempunyai penjadual pertanyaan yang sangat kuat dan sangat baik. Dan pemaju menumpukan banyak masa untuk pembangunannya. Bagaimana dia bekerja? Untuk membuat perancangan yang baik, PostgreSQL mengumpul statistik mengenai pengagihan data dalam jadual pada selang masa tertentu dan dengan frekuensi tertentu. Ini adalah nilai yang paling biasa: bilangan nilai unik, maklumat tentang NULL dalam jadual, banyak maklumat.

Berdasarkan statistik ini, perancang membina beberapa pertanyaan, memilih pertanyaan yang paling optimum dan menggunakan pelan pertanyaan ini untuk melaksanakan pertanyaan itu sendiri dan mengembalikan data.

Dan ia berlaku bahawa statistik "terapung". Data kualiti dan kuantiti entah bagaimana berubah dalam jadual, tetapi statistik tidak dikumpulkan. Dan rancangan yang dibentuk mungkin tidak optimum. Dan jika rancangan kami ternyata tidak optimum berdasarkan pemantauan yang dikumpul, berdasarkan jadual, kami akan dapat melihat anomali ini. Sebagai contoh, di suatu tempat data berubah secara kualitatif dan bukannya indeks, laluan berurutan melalui jadual mula digunakan, i.e. jika pertanyaan perlu mengembalikan hanya 100 baris (terdapat had 100), maka carian lengkap akan dilakukan untuk pertanyaan ini. Dan ini sentiasa mempunyai kesan yang sangat buruk terhadap prestasi.

Dan ini dapat kita lihat dalam pemantauan. Dan sudah melihat pertanyaan ini, jalankan penjelasan untuknya, kumpulkan statistik, bina indeks tambahan baharu. Dan sudah bertindak balas kepada masalah ini. Sebab tu penting.

Satu lagi contoh pemantauan. Saya rasa ramai yang mengenalinya kerana dia sangat popular. Siapa yang menggunakannya dalam projek mereka Prometheus? Siapa yang menggunakan produk ini bersama-sama dengan Prometheus? Hakikatnya ialah dalam repositori standard pemantauan ini terdapat papan pemuka untuk bekerja dengan PostgreSQL - postgres_exporter Prometheus. Tetapi ada satu perincian yang buruk.

Terdapat beberapa graf. Dan bait ditunjukkan sebagai kesatuan, iaitu terdapat 5 graf. Ini ialah Sisipkan data, Kemas kini data, Padam data, Ambil data dan Kembalikan data. Ukuran unit ialah bait. Tetapi masalahnya ialah statistik dalam PostgreSQL mengembalikan data dalam tuple (baris). Dan, sewajarnya, graf ini adalah cara yang sangat baik untuk meremehkan beban kerja anda beberapa kali, berpuluh-puluh kali, kerana tupel bukan bait, tuple ialah rentetan, ia adalah banyak bait dan ia sentiasa mempunyai panjang berubah-ubah. Iaitu, mengira beban kerja dalam bait menggunakan tupel adalah tugas yang tidak realistik atau sangat sukar. Oleh itu, apabila anda menggunakan papan pemuka atau pemantauan terbina dalam, sentiasa penting untuk memahami bahawa ia berfungsi dengan betul dan mengembalikan data yang dinilai dengan betul kepada anda.

Bagaimana untuk mendapatkan statistik pada jadual ini? Untuk tujuan ini, PostgreSQL mempunyai keluarga pandangan tertentu. Dan pandangan utama ialah pg_stat_user_tables. User_tables - ini bermaksud jadual yang dibuat bagi pihak pengguna. Sebaliknya, terdapat pandangan sistem yang digunakan oleh PostgreSQL sendiri. Dan terdapat jadual ringkasan Alltables, yang merangkumi kedua-dua sistem dan pengguna. Anda boleh bermula dari mana-mana daripada mereka yang paling anda sukai.

Menggunakan medan di atas anda boleh menganggarkan bilangan sisipan, kemas kini dan pemadaman. Contoh papan pemuka yang saya gunakan menggunakan medan ini untuk menilai ciri beban kerja. Oleh itu, kita juga boleh membina mereka. Tetapi perlu diingat bahawa ini adalah tupel, bukan bait, jadi kita tidak boleh melakukannya dalam bait sahaja.

Berdasarkan data ini, kita boleh membina apa yang dipanggil jadual TopN. Contohnya, Top-5, Top-10. Dan anda boleh menjejaki meja panas yang dikitar semula lebih daripada yang lain. Sebagai contoh, 5 jadual "panas" untuk sisipan. Dan menggunakan jadual TopN ini, kami menilai beban kerja kami dan boleh menilai letusan beban kerja selepas sebarang keluaran, kemas kini dan penggunaan.

Ia juga penting untuk menilai saiz jadual, kerana kadangkala pembangun melancarkan ciri baharu, dan jadual kami mula membengkak dalam saiznya yang besar, kerana mereka memutuskan untuk menambah jumlah data tambahan, tetapi tidak meramalkan bagaimana ini akan berlaku. mempengaruhi saiz pangkalan data. Kes sebegini juga mengejutkan kami.

Dan sekarang soalan kecil untuk anda. Apakah soalan yang timbul apabila anda melihat beban pada pelayan pangkalan data anda? Apakah soalan seterusnya yang anda ada?

Tetapi sebenarnya persoalannya timbul seperti berikut. Apakah permintaan yang disebabkan oleh beban? Iaitu, tidak menarik untuk melihat proses yang disebabkan oleh beban. Adalah jelas bahawa jika hos mempunyai pangkalan data, maka pangkalan data berjalan di sana dan jelas bahawa hanya pangkalan data akan dilupuskan di sana. Jika kita membuka Atas, kita akan melihat terdapat senarai proses dalam PostgreSQL yang melakukan sesuatu. Ia tidak akan jelas daripada Top apa yang mereka lakukan.

Sehubungan itu, anda perlu mencari pertanyaan yang menyebabkan beban tertinggi, kerana pertanyaan penalaan, sebagai peraturan, memberikan lebih banyak keuntungan daripada menala konfigurasi PostgreSQL atau sistem pengendalian, atau menala perkakasan. Mengikut anggaran saya, ini adalah lebih kurang 80-85-90%. Dan ini dilakukan dengan lebih cepat. Ia lebih pantas untuk membetulkan permintaan daripada membetulkan konfigurasi, menjadualkan permulaan semula, terutamanya jika pangkalan data tidak boleh dimulakan semula atau menambah perkakasan. Lebih mudah untuk menulis semula pertanyaan di suatu tempat atau menambah indeks untuk mendapatkan hasil yang lebih baik daripada pertanyaan ini.

Sehubungan itu, adalah perlu untuk memantau permintaan dan kecukupan mereka. Mari kita ambil satu lagi contoh pemantauan. Dan di sini juga, nampaknya terdapat pemantauan yang sangat baik. Terdapat maklumat mengenai replikasi, terdapat maklumat mengenai throughput, penyekatan, penggunaan sumber. Semuanya baik-baik saja, tetapi tiada maklumat mengenai permintaan. Tidak jelas apakah pertanyaan yang dijalankan dalam pangkalan data kami, berapa lama ia dijalankan, berapa banyak pertanyaan ini. Kami sentiasa perlu mempunyai maklumat ini dalam pemantauan kami.

Dan untuk mendapatkan maklumat ini kita boleh menggunakan modul pg_stat_statements. Berdasarkannya, anda boleh membina pelbagai graf. Sebagai contoh, anda boleh mendapatkan maklumat tentang pertanyaan yang paling kerap, iaitu, pada pertanyaan yang paling kerap dilaksanakan. Ya, selepas penempatan, ia juga sangat berguna untuk melihatnya dan memahami jika terdapat sebarang lonjakan permintaan.

Anda boleh memantau pertanyaan terpanjang, iaitu pertanyaan yang mengambil masa paling lama untuk diselesaikan. Mereka berjalan pada pemproses, mereka menggunakan I/O. Kami juga boleh menilai ini menggunakan medan total_time, mean_time, blk_write_time dan blk_read_time.

Kami boleh menilai dan memantau permintaan yang paling berat dari segi penggunaan sumber, yang membaca dari cakera, yang berfungsi dengan memori, atau, sebaliknya, mencipta beberapa jenis beban penulisan.

Kami boleh menilai permintaan yang paling murah hati. Ini ialah pertanyaan yang mengembalikan sejumlah besar baris. Sebagai contoh, ini mungkin beberapa permintaan apabila mereka terlupa untuk menetapkan had. Dan ia hanya mengembalikan keseluruhan kandungan jadual atau pertanyaan merentas jadual pertanyaan.

Dan anda juga boleh memantau pertanyaan yang menggunakan fail sementara atau jadual sementara.

Dan kami masih mempunyai proses latar belakang. Proses latar belakang terutamanya pusat pemeriksaan atau ia juga dipanggil pusat pemeriksaan, ini adalah autovakum dan replikasi.

Satu lagi contoh pemantauan. Terdapat tab Penyelenggaraan di sebelah kiri, pergi ke sana dan berharap untuk melihat sesuatu yang berguna. Tetapi di sini hanya masa operasi vakum dan pengumpulan statistik, tidak lebih. Ini adalah maklumat yang sangat lemah, jadi kami sentiasa perlu mempunyai maklumat tentang cara proses latar belakang berfungsi dalam pangkalan data kami dan sama ada terdapat sebarang masalah daripada kerja mereka.

Apabila kita melihat di pusat pemeriksaan, kita harus ingat bahawa pusat pemeriksaan menyiram halaman kotor dari kawasan memori yang dipecahkan ke cakera, kemudian mencipta pusat pemeriksaan. Dan pusat pemeriksaan ini kemudiannya boleh digunakan sebagai tempat untuk pemulihan jika PostgreSQL tiba-tiba ditamatkan dalam keadaan kecemasan.

Sehubungan itu, untuk mengepam semua halaman "kotor" ke cakera, anda perlu melakukan penulisan tertentu. Dan, sebagai peraturan, pada sistem dengan jumlah memori yang besar, ini banyak. Dan jika kita melakukan pemeriksaan dengan kerap dalam selang masa yang singkat, prestasi cakera akan menurun dengan ketara. Dan permintaan pelanggan akan mengalami kekurangan sumber. Mereka akan bersaing untuk mendapatkan sumber dan kekurangan produktiviti.

Sehubungan itu, melalui pg_stat_bgwriter menggunakan medan yang ditentukan kita boleh memantau bilangan pusat pemeriksaan yang berlaku. Dan jika kita mempunyai banyak pusat pemeriksaan dalam tempoh masa tertentu (dalam 10-15-20 minit, dalam setengah jam), sebagai contoh, 3-4-5, maka ini sudah boleh menjadi masalah. Dan anda sudah perlu melihat dalam pangkalan data, lihat dalam konfigurasi, apa yang menyebabkan banyaknya pusat pemeriksaan. Mungkin ada beberapa jenis rakaman besar sedang berlaku. Kami sudah boleh menilai beban kerja, kerana kami telah menambah graf beban kerja. Kami sudah boleh mengubah suai parameter pusat pemeriksaan dan memastikan ia tidak menjejaskan prestasi pertanyaan.

Saya kembali ke autovakum sekali lagi kerana perkara sedemikian, seperti yang saya katakan, yang boleh menambah prestasi cakera dan pertanyaan dengan mudah, jadi sentiasa penting untuk menganggarkan jumlah autovakum.

Bilangan pekerja autovakum dalam pangkalan data adalah terhad. Secara lalai, terdapat tiga daripada mereka, jadi jika kami sentiasa mempunyai tiga pekerja yang bekerja dalam pangkalan data, ini bermakna autovakum kami tidak dikonfigurasikan, kami perlu meningkatkan had, menyemak tetapan autovakum dan masuk ke konfigurasi.
Adalah penting untuk menilai pekerja vakum yang kita ada. Sama ada ia dilancarkan daripada pengguna, DBA datang dan melancarkan beberapa jenis vakum secara manual, dan ini menghasilkan beban. Kami mempunyai beberapa jenis masalah. Atau ini ialah bilangan vakum yang membuka skru kaunter transaksi. Untuk sesetengah versi PostgreSQL ini adalah vakum yang sangat berat. Dan mereka boleh menambah prestasi dengan mudah kerana mereka membaca keseluruhan jadual, mengimbas semua blok dalam jadual itu.

Dan, sudah tentu, tempoh vakum. Jika kita mempunyai vakum tahan lama yang berjalan untuk masa yang sangat lama, maka ini bermakna kita sekali lagi perlu memberi perhatian kepada konfigurasi vakum dan mungkin mempertimbangkan semula tetapannya. Kerana situasi mungkin timbul apabila vakum berfungsi di atas meja untuk masa yang lama (3-4 jam), tetapi semasa vakum berfungsi, sejumlah besar baris mati berjaya terkumpul di dalam jadual semula. Dan sebaik sahaja vakum selesai, dia perlu mengosongkan meja ini semula. Dan kita datang ke satu situasi - vakum yang tidak berkesudahan. Dan dalam kes ini, vakum tidak melakukan tugasnya, dan jadual secara beransur-ansur mula membengkak dalam saiz, walaupun jumlah data berguna di dalamnya tetap sama. Oleh itu, semasa vakum yang panjang, kami sentiasa melihat konfigurasi dan cuba mengoptimumkannya, tetapi pada masa yang sama supaya prestasi permintaan pelanggan tidak terjejas.

Pada masa kini hampir tiada pemasangan PostgreSQL yang tidak mempunyai replikasi penstriman. Replikasi ialah proses memindahkan data daripada induk kepada replika.

Replikasi dalam PostgreSQL dilakukan melalui log transaksi. Wizard menjana log transaksi. Log transaksi bergerak melalui sambungan rangkaian ke replika, dan kemudian ia diterbitkan semula pada replika. Mudah sahaja.

Sehubungan itu, paparan pg_stat_replication digunakan untuk memantau ketinggalan replikasi. Tetapi tidak semuanya mudah dengannya. Dalam versi 10, paparan telah mengalami beberapa perubahan. Pertama, beberapa medan telah dinamakan semula. Dan beberapa medan telah ditambah. Dalam versi 10, medan muncul yang membolehkan anda menganggarkan ketinggalan replikasi dalam beberapa saat. Ia sangat selesa. Sebelum versi 10, adalah mungkin untuk menganggarkan ketinggalan replikasi dalam bait. Pilihan ini kekal dalam versi 10, iaitu anda boleh memilih perkara yang lebih mudah untuk anda - menganggarkan ketinggalan dalam bait atau menganggarkan ketinggalan dalam beberapa saat. Ramai orang melakukan kedua-duanya.

Namun begitu, untuk menilai lag replikasi, anda perlu mengetahui kedudukan log dalam transaksi. Dan kedudukan log transaksi ini betul-betul dalam paparan pg_stat_replication. Secara relatifnya, kita boleh mengambil dua mata dalam log transaksi menggunakan fungsi pg_xlog_location_diff(). Kira delta antara mereka dan dapatkan ketinggalan replikasi dalam bait. Ia sangat mudah dan ringkas.

Dalam versi 10, fungsi ini telah dinamakan semula kepada pg_wal_lsn_diff(). Secara umum, dalam semua fungsi, pandangan dan utiliti di mana perkataan "xlog" muncul, ia digantikan dengan nilai "wal". Ini terpakai kepada kedua-dua pandangan dan fungsi. Ini adalah satu inovasi.

Selain itu, dalam versi 10, baris telah ditambahkan yang secara khusus menunjukkan ketinggalan. Ini ialah lag tulis, lag siram, lag tayang semula. Iaitu, adalah penting untuk memantau perkara-perkara ini. Jika kita melihat bahawa kita mempunyai ketinggalan replikasi, maka kita perlu menyiasat mengapa ia muncul, dari mana ia datang dan membetulkan masalah.

Hampir semuanya teratur dengan metrik sistem. Apabila mana-mana pemantauan bermula, ia bermula dengan metrik sistem. Ini ialah pelupusan pemproses, memori, swap, rangkaian dan cakera. Walau bagaimanapun, banyak parameter tidak ada secara lalai.

Jika semuanya teratur dengan proses kitar semula, maka terdapat masalah dengan kitar semula cakera. Sebagai peraturan, pemaju pemantauan menambah maklumat tentang daya pemprosesan. Ia boleh dalam iop atau bait. Tetapi mereka lupa tentang kependaman dan penggunaan peranti cakera. Ini adalah parameter yang lebih penting yang membolehkan kami menilai sejauh mana cakera kami dimuatkan dan sejauh mana ia perlahan. Jika kita mempunyai kependaman yang tinggi, maka ini bermakna terdapat beberapa masalah dengan cakera. Jika kita mempunyai penggunaan yang tinggi, ini bermakna cakera tidak dapat mengatasinya. Ini adalah ciri yang lebih baik daripada pemprosesan.

Selain itu, statistik ini juga boleh diperoleh daripada sistem fail /proc, seperti yang dilakukan untuk pemproses kitar semula. Saya tidak tahu mengapa maklumat ini tidak ditambahkan pada pemantauan. Namun begitu, adalah penting untuk mempunyai ini dalam pemantauan anda.

Perkara yang sama berlaku untuk antara muka rangkaian. Terdapat maklumat tentang pemprosesan rangkaian dalam paket, dalam bait, tetapi bagaimanapun tiada maklumat tentang kependaman dan tiada maklumat tentang penggunaan, walaupun ini juga merupakan maklumat yang berguna.

Sebarang pemantauan mempunyai kelemahan. Dan tidak kira apa jenis pemantauan yang anda ambil, ia akan sentiasa tidak memenuhi beberapa kriteria. Namun begitu, mereka sedang membangun, ciri baharu dan perkara baharu sedang ditambah, jadi pilih sesuatu dan selesaikannya.

Dan untuk menyelesaikannya, anda mesti sentiasa mempunyai idea tentang maksud statistik yang disediakan dan bagaimana anda boleh menggunakannya untuk menyelesaikan masalah.

Dan beberapa perkara penting:

• Anda harus sentiasa memantau ketersediaan dan mempunyai papan pemuka supaya anda boleh menilai dengan cepat bahawa semuanya teratur dengan pangkalan data.
• Anda sentiasa perlu mempunyai idea tentang apa yang pelanggan bekerja dengan pangkalan data anda untuk menyingkirkan pelanggan yang buruk dan menembak mereka.
• Adalah penting untuk menilai cara pelanggan ini berfungsi dengan data. Anda perlu mempunyai idea tentang beban kerja anda.
• Adalah penting untuk menilai bagaimana beban kerja ini dibentuk, dengan bantuan pertanyaan apa. Anda boleh menilai pertanyaan, anda boleh mengoptimumkannya, memfaktorkannya semula, membina indeks untuknya. Ianya sangat penting.
• Proses latar belakang boleh memberi kesan negatif kepada permintaan pelanggan, jadi penting untuk memantau bahawa mereka tidak menggunakan terlalu banyak sumber.
• Metrik sistem membolehkan anda membuat rancangan untuk menskala dan meningkatkan kapasiti pelayan anda, jadi adalah penting untuk menjejak dan menilai mereka juga.

Jika anda berminat dengan topik ini, maka anda boleh mengikuti pautan ini.
http://bit.do/stats_collector - ini adalah dokumentasi rasmi daripada pengumpul statistik. Terdapat perihalan semua pandangan statistik dan penerangan semua medan. Anda boleh membaca, memahami dan menganalisisnya. Dan berdasarkannya, bina graf anda dan tambahkannya pada pemantauan anda.

Contoh permintaan:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Ini adalah repositori korporat kami dan milik saya. Ia mengandungi contoh pertanyaan. Tiada pertanyaan daripada siri pilih* daripada di sana. Terdapat pertanyaan siap sedia dengan gabungan, menggunakan fungsi menarik yang membolehkan anda menukar nombor mentah kepada nilai mudah dibaca dan mudah, iaitu ini adalah bait, masa. Anda boleh mengambilnya, melihatnya, menganalisisnya, menambahnya pada pemantauan anda, membina pemantauan anda berdasarkannya.

soalan

Soalan: Anda mengatakan bahawa anda tidak akan mengiklankan jenama, tetapi saya masih ingin tahu - apakah jenis papan pemuka yang anda gunakan dalam projek anda?
Jawapan: Ia berbeza-beza. Kebetulan kami datang kepada pelanggan dan dia sudah mempunyai pemantauan sendiri. Dan kami menasihati pelanggan tentang perkara yang perlu ditambah pada pemantauan mereka. Keadaan yang paling teruk ialah dengan Zabbix. Kerana ia tidak mempunyai keupayaan untuk membina graf TopN. Kita sendiri guna Okmeter, kerana kami sedang berunding dengan mereka tentang pemantauan. Mereka memantau PostgreSQL berdasarkan spesifikasi teknikal kami. Saya sedang menulis projek haiwan kesayangan saya sendiri, yang mengumpul data melalui Prometheus dan menjadikannya masuk grafana. Tugas saya ialah mencipta pengeksport saya sendiri di Prometheus dan kemudian membuat semuanya dalam Grafana.

Soalan: Adakah terdapat sebarang analog laporan AWR atau... pengagregatan? Adakah anda tahu tentang perkara seperti ini?
Jawapan: Ya, saya tahu apa itu AWR, ia adalah perkara yang menarik. Pada masa ini terdapat pelbagai basikal yang melaksanakan kira-kira model berikut. Pada selang masa tertentu, beberapa garis dasar ditulis ke PostgreSQL yang sama atau ke storan berasingan. Anda boleh google mereka di Internet, mereka ada. Salah satu pembangun perkara sedemikian sedang duduk di forum sql.ru dalam benang PostgreSQL. Anda boleh menangkapnya di sana. Ya, ada perkara sedemikian, ia boleh digunakan. Tambahan pula di dalamnya pgCenter Saya juga sedang menulis perkara yang membolehkan anda melakukan perkara yang sama.

PS1 Jika anda menggunakan postgres_exporter, papan pemuka apa yang anda gunakan? Terdapat beberapa daripada mereka. Mereka sudah ketinggalan zaman. Mungkin komuniti akan membuat templat yang dikemas kini?

PS2 Dikeluarkan pganalyze kerana ia merupakan tawaran SaaS proprietari yang memfokuskan pada pemantauan prestasi dan cadangan penalaan automatik.

Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. Log masuk, Sama-sama.

Pemantauan postgresql hos sendiri yang manakah (dengan papan pemuka) yang anda anggap terbaik?

• 30,0% Zabbix + tambahan daripada Alexey Lesovsky atau zabbix 4.4 atau libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0% https://github.com/lesovsky/pgcenter0

• 0,0% https://github.com/pg-monz/pg_monz0

• 20,0% https://github.com/cybertec-postgresql/pgwatch22

• 20,0% https://github.com/postgrespro/mamonsu2

• 0,0% https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0% pganalyze ialah SaaS proprietari - saya tidak boleh memadamkannya1

• 10,0% https://github.com/powa-team/powa1

• 0,0% https://github.com/darold/pgbadger0

• 0,0% https://github.com/darold/pgcluu0

• 0,0% https://github.com/zalando/PGObserver0

• 10,0% https://github.com/spotify/postgresql-metrics1

10 pengguna mengundi. 26 pengguna berpantang.

Sumber: www.habr.com