Mga pangunahing kaalaman sa pagsubaybay sa PostgreSQL. Alexey Lesovsky

Iminumungkahi kong basahin mo ang transcript ng ulat ni Alexey Lesovsky mula sa Data Egret "Mga Batayan ng Pagsubaybay sa PostgreSQL"

Sa ulat na ito, tatalakayin ni Alexey Lesovsky ang tungkol sa mga pangunahing punto ng mga istatistika ng post-gress, kung ano ang ibig sabihin nito, at kung bakit dapat silang naroroon sa pagsubaybay; tungkol sa kung anong mga graph ang dapat nasa pagsubaybay, kung paano idagdag ang mga ito at kung paano i-interpret ang mga ito. Magiging kapaki-pakinabang ang ulat sa mga administrator ng database, mga administrator ng system at mga developer na interesado sa pag-troubleshoot ng Postgres.

Ang pangalan ko ay Alexey Lesovsky, kinakatawan ko ang kumpanya ng Data Egret.

Ang ilang mga salita tungkol sa aking sarili. Matagal na akong nagsimula bilang isang system administrator.

Pinangasiwaan ko ang lahat ng uri ng iba't ibang mga sistema ng Linux, nagtrabaho sa iba't ibang bagay na may kaugnayan sa Linux, ibig sabihin, virtualization, pagsubaybay, nagtrabaho sa mga proxy, atbp. Ngunit sa ilang mga punto nagsimula akong magtrabaho nang higit pa sa mga database, PostgreSQL. Nagustuhan ko talaga siya. At sa ilang mga punto nagsimula akong magtrabaho sa PostgreSQL sa halos lahat ng oras ng aking pagtatrabaho. At kaya unti-unti akong naging isang PostgreSQL DBA.

At sa buong karera ko, palagi akong interesado sa mga paksa ng istatistika, pagsubaybay, at telemetry. At noong ako ay isang system administrator, nagtrabaho ako nang malapit sa Zabbix. At nagsulat ako ng isang maliit na hanay ng mga script tulad ng zabbix-extension. Medyo sikat siya noong panahon niya. At doon posible na subaybayan ang iba't ibang mahahalagang bagay, hindi lamang ang Linux, kundi pati na rin ang iba't ibang mga bahagi.

Ngayon ay nagtatrabaho ako sa PostgreSQL. Nagsusulat na ako ng isa pang bagay na nagpapahintulot sa iyo na magtrabaho kasama ang mga istatistika ng PostgreSQL. Ito ay tinatawag na pgCenter (artikulo sa Habré - Mga istatistika ng post-gress na walang nerbiyos at tensyon).

Isang maliit na pambungad na tala. Anong mga sitwasyon ang mayroon ang aming mga customer, ang aming mga kliyente? Mayroong ilang uri ng aksidente na nauugnay sa database. At kapag ang database ay naibalik na, ang pinuno ng departamento o ang pinuno ng pag-unlad ay darating at sasabihin: "Mga kaibigan, kailangan nating subaybayan ang database, dahil may nangyaring masama at kailangan nating pigilan ito na mangyari sa hinaharap." At dito magsisimula ang kawili-wiling proseso ng pagpili ng isang sistema ng pagsubaybay o pag-angkop ng isang umiiral na sistema ng pagsubaybay upang masubaybayan mo ang iyong database - PostgreSQL, MySQL o ilang iba pa. At ang mga kasamahan ay nagsimulang magmungkahi: "Narinig ko na mayroong ganito at ganoong database. Gamitin natin." Nagsisimulang makipagtalo ang mga kasamahan sa isa't isa. At sa huli ay lumalabas na pumili kami ng ilang uri ng database, ngunit ang pagsubaybay sa PostgreSQL ay ipinakita dito sa halip na hindi maganda at palagi kaming may idagdag. Kumuha ng ilang mga repository mula sa GitHub, i-clone ang mga ito, iakma ang mga script, at kahit papaano ay i-customize ang mga ito. At sa huli ito ay nagtatapos sa pagiging isang uri ng manu-manong gawain.

Samakatuwid, sa pag-uusap na ito susubukan kong bigyan ka ng ilang kaalaman kung paano pumili ng pagsubaybay hindi lamang para sa PostgreSQL, kundi pati na rin sa database. At bigyan ka ng kaalaman na magbibigay-daan sa iyong kumpletuhin ang iyong pagsubaybay upang makakuha ng kaunting pakinabang mula dito, upang masubaybayan mo ang iyong database nang may benepisyo, upang agad na maiwasan ang anumang paparating na mga sitwasyong pang-emergency na maaaring lumitaw.

At ang mga ideya na nasa ulat na ito ay maaaring direktang iakma sa anumang database, maging ito ay isang DBMS o noSQL. Samakatuwid, mayroong hindi lamang PostgreSQL, ngunit magkakaroon ng maraming mga recipe kung paano ito gagawin sa PostgreSQL. Magkakaroon ng mga halimbawa ng mga query, mga halimbawa ng mga entity na mayroon ang PostgreSQL para sa pagsubaybay. At kung ang iyong DBMS ay may parehong mga bagay na nagpapahintulot sa iyo na ilagay ang mga ito sa pagsubaybay, maaari mo ring iakma ang mga ito, idagdag ang mga ito at ito ay magiging mabuti.

Wala ako sa report
pag-usapan kung paano maghatid at mag-imbak ng mga sukatan. Wala akong sasabihin tungkol sa post-processing ng data at pagpapakita nito sa user. At wala akong sasabihin tungkol sa pag-alerto.
Ngunit habang umuusad ang kwento, magpapakita ako ng iba't ibang mga screenshot ng umiiral na pagsubaybay at kahit papaano ay pupunahin ang mga ito. Ngunit gayunpaman, susubukan kong huwag pangalanan ang mga tatak upang hindi lumikha ng advertising o anti-advertising para sa mga produktong ito. Samakatuwid, ang lahat ng mga pagkakataon ay random at naiwan sa iyong imahinasyon.

Una, alamin natin kung ano ang pagsubaybay. Ang pagsubaybay ay isang napakahalagang bagay na dapat magkaroon. Naiintindihan ito ng lahat. Ngunit sa parehong oras, ang pagsubaybay ay hindi nauugnay sa isang produkto ng negosyo at hindi direktang nakakaapekto sa kita ng kumpanya, kaya ang oras ay palaging inilalaan sa pagsubaybay sa isang natitirang batayan. Kung mayroon kaming oras, pagkatapos ay ginagawa namin ang pagsubaybay; kung wala kaming oras, pagkatapos ay OK, ilalagay namin ito sa backlog at balang araw ay babalik kami sa mga gawaing ito.

Samakatuwid, mula sa aming pagsasanay, pagdating namin sa mga kliyente, ang pagsubaybay ay madalas na hindi kumpleto at walang anumang mga kawili-wiling bagay na makakatulong sa amin na gumawa ng isang mas mahusay na trabaho sa database. At samakatuwid ang pagsubaybay ay palaging kailangang makumpleto.

