Dasar ngawasi PostgreSQL. Alexey Lesovsky

Aku saranake sampeyan maca transkrip laporan dening Alexey Lesovsky saka Data Egret "Dasar-dasar pemantauan PostgreSQL"

Ing laporan iki, Alexey Lesovsky bakal ngomong babagan titik-titik kunci statistik pasca-gress, apa tegese, lan ngapa kudu ana ing pemantauan; bab apa grafik kudu ing ngawasi, carane nambah lan carane kokwaca wong. Laporan kasebut bakal migunani kanggo pangurus basis data, pangurus sistem lan pangembang sing kasengsem ing ngatasi masalah Postgres.

Jenengku Alexey Lesovsky, aku makili perusahaan Data Egret.

A sawetara tembung bab aku. Aku wiwit suwe dadi administrator sistem.

Aku ngatur kabeh macem-macem sistem Linux, nggarap macem-macem perkara sing ana gandhengane karo Linux, yaiku virtualisasi, ngawasi, nggarap proxy, lan liya-liyane. Aku pancene disenengi wong. Lan ing sawetara wektu aku wiwit nggarap PostgreSQL paling akeh wektu kerja. Lan mboko sithik aku dadi PostgreSQL DBA.

Lan sajrone karirku, aku tansah kasengsem ing topik statistik, pemantauan, lan telemetri. Lan nalika aku dadi administrator sistem, aku kerja banget karo Zabbix. Lan aku nulis pesawat cilik script kaya zabbix-ekstensi. Dheweke cukup populer ing jamane. Lan ing kana bisa ngawasi perkara-perkara penting sing beda banget, ora mung Linux, nanging uga macem-macem komponen.

Saiki aku nggarap PostgreSQL. Aku wis nulis bab liyane sing ngidini sampeyan nggarap statistik PostgreSQL. Iku diarani pgCenter (artikel Habré- Statistik post-gress tanpa saraf lan ketegangan).

Cathetan pambuka sethitik. Apa kahanan sing ditindakake para pelanggan, klien kita? Ana sawetara jinis kacilakan sing ana gandhengane karo database. Lan nalika basis data wis dibalekake, kepala departemen utawa kepala pangembangan teka lan ujar: "Kanca-kanca, kita kudu ngawasi database kasebut, amarga ana kedadeyan sing ala lan kita kudu nyegah kedadeyan kasebut ing mangsa ngarep." Lan ing kene diwiwiti proses sing menarik kanggo milih sistem pemantauan utawa adaptasi sistem pemantauan sing wis ana supaya sampeyan bisa ngawasi database - PostgreSQL, MySQL utawa sawetara liyane. Lan kanca-kanca wiwit menehi saran: "Aku krungu manawa ana database kasebut. Ayo nganggo." Kolega wiwit mbantah karo saben liyane. Lan ing pungkasan dadi metu sing kita milih sawetara jenis database, nanging ngawasi PostgreSQL presented ing rodo kurang lan kita tansah kudu nambah soko. Njupuk sawetara repositori saka GitHub, kloning, adaptasi skrip, lan kepiye carane ngatur. Lan ing pungkasan iku dadi sawetara jinis karya manual.

Mulane, ing pirembagan iki aku bakal nyoba kanggo menehi sawetara kawruh babagan carane milih ngawasi ora mung kanggo PostgreSQL, nanging uga kanggo database. Lan menehi kawruh sing bakal ngidini sampeyan ngrampungake pemantauan supaya entuk manfaat, supaya sampeyan bisa ngawasi basis data kanthi entuk manfaat, supaya bisa nyegah kahanan darurat sing bakal teka.

Lan gagasan sing bakal ana ing laporan iki bisa langsung diadaptasi menyang database apa wae, dadi DBMS utawa noSQL. Mulane, ora mung PostgreSQL, nanging bakal ana akeh resep babagan carane nindakake iki ing PostgreSQL. Bakal ana conto pitakon, conto entitas sing diduweni PostgreSQL kanggo ngawasi. Lan yen DBMS sampeyan duwe perkara sing padha sing ngidini sampeyan ngawasi, sampeyan uga bisa ngganti, nambah lan bakal apik.

Aku ora bakal ana ing laporan
ngomong babagan cara ngirim lan nyimpen metrik. Aku ora bakal ngomong apa-apa babagan post-processing data lan nampilake menyang pangguna. Lan aku ora bakal ngomong apa-apa bab alerting.
Nanging nalika crita maju, aku bakal nuduhake macem-macem gambar pemantauan sing wis ana lan ngritik. Nanging, aku bakal nyoba ora menehi jeneng merek supaya ora nggawe iklan utawa anti-iklan kanggo produk kasebut. Mulane, kabeh kebetulan iku acak lan ditinggalake ing imajinasi sampeyan.

Pisanan, ayo ngerteni apa pemantauan kasebut. Ngawasi iku penting banget kanggo duwe. Kabeh wong ngerti iki. Nanging ing wektu sing padha, ngawasi ora ana hubungane karo produk bisnis lan ora langsung mengaruhi keuntungan perusahaan, saengga wektu tansah dialokasikan kanggo ngawasi kanthi basis residual. Yen kita duwe wektu, banjur kita ngawasi; yen kita ora duwe wektu, banjur OK, kita bakal nyelehake ing backlog lan ing sawijining dina kita bakal bali menyang tugas kasebut.

Mulane, saka praktik kita, nalika kita teka menyang klien, ngawasi asring ora lengkap lan ora ana perkara sing menarik sing bakal mbantu kita nindakake tugas sing luwih apik karo database. Lan mulane ngawasi tansah kudu rampung.

Basis data minangka perkara rumit sing uga kudu dipantau, amarga basis data minangka gudang informasi. Lan informasi penting banget kanggo perusahaan; ora bisa ilang kanthi cara apa wae. Nanging ing wektu sing padha, database minangka piranti lunak sing rumit banget. Padha kalebu nomer akeh komponen. Lan akeh komponen kasebut kudu dipantau.

