Ninapendekeza usome nakala ya ripoti ya Alexey Lesovsky kutoka kwa Data Egret "Misingi ya ufuatiliaji wa PostgreSQL"
Katika ripoti hii, Alexey Lesovsky atazungumzia kuhusu pointi muhimu za takwimu za baada ya gress, nini maana yake, na kwa nini wanapaswa kuwepo katika ufuatiliaji; kuhusu grafu zipi zinapaswa kuwa katika ufuatiliaji, jinsi ya kuziongeza na jinsi ya kuzitafsiri. Ripoti itakuwa muhimu kwa wasimamizi wa hifadhidata, wasimamizi wa mfumo na wasanidi programu ambao wangependa utatuzi wa Postgres.
Jina langu ni Alexey Lesovsky, ninawakilisha kampuni ya Data Egret.
Maneno machache kuhusu mimi mwenyewe. Nilianza muda mrefu uliopita kama msimamizi wa mfumo.
Nilisimamia kila aina ya mifumo tofauti ya Linux, nilifanya kazi kwenye mambo mbalimbali yanayohusiana na Linux, yaani, virtualization, ufuatiliaji, nilifanya kazi na washirika, nk. Lakini wakati fulani nilianza kufanya kazi zaidi na hifadhidata, PostgreSQL. Nilimpenda sana. Na wakati fulani nilianza kufanya kazi kwenye PostgreSQL zaidi ya wakati wangu wa kufanya kazi. Na kwa hivyo polepole nikawa PostgreSQL DBA.
Na katika kazi yangu yote, nimekuwa nikipendezwa na mada za takwimu, ufuatiliaji, na telemetry. Na nilipokuwa msimamizi wa mfumo, nilifanya kazi kwa karibu sana na Zabbix. Na niliandika seti ndogo ya maandishi kama . Alikuwa maarufu sana wakati wake. Na huko iliwezekana kufuatilia mambo tofauti sana muhimu, si tu Linux, lakini pia vipengele mbalimbali.
Sasa ninafanya kazi kwenye PostgreSQL. Tayari ninaandika jambo lingine ambalo hukuruhusu kufanya kazi na takwimu za PostgreSQL. Inaitwa (makala ya Habre - ).
Kidokezo kidogo cha utangulizi. Wateja wetu na wateja wetu wana hali gani? Kuna aina fulani ya ajali inayohusiana na hifadhidata. Na wakati hifadhidata tayari imerejeshwa, mkuu wa idara au mkuu wa maendeleo huja na kusema: "Marafiki, tunahitaji kufuatilia hifadhidata, kwa sababu kuna jambo baya limetokea na tunahitaji kuzuia hili kutokea katika siku zijazo." Na hapa huanza mchakato wa kuvutia wa kuchagua mfumo wa ufuatiliaji au kurekebisha mfumo uliopo wa ufuatiliaji ili uweze kufuatilia hifadhidata yako - PostgreSQL, MySQL au zingine. Na wenzake wanaanza kupendekeza: "Nilisikia kwamba kuna hifadhidata kama hiyo. Tuitumie." Wenzake wanaanza kugombana wao kwa wao. Na mwishowe inageuka kuwa tunachagua aina fulani ya hifadhidata, lakini ufuatiliaji wa PostgreSQL unawasilishwa ndani yake badala ya vibaya na tunapaswa kuongeza kitu kila wakati. Chukua hazina kutoka kwa GitHub, zitengeneze, rekebisha hati, na ubadilishe kukufaa. Na mwishowe inaishia kuwa aina fulani ya kazi ya mwongozo.
Kwa hiyo, katika mazungumzo haya nitajaribu kukupa ujuzi fulani juu ya jinsi ya kuchagua ufuatiliaji sio tu kwa PostgreSQL, lakini pia kwa hifadhidata. Na kukupa maarifa yatakayokuruhusu kukamilisha ufuatiliaji wako ili kupata manufaa fulani kutoka kwayo, ili uweze kufuatilia hifadhidata yako kwa manufaa, ili kuzuia mara moja hali zozote zijazo za dharura zinazoweza kutokea.
Na mawazo ambayo yatakuwa katika ripoti hii yanaweza kubadilishwa moja kwa moja kwa hifadhidata yoyote, iwe DBMS au noSQL. Kwa hivyo, hakuna PostgreSQL pekee, lakini kutakuwa na mapishi mengi ya jinsi ya kufanya hivyo katika PostgreSQL. Kutakuwa na mifano ya maswali, mifano ya mashirika ambayo PostgreSQL inayo kwa ufuatiliaji. Na ikiwa DBMS yako ina vitu sawa vinavyokuwezesha kuziweka katika ufuatiliaji, unaweza pia kuzibadilisha, kuziongeza na itakuwa nzuri.
Sitakuwa kwenye ripoti
zungumza kuhusu jinsi ya kutoa na kuhifadhi vipimo. Sitasema chochote kuhusu kuchakata baada ya usindikaji wa data na kuiwasilisha kwa mtumiaji. Na sitasema chochote kuhusu kuonya.
Lakini hadithi inavyoendelea, nitaonyesha viwambo tofauti vya ufuatiliaji uliopo na kwa namna fulani kuwakosoa. Lakini hata hivyo, nitajaribu kutotaja chapa ili nisitengeneze utangazaji au kupinga utangazaji wa bidhaa hizi. Kwa hivyo, matukio yote ni ya nasibu na yameachwa kwa mawazo yako.
Kwanza, hebu tujue ufuatiliaji ni nini. Ufuatiliaji ni jambo muhimu sana kuwa nalo. Kila mtu anaelewa hili. Lakini wakati huo huo, ufuatiliaji hauhusiani na bidhaa za biashara na hauathiri moja kwa moja faida ya kampuni, hivyo wakati daima hutolewa kwa ufuatiliaji kwa msingi wa mabaki. Ikiwa tuna muda, basi tunafanya ufuatiliaji; ikiwa hatuna muda, basi sawa, tutaiweka kwenye kumbukumbu na siku moja tutarejea kwenye kazi hizi.
Kwa hiyo, kutokana na mazoezi yetu, tunapokuja kwa wateja, ufuatiliaji mara nyingi haujakamilika na hauna mambo yoyote ya kuvutia ambayo yanaweza kutusaidia kufanya kazi bora na hifadhidata. Na kwa hivyo ufuatiliaji unahitaji kukamilika kila wakati.
Hifadhidata ni vitu ngumu ambavyo pia vinahitaji kufuatiliwa, kwa sababu hifadhidata ni hazina ya habari. Na habari ni muhimu sana kwa kampuni; haiwezi kupotea kwa njia yoyote. Lakini wakati huo huo, hifadhidata ni vipande ngumu sana vya programu. Wao hujumuisha idadi kubwa ya vipengele. Na nyingi ya vipengele hivi vinahitaji kufuatiliwa.
Ikiwa tunazungumzia hasa kuhusu PostgreSQL, basi inaweza kuwakilishwa kwa namna ya mpango unaojumuisha idadi kubwa ya vipengele. Vipengele hivi vinaingiliana. Na wakati huo huo, PostgreSQL ina kinachojulikana kama mfumo mdogo wa Ukusanyaji wa Takwimu, ambayo hukuruhusu kukusanya takwimu kuhusu utendakazi wa mifumo hii ndogo na kutoa aina fulani ya kiolesura kwa msimamizi au mtumiaji ili aweze kutazama takwimu hizi.
Takwimu hizi zinawasilishwa kwa namna ya seti fulani ya kazi na maoni. Wanaweza pia kuitwa meza. Hiyo ni, kwa kutumia mteja wa kawaida wa psql, unaweza kuunganisha kwenye hifadhidata, chagua kazi na maoni haya, na kupata nambari maalum kuhusu uendeshaji wa mifumo ndogo ya PostgreSQL.
Unaweza kuongeza nambari hizi kwenye mfumo unaopenda wa ufuatiliaji, kuchora grafu, kuongeza vitendaji na kupata uchanganuzi kwa muda mrefu.
Lakini katika ripoti hii sitashughulikia kazi hizi zote kabisa, kwa sababu inaweza kuchukua siku nzima. Nitashughulikia mambo mawili, matatu au manne na kukuambia jinsi yanavyosaidia kufanya ufuatiliaji kuwa bora zaidi.
Na ikiwa tunazungumza juu ya ufuatiliaji wa hifadhidata, basi ni nini kinachohitajika kufuatiliwa? Kwanza kabisa, tunahitaji kufuatilia upatikanaji, kwa sababu database ni huduma ambayo hutoa upatikanaji wa data kwa wateja na tunahitaji kufuatilia upatikanaji, na pia kutoa baadhi ya sifa zake za ubora na kiasi.
Pia tunahitaji kufuatilia wateja wanaounganisha kwenye hifadhidata yetu, kwa sababu wanaweza kuwa wateja wa kawaida na wateja hatari ambao wanaweza kudhuru hifadhidata. Pia wanahitaji kufuatiliwa na kufuatiliwa shughuli zao.
Wateja wanapounganisha kwenye hifadhidata, ni dhahiri kwamba wanaanza kufanya kazi na data zetu, kwa hivyo tunahitaji kufuatilia jinsi wateja wanavyofanya kazi na data: na majedwali gani, na kwa kiwango kidogo, na faharisi zipi. Hiyo ni, tunahitaji kutathmini mzigo wa kazi ambao umeundwa na wateja wetu.
Lakini mzigo wa kazi pia una, bila shaka, maombi. Maombi huunganishwa kwenye hifadhidata, fikia data kwa kutumia maswali, kwa hivyo ni muhimu kutathmini ni maswali gani tunayo kwenye hifadhidata, kufuatilia utoshelevu wao, kwamba hayajaandikwa kwa upotovu, kwamba chaguzi zingine zinahitaji kuandikwa upya na kufanywa ili zifanye kazi haraka. na utendaji bora.
Na kwa kuwa tunazungumza juu ya hifadhidata, hifadhidata ni michakato ya nyuma kila wakati. Michakato ya usuli husaidia kudumisha utendakazi wa hifadhidata kwa kiwango kizuri, kwa hivyo zinahitaji kiasi fulani cha rasilimali ili zifanye kazi. Na wakati huo huo, wanaweza kuingiliana na rasilimali za ombi la mteja, kwa hivyo michakato ya nyuma ya uchoyo inaweza kuathiri moja kwa moja utendaji wa maombi ya mteja. Kwa hiyo, wanahitaji pia kufuatiliwa na kufuatiliwa ili hakuna upotovu katika suala la michakato ya nyuma.
Na hii yote kwa suala la ufuatiliaji wa hifadhidata inabaki kwenye metriki ya mfumo. Lakini kwa kuzingatia kwamba miundombinu yetu mingi inahamia kwenye uwingu, vipimo vya mfumo wa seva pangishi kila mara hufifia chinichini. Lakini katika hifadhidata bado ni muhimu na, bila shaka, ni muhimu pia kufuatilia metrics za mfumo.
Kila kitu kiko sawa na vipimo vya mfumo, mifumo yote ya kisasa ya ufuatiliaji tayari inasaidia vipimo hivi, lakini kwa ujumla, baadhi ya vipengele bado havitoshi na baadhi ya vitu vinahitaji kuongezwa. Pia nitagusa juu yao, kutakuwa na slaidi kadhaa juu yao.
Hatua ya kwanza ya mpango ni upatikanaji. Ufikivu ni nini? Upatikanaji katika ufahamu wangu ni uwezo wa msingi wa miunganisho ya huduma, i.e. msingi umeinuliwa, kama huduma, inakubali miunganisho kutoka kwa wateja. Na upatikanaji huu unaweza kutathminiwa na sifa fulani. Ni rahisi sana kuonyesha sifa hizi kwenye dashibodi.
Kila mtu anajua dashibodi ni nini. Huu ndio wakati uliangalia skrini moja ambayo habari muhimu imefupishwa. Na unaweza kuamua mara moja ikiwa kuna shida kwenye hifadhidata au la.
Ipasavyo, upatikanaji wa hifadhidata na sifa zingine muhimu zinapaswa kuonyeshwa kila wakati kwenye dashibodi ili habari hii iko karibu na inapatikana kwako kila wakati. Baadhi ya maelezo ya ziada ambayo tayari yanasaidia katika uchunguzi wa matukio, wakati wa kuchunguza baadhi ya hali za dharura, tayari yanahitaji kuwekwa kwenye dashibodi za pili, au kufichwa katika viungo vya kuchimbua ambavyo husababisha mifumo ya ufuatiliaji wa watu wengine.
Mfano wa mfumo mmoja wa ufuatiliaji unaojulikana. Huu ni mfumo mzuri sana wa ufuatiliaji. Anakusanya data nyingi, lakini kwa mtazamo wangu, ana dhana ya ajabu ya dashibodi. Kuna kiungo cha "kuunda dashibodi". Lakini unapounda dashibodi, unaunda orodha ya safu wima mbili, orodha ya grafu. Na unapohitaji kuangalia kitu, unaanza kubofya na panya, ukizunguka, ukitafuta chati inayotakiwa. Na hii inachukua muda, i.e. hakuna dashibodi kama hizo. Kuna orodha tu za chati.
Je, unapaswa kuongeza nini kwenye dashibodi hizi? Unaweza kuanza na sifa kama vile wakati wa kujibu. PostgreSQL ina mwonekano wa pg_stat_statements. Imezimwa kwa chaguo-msingi, lakini ni mojawapo ya mitazamo muhimu ya mfumo ambayo inapaswa kuwashwa na kutumiwa kila wakati. Huhifadhi taarifa kuhusu maswali yote yanayoendeshwa ambayo yametekelezwa katika hifadhidata.
Ipasavyo, tunaweza kuanza kutoka kwa ukweli kwamba tunaweza kuchukua muda wa utekelezaji wa maombi yote na kuigawanya kwa idadi ya maombi kwa kutumia sehemu zilizo hapo juu. Lakini hii ni joto la wastani katika hospitali. Tunaweza kuanza kutoka nyanja zingine - muda wa chini zaidi wa utekelezaji wa hoja, upeo na wastani. Na tunaweza hata kujenga percentiles; PostgreSQL ina kazi zinazolingana kwa hili. Na tunaweza kupata nambari kadhaa ambazo zinaonyesha wakati wa majibu ya hifadhidata yetu kwa maombi yaliyokamilishwa tayari, i.e. hatutekelezi ombi la uwongo 'chagua 1' na kuangalia wakati wa kujibu, lakini tunachambua wakati wa kujibu kwa maombi yaliyokamilishwa tayari na kuchora. ama takwimu tofauti, au tunajenga grafu kulingana na hilo.
Pia ni muhimu kufuatilia idadi ya makosa ambayo sasa yanazalishwa na mfumo. Na kwa hili unaweza kutumia mwonekano wa pg_stat_database. Tunazingatia uga wa xact_rollback. Sehemu hii inaonyesha sio tu idadi ya kurudi nyuma ambayo hufanyika kwenye hifadhidata, lakini pia inazingatia idadi ya makosa. Kwa kulinganishwa, tunaweza kuonyesha takwimu hii kwenye dashibodi yetu na kuona ni makosa ngapi tuliyo nayo kwa sasa. Ikiwa kuna makosa mengi, basi hii ni sababu nzuri ya kuangalia ndani ya magogo na kuona ni aina gani ya makosa na kwa nini hutokea, na kisha kuwekeza na kutatua.
Unaweza kuongeza kitu kama Tachometer. Hizi ni idadi ya miamala kwa sekunde na idadi ya maombi kwa sekunde. Kwa kulinganishwa, unaweza kutumia nambari hizi kama utendakazi wa sasa wa hifadhidata yako na uangalie ikiwa kuna kilele cha maombi, kilele cha miamala, au, kinyume chake, ikiwa hifadhidata imepakiwa kwa sababu sehemu nyingine ya nyuma imeshindwa. Ni muhimu kutazama takwimu hii kila wakati na kukumbuka kuwa kwa mradi wetu aina hii ya utendaji ni ya kawaida, lakini maadili hapo juu na chini tayari ni aina fulani ya shida na isiyoeleweka, ambayo inamaanisha tunahitaji kuangalia kwa nini nambari hizi ziko. juu sana.
Ili kukadiria idadi ya miamala, tunaweza tena kurejelea mwonekano wa hifadhidata ya pg_stat. Tunaweza kuongeza idadi ya ahadi na idadi ya kurudi nyuma na kupata idadi ya miamala kwa sekunde.
Je, kila mtu anaelewa kuwa maombi kadhaa yanaweza kutoshea katika shughuli moja? Kwa hivyo TPS na QPS ni tofauti kidogo.
Idadi ya maombi kwa sekunde inaweza kupatikana kutoka pg_stat_statements na kukokotoa tu jumla ya maombi yote yaliyokamilishwa. Ni wazi kwamba tunalinganisha thamani ya sasa na ya awali, toa, pata delta, na upate wingi.
Unaweza kuongeza vipimo vya ziada ukipenda, ambavyo pia husaidia kutathmini upatikanaji wa hifadhidata yetu na kufuatilia ikiwa kumekuwa na nyakati zozote za kutofanyika.
Moja ya vipimo hivi ni uptime. Lakini uptime katika PostgreSQL ni gumu kidogo. Nitakuambia kwa nini. Wakati PostgreSQL imeanza, uptime huanza kuripoti. Lakini ikiwa wakati fulani, kwa mfano, kazi fulani ilikuwa ikiendelea usiku, muuaji wa OOM alikuja na kukomesha kwa nguvu mchakato wa mtoto wa PostgreSQL, basi katika kesi hii PostgreSQL inasitisha muunganisho wa wateja wote, kuweka upya eneo la kumbukumbu iliyokatwa na kuanza kupona kutoka. kituo cha ukaguzi cha mwisho. Na wakati urejeshaji huu kutoka kwa ukaguzi unadumu, hifadhidata haikubali miunganisho, i.e. hali hii inaweza kutathminiwa kama wakati wa kupumzika. Lakini kihesabu cha uptime hakitawekwa upya, kwa sababu inazingatia muda wa kuanzisha postmaster kutoka wakati wa kwanza kabisa. Kwa hivyo, hali kama hizo zinaweza kuruka.
Unapaswa pia kufuatilia idadi ya wafanyakazi wa utupu. Kila mtu anajua autovacuum ni nini katika PostgreSQL? Huu ni mfumo mdogo wa kuvutia katika PostgreSQL. Nakala nyingi zimeandikwa juu yake, ripoti nyingi zimetolewa. Kuna mijadala mingi kuhusu ombwe na jinsi inavyopaswa kufanya kazi. Wengi wanaona kuwa ni uovu wa lazima. Lakini ndivyo ilivyo. Hii ni aina ya analogi ya mtoza takataka ambayo husafisha matoleo ya zamani ya safu mlalo ambayo haihitajiki na shughuli yoyote na kutoa nafasi katika jedwali na faharisi kwa safu mpya.
Kwa nini unahitaji kuifuatilia? Kwa sababu utupu wakati mwingine huumiza sana. Inatumia kiasi kikubwa cha rasilimali na maombi ya mteja huanza kuteseka kama matokeo.
Na inapaswa kufuatiliwa kupitia pg_stat_activity view, ambayo nitazungumzia katika sehemu inayofuata. Mwonekano huu unaonyesha shughuli ya sasa katika hifadhidata. Na kupitia shughuli hii tunaweza kufuatilia idadi ya ombwe zinazofanya kazi hivi sasa. Tunaweza kufuatilia ombwe na kuona kwamba ikiwa tumezidi kikomo, basi hii ni sababu ya kuangalia mipangilio ya PostgreSQL na kwa namna fulani kuboresha utendakazi wa ombwe.
Jambo lingine kuhusu PostgreSQL ni kwamba PostgreSQL ni mgonjwa sana wa shughuli ndefu. Hasa kutoka kwa shughuli ambazo hutegemea kwa muda mrefu na hazifanyi chochote. Huu ndio unaoitwa stat-idle-in-transaction. Shughuli kama hiyo inashikilia kufuli na inazuia utupu kufanya kazi. Na matokeo yake, meza huvimba na kuongezeka kwa ukubwa. Na maswali yanayofanya kazi na meza hizi huanza kufanya kazi polepole, kwa sababu unahitaji kupiga matoleo yote ya zamani ya safu kutoka kwa kumbukumbu hadi diski na nyuma. Kwa hiyo, muda, muda wa shughuli ndefu zaidi, maombi ya muda mrefu ya utupu pia yanahitaji kufuatiliwa. Na ikiwa tunaona michakato kadhaa ambayo imekuwa ikiendelea kwa muda mrefu sana, tayari zaidi ya dakika 10-20-30 kwa mzigo wa OLTP, basi tunahitaji kuzizingatia na kuzizima kwa nguvu, au kuboresha programu ili waweze. si kuitwa na wala hutegemea muda mrefu. Kwa mzigo wa kazi ya uchambuzi, dakika 10-20-30 ni ya kawaida; pia kuna ndefu zaidi.
Ifuatayo, tunayo chaguo na wateja waliounganishwa. Wakati tayari tumeunda dashibodi na kuchapisha vipimo muhimu vya upatikanaji juu yake, tunaweza pia kuongeza maelezo ya ziada kuhusu wateja waliounganishwa hapo.
Taarifa kuhusu wateja waliounganishwa ni muhimu kwa sababu, kwa mtazamo wa PostgreSQL, wateja ni tofauti. Kuna wateja wazuri na kuna wateja wabaya.
Mfano rahisi. Kwa mteja ninaelewa programu. Programu imeunganishwa kwenye hifadhidata na mara moja huanza kutuma maombi yake hapo, hifadhidata inachakata na kuyatekeleza, na kurudisha matokeo kwa mteja. Hawa ni wateja wazuri na sahihi.
Kuna hali wakati mteja ameunganishwa, anashikilia uunganisho, lakini haifanyi chochote. Iko katika hali ya uvivu.
Lakini kuna wateja mbaya. Kwa mfano, mteja sawa aliunganishwa, alifungua shughuli, alifanya kitu kwenye hifadhidata na kisha akaingia kwenye msimbo, kwa mfano, kufikia chanzo cha nje au kusindika data iliyopokelewa huko. Lakini hakufunga shughuli hiyo. Na shughuli hutegemea hifadhidata na inashikiliwa kwa kufuli kwenye mstari. Hii ni hali mbaya. Na ikiwa ghafla maombi mahali fulani ndani yenyewe inashindwa isipokuwa, basi shughuli inaweza kubaki wazi kwa muda mrefu sana. Na hii inathiri moja kwa moja utendaji wa PostgreSQL. PostgreSQL itakuwa polepole. Kwa hiyo, ni muhimu kufuatilia wateja vile kwa wakati na kusitisha kazi zao kwa nguvu. Na unahitaji kuboresha programu yako ili hali kama hizi zisitokee.
Wateja wengine wabaya wanasubiri wateja. Lakini huwa mbaya kwa sababu ya hali. Kwa mfano, shughuli rahisi ya uvivu: inaweza kufungua shughuli, kuchukua kufuli kwenye mistari fulani, kisha mahali fulani katika msimbo itashindwa, na kuacha shughuli ya kunyongwa. Mteja mwingine atakuja na kuomba data sawa, lakini atakutana na kufuli, kwa sababu shughuli hiyo ya kunyongwa tayari inashikilia kufuli kwenye safu kadhaa zinazohitajika. Na muamala wa pili utaning'inia ukingoja muamala wa kwanza ukamilike au kuifunga kwa lazima na msimamizi. Kwa hiyo, shughuli zinazosubiri zinaweza kukusanya na kujaza kikomo cha muunganisho wa hifadhidata. Na wakati kikomo kimejaa, programu haiwezi kufanya kazi tena na hifadhidata. Hii tayari ni hali ya dharura kwa mradi. Kwa hiyo, wateja wabaya wanahitaji kufuatiliwa na kuitikiwa kwa wakati.
Mfano mwingine wa ufuatiliaji. Na tayari kuna dashibodi nzuri hapa. Kuna habari juu ya miunganisho hapo juu. Uunganisho wa DB - vipande 8. Na ni yote. Hatuna habari kuhusu ni wateja gani wanaofanya kazi, ni wateja gani hawana kazi tu, hawafanyi chochote. Hakuna taarifa kuhusu miamala inayosubiri na miunganisho inayosubiri, yaani, hii ni takwimu inayoonyesha idadi ya miunganisho na ndivyo hivyo. Na kisha fikiria mwenyewe.
Ipasavyo, ili kuongeza maelezo haya kwenye ufuatiliaji, unahitaji kufikia mwonekano wa mfumo wa pg_stat_activity. Ikiwa unatumia muda mwingi katika PostgreSQL, basi huu ni mtazamo mzuri sana ambao unapaswa kuwa rafiki yako, kwa sababu inaonyesha shughuli za sasa katika PostgreSQL, yaani kile kinachotokea ndani yake. Kwa kila mchakato kuna mstari tofauti unaoonyesha habari kuhusu mchakato huu: kutoka kwa mwenyeji gani uunganisho ulifanywa, chini ya mtumiaji gani, chini ya jina gani, wakati shughuli ilianza, ni ombi gani linaloendelea sasa, ni ombi gani lililotekelezwa mwisho. Na, ipasavyo, tunaweza kutathmini hali ya mteja kwa kutumia uwanja wa takwimu. Kwa ulinganifu, tunaweza kupanga kulingana na uga huu na kupata takwimu ambazo kwa sasa ziko kwenye hifadhidata na idadi ya miunganisho iliyo na takwimu hii kwenye hifadhidata. Na tunaweza kutuma nambari zilizopokelewa tayari kwa ufuatiliaji wetu na kuchora grafu kulingana nao.
Pia ni muhimu kutathmini muda wa shughuli. Tayari nilisema kuwa ni muhimu kutathmini muda wa utupu, lakini shughuli zinatathminiwa kwa njia ile ile. Kuna sehemu za xact_start na query_start. Wao, kwa kusema, wanaonyesha wakati wa kuanza kwa shughuli na wakati wa kuanza kwa ombi. Tunachukua chaguo la kukokotoa sasa(), ambalo linaonyesha muhuri wa muda wa sasa, na kutoa muamala na kuomba muhuri wa muda. Na tunapata muda wa shughuli, muda wa ombi.
Ikiwa tunaona shughuli za muda mrefu, tunapaswa kuzikamilisha tayari. Kwa mzigo wa OLTP, shughuli za muda mrefu tayari ni zaidi ya dakika 1-2-3. Kwa mzigo wa kazi wa OLAP, shughuli za muda mrefu ni za kawaida, lakini ikiwa huchukua zaidi ya saa mbili kukamilisha, basi hii pia ni ishara kwamba tuna skew mahali fulani.
Mara tu wateja wameunganishwa kwenye hifadhidata, wanaanza kufanya kazi na data yetu. Wanapata majedwali, wanapata faharisi ili kupata data kutoka kwa jedwali. Na ni muhimu kutathmini jinsi wateja wanavyoingiliana na data hii.
Hii ni muhimu ili kutathmini mzigo wetu wa kazi na kuelewa takriban ni majedwali gani ni "motomoto zaidi" kwetu. Kwa mfano, hii inahitajika katika hali ambapo tunataka kuweka meza "za moto" kwenye aina fulani ya hifadhi ya haraka ya SSD. Kwa mfano, baadhi ya majedwali ya kumbukumbu ambayo hatujatumia kwa muda mrefu yanaweza kuhamishiwa kwenye aina fulani ya kumbukumbu "baridi", hadi kwenye viendeshi vya SATA na kuziruhusu ziishi humo, zitafikiwa kama inahitajika.
Hii pia ni muhimu kwa kugundua hitilafu baada ya matoleo yoyote na matumizi. Wacha tuseme mradi umetoa kipengele kipya. Kwa mfano, tuliongeza utendaji mpya wa kufanya kazi na hifadhidata. Na ikiwa tutapanga grafu za matumizi ya jedwali, tunaweza kugundua hitilafu hizi kwenye grafu hizi kwa urahisi. Kwa mfano, sasisha kupasuka au kufuta milipuko. Itaonekana sana.
Unaweza pia kugundua hitilafu katika takwimu "zinazoelea". Ina maana gani? PostgreSQL ina mpangilio wa hoja wenye nguvu sana na mzuri sana. Na watengenezaji hutumia muda mwingi kwa maendeleo yake. Anafanyaje kazi? Ili kufanya mipango mizuri, PostgreSQL hukusanya takwimu za usambazaji wa data kwenye jedwali kwa muda fulani na kwa mzunguko fulani. Hizi ni maadili ya kawaida: idadi ya maadili ya kipekee, habari kuhusu NULL katika meza, habari nyingi.
Kulingana na takwimu hizi, mpangaji huunda hoja kadhaa, huchagua mojawapo zaidi, na hutumia mpango huu wa hoja kutekeleza hoja yenyewe na kurejesha data.
Na hutokea kwamba takwimu "huelea". Data ya ubora na wingi kwa namna fulani ilibadilika kwenye jedwali, lakini takwimu hazikukusanywa. Na mipango iliyoundwa inaweza isiwe sawa. Na ikiwa mipango yetu itageuka kuwa ndogo kulingana na ufuatiliaji uliokusanywa, kulingana na majedwali, tutaweza kuona hitilafu hizi. Kwa mfano, mahali fulani data ilibadilika kwa ubora na badala ya index, kupita kwa mlolongo kupitia meza ilianza kutumika, i.e. ikiwa swali linahitaji kurudisha safu mlalo 100 pekee (kuna kikomo cha 100), basi utafutaji kamili utafanywa kwa swali hili. Na hii daima ina athari mbaya sana juu ya utendaji.
Na tunaweza kuona hili katika ufuatiliaji. Na tayari angalia swala hili, endesha maelezo yake, kukusanya takwimu, jenga faharisi mpya ya ziada. Na tayari kujibu tatizo hili. Ndiyo maana ni muhimu.
Mfano mwingine wa ufuatiliaji. Nadhani watu wengi walimtambua kwa sababu ni maarufu sana. Ambao hutumia katika miradi yao ? Nani hutumia bidhaa hii kwa kushirikiana na Prometheus? Ukweli ni kwamba katika hazina ya kawaida ya ufuatiliaji huu kuna dashibodi ya kufanya kazi na PostgreSQL - Prometheus. Lakini kuna maelezo moja mbaya.
Kuna grafu kadhaa. Na byte zimeonyeshwa kama umoja, i.e. kuna grafu 5. Hizi ni Ingiza data, Sasisha data, Futa data, Leta data na Rejesha data. Kipimo cha kitengo ni ka. Lakini jambo ni kwamba takwimu katika PostgreSQL inarudisha data katika tuple (safu). Na, ipasavyo, grafu hizi ni njia nzuri sana ya kudharau mzigo wako wa kazi mara kadhaa, makumi ya nyakati, kwa sababu tuple sio byte, tuple ni kamba, ni byte nyingi na daima ni ya urefu wa kutofautiana. Hiyo ni, kuhesabu mzigo wa kazi katika byte kwa kutumia tuples ni kazi isiyo ya kweli au ngumu sana. Kwa hiyo, unapotumia dashibodi au ufuatiliaji uliojengwa, daima ni muhimu kuelewa kwamba inafanya kazi kwa usahihi na inakurudishia data iliyopimwa kwa usahihi.
Jinsi ya kupata takwimu kwenye meza hizi? Kwa kusudi hili, PostgreSQL ina familia fulani ya maoni. Na mtazamo kuu ni . User_tables - hii inamaanisha majedwali yaliyoundwa kwa niaba ya mtumiaji. Kinyume chake, kuna maoni ya mfumo ambayo hutumiwa na PostgreSQL yenyewe. Na kuna jedwali la muhtasari Alltables, ambalo linajumuisha mfumo na watumiaji. Unaweza kuanza kutoka kwa yeyote kati yao unayopenda zaidi.
Kwa kutumia sehemu zilizo hapo juu unaweza kukadiria idadi ya viingilio, masasisho na kufuta. Mfano wa dashibodi ambayo nilitumia hutumia sehemu hizi kutathmini sifa za mzigo wa kazi. Kwa hiyo, tunaweza pia kujenga juu yao. Lakini inafaa kukumbuka kuwa hizi ni nakala, sio ka, kwa hivyo hatuwezi kuifanya kwa kaiti.
Kulingana na data hii, tunaweza kuunda meza zinazoitwa TopN. Kwa mfano, Juu-5, Juu-10. Na unaweza kufuatilia meza hizo moto ambazo zinasindika zaidi kuliko zingine. Kwa mfano, meza 5 "za moto" za kuingizwa. Na kwa kutumia majedwali haya ya TopN tunatathmini mzigo wetu wa kazi na tunaweza kutathmini wingi wa mzigo baada ya matoleo, masasisho na utumiaji wowote.
Pia ni muhimu kutathmini ukubwa wa meza, kwa sababu wakati mwingine watengenezaji hutoa kipengele kipya, na meza zetu huanza kuvimba kwa ukubwa wao mkubwa, kwa sababu waliamua kuongeza kiasi cha ziada cha data, lakini hawakutabiri jinsi hii ingekuwa. kuathiri ukubwa wa hifadhidata. Kesi kama hizo pia huja kama mshangao kwetu.
Na sasa swali dogo kwako. Swali gani linatokea unapoona mzigo kwenye seva yako ya hifadhidata? Una swali gani linalofuata?
Lakini kwa kweli swali linatokea kama ifuatavyo. Je, mzigo husababisha maombi gani? Hiyo ni, sio kuvutia kuangalia taratibu zinazosababishwa na mzigo. Ni wazi kwamba ikiwa mwenyeji ana hifadhidata, basi hifadhidata inaendeshwa hapo na ni wazi kuwa hifadhidata pekee ndizo zitakazotupwa hapo. Ikiwa tutafungua Juu, tutaona kuna orodha ya michakato katika PostgreSQL ambayo inafanya kitu. Haitakuwa wazi kutoka Juu wanachofanya.
Ipasavyo, unahitaji kupata maswali ambayo husababisha mzigo wa juu zaidi, kwa sababu maswali ya kurekebisha, kama sheria, hutoa faida zaidi kuliko kurekebisha PostgreSQL au usanidi wa mfumo wa uendeshaji, au hata kurekebisha vifaa. Kulingana na makadirio yangu, hii ni takriban 80-85-90%. Na hii inafanywa kwa kasi zaidi. Ni haraka kusahihisha ombi kuliko kusahihisha usanidi, ratiba ya kuanza upya, haswa ikiwa hifadhidata haiwezi kuanza tena, au kuongeza maunzi. Ni rahisi kuandika swali upya mahali fulani au kuongeza faharasa ili kupata matokeo bora kutoka kwa swali hili.
Ipasavyo, ni muhimu kufuatilia maombi na utoshelevu wao. Hebu tuchukue mfano mwingine wa ufuatiliaji. Na hapa, pia, inaonekana kuna ufuatiliaji bora. Kuna habari juu ya replication, kuna habari juu ya throughput, kuzuia, matumizi ya rasilimali. Kila kitu ni sawa, lakini hakuna habari juu ya maombi. Haijulikani ni hoja gani zinazoendeshwa katika hifadhidata yetu, zinaendeshwa kwa muda gani, ni hoja ngapi kati ya hizi. Daima tunahitaji kuwa na habari hii katika ufuatiliaji wetu.
Na kupata habari hii tunaweza kutumia pg_stat_statements moduli. Kulingana na hilo, unaweza kuunda aina mbalimbali za grafu. Kwa mfano, unaweza kupata habari juu ya maswali ya mara kwa mara, ambayo ni, juu ya maswali ambayo yanatekelezwa mara nyingi. Ndio, baada ya kupelekwa pia ni muhimu sana kuiangalia na kuelewa ikiwa kuna kuongezeka kwa maombi.
Unaweza kufuatilia hoja ndefu zaidi, yaani, maswali ambayo huchukua muda mrefu zaidi kukamilika. Wanaendesha kwenye processor, hutumia I/O. Tunaweza pia kutathmini hili kwa kutumia sehemu total_time, mean_time, blk_write_time na blk_read_time.
Tunaweza kutathmini na kufuatilia maombi mazito zaidi kwa suala la matumizi ya rasilimali, wale wanaosoma kutoka kwa diski, wanaofanya kazi na kumbukumbu, au, kinyume chake, kuunda aina fulani ya mzigo wa kuandika.
Tunaweza kutathmini maombi ya ukarimu zaidi. Haya ni maswali ambayo yanarudisha idadi kubwa ya safu mlalo. Kwa mfano, hii inaweza kuwa ombi fulani ambapo walisahau kuweka kikomo. Na inarudisha tu yaliyomo yote ya jedwali au hoja kwenye jedwali zilizoulizwa.
Na unaweza pia kufuatilia maswali yanayotumia faili za muda au meza za muda.
Na bado tuna michakato ya usuli. Michakato ya usuli kimsingi ni vituo vya ukaguzi au pia huitwa vituo vya ukaguzi, hizi ni otomatiki na urudufishaji.
Mfano mwingine wa ufuatiliaji. Kuna kichupo cha Matengenezo upande wa kushoto, nenda humo na utumaini kuona kitu muhimu. Lakini hapa ni wakati tu wa operesheni ya utupu na ukusanyaji wa takwimu, hakuna zaidi. Haya ni taarifa duni sana, kwa hivyo tunahitaji kuwa na taarifa kuhusu jinsi michakato ya usuli inavyofanya kazi katika hifadhidata yetu na kama kuna matatizo yoyote kutoka kwa kazi yao.
Tunapoangalia vituo vya ukaguzi, tunapaswa kukumbuka kuwa vituo vya ukaguzi vinafuta kurasa chafu kutoka eneo la kumbukumbu iliyokatwa hadi kwenye diski, kisha unda kituo cha ukaguzi. Na kituo hiki cha ukaguzi kinaweza kutumika kama mahali pa kupona ikiwa PostgreSQL ilikomeshwa ghafla katika dharura.
Ipasavyo, ili kufuta kurasa zote "chafu" kwenye diski, unahitaji kufanya kiasi fulani cha kuandika. Na, kama sheria, kwenye mifumo iliyo na kumbukumbu nyingi, hii ni nyingi. Na ikiwa tutafanya vituo vya ukaguzi mara nyingi sana kwa muda mfupi, basi utendaji wa diski utashuka sana. Na maombi ya mteja yatakabiliwa na ukosefu wa rasilimali. Watashindana kwa rasilimali na kukosa tija.
Ipasavyo, kupitia pg_stat_bgwriter kwa kutumia sehemu zilizobainishwa tunaweza kufuatilia idadi ya vituo vya ukaguzi vinavyotokea. Na ikiwa tuna vituo vingi vya ukaguzi kwa muda fulani (katika dakika 10-15-20, katika nusu saa), kwa mfano, 3-4-5, basi hii inaweza tayari kuwa tatizo. Na tayari unahitaji kuangalia kwenye hifadhidata, angalia katika usanidi, ni nini husababisha wingi wa vituo vya ukaguzi. Labda kuna aina fulani ya rekodi kubwa inayoendelea. Tunaweza tayari kutathmini mzigo wa kazi, kwa sababu tayari tumeongeza grafu za mzigo wa kazi. Tayari tunaweza kurekebisha vigezo vya ukaguzi na kuhakikisha kuwa haviathiri sana utendaji wa hoja.
Ninarudi kwenye otomatiki tena kwa sababu ni kitu kama vile, kama nilivyosema, ambacho kinaweza kuongeza utendaji wa diski na hoja kwa urahisi, kwa hivyo ni muhimu kila wakati kukadiria kiwango cha otomatiki.
Idadi ya wafanyikazi wa otomatiki kwenye hifadhidata ni mdogo. Kwa msingi, kuna tatu kati yao, kwa hivyo ikiwa tuna wafanyikazi watatu kila wakati wanaofanya kazi kwenye hifadhidata, hii inamaanisha kuwa otomatiki yetu haijasanidiwa, tunahitaji kuongeza mipaka, kurekebisha mipangilio ya otomatiki na kuingia kwenye usanidi.
Ni muhimu kutathmini ni wafanyikazi gani wa utupu tulionao. Ama ilizinduliwa kutoka kwa mtumiaji, DBA ilikuja na kuzindua kwa mikono aina fulani ya utupu, na hii iliunda mzigo. Tuna aina fulani ya tatizo. Au hii ni idadi ya ombwe ambazo zinafungua kihesabu cha shughuli. Kwa matoleo mengine ya PostgreSQL haya ni ombwe nzito sana. Na wanaweza kuongeza utendaji kwa urahisi kwa sababu wanasoma jedwali zima, kuchanganua vizuizi vyote kwenye jedwali hilo.
Na, bila shaka, muda wa vacuums. Ikiwa tuna utupu wa muda mrefu ambao huendesha kwa muda mrefu sana, basi hii ina maana kwamba tunahitaji tena kuzingatia usanidi wa utupu na labda upya upya mipangilio yake. Kwa sababu hali inaweza kutokea wakati utupu unafanya kazi kwenye meza kwa muda mrefu (masaa 3-4), lakini wakati wa utupu ukifanya kazi, kiasi kikubwa cha safu zilizokufa kiliweza kujilimbikiza kwenye meza tena. Na mara tu utupu ukamilika, anahitaji kufuta meza hii tena. Na tunakuja kwa hali - utupu usio na mwisho. Na katika kesi hii, utupu hauwezi kukabiliana na kazi yake, na meza hatua kwa hatua huanza kuvimba kwa ukubwa, ingawa kiasi cha data muhimu ndani yake kinabaki sawa. Kwa hiyo, wakati wa utupu wa muda mrefu, sisi daima tunaangalia usanidi na kujaribu kuimarisha, lakini wakati huo huo ili utendaji wa maombi ya mteja hauteseka.
Siku hizi hakuna usakinishaji wa PostgreSQL ambao hauna urudufu wa utiririshaji. Urudiaji ni mchakato wa kuhamisha data kutoka kwa bwana hadi nakala.
Replication katika PostgreSQL inafanywa kupitia logi ya manunuzi. Mchawi hutoa logi ya shughuli. Rekodi ya muamala husafiri kupitia muunganisho wa mtandao hadi kwenye nakala, na kisha inatolewa tena kwenye nakala. Ni rahisi.
Ipasavyo, mwonekano wa pg_stat_replication hutumika kufuatilia kuchelewa kurudiwa. Lakini sio kila kitu ni rahisi kwake. Katika toleo la 10, mtazamo umefanyika mabadiliko kadhaa. Kwanza, sehemu zingine zimebadilishwa jina. Na baadhi ya mashamba yameongezwa. Katika toleo la 10, sehemu zilionekana ambazo hukuruhusu kukadiria bakia ya kurudia kwa sekunde. Ni vizuri sana. Kabla ya toleo la 10, iliwezekana kukadiria baiti za urudufishaji. Chaguo hili linabaki katika toleo la 10, i.e. unaweza kuchagua kile ambacho kinafaa zaidi kwako - kadiria kuchelewa kwa baiti au kukadiria baki kwa sekunde. Watu wengi hufanya yote mawili.
Lakini hata hivyo, ili kutathmini lag replication, unahitaji kujua nafasi ya logi katika manunuzi. Na nafasi hizi za logi za muamala ziko katika mwonekano wa pg_stat_replication. Kuzungumza kwa ulinganifu, tunaweza kuchukua alama mbili kwenye logi ya ununuzi kwa kutumia pg_xlog_location_diff() chaguo la kukokotoa. Kuhesabu delta kati yao na kupata baiti replication katika byte. Ni rahisi sana na rahisi.
Katika toleo la 10, chaguo hili la kukokotoa lilibadilishwa jina na kuwa pg_wal_lsn_diff(). Kwa ujumla, katika kazi zote, maoni, na huduma ambapo neno "xlog" lilionekana, lilibadilishwa na thamani "wal". Hii inatumika kwa maoni na chaguo za kukokotoa. Huu ni uvumbuzi kama huu.
Zaidi, katika toleo la 10, mistari iliongezwa ambayo inaonyesha lag. Hizi ni bakia za uandishi, bakia za flush, lagi ya kucheza tena. Hiyo ni, ni muhimu kufuatilia mambo haya. Ikiwa tunaona kwamba tuna lagi ya kurudia, basi tunahitaji kuchunguza kwa nini ilionekana, ilitoka wapi na kurekebisha tatizo.
Karibu kila kitu kiko sawa na vipimo vya mfumo. Ufuatiliaji wowote unapoanza, huanza na vipimo vya mfumo. Huu ni utupaji wa wasindikaji, kumbukumbu, ubadilishaji, mtandao na diski. Walakini, vigezo vingi havipo kwa msingi.
Ikiwa kila kitu kinafaa kwa mchakato wa kuchakata, basi kuna shida na kuchakata diski. Kama sheria, watengenezaji wa ufuatiliaji huongeza habari kuhusu matokeo. Inaweza kuwa katika iops au ka. Lakini wanasahau kuhusu latency na matumizi ya vifaa vya disk. Hizi ni vigezo muhimu zaidi vinavyotuwezesha kutathmini jinsi diski zetu zinavyopakiwa na jinsi zinavyo polepole. Ikiwa tuna latency ya juu, basi hii ina maana kwamba kuna matatizo fulani na disks. Ikiwa tuna matumizi ya juu, inamaanisha kwamba disks hazikabiliani. Hizi ni sifa bora kuliko matokeo.
Zaidi ya hayo, takwimu hizi pia zinaweza kupatikana kutoka kwa mfumo wa faili wa /proc, kama inavyofanywa kwa kuchakata vichakataji. Sijui kwa nini maelezo haya hayaongezwe kwenye ufuatiliaji. Lakini hata hivyo, ni muhimu kuwa na hili katika ufuatiliaji wako.
Vile vile hutumika kwa miingiliano ya mtandao. Kuna habari juu ya upitishaji wa mtandao kwenye pakiti, kwenye ka, lakini hata hivyo hakuna habari juu ya latency na hakuna habari juu ya utumiaji, ingawa hii pia ni habari muhimu.
Ufuatiliaji wowote una mapungufu. Na haijalishi ni aina gani ya ufuatiliaji unaochukua, hautafikia vigezo fulani kila wakati. Lakini hata hivyo, wanaendeleza, vipengele vipya na vitu vipya vinaongezwa, kwa hiyo chagua kitu na ukamilishe.
Na ili kumaliza, lazima kila wakati uwe na wazo la nini takwimu zilizotolewa zinamaanisha na jinsi unavyoweza kuzitumia kutatua shida.
Na vidokezo vichache muhimu:
- Unapaswa kufuatilia upatikanaji kila wakati na kuwa na dashibodi ili uweze kutathmini haraka kuwa kila kitu kiko sawa na hifadhidata.
- Daima unahitaji kuwa na wazo la nini wateja wanafanya kazi na hifadhidata yako ili kuwaondoa wateja wabaya na kuwapiga risasi.
- Ni muhimu kutathmini jinsi wateja hawa wanavyofanya kazi na data. Unahitaji kuwa na wazo kuhusu mzigo wako wa kazi.
- Ni muhimu kutathmini jinsi mzigo huu wa kazi unavyoundwa, kwa msaada wa maswali gani. Unaweza kutathmini maswali, unaweza kuyaboresha, kuyarekebisha, kuyajengea faharisi. Ni muhimu sana.
- Michakato ya usuli inaweza kuathiri vibaya maombi ya mteja, kwa hivyo ni muhimu kufuatilia kuwa hawatumii rasilimali nyingi sana.
- Vipimo vya mfumo hukuruhusu kupanga mipango ya kuongeza na kuongeza uwezo wa seva zako, kwa hivyo ni muhimu kuzifuatilia na kuzitathmini pia.
Ikiwa una nia ya mada hii, basi unaweza kufuata viungo hivi.
- hii ni nyaraka rasmi kutoka kwa mtoza takwimu. Kuna maelezo ya maoni yote ya takwimu na maelezo ya nyanja zote. Unaweza kuzisoma, kuzielewa na kuzichambua. Na kwa kuzingatia yao, jenga grafu zako na uziongeze kwenye ufuatiliaji wako.
Maombi ya mfano:
Hili ni hazina yetu ya ushirika na yangu mwenyewe. Zina maswali ya mfano. Hakuna maswali kutoka kwa select* kutoka kwa mfululizo hapo. Tayari kuna maswali yaliyotengenezwa tayari na viungio, kwa kutumia vitendaji vya kupendeza ambavyo hukuruhusu kugeuza nambari mbichi kuwa maadili yanayosomeka, rahisi, i.e. hizi ni ka, wakati. Unaweza kuzichukua, kuziangalia, kuzichambua, kuziongeza kwenye ufuatiliaji wako, kujenga ufuatiliaji wako kulingana nao.
maswali
Swali: Ulisema kuwa hutatangaza chapa, lakini bado nina hamu ya kujua - ni aina gani za dashibodi unazotumia katika miradi yako?
Jibu: Inatofautiana. Inatokea kwamba tunakuja kwa mteja na tayari ana ufuatiliaji wake mwenyewe. Na tunamshauri mteja juu ya kile kinachohitajika kuongezwa kwa ufuatiliaji wao. Hali mbaya zaidi iko kwa Zabbix. Kwa sababu haina uwezo wa kutengeneza grafu za TopN. Sisi wenyewe tunatumia , kwa sababu tulikuwa tukishauriana na watu hawa juu ya ufuatiliaji. Walifuatilia PostgreSQL kulingana na maelezo yetu ya kiufundi. Ninaandika mradi wangu wa kipenzi, ambao hukusanya data kupitia Prometheus na kuifanya . Kazi yangu ni kuunda msafirishaji wangu mwenyewe huko Prometheus na kisha kutoa kila kitu huko Grafana.
Swali: Je, kuna mlinganisho wowote wa ripoti za AWR au... kujumlisha? Je! unajua kitu kama hiki?
Jibu: Ndiyo, najua AWR ni nini, ni jambo la kupendeza. Kwa sasa kuna aina mbalimbali za baiskeli zinazotekeleza takriban modeli ifuatayo. Katika muda fulani, baadhi ya misingi huandikwa kwa PostgreSQL sawa au kwenye hifadhi tofauti. Unaweza kuzigoogle kwenye mtandao, zipo. Mmoja wa watengenezaji wa kitu kama hicho ameketi kwenye jukwaa la sql.ru kwenye uzi wa PostgreSQL. Unaweza kumkamata huko. Ndio, kuna vitu kama hivyo, vinaweza kutumika. Plus katika yake Pia ninaandika jambo ambalo hukuruhusu kufanya jambo lile lile.
PS1 Ikiwa unatumia postgres_exporter, unatumia dashibodi gani? Kuna kadhaa yao. Tayari zimepitwa na wakati. Labda jumuiya itaunda kiolezo kilichosasishwa?
PS2 Imeondolewa pganalyze kwa sababu ni toleo miliki la SaaS ambalo linaangazia ufuatiliaji wa utendaji na mapendekezo ya kurekebisha kiotomatiki.
Watumiaji waliojiandikisha pekee ndio wanaweza kushiriki katika utafiti. tafadhali.
Je, ni ufuatiliaji gani wa postgresql unaopangishwa binafsi (na dashibodi) unaona kuwa bora zaidi?
-
30,0%Zabbix + nyongeza kutoka kwa Alexey Lesovsky au zabbix 4.4 au 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 ni SaaS inayomilikiwa - siwezi kuifuta1
-
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
Watumiaji 10 walipiga kura. Watumiaji 26 walijizuia.
Chanzo: mapenzi.com