Ang mga database ay mga kumplikadong bagay na kailangan ding subaybayan, dahil ang mga database ay isang imbakan ng impormasyon. At ang impormasyon ay napakahalaga para sa kumpanya; hindi ito maaaring mawala sa anumang paraan. Ngunit sa parehong oras, ang mga database ay napakakomplikadong piraso ng software. Binubuo sila ng isang malaking bilang ng mga sangkap. At marami sa mga sangkap na ito ang kailangang subaybayan.

Kung partikular na pinag-uusapan natin ang PostgreSQL, maaari itong ilarawan sa anyo ng isang scheme na binubuo ng isang malaking bilang ng mga bahagi. Ang mga sangkap na ito ay nakikipag-ugnayan sa isa't isa. At kasabay nito, ang PostgreSQL ay may tinatawag na Stats Collector subsystem, na nagbibigay-daan sa iyong mangolekta ng mga istatistika tungkol sa pagpapatakbo ng mga subsystem na ito at magbigay ng ilang uri ng interface sa administrator o user upang matingnan niya ang mga istatistikang ito.

Ang mga istatistikang ito ay ipinakita sa anyo ng isang tiyak na hanay ng mga function at view. Maaari din silang tawaging mga talahanayan. Iyon ay, gamit ang isang regular na psql client, maaari kang kumonekta sa database, pumili sa mga function at view na ito, at makakuha ng ilang partikular na numero tungkol sa pagpapatakbo ng mga subsystem ng PostgreSQL.

Maaari mong idagdag ang mga numerong ito sa iyong paboritong monitoring system, gumuhit ng mga graph, magdagdag ng mga function at makakuha ng analytics sa mahabang panahon.

Ngunit sa ulat na ito hindi ko sasaklawin ang lahat ng mga function na ito nang buo, dahil maaaring tumagal ito ng buong araw. Literal na tatalakayin ko ang dalawa, tatlo o apat na bagay at sasabihin sa iyo kung paano sila nakakatulong na gawing mas mahusay ang pagsubaybay.

At kung pinag-uusapan natin ang pagsubaybay sa database, ano ang kailangang subaybayan? Una sa lahat, kailangan nating subaybayan ang availability, dahil ang database ay isang serbisyo na nagbibigay ng access sa data sa mga kliyente at kailangan nating subaybayan ang availability, at magbigay din ng ilan sa mga katangiang husay at dami nito.

Kailangan din naming subaybayan ang mga kliyenteng kumokonekta sa aming database, dahil maaari silang parehong normal na kliyente at mapaminsalang kliyente na maaaring makapinsala sa database. Kailangan din silang subaybayan at subaybayan ang kanilang mga aktibidad.

Kapag kumonekta ang mga kliyente sa database, malinaw na nagsisimula silang magtrabaho kasama ang aming data, kaya kailangan naming subaybayan kung paano gumagana ang mga kliyente sa data: kung saan ang mga talahanayan, at sa mas mababang lawak, kung aling mga index. Ibig sabihin, kailangan nating suriin ang workload na nilikha ng ating mga kliyente.

Ngunit ang workload ay binubuo rin, siyempre, ng mga kahilingan. Ang mga application ay kumonekta sa database, nag-access ng data gamit ang mga query, kaya mahalagang suriin kung anong mga query ang mayroon tayo sa database, subaybayan ang kanilang kasapatan, na hindi sila baluktot na nakasulat, na ang ilang mga pagpipilian ay kailangang muling isulat at gawin upang gumana ang mga ito nang mas mabilis at may mas mahusay na pagganap.

At dahil pinag-uusapan natin ang tungkol sa isang database, ang database ay palaging mga proseso sa background. Ang mga proseso sa background ay tumutulong na mapanatili ang pagganap ng database sa isang mahusay na antas, kaya nangangailangan sila ng isang tiyak na halaga ng mga mapagkukunan para sa kanilang sarili upang gumana. At sa parehong oras, maaari silang mag-overlap sa mga mapagkukunan ng kahilingan ng kliyente, kaya maaaring direktang makaapekto sa pagganap ng mga kahilingan ng kliyente ang matakaw na proseso sa background. Samakatuwid, kailangan din silang subaybayan at subaybayan upang walang mga pagbaluktot sa mga tuntunin ng mga proseso sa background.

At ang lahat ng ito sa mga tuntunin ng pagsubaybay sa database ay nananatili sa sukatan ng system. Ngunit kung isasaalang-alang na ang karamihan sa aming mga imprastraktura ay lumilipat sa mga ulap, ang mga sukatan ng system ng isang indibidwal na host ay palaging nawawala sa background. Ngunit sa mga database ay may kaugnayan pa rin sila at, siyempre, kinakailangan din na subaybayan ang mga sukatan ng system.

Ang lahat ay higit pa o hindi gaanong maayos sa mga sukatan ng system, lahat ng modernong sistema ng pagsubaybay ay sumusuporta na sa mga sukatan na ito, ngunit sa pangkalahatan, ang ilang mga bahagi ay hindi pa rin sapat at ilang mga bagay ang kailangang idagdag. Hahawakan ko rin sila, magkakaroon ng ilang mga slide tungkol sa kanila.

Ang unang punto ng plano ay accessibility. Ano ang accessibility? Ang kakayahang magamit sa aking pag-unawa ay ang kakayahan ng base sa mga koneksyon sa serbisyo, ibig sabihin, ang base ay itinaas, ito, bilang isang serbisyo, ay tumatanggap ng mga koneksyon mula sa mga kliyente. At ang accessibility na ito ay maaaring masuri ng ilang mga katangian. Napakaginhawang ipakita ang mga katangiang ito sa mga dashboard.

Alam ng lahat kung ano ang mga dashboard. Ito ay kapag tiningnan mo ang screen kung saan ibinubuod ang kinakailangang impormasyon. At maaari mong matukoy kaagad kung may problema sa database o wala.
Alinsunod dito, ang pagkakaroon ng database at iba pang mga pangunahing katangian ay dapat palaging ipinapakita sa mga dashboard upang ang impormasyong ito ay nasa kamay at laging magagamit sa iyo. Ilang karagdagang detalye na nakakatulong na sa pagsisiyasat ng mga insidente, kapag nag-iimbestiga sa ilang sitwasyong pang-emergency, kailangan na nilang ilagay sa mga pangalawang dashboard, o itago sa mga drilldown link na humahantong sa mga third-party na monitoring system.

Isang halimbawa ng isang kilalang sistema ng pagsubaybay. Ito ay isang napaka-cool na sistema ng pagsubaybay. Siya ay nangongolekta ng maraming data, ngunit sa aking pananaw, mayroon siyang kakaibang konsepto ng mga dashboard. May link para "lumikha ng dashboard". Ngunit kapag gumawa ka ng dashboard, gagawa ka ng listahan ng dalawang column, isang listahan ng mga graph. At kapag kailangan mong tumingin sa isang bagay, magsisimula kang mag-click gamit ang mouse, mag-scroll, hanapin ang nais na tsart. At nangangailangan ito ng oras, ibig sabihin, walang mga dashboard tulad nito. Mayroon lamang mga listahan ng mga chart.