Yen kita ngomong khusus babagan PostgreSQL, mula bisa diwakili ing wangun skema sing kasusun saka akeh komponen. Komponen kasebut saling sesambungan. Lan ing wektu sing padha, PostgreSQL duwe subsistem Stats Collector, sing ngidini sampeyan ngumpulake statistik babagan operasi subsistem kasebut lan menehi sawetara jinis antarmuka menyang administrator utawa pangguna supaya bisa ndeleng statistik kasebut.

Statistik kasebut ditampilake ing wangun fungsi lan tampilan tartamtu. Padha uga bisa disebut tabel. Sing, nggunakake klien psql biasa, sampeyan bisa nyambung menyang database, nggawe pilih ing fungsi lan views iki, lan njaluk sawetara nomer tartamtu bab operasi saka subsistem PostgreSQL.

Sampeyan bisa nambah nomer kasebut menyang sistem pemantauan favorit, nggambar grafik, nambah fungsi lan entuk analytics ing jangka panjang.

Nanging ing laporan iki aku ora bakal nutupi kabeh fungsi iki rampung, amarga bisa njupuk sedina muput. Aku bakal ngandhani loro, telu utawa patang perkara lan pitutur marang kowe carane mbantu ngawasi luwih apik.

Lan yen kita ngomong babagan pemantauan database, banjur apa sing kudu dipantau? Kaping pisanan, kita kudu ngawasi kasedhiyan, amarga database minangka layanan sing nyedhiyakake akses menyang data menyang klien lan kita kudu ngawasi kasedhiyan, lan uga nyedhiyakake sawetara karakteristik kualitatif lan kuantitatif.

Kita uga kudu ngawasi klien sing nyambung menyang basis data, amarga bisa dadi klien normal lan klien mbebayani sing bisa ngrusak database. Dheweke uga kudu dipantau lan dilacak kegiatane.

Nalika klien nyambung menyang database, iku ketok sing padha wiwiti nggarap data kita, supaya kita kudu ngawasi carane klien bisa karo data: karo kang tabel, lan kanggo ombone rodok kurang, karo kang indeks. Yaiku, kita kudu ngevaluasi beban kerja sing digawe dening klien kita.

Nanging beban kerja uga kalebu, mesthi, panjaluk. Aplikasi nyambung menyang basis data, ngakses data nggunakake pitakon, mula penting kanggo ngevaluasi pitakon apa sing ana ing database, ngawasi kecukupan, ora ditulis kanthi bengkong, sawetara pilihan kudu ditulis maneh lan digawe supaya bisa luwih cepet. lan kanthi kinerja sing luwih apik.

Lan wiwit kita ngomong bab database, database tansah pangolahan latar mburi. Proses latar mburi mbantu njaga kinerja database ing tingkat sing apik, mula mbutuhake sumber daya tartamtu supaya bisa digunakake. Lan ing wektu sing padha, bisa tumpang tindih karo sumber panyuwunan klien, mula proses latar mburi sing rakus bisa langsung mengaruhi kinerja panjaluk klien. Mulane, dheweke uga kudu dipantau lan dilacak supaya ora ana distorsi babagan proses latar mburi.

Lan kabeh iki babagan pemantauan database tetep ana ing metrik sistem. Nanging ngelingi umume infrastruktur kita pindhah menyang awan, metrik sistem host individu tansah sirna ing latar mburi. Nanging ing basis data isih relevan lan, mesthi, uga perlu kanggo ngawasi metrik sistem.

Kabeh luwih utawa kurang apik karo metrik sistem, kabeh sistem pemantauan modern wis ndhukung metrik kasebut, nanging umume, sawetara komponen isih ora cukup lan sawetara perkara sing kudu ditambahake. Aku uga bakal ndemek wong-wong mau, bakal ana sawetara slide babagan dheweke.

Titik pisanan saka rencana kasebut yaiku aksesibilitas. Apa aksesibilitas? Kasedhiyan ing pangertenku yaiku kemampuan basis kanggo layanan sambungan, yaiku basis diunggahake, minangka layanan, nampa sambungan saka klien. Lan aksesibilitas iki bisa ditaksir kanthi karakteristik tartamtu. Iku trep banget kanggo nampilake ciri kasebut ing dashboard.

Saben uwong ngerti apa dashboard. Iki nalika sampeyan ndeleng layar ing ngendi informasi sing dibutuhake diringkes. Lan sampeyan bisa langsung nemtokake manawa ana masalah ing database utawa ora.
Patut, kasedhiyan database lan ciri utama liyane kudu tansah ditampilake ing dashboards supaya informasi iki ing tangan lan tansah kasedhiya kanggo sampeyan. Sawetara rincian tambahan sing wis mbantu investigasi kedadeyan, nalika nyelidiki sawetara kahanan darurat, dheweke kudu diselehake ing dashboard sekunder, utawa didhelikake ing link drilldown sing ndadékaké sistem pemantauan pihak katelu.

Conto siji sistem pemantauan sing kondhang. Iki minangka sistem pemantauan sing apik banget. Dheweke ngumpulake akeh data, nanging saka sudut pandangku, dheweke duwe konsep dashboard sing aneh. Ana link kanggo "nggawe dashboard". Nanging nalika sampeyan nggawe dashboard, sampeyan nggawe dhaptar rong kolom, dhaptar grafik. Lan nalika sampeyan kudu ndeleng soko, sampeyan miwiti ngeklik mouse, nggulung, looking for grafik sing dikarepake. Lan iki mbutuhake wektu, yaiku ora ana dasbor kaya ngono. Ana mung dhaptar denah.

Apa sing kudu ditambahake ing dashboard kasebut? Sampeyan bisa miwiti kanthi karakteristik kaya wektu nanggepi. PostgreSQL nduweni tampilan pg_stat_statements. Dipateni minangka standar, nanging minangka salah sawijining tampilan sistem penting sing kudu diaktifake lan digunakake. Iki nyimpen informasi babagan kabeh pitakon sing wis ditindakake ing basis data.

Patut, kita bisa miwiti saka kasunyatan sing kita bisa njupuk total wektu eksekusi kabeh panjalukan lan dibagi dening nomer panjalukan nggunakake kothak ndhuwur. Nanging iki suhu rata-rata ing rumah sakit. Kita bisa miwiti saka lapangan liyane - wektu eksekusi query minimal, maksimum lan median. Lan kita malah bisa mbangun persentil; PostgreSQL nduweni fungsi sing cocog kanggo iki. Lan kita bisa entuk sawetara nomer sing menehi ciri wektu nanggepi database kita kanggo panjalukan sing wis rampung, yaiku kita ora nglakokake panjalukan 'pilih 1' palsu lan ndeleng wektu respon, nanging kita nganalisa wektu respon kanggo panjalukan sing wis rampung lan tarik. salah siji tokoh kapisah, utawa kita mbangun graph adhedhasar iku.

Sampeyan uga penting kanggo ngawasi jumlah kesalahan sing saiki digawe dening sistem. Lan kanggo iki sampeyan bisa nggunakake tampilan pg_stat_database. Kita fokus ing lapangan xact_rollback. Lapangan iki nuduhake ora mung nomer rollbacks sing dumadi ing database, nanging uga njupuk menyang akun nomer kasalahan. Relatif ngandika, kita bisa nampilake tokoh iki ing dashboard kita lan ndeleng carane akeh kasalahan kita saiki. Yen ana akeh kesalahan, mula iki minangka alesan sing apik kanggo ndeleng log lan ndeleng apa kesalahane lan kenapa kedadeyan kasebut, banjur nandur modal lan ngrampungake.

Sampeyan bisa nambah kaya Tachometer. Iki minangka jumlah transaksi per detik lan jumlah panjaluk saben detik. Relatif ngandika, sampeyan bisa nggunakake nomer iki minangka kinerja saiki database lan mirsani apa ana puncak ing panjalukan, puncak ing transaksi, utawa, Kosok baline, apa database underloaded amarga sawetara backend wis tiba mati. Penting kanggo ndeleng tokoh iki lan elinga yen kanggo proyek kita, kinerja kaya iki normal, nanging nilai ing ndhuwur lan ing ngisor iki wis ana sawetara masalah lan ora bisa dingerteni, tegese kita kudu ndeleng kenapa nomer kasebut ana. dhuwur banget.

Kanggo ngira jumlah transaksi, kita bisa ndeleng maneh pg_stat_database tampilan. Kita bisa nambah jumlah commit lan jumlah rollbacks lan entuk jumlah transaksi per detik.

Apa saben wong ngerti manawa sawetara panjaluk bisa cocog karo siji transaksi? Mulane TPS lan QPS rada beda.

Jumlah panjalukan per detik bisa dipikolehi saka pg_stat_statements lan mung ngetung jumlah kabeh panjalukan sing wis rampung. Cetha yen kita mbandhingake nilai saiki karo sing sadurunge, nyuda, entuk delta, lan entuk jumlahe.

Sampeyan bisa nambah metrik tambahan yen dikarepake, sing uga mbantu ngevaluasi kasedhiyan database kita lan ngawasi apa ana downtime.

Salah sawijining metrik kasebut yaiku wektu aktif. Nanging uptime ing PostgreSQL rada angel. Aku bakal ngomong apa. Nalika PostgreSQL wis diwiwiti, uptime wiwit nglaporake. Nanging yen ing sawetara titik, contone, sawetara tugas lagi mlaku ing wayah wengi, OOM-pembunuh teka lan meksa mungkasi proses anak PostgreSQL, banjur ing kasus iki PostgreSQL mungkasi sambungan kabeh klien, ngreset area memori sharded lan miwiti Recovery saka titik mriksa pungkasan. Lan nalika pemulihan iki saka checkpoint tetep, database ora nampa sambungan, yaiku kahanan iki bisa ditaksir minangka downtime. Nanging counter uptime ora bakal direset, amarga njupuk wektu wiwitan postmaster saka wayahe pisanan. Mulane, kahanan kaya mengkono bisa dilewati.

Sampeyan uga kudu ngawasi jumlah buruh vakum. Apa kabeh wong ngerti apa autovacuum ing PostgreSQL? Iki minangka subsistem sing menarik ing PostgreSQL. Akeh artikel sing wis ditulis babagan dheweke, akeh laporan sing digawe. Ana akeh diskusi babagan vakum lan cara kerjane. Akeh sing nganggep minangka ala sing perlu. Nanging kaya ngono. Iki minangka analog saka kolektor sampah sing ngresiki versi lawas saka baris sing ora dibutuhake kanggo transaksi apa wae lan mbebasake ruang ing tabel lan indeks kanggo baris anyar.

Napa sampeyan kudu ngawasi? Amarga vakum kadhangkala lara banget. Iku nganggo jumlah gedhe saka sumber daya lan panjalukan klien wiwit nandhang sangsara minangka asil.

Lan kudu dipantau liwat tampilan pg_stat_activity, sing bakal dakkandhakake ing bagean sabanjure. Tampilan iki nuduhake aktivitas saiki ing database. Lan liwat kegiatan iki kita bisa nglacak jumlah vakum sing digunakake saiki. Kita bisa nglacak vakum lan ndeleng manawa kita wis ngluwihi watesan, mula iki minangka alesan kanggo ndeleng setelan PostgreSQL lan ngoptimalake operasi vakum.