Ano ang dapat mong idagdag sa mga dashboard na ito? Maaari kang magsimula sa isang katangian tulad ng oras ng pagtugon. Ang PostgreSQL ay may pg_stat_statements view. Ito ay hindi pinagana bilang default, ngunit isa ito sa mga mahalagang view ng system na dapat palaging pinagana at ginagamit. Nag-iimbak ito ng impormasyon tungkol sa lahat ng tumatakbong mga query na naisakatuparan sa database.

Alinsunod dito, maaari tayong magsimula sa katotohanan na maaari nating kunin ang kabuuang oras ng pagpapatupad ng lahat ng mga kahilingan at hatiin ito sa bilang ng mga kahilingan gamit ang mga field sa itaas. Ngunit ito ang karaniwang temperatura sa ospital. Maaari tayong magsimula sa iba pang mga field - pinakamababang oras ng pagpapatupad ng query, maximum at median. At maaari pa nga tayong bumuo ng mga percentile; Ang PostgreSQL ay may kaukulang mga function para dito. At makakakuha tayo ng ilang numero na nagpapakilala sa oras ng pagtugon ng aming database para sa mga nakumpleto nang kahilingan, ibig sabihin, hindi namin isinasagawa ang pekeng kahilingan na 'piliin ang 1' at tinitingnan ang oras ng pagtugon, ngunit sinusuri namin ang oras ng pagtugon para sa mga nakumpleto nang kahilingan at gumuhit alinman sa isang hiwalay na figure, o bumuo kami ng isang graph batay dito.

Mahalaga rin na subaybayan ang bilang ng mga error na kasalukuyang nabuo ng system. At para dito maaari mong gamitin ang pg_stat_database view. Nakatuon kami sa xact_rollback field. Ipinapakita ng field na ito hindi lamang ang bilang ng mga rollback na nangyayari sa database, ngunit isinasaalang-alang din ang bilang ng mga error. Sa medyo pagsasalita, maaari naming ipakita ang figure na ito sa aming dashboard at makita kung gaano karaming mga error ang mayroon kami sa kasalukuyan. Kung mayroong maraming mga error, kung gayon ito ay isang magandang dahilan upang tingnan ang mga log at makita kung anong uri ng mga pagkakamali ang mga ito at kung bakit nangyari ang mga ito, at pagkatapos ay mamuhunan at lutasin ang mga ito.

Maaari kang magdagdag ng isang bagay bilang isang Tachometer. Ito ang bilang ng mga transaksyon sa bawat segundo at ang bilang ng mga kahilingan sa bawat segundo. Sa relatibong pagsasalita, maaari mong gamitin ang mga numerong ito bilang kasalukuyang pagganap ng iyong database at obserbahan kung may mga peak sa mga kahilingan, mga peak sa mga transaksyon, o, sa kabaligtaran, kung ang database ay kulang sa karga dahil nabigo ang ilang backend. Mahalagang palaging tingnan ang figure na ito at tandaan na para sa aming proyekto ang ganitong uri ng pagganap ay normal, ngunit ang mga halaga sa itaas at ibaba ay isang uri ng problema at hindi maintindihan, na nangangahulugang kailangan nating tingnan kung bakit ang mga numerong ito ay ang taas.

Upang matantya ang bilang ng mga transaksyon, maaari tayong sumangguni muli sa pg_stat_database view. Maaari naming idagdag ang bilang ng mga commit at ang bilang ng mga rollback at makuha ang bilang ng mga transaksyon sa bawat segundo.

Naiintindihan ba ng lahat na maraming kahilingan ang maaaring magkasya sa isang transaksyon? Samakatuwid ang TPS at QPS ay bahagyang naiiba.

Ang bilang ng mga kahilingan sa bawat segundo ay maaaring makuha mula sa pg_stat_statements at kalkulahin lamang ang kabuuan ng lahat ng nakumpletong kahilingan. Malinaw na inihambing natin ang kasalukuyang halaga sa nauna, ibawas ito, kunin ang delta, at kunin ang dami.

Maaari kang magdagdag ng mga karagdagang sukatan kung ninanais, na makakatulong din na suriin ang pagkakaroon ng aming database at subaybayan kung nagkaroon ng anumang mga downtime.

Isa sa mga sukatan na ito ay uptime. Ngunit ang uptime sa PostgreSQL ay medyo nakakalito. Sasabihin ko kung bakit. Kapag nagsimula na ang PostgreSQL, magsisimula ang pag-uulat ng uptime. Ngunit kung sa ilang mga punto, halimbawa, ang ilang gawain ay tumatakbo sa gabi, dumating ang isang OOM-killer at pilit na tinapos ang proseso ng bata ng PostgreSQL, kung gayon sa kasong ito, tinatapos ng PostgreSQL ang koneksyon ng lahat ng mga kliyente, ni-reset ang sharded memory area at nagsisimula sa pagbawi mula sa ang huling checkpoint. At habang ang pagbawi na ito mula sa checkpoint ay tumatagal, ang database ay hindi tumatanggap ng mga koneksyon, ibig sabihin, ang sitwasyong ito ay maaaring masuri bilang downtime. Ngunit hindi mare-reset ang uptime counter, dahil isinasaalang-alang nito ang oras ng pagsisimula ng postmaster mula sa pinakaunang sandali. Samakatuwid, ang mga ganitong sitwasyon ay maaaring laktawan.

Dapat mo ring subaybayan ang bilang ng mga vacuum worker. Alam ba ng lahat kung ano ang autovacuum sa PostgreSQL? Ito ay isang kawili-wiling subsystem sa PostgreSQL. Maraming mga artikulo ang isinulat tungkol sa kanya, maraming mga ulat ang ginawa. Maraming talakayan tungkol sa vacuum at kung paano ito dapat gumana. Itinuturing ng marami na ito ay isang kinakailangang kasamaan. Pero ganun talaga. Ito ay isang uri ng analogue ng isang garbage collector na naglilinis ng mga lumang bersyon ng mga row na hindi kailangan ng anumang transaksyon at nagpapalaya ng espasyo sa mga talahanayan at mga index para sa mga bagong row.

Bakit kailangan mong subaybayan ito? Kasi ang vacuum minsan sobrang sakit. Kumokonsumo ito ng malaking halaga ng mga mapagkukunan at ang mga kahilingan ng kliyente ay nagsisimulang magdusa bilang isang resulta.

At dapat itong subaybayan sa pamamagitan ng pg_stat_activity view, na tatalakayin ko sa susunod na seksyon. Ipinapakita ng view na ito ang kasalukuyang aktibidad sa database. At sa pamamagitan ng aktibidad na ito masusubaybayan natin ang bilang ng mga vacuum na gumagana ngayon. Maaari naming subaybayan ang mga vacuum at makita na kung lumampas kami sa limitasyon, ito ay isang dahilan upang tingnan ang mga setting ng PostgreSQL at kahit papaano ay i-optimize ang pagpapatakbo ng vacuum.