Bab liyane babagan PostgreSQL yaiku PostgreSQL lara banget amarga transaksi dawa. Utamane saka transaksi sing macet nganti suwe lan ora nindakake apa-apa. Iki sing diarani stat idle-in-transaction. Transaksi kasebut ngemu kunci lan nyegah vakum bisa digunakake. Lan minangka asil, tabel swell lan nambah ukuran. Lan pitakon sing bisa digunakake karo tabel iki wiwit kerjane luwih alon, amarga sampeyan kudu shovel kabeh versi lawas saka larik saka memori kanggo disk lan mburi. Mulane, wektu, durasi transaksi paling dawa, panjalukan vakum paling dawa uga kudu dipantau. Lan yen kita ndeleng sawetara proses sing wis suwe banget, wis luwih saka 10-20-30 menit kanggo mbukak OLTP, mula kita kudu nggatekake lan mungkasi kanthi kuat, utawa ngoptimalake aplikasi kasebut supaya bisa ditindakake. ora disebut lan ora nyumerepi supaya dawa. Kanggo beban kerja analitis, 10-20-30 menit normal, ana uga sing luwih dawa.

Sabanjure kita duwe pilihan karo klien sing disambungake. Nalika kita wis nggawe dashboard lan dikirim metrik kasedhiyan tombol ing, kita uga bisa nambah informasi tambahan babagan klien disambungake ana.

Informasi babagan klien sing disambungake penting amarga, saka perspektif PostgreSQL, klien beda. Ana klien apik lan ana klien ala.

Conto prasaja. Miturut klien aku ngerti aplikasi kasebut. Aplikasi wis disambungake menyang database lan langsung wiwit ngirim panjalukan ing kana, database ngolah lan nglakokaké, lan ngasilake asil kanggo klien. Iki minangka klien sing apik lan bener.

Ana kahanan nalika klien wis disambungake, terus sambungan, nanging ora nindakake apa-apa. Iku ing negara nganggur.

Nanging ana klien ala. Contone, klien sing padha disambungake, mbukak transaksi, nindakake apa wae ing database banjur mlebu kode kasebut, contone, kanggo ngakses sumber eksternal utawa ngolah data sing ditampa ing kana. Nanging dheweke ora nutup transaksi kasebut. Lan transaksi macet ing database lan dianakaké ing kunci ing baris. Iki minangka kahanan sing ala. Lan yen dumadakan aplikasi nang endi wae nang endi wae gagal karo pangecualian, banjur transaksi bisa tetep mbukak kanggo dangu. Lan iki langsung mengaruhi kinerja PostgreSQL. PostgreSQL bakal luwih alon. Mulane, penting kanggo nglacak klien kasebut kanthi pas wektune lan kanthi paksa mungkasi pakaryane. Lan sampeyan kudu ngoptimalake aplikasi supaya kahanan kasebut ora kedadeyan.

Klien ala liyane ngenteni klien. Nanging dheweke dadi ala amarga kahanan. Contone, transaksi nganggur prasaja: bisa mbukak transaksi, njupuk kunci ing sawetara baris, banjur nang endi wae ing kode bakal gagal, ninggalake transaksi hanging. Klien liyane bakal teka lan njaluk data sing padha, nanging dheweke bakal nemokake kunci, amarga transaksi gantung kasebut wis ngunci sawetara baris sing dibutuhake. Lan transaksi kapindho bakal mandheg ngenteni transaksi pisanan rampung utawa ditutup kanthi paksa dening administrator. Mulane, transaksi sing ditundha bisa nglumpukake lan ngisi watesan sambungan database. Lan nalika watesan kebak, aplikasi ora bisa digunakake maneh karo database. Iki wis dadi kahanan darurat kanggo proyek kasebut. Mulane, klien sing ala kudu dilacak lan ditanggapi kanthi pas wektune.

Conto liyane saka ngawasi. Lan wis ana dashboard prayoga kene. Ana informasi babagan sambungan ing ndhuwur. sambungan DB - 8 bêsik. Lan iku kabeh. Kita ora duwe informasi babagan klien sing aktif, klien sing mung nganggur, ora nindakake apa-apa. Ora ana informasi babagan transaksi sing ditundha lan sambungan sing ditundha, yaiku iki minangka tokoh sing nuduhake jumlah sambungan lan mung. Banjur guess dhewe.

Mulane, kanggo nambah informasi iki kanggo ngawasi, sampeyan kudu ngakses pg_stat_activity tampilan sistem. Yen sampeyan nglampahi akeh wektu ing PostgreSQL, iki minangka tampilan sing apik banget sing kudu dadi kanca, amarga nuduhake kegiatan saiki ing PostgreSQL, yaiku apa sing kedadeyan. Kanggo saben proses, ana baris kapisah sing nuduhake informasi babagan proses iki: saka ngendi host sambungan digawe, ing pangguna apa, miturut jeneng apa, nalika transaksi diwiwiti, panjaluk apa sing lagi ditindakake, panjaluk apa sing pungkasan ditindakake. Lan, miturut, kita bisa ngevaluasi negara klien nggunakake kolom stat. Relatif ngandika, kita bisa klompok dening lapangan iki lan njaluk sing stats sing saiki ing database lan nomer sambungan sing duwe stat iki ing database. Lan kita bisa ngirim nomer sing wis ditampa menyang pemantauan lan nggambar grafik adhedhasar.
Sampeyan uga penting kanggo ngevaluasi durasi transaksi. Aku wis ngomong yen penting kanggo ngevaluasi durasi vakum, nanging transaksi dievaluasi kanthi cara sing padha. Ana kolom xact_start lan query_start. Dheweke, kanthi relatif, nuduhake wektu wiwitan transaksi lan wektu wiwitan panyuwunan. We njupuk saiki () fungsi, kang nuduhake timestamp saiki, lan nyuda transaksi lan nyuwun timestamp. Lan kita entuk durasi transaksi, durasi panyuwunan.

Yen kita ndeleng transaksi dawa, kita kudu ngrampungake. Kanggo beban OLTP, transaksi dawa wis luwih saka 1-2-3 menit. Kanggo beban kerja OLAP, transaksi dawa iku normal, nanging yen luwih saka rong jam rampung, iki uga minangka tandha yen kita duwe skew nang endi wae.

Sawise klien wis nyambung menyang database, padha miwiti nggarap data kita. Dheweke ngakses tabel, ngakses indeks kanggo entuk data saka tabel. Lan penting kanggo ngevaluasi carane klien sesambungan karo data iki.

Iki perlu kanggo ngevaluasi beban kerja lan kira-kira ngerti tabel sing "paling monjo" kanggo kita. Contone, iki perlu ing kahanan ngendi kita arep kanggo nyeleh "panas" tabel ing sawetara jinis panyimpenan SSD cepet. Contone, sawetara tabel arsip sing wis ora digunakake kanggo dangu bisa dipindhah menyang sawetara jenis "kadhemen" arsip, kanggo SATA drive lan supaya wong-wong mau manggon ana, padha bakal diakses minangka needed.

Iki uga migunani kanggo ndeteksi anomali sawise ana rilis lan penyebaran. Ayo dadi proyèk wis ngrilis sawetara fitur anyar. Contone, kita nambah fungsi anyar kanggo nggarap database. Lan yen kita ngrancang grafik panggunaan tabel, kita bisa kanthi gampang ndeteksi anomali kasebut ing grafik kasebut. Contone, nganyari bursts utawa mbusak bursts. Iku bakal katon banget.

Sampeyan uga bisa ndeteksi anomali ing statistik "ngambang". Iki artine apa? PostgreSQL nduweni perencana pitakon sing kuwat lan apik banget. Lan pangembang nyedhiyakake akeh wektu kanggo pangembangane. Piye cara kerjane? Kanggo nggawe rencana sing apik, PostgreSQL nglumpukake statistik babagan distribusi data ing tabel ing interval wektu tartamtu lan frekuensi tartamtu. Iki minangka nilai sing paling umum: jumlah nilai unik, informasi babagan NULL ing tabel, akeh informasi.

Adhedhasar statistik kasebut, planner nggawe sawetara pitakon, milih sing paling optimal, lan nggunakake rencana pitakon iki kanggo nglakokake pitakon kasebut lan ngasilake data.

Lan kedadeyan yen statistik "ngambang". Kualitas lan jumlah data piye wae diganti ing tabel, nanging statistik ora diklumpukake. Lan rencana sing dibentuk bisa uga ora optimal. Lan yen rencana kita dadi suboptimal adhedhasar pemantauan sing diklumpukake, adhedhasar tabel, kita bakal bisa ndeleng anomali kasebut. Contone, nang endi wae data diganti qualitatively lan tinimbang indeks, pass urutan liwat meja wiwit digunakake, i.e. yen pitakon mung kudu ngasilake 100 larik (ana watesan 100), banjur telusuran lengkap bakal ditindakake kanggo pitakon iki. Lan iki tansah duwe efek ala banget ing kinerja.

Lan kita bisa ndeleng iki ing ngawasi. Lan wis katon ing pitakonan iki, mbukak nerangake kanggo iku, ngumpulake statistik, mbangun indeks tambahan anyar. Lan wis nanggapi masalah iki. Mulane iku penting.

Conto liyane saka ngawasi. Aku mikir akeh wong sing ngerti dheweke amarga dheweke misuwur banget. Sapa sing nggunakake ing proyeke Prometheus? Sapa sing nggunakake produk iki bebarengan karo Prometheus? Kasunyatane yaiku ing repositori standar pemantauan iki ana dashboard kanggo nggarap PostgreSQL - postgres_exporter Prometheus. Nanging ana siji rincian ala.

Ana sawetara grafik. Lan bita dituduhake minangka kesatuan, yaiku ana 5 grafik. Iki minangka Lebokake data, Nganyari data, Busak data, Njupuk data lan Mbalekake data. Pangukuran unit yaiku bita. Nanging bab iku statistik ing PostgreSQL ngasilake data ing tuple (baris). Lan, kanthi mangkono, grafik kasebut minangka cara sing apik banget kanggo ngremehake beban kerja sampeyan kaping pirang-pirang, kaping pirang-pirang, amarga tuple dudu bait, tuple minangka senar, akeh bita lan dawane variabel. Tegese, ngitung beban kerja ing bait nggunakake tuple minangka tugas sing ora nyata utawa angel banget. Mulane, nalika sampeyan nggunakake dashboard utawa ngawasi dibangun ing, iku tansah penting kanggo ngerti sing bisa digunakake kanthi bener lan ngasilake data sing ditaksir kanthi bener.

Kepiye carane entuk statistik ing tabel kasebut? Kanggo tujuan iki, PostgreSQL duwe kulawarga tampilan tartamtu. Lan tampilan utama yaiku pg_stat_user_tables. User_tables tegese tabel digawe atas jenenge pangguna. Ing kontras, ana tampilan sistem sing digunakake dening PostgreSQL dhewe. Lan ana tabel ringkesan Alltables, sing kalebu sistem lan pangguna. Sampeyan bisa miwiti saka apa wae sing paling disenengi.

Nggunakake kolom ing ndhuwur sampeyan bisa ngira jumlah sisipan, nganyari lan mbusak. Conto dashboard sing digunakake nggunakake kolom kasebut kanggo ngevaluasi karakteristik beban kerja. Mulane, kita uga bisa mbangun ing wong-wong mau. Nanging iku worth ngelengke sing iki tuples, ora bita, supaya kita ora bisa mung nindakake ing bita.