Ang isa pang bagay tungkol sa PostgreSQL ay ang PostgreSQL ay napakasakit ng mahabang transaksyon. Lalong-lalo na sa mga transaksyong tumatambay nang matagal at walang ginagawa. Ito ang tinatawag na stat idle-in-transaction. Ang ganitong transaksyon ay may hawak na mga kandado at pinipigilan ang vacuum na gumana. At bilang isang resulta, ang mga talahanayan ay namamaga at lumalaki sa laki. At ang mga query na gumagana sa mga talahanayang ito ay nagsisimulang gumana nang mas mabagal, dahil kailangan mong pala ang lahat ng mga lumang bersyon ng mga hilera mula sa memorya patungo sa disk at pabalik. Samakatuwid, ang oras, ang tagal ng pinakamahabang transaksyon, ang pinakamahabang kahilingan sa vacuum ay kailangan ding subaybayan. At kung makakita tayo ng ilang mga proseso na tumatakbo nang napakahabang panahon, na higit sa 10-20-30 minuto para sa isang OLTP load, kailangan nating bigyang pansin ang mga ito at pilit na wakasan ang mga ito, o i-optimize ang application upang sila ay ay hindi tinatawag at hindi nakabitin nang napakatagal. Para sa isang analytical workload, 10-20-30 minuto ay normal; mayroon ding mas mahaba.

Susunod na mayroon kaming opsyon sa mga konektadong kliyente. Kapag nakagawa na kami ng dashboard at nag-post dito ng mga pangunahing sukatan ng availability, maaari rin kaming magdagdag ng karagdagang impormasyon tungkol sa mga konektadong kliyente doon.

Mahalaga ang impormasyon tungkol sa mga konektadong kliyente dahil, mula sa pananaw ng PostgreSQL, iba ang mga kliyente. May mabubuting kliyente at may masamang kliyente.

Isang simpleng halimbawa. Sa pamamagitan ng kliyente naiintindihan ko ang aplikasyon. Ang application ay nakakonekta sa database at agad na nagsimulang magpadala ng mga kahilingan nito doon, ang database ay nagpoproseso at nagpapatupad ng mga ito, at nagbabalik ng mga resulta sa kliyente. Ang mga ito ay mabuti at tamang mga kliyente.

May mga sitwasyon kung kailan nakakonekta ang kliyente, hawak nito ang koneksyon, ngunit walang ginagawa. Ito ay nasa idle state.

Ngunit may mga masamang kliyente. Halimbawa, ang parehong kliyente ay nakakonekta, nagbukas ng isang transaksyon, gumawa ng isang bagay sa database at pagkatapos ay pumasok sa code, halimbawa, upang ma-access ang isang panlabas na mapagkukunan o upang iproseso ang natanggap na data doon. Ngunit hindi niya isinara ang transaksyon. At ang transaksyon ay nakabitin sa database at naka-lock sa linya. Ito ay isang masamang kalagayan. At kung biglang nabigo ang isang aplikasyon sa isang lugar sa loob mismo ng isang pagbubukod, kung gayon ang transaksyon ay maaaring manatiling bukas sa napakatagal na panahon. At ito ay direktang nakakaapekto sa pagganap ng PostgreSQL. Magiging mas mabagal ang PostgreSQL. Samakatuwid, mahalagang subaybayan ang mga naturang kliyente sa isang napapanahong paraan at puwersahang wakasan ang kanilang trabaho. At kailangan mong i-optimize ang iyong application upang hindi mangyari ang mga ganitong sitwasyon.

Ang ibang masamang kliyente ay naghihintay ng mga kliyente. Ngunit nagiging masama sila dahil sa mga pangyayari. Halimbawa, isang simpleng idle na transaksyon: maaari itong magbukas ng isang transaksyon, kumuha ng mga kandado sa ilang mga linya, pagkatapos ay sa isang lugar sa code ito ay mabibigo, na nag-iiwan ng isang nakabitin na transaksyon. Darating ang isa pang kliyente at hihilingin ang parehong data, ngunit makakatagpo siya ng isang kandado, dahil ang nakabitin na transaksyong iyon ay may mga kandado na sa ilang kinakailangang mga hilera. At ang pangalawang transaksyon ay tatambay sa paghihintay para sa unang transaksyon na makumpleto o puwersahang isara ito ng administrator. Samakatuwid, ang mga nakabinbing transaksyon ay maaaring maipon at punan ang limitasyon ng koneksyon sa database. At kapag puno na ang limitasyon, hindi na gagana ang application sa database. Isa na itong emergency na sitwasyon para sa proyekto. Samakatuwid, ang mga masasamang kliyente ay kailangang masubaybayan at tumugon sa isang napapanahong paraan.

Isa pang halimbawa ng pagsubaybay. At mayroon nang disenteng dashboard dito. Mayroong impormasyon sa mga koneksyon sa itaas. Koneksyon ng DB – 8 piraso. At lahat na. Wala kaming impormasyon tungkol sa kung aling mga kliyente ang aktibo, kung aling mga kliyente ang walang ginagawa, walang ginagawa. Walang impormasyon tungkol sa mga nakabinbing transaksyon at nakabinbing koneksyon, ibig sabihin, ito ay isang figure na nagpapakita ng bilang ng mga koneksyon at iyon lang. At pagkatapos ay hulaan para sa iyong sarili.

Alinsunod dito, upang idagdag ang impormasyong ito sa pagsubaybay, kailangan mong i-access ang pg_stat_activity system view. Kung gumugugol ka ng maraming oras sa PostgreSQL, kung gayon ito ay isang napakagandang view na dapat maging iyong kaibigan, dahil ipinapakita nito ang kasalukuyang aktibidad sa PostgreSQL, ibig sabihin, kung ano ang nangyayari dito. Para sa bawat proseso mayroong isang hiwalay na linya na nagpapakita ng impormasyon tungkol sa prosesong ito: mula sa kung saan host ang koneksyon ay ginawa, sa ilalim ng kung anong user, sa ilalim ng anong pangalan, kapag nagsimula ang transaksyon, anong kahilingan ang kasalukuyang tumatakbo, anong kahilingan ang huling naisagawa. At, nang naaayon, maaari naming suriin ang estado ng kliyente gamit ang field ng istatistika. Sa relatibong pagsasalita, maaari tayong magpangkat ayon sa field na ito at makuha ang mga istatistikang iyon na kasalukuyang nasa database at ang bilang ng mga koneksyon na mayroong ganitong istatistika sa database. At maaari naming ipadala ang mga natanggap na numero sa aming pagsubaybay at gumuhit ng mga graph batay sa kanila.
Mahalaga rin na suriin ang tagal ng transaksyon. Sinabi ko na na mahalagang suriin ang tagal ng mga vacuum, ngunit ang mga transaksyon ay sinusuri sa parehong paraan. Mayroong xact_start at query_start na mga patlang. Ang mga ito, medyo nagsasalita, ay nagpapakita ng oras ng pagsisimula ng transaksyon at ang oras ng pagsisimula ng kahilingan. Kinukuha namin ang function na now(), na nagpapakita ng kasalukuyang timestamp, at ibawas ang transaksyon at humiling ng timestamp. At nakukuha namin ang tagal ng transaksyon, ang tagal ng kahilingan.