Adhedhasar data kasebut, kita bisa nggawe tabel TopN. Contone, Top-5, Top-10. Lan sampeyan bisa nglacak tabel panas sing didaur ulang luwih akeh tinimbang liyane. Contone, 5 "panas" tabel kanggo selipan. Lan nggunakake tabel TopN iki, kita ngevaluasi beban kerja lan bisa ngevaluasi beban kerja sawise ana rilis, nganyari, lan penyebaran.

Sampeyan uga penting kanggo ngira-ngira ukuran meja, amarga kadhangkala pangembang muter metu fitur anyar, lan tabel kita wiwiti swell ing ukuran gedhe, amarga padha mutusaké kanggo nambah jumlah data tambahan, nanging ora prédhiksi carane iki bakal. mengaruhi ukuran database. Kasus kaya mengkono uga dadi kejutan kanggo kita.

Lan saiki pitakonan cilik kanggo sampeyan. Pitakonan apa sing muncul nalika sampeyan ngerteni beban ing server database sampeyan? Apa pitakonan sabanjure sampeyan?

Nanging nyatane pitakonan kasebut muncul kaya ing ngisor iki. Panjaluk apa sing nyebabake beban? Tegese, ora menarik kanggo ndeleng proses sing disebabake dening beban. Cetha yen host duwe basis data, mula database kasebut mlaku ing kana lan jelas yen mung database sing bakal dibuwang ing kana. Yen kita mbukak Ndhuwur, kita bakal weruh ana dhaptar pangolahan ing PostgreSQL sing nindakake soko. Ora bakal jelas saka Top apa sing ditindakake.

Mulane, sampeyan kudu nemokake pitakon sing nyebabake beban paling dhuwur, amarga pitakon tuning, minangka aturan, menehi bathi luwih akeh tinimbang nyetel konfigurasi PostgreSQL utawa sistem operasi, utawa malah nyetel hardware. Miturut perkiraanku, iki kira-kira 80-85-90%. Lan iki rampung luwih cepet. Luwih cepet mbenerake panjalukan tinimbang mbenerake konfigurasi, gawe jadwal restart, utamane yen database ora bisa diwiwiti maneh, utawa nambah hardware. Luwih gampang nulis ulang pitakon ing endi wae utawa nambah indeks kanggo entuk asil sing luwih apik saka pitakon iki.

Mulane, perlu kanggo ngawasi panjalukan lan kecukupan. Ayo njupuk conto liyane saka ngawasi. Lan ing kene uga katon ana pemantauan sing apik banget. Ana informasi babagan replikasi, ana informasi babagan throughput, pamblokiran, panggunaan sumber daya. Kabeh apik, nanging ora ana informasi babagan panjaluk. Ora jelas pitakon apa sing ditindakake ing basis data kita, suwene wektu mlaku, pira pitakon kasebut. Kita kudu tansah duwe informasi iki ing pemantauan kita.

Lan kanggo entuk informasi iki, kita bisa nggunakake modul pg_stat_statements. Adhedhasar, sampeyan bisa nggawe macem-macem grafik. Contone, sampeyan bisa entuk informasi babagan pitakon sing paling kerep, yaiku, pitakon sing paling asring ditindakake. Ya, sawise panyebaran uga migunani banget kanggo ndeleng lan ngerti yen ana panjaluk sing mundhak.

Sampeyan bisa ngawasi pitakon sing paling dawa, yaiku, pitakon sing paling dawa rampung. Padha mbukak ing prosesor, padha nganggo I / ing. Kita uga bisa ngevaluasi iki nggunakake kolom total_time, mean_time, blk_write_time lan blk_read_time.

Kita bisa ngevaluasi lan ngawasi panjalukan sing paling abot babagan panggunaan sumber daya, sing maca saka disk, sing bisa nganggo memori, utawa, kosok balene, nggawe sawetara jinis beban nulis.

Kita bisa ngevaluasi panjalukan sing paling loman. Iki minangka pitakon sing ngasilake akeh larik. Contone, iki bisa dadi sawetara panyuwunan ing ngendi dheweke kelalen nyetel watesan. Lan mung ngasilake kabeh isi tabel utawa pitakon ing tabel sing ditakoni.

Lan sampeyan uga bisa ngawasi pitakon sing nggunakake file sauntara utawa tabel sementara.

Lan kita isih duwe proses latar mburi. Proses latar mburi utamane minangka checkpoints utawa uga disebut checkpoints, yaiku autovacuum lan replikasi.

Conto liyane saka ngawasi. Ana tab Maintenance ing sisih kiwa, pindhah menyang lan ngarep-arep kanggo ndeleng soko migunani. Nanging ing kene mung wektu operasi vakum lan koleksi statistik, ora liya. Iki minangka informasi sing ora apik, mula kita kudu duwe informasi babagan cara proses latar mburi ing database kita lan apa ana masalah saka karyane.

Nalika kita ndeleng checkpoints, kita kudu elinga yen checkpoints flush kaca reged saka wilayah memori sharded menyang disk, banjur nggawe checkpoint. Lan checkpoint iki banjur bisa digunakake minangka panggonan kanggo Recovery yen PostgreSQL dumadakan mungkasi ing darurat.

Patut, kanggo siram kabeh kaca "reged" menyang disk, sampeyan kudu nindakake jumlah tartamtu saka nulis. Lan, minangka aturan, ing sistem karo jumlah gedhe saka memori, iki akeh. Lan yen kita nindakake checkpoints asring banget ing interval cendhak, kinerja disk bakal mudhun banget Ngartekno. Lan panjaluk klien bakal nandhang kekurangan sumber daya. Dheweke bakal bersaing kanggo sumber daya lan ora duwe produktivitas.