Kung makakakita tayo ng mahahabang transaksyon, dapat na natin itong kumpletuhin. Para sa OLTP load, ang mahahabang transaksyon ay mahigit 1-2-3 minuto na. Para sa isang OLAP na workload, ang mahahabang transaksyon ay normal, ngunit kung sila ay tumagal ng higit sa dalawang oras upang makumpleto, ito ay isa ring senyales na mayroon tayong hilig sa isang lugar.

Kapag nakakonekta na ang mga kliyente sa database, magsisimula silang magtrabaho sa aming data. Ina-access nila ang mga talahanayan, ina-access nila ang mga index upang makakuha ng data mula sa talahanayan. At mahalagang suriin kung paano nakikipag-ugnayan ang mga kliyente sa data na ito.

Ito ay kinakailangan upang masuri ang aming workload at halos maunawaan kung aling mga talahanayan ang "pinakamainit" para sa amin. Halimbawa, kailangan ito sa mga sitwasyon kung saan gusto naming maglagay ng mga “mainit” na talahanayan sa ilang uri ng mabilis na storage ng SSD. Halimbawa, ang ilang mga talahanayan ng archive na hindi namin nagamit sa loob ng mahabang panahon ay maaaring ilipat sa ilang uri ng "malamig" na archive, sa mga SATA drive at hayaan silang manirahan doon, maa-access ang mga ito kung kinakailangan.

Kapaki-pakinabang din ito para sa pag-detect ng mga anomalya pagkatapos ng anumang paglabas at pag-deploy. Sabihin nating naglabas ang proyekto ng ilang bagong feature. Halimbawa, nagdagdag kami ng bagong functionality para sa pagtatrabaho sa database. At kung mag-plot kami ng mga graph ng paggamit ng talahanayan, madali naming matutukoy ang mga anomalyang ito sa mga graph na ito. Halimbawa, i-update ang mga pagsabog o tanggalin ang mga pagsabog. Ito ay magiging napaka-visible.

Maaari ka ring makakita ng mga anomalya sa mga istatistika ng "lumulutang". Ano ang ibig sabihin nito? Ang PostgreSQL ay may napakalakas at napakahusay na tagaplano ng query. At ang mga developer ay naglalaan ng maraming oras sa pag-unlad nito. Paano siya nagtatrabaho? Upang makagawa ng magagandang plano, kinokolekta ng PostgreSQL ang mga istatistika sa pamamahagi ng data sa mga talahanayan sa isang tiyak na agwat ng oras at sa isang tiyak na dalas. Ito ang mga pinakakaraniwang halaga: ang bilang ng mga natatanging halaga, impormasyon tungkol sa NULL sa talahanayan, maraming impormasyon.

Batay sa mga istatistikang ito, ang tagaplano ay gumagawa ng ilang mga query, pinipili ang pinakamainam na isa, at ginagamit ang query plan na ito upang isagawa ang query mismo at ibalik ang data.

At nangyayari na ang mga istatistika ay "lumulutang". Ang kalidad at dami ng data kahit papaano ay nagbago sa talahanayan, ngunit ang mga istatistika ay hindi nakolekta. At ang mga planong nabuo ay maaaring hindi pinakamainam. At kung ang aming mga plano ay magiging suboptimal batay sa pagsubaybay na nakolekta, batay sa mga talahanayan, makikita namin ang mga anomalyang ito. Halimbawa, sa isang lugar ang data ay nagbago nang husay at sa halip na ang index, isang sequential pass sa talahanayan ay nagsimulang gamitin, i.e. kung 100 row lang ang kailangang ibalik ng isang query (may limitasyon na 100), isasagawa ang kumpletong paghahanap para sa query na ito. At ito ay palaging may napakasamang epekto sa pagganap.

At makikita natin ito sa pagsubaybay. At tingnan na ang query na ito, magpatakbo ng paliwanag para dito, mangolekta ng mga istatistika, bumuo ng isang bagong karagdagang index. At tumugon na sa problemang ito. Kaya naman importante.

Isa pang halimbawa ng pagsubaybay. Sa tingin ko marami ang nakakilala sa kanya dahil sikat na sikat siya. Sino ang gumagamit nito sa kanilang mga proyekto Promiteyus? Sino ang gumagamit ng produktong ito kasabay ng Prometheus? Ang katotohanan ay sa karaniwang imbakan ng pagsubaybay na ito mayroong isang dashboard para sa pagtatrabaho sa PostgreSQL - postgres_exporter Prometheus. Ngunit mayroong isang masamang detalye.

Mayroong ilang mga graph. At ang mga byte ay ipinahiwatig bilang pagkakaisa, ibig sabihin, mayroong 5 mga graph. Ito ay ang Insert data, Update data, Delete data, Fetch data at Return data. Ang pagsukat ng unit ay bytes. Ngunit ang bagay ay ang mga istatistika sa PostgreSQL ay nagbabalik ng data sa tuple (mga hilera). At, ayon dito, ang mga graph na ito ay isang napakahusay na paraan upang maliitin ang iyong workload nang ilang beses, sampu-sampung beses, dahil ang isang tuple ay hindi isang byte, ang isang tuple ay isang string, ito ay maraming byte at ito ay palaging may variable na haba. Iyon ay, ang pagkalkula ng workload sa mga byte gamit ang mga tuple ay isang hindi makatotohanang gawain o napakahirap. Samakatuwid, kapag gumamit ka ng dashboard o built-in na pagsubaybay, palaging mahalagang maunawaan na gumagana ito nang tama at ibabalik sa iyo ang data na nasuri nang tama.

Paano makakuha ng mga istatistika sa mga talahanayang ito? Para sa layuning ito, ang PostgreSQL ay may isang tiyak na pamilya ng mga view. At ang pangunahing view ay pg_stat_user_tables. User_tables - nangangahulugan ito ng mga talahanayan na ginawa sa ngalan ng user. Sa kaibahan, may mga view ng system na ginagamit mismo ng PostgreSQL. At mayroong isang summary table na Alltables, na kinabibilangan ng parehong system at user. Maaari kang magsimula sa alinman sa mga ito na pinakagusto mo.

Gamit ang mga field sa itaas maaari mong tantyahin ang bilang ng mga pagsingit, pag-update at pagtanggal. Ang halimbawa ng isang dashboard na ginamit ko ay gumagamit ng mga field na ito upang suriin ang mga katangian ng isang workload. Samakatuwid, maaari rin tayong bumuo sa kanila. Ngunit ito ay nagkakahalaga ng pag-alala na ang mga ito ay mga tuple, hindi mga byte, kaya hindi natin ito magagawa sa mga byte.

Batay sa data na ito, maaari tayong bumuo ng tinatawag na mga talahanayan ng TopN. Halimbawa, Top-5, Top-10. At masusubaybayan mo ang mga maiinit na mesa na mas nire-recycle kaysa sa iba. Halimbawa, 5 "mainit" na talahanayan para sa pagpasok. At gamit ang mga talahanayan ng TopN na ito, sinusuri namin ang aming workload at masusuri namin ang mga pagsabog ng workload pagkatapos ng anumang mga release, update, at deployment.

Mahalaga rin na suriin ang laki ng talahanayan, dahil minsan ang mga developer ay naglalabas ng bagong feature, at ang aming mga talahanayan ay nagsisimulang lumaki sa kanilang malalaking sukat, dahil nagpasya silang magdagdag ng karagdagang halaga ng data, ngunit hindi hinulaan kung paano ito mangyayari. nakakaapekto sa laki ng database. Ang mga ganitong kaso ay dumating din bilang mga sorpresa sa amin.

At ngayon isang maliit na tanong para sa iyo. Anong tanong ang lumitaw kapag napansin mo ang pagkarga sa iyong database server? Ano ang susunod na tanong mo?

Ngunit sa katunayan ang tanong ay lumitaw tulad ng sumusunod. Anong mga kahilingan ang sanhi ng pagkarga? Iyon ay, hindi kawili-wiling tingnan ang mga proseso na sanhi ng pag-load. Malinaw na kung ang host ay may database, kung gayon ang database ay tumatakbo doon at malinaw na ang mga database lamang ang itatapon doon. Kung bubuksan namin ang Top, makikita namin doon ang isang listahan ng mga proseso sa PostgreSQL na may ginagawa. Hindi malinaw kay Top kung ano ang ginagawa nila.

Alinsunod dito, kailangan mong hanapin ang mga query na nagdudulot ng pinakamataas na load, dahil ang pag-tune ng mga query, bilang panuntunan, ay nagbibigay ng higit na kita kaysa sa pag-tune ng PostgreSQL o configuration ng operating system, o kahit na pag-tune ng hardware. Ayon sa aking tantiya, ito ay humigit-kumulang 80-85-90%. At ito ay ginagawa nang mas mabilis. Mas mabilis na itama ang isang kahilingan kaysa itama ang pagsasaayos, mag-iskedyul ng pag-restart, lalo na kung hindi ma-restart ang database, o magdagdag ng hardware. Mas madaling isulat muli ang query sa isang lugar o magdagdag ng index para makakuha ng mas magandang resulta mula sa query na ito.

Alinsunod dito, kinakailangan na subaybayan ang mga kahilingan at ang kanilang kasapatan. Kumuha tayo ng isa pang halimbawa ng pagsubaybay. At dito rin, tila may mahusay na pagsubaybay. Mayroong impormasyon sa pagtitiklop, mayroong impormasyon sa throughput, pagharang, paggamit ng mapagkukunan. Maayos ang lahat, ngunit walang impormasyon sa mga kahilingan. Hindi malinaw kung anong mga query ang tumatakbo sa aming database, gaano katagal tumatakbo ang mga ito, ilan sa mga query na ito. Kailangan nating laging magkaroon ng impormasyong ito sa ating pagsubaybay.

At para makuha ang impormasyong ito maaari naming gamitin ang module ng pg_stat_statements. Batay dito, maaari kang bumuo ng iba't ibang mga graph. Halimbawa, maaari kang makakuha ng impormasyon sa mga pinakamadalas na query, iyon ay, sa mga query na iyon na pinakamadalas na isinasagawa. Oo, pagkatapos ng mga pag-deploy, napaka-kapaki-pakinabang din na tingnan ito at maunawaan kung mayroong anumang surge sa mga kahilingan.

Maaari mong subaybayan ang pinakamahabang mga query, iyon ay, ang mga query na iyon na pinakamatagal upang makumpleto. Tumatakbo sila sa processor, kumokonsumo sila ng I/O. Masusuri din natin ito gamit ang mga field na total_time, mean_time, blk_write_time at blk_read_time.

Maaari naming suriin at subaybayan ang pinakamabigat na kahilingan sa mga tuntunin ng paggamit ng mapagkukunan, ang mga nagbabasa mula sa disk, na gumagana sa memorya, o, sa kabaligtaran, lumikha ng ilang uri ng pagkarga ng pagsulat.

Maaari naming suriin ang mga pinaka mapagbigay na kahilingan. Ito ang mga query na nagbabalik ng malaking bilang ng mga row. Halimbawa, maaaring ito ang ilang kahilingan kung saan nakalimutan nilang magtakda ng limitasyon. At ibinabalik lamang nito ang buong nilalaman ng talahanayan o query sa mga na-query na talahanayan.

At maaari mo ring subaybayan ang mga query na gumagamit ng mga pansamantalang file o pansamantalang mga talahanayan.

At mayroon pa kaming mga proseso sa background. Pangunahing mga checkpoint ang mga proseso sa background o tinatawag din itong mga checkpoint, ito ay autovacuum at replication.

Isa pang halimbawa ng pagsubaybay. Mayroong tab na Pagpapanatili sa kaliwa, pumunta dito at umaasa na makakita ng kapaki-pakinabang. Ngunit narito lamang ang oras ng pagpapatakbo ng vacuum at pagkolekta ng mga istatistika, wala nang iba pa. Ito ay napakahinang impormasyon, kaya kailangan nating laging magkaroon ng impormasyon tungkol sa kung paano gumagana ang mga proseso sa background sa ating database at kung mayroong anumang mga problema mula sa kanilang trabaho.

Kapag tumitingin tayo sa mga checkpoint, dapat nating tandaan na ang mga checkpoint ay nag-flush ng mga maruruming pahina mula sa sharded memory area patungo sa disk, pagkatapos ay lumikha ng checkpoint. At ang checkpoint na ito ay maaaring gamitin bilang isang lugar para sa pagbawi kung ang PostgreSQL ay biglang winakasan sa isang emergency.

Alinsunod dito, upang ma-flush ang lahat ng "marumi" na pahina sa disk, kailangan mong gumawa ng isang tiyak na dami ng pagsulat. At, bilang isang patakaran, sa mga system na may malaking halaga ng memorya, ito ay marami. At kung madalas kaming gumawa ng mga checkpoint sa isang maikling pagitan, kung gayon ang pagganap ng disk ay bababa nang malaki. At ang mga kahilingan ng kliyente ay magdurusa dahil sa kakulangan ng mga mapagkukunan. Makikipagkumpitensya sila para sa mga mapagkukunan at kulang sa produktibidad.