Mulane, liwat pg_stat_bgwriter nggunakake kolom sing ditemtokake, kita bisa ngawasi jumlah checkpoints sing kedadeyan. Lan yen kita duwe akeh checkpoints sajrone wektu tartamtu (ing 10-15-20 menit, ing setengah jam), contone, 3-4-5, banjur iki bisa dadi masalah. Lan sampeyan wis kudu katon ing database, katon ing konfigurasi, apa nimbulaké kuwi turah mbrawah saka checkpoints. Mungkin ana sawetara jinis rekaman gedhe sing ditindakake. Kita wis bisa ngevaluasi beban kerja, amarga kita wis nambah grafik beban kerja. Kita wis bisa ngapiki parameter checkpoint lan priksa manawa ora mengaruhi kinerja pitakon.

Aku bali menyang autovacuum maneh amarga iki, kaya sing dakkandhakake, bisa nambah kinerja disk lan pitakon kanthi gampang, mula penting banget kanggo ngira jumlah autovakum.

Jumlah buruh autovacuum ing database diwatesi. Kanthi gawan, ana telu, dadi yen kita tansah duwe telung buruh sing kerja ing database, iki tegese autovacuum kita ora dikonfigurasi, kita kudu ngunggahake watesan, ngowahi setelan autovacuum lan mlebu konfigurasi.
Penting kanggo ngevaluasi buruh vakum sing kita duwe. Salah siji iki dibukak saka pangguna, teka DBA lan kanthi manual dibukak sawetara jenis vakum, lan iki digawe mbukak. Kita duwe sawetara masalah. Utawa iki nomer vakum sing unscrew counter transaksi. Kanggo sawetara versi PostgreSQL, iki minangka vakum sing abot banget. Lan padha bisa gampang nambah munggah kinerja amarga padha maca kabeh meja, mindai kabeh pamblokiran ing meja sing.

Lan, mesthi, durasi vakum. Yen kita duwe vakum sing tahan suwe, mula iki tegese maneh kudu menehi perhatian marang konfigurasi vakum lan bisa uga nimbang maneh setelan kasebut. Amarga kahanan bisa njedhul nalika vakum dianggo ing meja kanggo dangu (3-4 jam), nanging sak wektu vakum iki digunakake, jumlah gedhe saka larik mati ngatur kanggo nglumpukake ing meja maneh. Lan sanalika vakum wis rampung, dheweke kudu vakum meja iki maneh. Lan kita teka ing kahanan - vakum tanpa wates. Lan ing kasus iki, vakum ora bisa ngrampungake karyane, lan tabel mboko sithik wiwit swell ing ukuran, sanajan volume data migunani ing tetep padha. Mulane, sajrone vakum dawa, kita tansah ndeleng konfigurasi lan nyoba ngoptimalake, nanging ing wektu sing padha supaya kinerja panjalukan klien ora nandhang sangsara.

Saiki ora ana instalasi PostgreSQL sing ora duwe replikasi streaming. Replikasi yaiku proses mindhah data saka master menyang replika.

Replikasi ing PostgreSQL ditindakake liwat log transaksi. Wisaya ngasilake log transaksi. Log transaksi lelungan liwat sambungan jaringan menyang tiron, lan banjur diprodhuksi ing replika. Iku prasaja.

Patut, tampilan pg_stat_replication digunakake kanggo ngawasi lag réplikasi. Nanging ora kabeh prasaja karo dheweke. Ing versi 10, tampilan wis ngalami sawetara owah-owahan. Kaping pisanan, sawetara lapangan wis diganti jeneng. Lan sawetara lapangan wis ditambahake. Ing versi 10, kolom katon sing ngidini sampeyan ngira lag replikasi ing sawetara detik. Iku banget nyaman. Sadurunge versi 10, sampeyan bisa ngira replikasi lag ing bita. Opsi iki tetep ing versi 10, yaiku sampeyan bisa milih sing luwih trep kanggo sampeyan - ngira lag ing bita utawa ngira lag ing sawetara detik. Akeh wong nindakake loro-lorone.

Nanging, kanggo ngevaluasi lag réplikasi, sampeyan kudu ngerti posisi log ing transaksi kasebut. Lan posisi log transaksi iki persis ing tampilan pg_stat_replication. Relatif ngandika, kita bisa njupuk rong titik ing log transaksi nggunakake pg_xlog_location_diff () fungsi. Etung delta ing antarane lan entuk replikasi lag ing bita. Iku banget trep lan prasaja.

Ing versi 10, fungsi iki diganti jeneng pg_wal_lsn_diff (). Umumé, ing kabeh fungsi, tampilan, lan keperluan ing ngendi tembung "xlog" muncul, diganti karo nilai "wal". Iki ditrapake kanggo tampilan lan fungsi. Iki minangka inovasi.

Kajaba iku, ing versi 10, garis ditambahake sing nuduhake lag. Iki minangka write lag, flush lag, replay lag. Sing, iku penting kanggo ngawasi iku. Yen kita ndeleng manawa ana replikasi lag, mula kita kudu nyelidiki kenapa muncul, saka endi lan ndandani masalah kasebut.

Meh kabeh ana ing urutan karo metrik sistem. Nalika sembarang ngawasi diwiwiti, iku diwiwiti karo metrik sistem. Iki minangka pembuangan prosesor, memori, swap, jaringan lan disk. Nanging, akeh paramèter ora ana kanthi standar.

Yen kabeh iku supaya karo proses daur ulang, banjur ana masalah karo daur ulang disk. Minangka aturan, pangembang ngawasi nambah informasi babagan throughput. Bisa ing iops utawa byte. Nanging dheweke lali babagan latensi lan panggunaan piranti disk. Iki minangka paramèter sing luwih penting sing ngidini kita ngevaluasi carane dimuat disk kita lan carane alon. Yen kita duwe latensi dhuwur, iki tegese ana sawetara masalah karo disk. Yen kita duwe panggunaan sing dhuwur, tegese disk ora bisa ngatasi. Iki minangka ciri sing luwih apik tinimbang throughput.