Alinsunod dito, sa pamamagitan ng pg_stat_bgwriter gamit ang mga tinukoy na field masusubaybayan namin ang bilang ng mga checkpoint na nagaganap. At kung marami tayong checkpoints sa isang tiyak na tagal ng panahon (sa 10-15-20 minuto, sa kalahating oras), halimbawa, 3-4-5, maaari na itong maging problema. At kailangan mo nang tumingin sa database, tingnan ang pagsasaayos, kung ano ang nagiging sanhi ng kasaganaan ng mga checkpoint. Marahil ay may ilang uri ng malaking pag-record na nagaganap. Masusuri na namin ang workload, dahil nagdagdag na kami ng workload graphs. Maaari na nating i-tweak ang mga parameter ng checkpoint at tiyaking hindi ito makakaapekto nang malaki sa pagganap ng query.

Babalik ako sa autovacuum muli dahil ito ay isang bagay, tulad ng sinabi ko, na madaling magdagdag ng parehong disk at pagganap ng query, kaya palaging mahalaga na tantyahin ang halaga ng autovacuum.

Limitado ang bilang ng mga manggagawa sa autovacuum sa database. Bilang default, mayroong tatlo sa kanila, kaya kung palagi kaming may tatlong manggagawa na nagtatrabaho sa database, nangangahulugan ito na ang aming autovacuum ay hindi na-configure, kailangan naming itaas ang mga limitasyon, baguhin ang mga setting ng autovacuum at pumasok sa pagsasaayos.
Mahalagang suriin kung aling mga vacuum worker ang mayroon tayo. Alinman ito ay inilunsad mula sa user, dumating ang DBA at manu-manong naglunsad ng ilang uri ng vacuum, at lumikha ito ng load. Mayroon kaming isang uri ng problema. O ito ang bilang ng mga vacuum na nag-unscrew sa counter ng transaksyon. Para sa ilang mga bersyon ng PostgreSQL ito ay napakabigat na mga vacuum. At madali nilang madaragdagan ang pagganap dahil binabasa nila ang buong talahanayan, i-scan ang lahat ng mga bloke sa talahanayang iyon.

At, siyempre, ang tagal ng mga vacuum. Kung mayroon tayong mga pangmatagalang vacuum na tumatakbo nang napakatagal, nangangahulugan ito na kailangan nating muling bigyang pansin ang pagsasaayos ng vacuum at marahil ay muling isaalang-alang ang mga setting nito. Dahil ang isang sitwasyon ay maaaring lumitaw kapag ang vacuum ay gumagana sa mesa sa loob ng mahabang panahon (3-4 na oras), ngunit sa oras na ang vacuum ay gumagana, ang isang malaking halaga ng mga patay na hanay ay pinamamahalaang upang maipon muli sa talahanayan. At sa sandaling makumpleto ang vacuum, kailangan niyang i-vacuum muli ang talahanayang ito. At dumating tayo sa isang sitwasyon - isang walang katapusang vacuum. At sa kasong ito, ang vacuum ay hindi nakayanan ang trabaho nito, at ang mga talahanayan ay unti-unting nagsisimulang lumaki sa laki, bagaman ang dami ng kapaki-pakinabang na data sa loob nito ay nananatiling pareho. Samakatuwid, sa mahabang panahon ng vacuum, palagi naming tinitingnan ang pagsasaayos at sinusubukang i-optimize ito, ngunit sa parehong oras upang ang pagganap ng mga kahilingan ng kliyente ay hindi magdusa.

Sa ngayon, halos walang pag-install ng PostgreSQL na walang streaming na pagtitiklop. Ang pagtitiklop ay ang proseso ng paglipat ng data mula sa isang master patungo sa isang replika.

Ang pagtitiklop sa PostgreSQL ay ginagawa sa pamamagitan ng isang log ng transaksyon. Bumubuo ang wizard ng log ng transaksyon. Ang log ng transaksyon ay naglalakbay sa koneksyon ng network patungo sa replica, at pagkatapos ay i-reproduce ito sa replica. Simple lang.

Alinsunod dito, ang pg_stat_replication view ay ginagamit upang subaybayan ang replication lag. Ngunit hindi lahat ay simple sa kanya. Sa bersyon 10, ang view ay sumailalim sa ilang mga pagbabago. Una, pinalitan ng pangalan ang ilang field. At ang ilang mga patlang ay naidagdag. Sa bersyon 10, lumitaw ang mga field na nagbibigay-daan sa iyong tantiyahin ang lag ng pagtitiklop sa loob ng ilang segundo. Ito ay napaka komportable. Bago ang bersyon 10, posibleng tantyahin ang lag ng pagtitiklop sa mga byte. Ang pagpipiliang ito ay nananatili sa bersyon 10, ibig sabihin, maaari mong piliin kung ano ang mas maginhawa para sa iyo - tantyahin ang lag sa mga byte o tantyahin ang lag sa mga segundo. Maraming tao ang gumagawa ng pareho.

Ngunit gayunpaman, upang masuri ang lag ng pagtitiklop, kailangan mong malaman ang posisyon ng log sa transaksyon. At ang mga posisyon ng log ng transaksyon na ito ay eksaktong nasa pg_stat_replication view. Sa relatibong pagsasalita, maaari tayong kumuha ng dalawang puntos sa log ng transaksyon gamit ang pg_xlog_location_diff() function. Kalkulahin ang delta sa pagitan ng mga ito at kunin ang replication lag sa bytes. Ito ay napaka-maginhawa at simple.

Sa bersyon 10, pinalitan ng pangalan ang function na ito sa pg_wal_lsn_diff(). Sa pangkalahatan, sa lahat ng function, view, at utility kung saan natagpuan ang salitang "xlog", pinalitan ito ng value na "wal". Nalalapat ito sa parehong mga view at function. Ito ay isang pagbabago.

Dagdag pa, sa bersyon 10, idinagdag ang mga linya na partikular na nagpapakita ng lag. Ito ay write lag, flush lag, replay lag. Ibig sabihin, mahalagang subaybayan ang mga bagay na ito. Kung nakita natin na mayroon tayong replication lag, kailangan nating imbestigahan kung bakit ito lumitaw, kung saan ito nanggaling at ayusin ang problema.

Halos lahat ay maayos sa mga sukatan ng system. Kapag nagsimula ang anumang pagsubaybay, magsisimula ito sa mga sukatan ng system. Ito ang pagtatapon ng mga processor, memorya, swap, network at disk. Gayunpaman, maraming mga parameter ang wala doon bilang default.

Kung ang lahat ay maayos sa proseso ng pag-recycle, kung gayon may mga problema sa pag-recycle ng disk. Bilang isang tuntunin, ang mga developer ng pagsubaybay ay nagdaragdag ng impormasyon tungkol sa throughput. Maaari itong nasa iops o bytes. Ngunit nakakalimutan nila ang tungkol sa latency at paggamit ng mga disk device. Ang mga ito ay mas mahalagang mga parameter na nagbibigay-daan sa amin upang suriin kung gaano na-load ang aming mga disk at kung gaano kabagal ang mga ito. Kung mayroon kaming mataas na latency, nangangahulugan ito na may ilang mga problema sa mga disk. Kung mayroon kaming mataas na paggamit, nangangahulugan ito na ang mga disk ay hindi nakakaya. Ang mga ito ay mas mahusay na mga katangian kaysa sa throughput.