Kajaba iku, statistik kasebut uga bisa dipikolehi saka sistem file / proc, kaya sing ditindakake kanggo prosesor daur ulang. Aku ora ngerti apa informasi iki ora ditambahake kanggo ngawasi. Nanging, penting kanggo duwe iki ing pemantauan sampeyan.

Padha ditrapake kanggo antarmuka jaringan. Ana informasi babagan throughput jaringan ing paket, ing bita, nanging ora ana informasi babagan latensi lan ora ana informasi babagan panggunaan, sanajan iki uga informasi sing migunani.

Sembarang ngawasi duwe kekurangan. Lan ora preduli apa jenis pemantauan sing sampeyan lakoni, mesthi ora bakal cocog karo sawetara kritéria. Nanging, lagi berkembang, fitur-fitur anyar lan barang-barang anyar ditambahake, mula pilih lan rampungake.

Lan kanggo ngrampungake, sampeyan kudu tansah duwe gagasan apa tegese statistik sing diwenehake lan carane sampeyan bisa nggunakake kanggo ngatasi masalah.

Lan sawetara poin penting:

• Sampeyan kudu tansah ngawasi kasedhiyan lan duwe dashboards supaya sampeyan bisa kanthi cepet netepke sing kabeh iku supaya karo database.
• Sampeyan mesthi kudu duwe ide babagan apa sing digunakake klien karo database sampeyan supaya bisa ngilangi klien sing ala lan nembak.
• Penting kanggo ngevaluasi cara klien kasebut nggarap data. Sampeyan kudu duwe gagasan babagan beban kerja sampeyan.
• Penting kanggo ngevaluasi carane beban kerja iki dibentuk, kanthi bantuan pitakon apa. Sampeyan bisa ngevaluasi pitakon, sampeyan bisa ngoptimalake, refactor, mbangun indeks kanggo wong-wong mau. Iku penting banget.
• Proses latar mburi bisa mengaruhi panjalukan klien, mula penting kanggo ngawasi manawa dheweke ora nggunakake sumber daya sing akeh banget.
• Metrik sistem ngidini sampeyan nggawe rencana kanggo skala lan nambah kapasitas server, mula uga penting kanggo nglacak lan ngevaluasi.

Yen sampeyan kasengsem ing topik iki, sampeyan bisa tindakake pranala iki.
http://bit.do/stats_collector - iki dokumentasi resmi saka kolektor statistik. Ana deskripsi kabeh tampilan statistik lan deskripsi kabeh lapangan. Sampeyan bisa maca, ngerti lan nganalisa. Lan adhedhasar kasebut, gawe grafik lan tambahake menyang pemantauan sampeyan.

Tuladha panyuwunan:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Iki minangka gudang perusahaan lan aku dhewe. Padha ngemot conto pitakon. Ora ana pitakon saka pilihan * saka seri ing kana. Ana pitakon sing wis siap karo gabung, nggunakake fungsi menarik sing ngidini sampeyan ngowahi angka mentah dadi nilai sing bisa diwaca, trep, yaiku bita, wektu. Sampeyan bisa milih, ndeleng, nganalisa, nambah menyang pemantauan, mbangun pemantauan adhedhasar.

Pitakonan

Pitakonan: Sampeyan ujar manawa sampeyan ora bakal ngiklanake merek, nanging aku isih kepengin weruh - apa jenis dashboard sing sampeyan gunakake ing proyek sampeyan?
Jawaban: Iku beda-beda. Iku kedadeyan yen kita teka menyang pelanggan lan dheweke wis duwe pemantauan dhewe. Lan kita menehi saran marang pelanggan babagan apa sing kudu ditambahake ing pemantauan. Kahanan sing paling ala yaiku karo Zabbix. Amarga ora duwe kemampuan kanggo mbangun grafik TopN. Awake dhewe nggunakake Okmeter, amarga kita padha konsultasi karo wong-wong iki babagan ngawasi. Dheweke ngawasi PostgreSQL adhedhasar spesifikasi teknis kita. Aku nulis pet-proyek dhewe, kang ngumpulake data liwat Prometheus lan nerjemahake ing Grafana. Tugasku yaiku nggawe eksportir dhewe ing Prometheus banjur nerjemahake kabeh ing Grafana.

Pitakonan: Apa ana analog saka laporan AWR utawa ... agregasi? Apa sampeyan ngerti babagan kaya iki?
Wangsulan: Ya, aku ngerti apa AWR, iku kelangan. Ing wayahe ana macem-macem pit sing ngleksanakake kira-kira model ing ngisor iki. Ing sawetara interval wektu, sawetara garis dasar ditulis menyang PostgreSQL sing padha utawa menyang panyimpenan sing kapisah. Sampeyan bisa google ing Internet, padha ana. Salah sawijining pangembang sing kaya ngono lungguh ing forum sql.ru ing Utas PostgreSQL. Sampeyan bisa nyekel dheweke ana. Ya, ana sing kaya ngono, bisa digunakake. Plus ing sawijining pgCenter Aku uga nulis bab sing ngidini sampeyan nindakake perkara sing padha.

P.S.1 Yen sampeyan nggunakake postgres_exporter, dasbor apa sing sampeyan gunakake? Ana sawetara. Padha wis outdated. Mungkin masyarakat bakal nggawe cithakan dianyari?

P.S.2 Dibusak pganalyze, amarga iki minangka penawaran SaaS eksklusif sing fokus ing pemantauan kinerja lan saran tuning otomatis.

Mung pangguna pangguna sing bisa melu survey. mlebunggih.

Pemantauan postgresql sing dadi tuan rumah dhewe (karo dasbor) sing sampeyan anggep paling apik?

• 30,0%Zabbix + tambahan saka Alexey Lesovsky utawa zabbix 4.4 utawa 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 minangka SaaS kepemilikan - aku ora bisa mbusak1

• 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 pangguna milih. 26 kedhaftar abstained.

Source: www.habr.com