Bukod dito, ang mga istatistikang ito ay maaari ding makuha mula sa /proc file system, tulad ng ginagawa para sa mga recycling processor. Hindi ko alam kung bakit hindi idinaragdag ang impormasyong ito sa pagsubaybay. Ngunit gayunpaman, mahalagang magkaroon nito sa iyong pagsubaybay.

Ang parehong naaangkop sa mga interface ng network. Mayroong impormasyon tungkol sa throughput ng network sa mga packet, sa mga byte, ngunit gayunpaman walang impormasyon tungkol sa latency at walang impormasyon tungkol sa paggamit, bagama't ito ay kapaki-pakinabang din na impormasyon.

Ang anumang pagsubaybay ay may mga kakulangan. At kahit na anong uri ng pagsubaybay ang gawin mo, palaging hindi ito makakatugon sa ilang pamantayan. Ngunit gayunpaman, sila ay umuunlad, ang mga bagong tampok at mga bagong bagay ay idinagdag, kaya pumili ng isang bagay at tapusin ito.

At para makatapos, dapat lagi kang magkaroon ng ideya kung ano ang ibig sabihin ng mga istatistikang ibinigay at kung paano mo magagamit ang mga ito upang malutas ang mga problema.

At ilang mahahalagang punto:

• Dapat mong palaging subaybayan ang kakayahang magamit at magkaroon ng mga dashboard upang mabilis mong masuri na ang lahat ay maayos sa database.
• Kailangan mong palaging magkaroon ng ideya kung anong mga kliyente ang nagtatrabaho sa iyong database upang maalis ang mga masasamang kliyente at mabaril sila.
• Mahalagang suriin kung paano gumagana ang mga kliyenteng ito sa data. Kailangan mong magkaroon ng ideya tungkol sa iyong workload.
• Mahalagang suriin kung paano nabuo ang workload na ito, sa tulong ng kung anong mga query. Maaari mong suriin ang mga query, maaari mong i-optimize ang mga ito, refactor ang mga ito, bumuo ng mga index para sa kanila. Napakahalaga nito.
• Ang mga proseso sa background ay maaaring negatibong makaapekto sa mga kahilingan ng kliyente, kaya mahalagang subaybayan na hindi sila gumagamit ng masyadong maraming mapagkukunan.
• Nagbibigay-daan sa iyo ang mga sukatan ng system na gumawa ng mga plano para sa pag-scale at pagpapataas ng kapasidad ng iyong mga server, kaya mahalagang subaybayan at suriin din ang mga ito.

Kung interesado ka sa paksang ito, maaari mong sundin ang mga link na ito.
http://bit.do/stats_collector - ito ay opisyal na dokumentasyon mula sa kolektor ng istatistika. Mayroong isang paglalarawan ng lahat ng mga istatistikal na pagtingin at isang paglalarawan ng lahat ng mga patlang. Maaari mong basahin, unawain at pag-aralan ang mga ito. At batay sa mga ito, buuin ang iyong mga graph at idagdag ang mga ito sa iyong pagsubaybay.

Mga halimbawang kahilingan:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Ito ang aming corporate repository at sarili ko. Naglalaman ang mga ito ng mga halimbawang query. Walang mga query mula sa piling* mula sa serye doon. Mayroon nang mga handa na query na may mga pagsali, gamit ang mga kagiliw-giliw na function na nagbibigay-daan sa iyo upang gawing nababasa, maginhawang mga halaga, i.e. ito ay mga byte, oras. Maaari mong kunin ang mga ito, tingnan ang mga ito, pag-aralan ang mga ito, idagdag ang mga ito sa iyong pagsubaybay, buuin ang iyong pagsubaybay batay sa kanila.

mga katanungan

Tanong: Sinabi mo na hindi ka mag-a-advertise ng mga tatak, ngunit nagtataka pa rin ako - anong uri ng mga dashboard ang ginagamit mo sa iyong mga proyekto?
Sagot: Iba-iba ito. It happens that we come to a customer and meron na siyang sariling monitoring. At pinapayuhan namin ang customer kung ano ang kailangang idagdag sa kanilang pagsubaybay. Ang pinakamasamang sitwasyon ay kasama si Zabbix. Dahil wala itong kakayahang bumuo ng mga TopN graph. Kami mismo ang gumagamit Okmeter, dahil kinukunsulta namin ang mga taong ito sa pagsubaybay. Sinusubaybayan nila ang PostgreSQL batay sa aming mga teknikal na detalye. Nagsusulat ako ng sarili kong pet-project, na nangongolekta ng data sa pamamagitan ng Prometheus at nag-render nito grafana. Ang aking gawain ay lumikha ng sarili kong exporter sa Prometheus at pagkatapos ay i-render ang lahat sa Grafana.

Tanong: Mayroon bang anumang mga analogue ng mga ulat ng AWR o... pagsasama-sama? May alam ka bang ganito?
Sagot: Oo, alam ko kung ano ang AWR, ito ay isang cool na bagay. Sa ngayon, mayroong iba't ibang mga bisikleta na nagpapatupad ng humigit-kumulang sa sumusunod na modelo. Sa ilang pagitan ng oras, ang ilang mga baseline ay isinusulat sa parehong PostgreSQL o sa isang hiwalay na storage. Maaari mong i-google ang mga ito sa Internet, nandiyan sila. Ang isa sa mga nag-develop ng ganoong bagay ay nakaupo sa sql.ru forum sa PostgreSQL thread. Mahuhuli mo siya doon. Oo, may mga ganoong bagay, maaari silang magamit. Plus sa nito pgCenter Nagsusulat din ako ng isang bagay na nagpapahintulot sa iyo na gawin ang parehong bagay.

PS1 Kung gumagamit ka ng postgres_exporter, anong dashboard ang ginagamit mo? Mayroong ilan sa kanila. Outdated na sila. Baka gagawa ang komunidad ng na-update na template?

Inalis ng PS2 ang pganalyze dahil isa itong pagmamay-ari na alok ng SaaS na nakatuon sa pagsubaybay sa pagganap at mga suhestyon sa awtomatikong pag-tune.

Ang mga rehistradong user lamang ang maaaring lumahok sa survey. Mag-sign in, pakiusap

Aling self-hosted postgresql monitoring (na may dashboard) ang itinuturing mong pinakamahusay?

• 30,0%Zabbix + mga karagdagan mula kay Alexey Lesovsky o zabbix 4.4 o 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%Ang pganalyze ay isang pagmamay-ari na SaaS - hindi ko ito matatanggal1

• 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 user ang bumoto. 26 na user ang umiwas.

Pinagmulan: www.habr.com