PostgreSQL-i jälgimise põhitõed. Aleksei Lesovski

Soovitan teil tutvuda Alexey Lesovski raporti ärakirjaga Data Egretist "PostgreSQL-i jälgimise alused"

Käesolevas aruandes räägib Aleksei Lesovski postgresi statistika põhipunktidest, mida need tähendavad ja miks neid seiresse kaasata; millised diagrammid peaksid olema seires, kuidas neid lisada ja kuidas tõlgendada. Aruanne on kasulik andmebaasi administraatoritele, süsteemiadministraatoritele ja arendajatele, kes on huvitatud Postgresi tõrkeotsingust.

Minu nimi on Aleksei Lesovski, esindan Data Egret.

Paar sõna endast. Alustasin tükk aega tagasi süsteemiadministraatorina.

Manustas igasuguseid erinevaid asju Linux, oli seotud mitmesuguste asjadega, mis olid seotud Linux, st virtualiseerimine, jälgimine, puhverserveritega töötamine jne. Aga mingil hetkel hakkasin rohkem tegelema andmebaasidega, PostgreSQL-iga. See meeldis mulle väga. Ja mingil hetkel hakkasin suurema osa ajast veetma PostgreSQL-iga töötades. Ja nii saingi tasapisi PostgreSQL-i andmebaasijuhiks.

Ja kogu oma karjääri jooksul on mind alati huvitanud statistika, monitooringu, telemeetria teemad. Ja kui olin süsteemiadministraator, töötasin ma Zabbixi kallal kõvasti. Ja kirjutas väikese komplekti skripte nagu zabbix-laiendidSee oli omal ajal üsna populaarne. Ja seal sai jälgida mitmesuguseid olulisi asju, mitte ainult Linux, aga ka erinevaid komponente.

Nüüd teen juba PostgreSQL-i. Kirjutan juba teist asja, mis võimaldab töötada PostgreSQL statistikaga. Seda nimetatakse pgCenter (artikkel Habré kohta - Postgres stat ilma närvide ja pingeteta).

Väike sissejuhatus. Millised on olukorrad meie klientidega, meie klientidega? Andmebaasiga on seotud mingisugune õnnetus. Ja kui andmebaas on juba taastatud, tuleb osakonnajuhataja või arendusjuht ja ütleb: "Sõbrad, me peaksime andmebaasi jälgima, sest juhtus midagi halba ja on vaja, et seda ei juhtuks tulevikus." Ja siit algab huvitav seiresüsteemi valimise või olemasoleva jälgimissüsteemi kohandamise protsess, et saaksite jälgida oma andmebaasi – PostgreSQL, MySQL või mõni muu. Ja kolleegid hakkavad pakkuma: “Kuulsin, et on olemas selline ja selline andmebaas. Kasutame ära." Kolleegid hakkavad omavahel vaidlema. Ja lõpuks selgub, et me valime mingisuguse andmebaasi, aga PostgreSQL monitooring on selles üsna kehvasti esindatud ja alati tuleb midagi lõpetada. Võtke GitHubist mõned hoidlad, kloonige need, kohandage skripte, häälestage neid kuidagi. Ja lõpuks kukub see välja mingisuguseks käsitsitööks.

Seetõttu püüan selles aruandes anda teile teadmisi selle kohta, kuidas valida monitooringut mitte ainult PostgreSQL-i, vaid ka andmebaasi jaoks. Ja anda teadmisi, mis võimaldavad teil oma monitooringu lõpetada, et sellest kasu saada, et saaksite oma andmebaasi kasulikult jälgida, et ennetada õigel ajal ettetulevaid hädaolukordi.

Ja need ideed, mis selles aruandes on, saab neid otse kohandada mis tahes andmebaasiga, olgu see siis DBMS või noSQL. Seetõttu pole siin mitte ainult PostgreSQL, vaid ka palju retsepte, kuidas seda PostgreSQL-is teha. Seal on näiteid päringutest, näiteid olemitest, mida PostgreSQL jälgib. Ja kui teie DBMS-is on samad asjad, mis võimaldavad teil neid jälgida, saate neid ka kohandada, lisada ja kõik on korras.

Ma ei teata
räägime, kuidas mõõdikuid edastada ja talletada. Andmete järeltöötluse ja kasutajale edastamise kohta ma midagi ei ütle. Ja hoiatamise kohta ei ütle ma midagi.
Aga loo käigus näitan erinevaid ekraanipilte olemasolevatest monitooringutest, kuidagi kritiseerin neid. Sellegipoolest püüan ma kaubamärke mitte nimetada, et mitte tekitada nendele toodetele reklaami või antireklaami. Seetõttu on kõik kokkusattumused juhuslikud ja jäävad teie kujutlusvõimesse.

Esiteks mõistame, mis on jälgimine. Järelevalve on väga oluline. Kõik saavad sellest aru. Kuid samas ei ole monitooring seotud äritootega ega mõjuta otseselt ettevõtte kasumit, seega antakse jälgimisele alati aega jääkpõhiselt. Kui aega on, siis tegeleme jälgimisega, kui aega pole, siis OK, paneme selle mahajäämusse ja millalgi tuleme nende ülesannete juurde tagasi.

Seetõttu on meie praktikast lähtudes nii, et klientide juurde tulles on monitooring sageli vähearenenud ega sisalda ühtegi huvitavat, mis aitaks meil andmebaasiga paremini tööd teha. Seetõttu tuleb seire alati lõpetada.

Andmebaasid on nii keerulised asjad, mida tuleb ka jälgida, sest andmebaasid on infohoidla. Ja info on ettevõtte jaoks väga oluline, see ei saa kuidagi kaduma minna. Kuid samal ajal on andmebaasid väga keerulised tarkvara osad. Need koosnevad paljudest komponentidest. Ja paljusid neist komponentidest tuleb jälgida.

Kui me räägime konkreetselt PostgreSQL-ist, siis võib seda kujutada sellise skeemina, mis koosneb suurest hulgast komponentidest. Need komponendid suhtlevad üksteisega. Ja samas on PostgreSQL-is nn Stats Collectori alamsüsteem, mis võimaldab koguda statistikat nende alamsüsteemide toimimise kohta ja pakkuda administraatorile või kasutajale liidest, et ta saaks seda statistikat vaadata.

See statistika on esitatud teatud funktsioonide ja vaadete (vaate) kujul. Neid võib nimetada ka tabeliteks. See tähendab, et tavalist psql-klienti kasutades saate luua ühenduse andmebaasiga, valida need funktsioonid ja vaated ning saada mõned konkreetsed numbrid PostgreSQL-i alamsüsteemide toimimise kohta.

Saate need numbrid lisada oma lemmikseiresüsteemi, joonistada graafikuid, lisada funktsioone ja saada pikemas perspektiivis analüüsi.

Kuid selles aruandes ei käsitle ma eranditult kõiki neid funktsioone, sest selleks võib kuluda terve päev. Viitan sõna otseses mõttes kahele, kolmele või neljale asjale ja räägin teile, kuidas need aitavad jälgimist paremaks muuta.

Ja kui me räägime andmebaasi jälgimisest, siis mida on vaja jälgida? Esiteks peame jälgima saadavust, kuna andmebaas on teenus, mis tagab klientidele juurdepääsu andmetele ja me peame jälgima saadavust ning esitama ka mõned selle kvalitatiivsed ja kvantitatiivsed omadused.

Samuti peame jälgima meie andmebaasiga ühenduvaid kliente, sest need võivad olla nii tavalised kliendid kui ka kahjulikud kliendid, kes võivad andmebaasi kahjustada. Neid tuleb ka jälgida ja jälgida.

Kui kliendid ühenduvad andmebaasiga, on ilmne, et nad hakkavad meie andmetega töötama, seega peame jälgima, kuidas kliendid andmetega töötavad: milliste tabelitega, vähemal määral milliste indeksitega. See tähendab, et peame hindama klientide loodud töökoormust.

Aga töökoormus koosneb loomulikult ka taotlustest. Rakendused ühenduvad andmebaasiga, pääsevad andmetele päringute abil, seega on oluline hinnata, millised päringud meil andmebaasis on, jälgida nende adekvaatsust, et need poleks kõverad, et mõned valikud tuleks ümber kirjutada ja muuta nii, et need kiiremini töötaksid ja parema jõudlusega.

Ja kuna me räägime andmebaasist, on andmebaas alati taustaprotsessid. Taustaprotsessid hoiavad andmebaasi jõudluse heal tasemel, seega nõuavad nende käitamiseks teatud hulga ressursse. Ja samal ajal võivad need kattuda kliendi päringu ressurssidega, nii et taustaprotsesside ahne töö võib otseselt mõjutada kliendi päringute toimimist. Seetõttu tuleb ka neid jälgida ja jälgida, et taustaprotsessides ei tekiks moonutusi.

Ja see on kõik, mis puudutab andmebaasi jälgimist, mis jääb süsteemi mõõdikusse. Kuid arvestades, et enamasti läheb kogu meie infrastruktuur pilvedesse, jäävad üksiku hosti süsteemimõõdikud alati tagaplaanile. Aga andmebaasides on need siiski aktuaalsed ja loomulikult on vaja jälgida ka süsteemimõõdikuid.

Süsteemi mõõdikutega on kõik enam-vähem korras, kõik kaasaegsed monitooringusüsteemid juba toetavad neid mõõdikuid, aga üldiselt ikka ei piisa mõnest komponendist ja osa asju tuleb lisada. Puudutan ka neid, nendest tuleb mitu slaidi.

Plaani esimene punkt on juurdepääsetavus. Mis on juurdepääsetavus? Kättesaadavus on minu arusaamises baasi võimekus ühendusi teenindada, st baasi tõstetakse, see võtab teenusena vastu klientidelt ühendusi. Ja seda ligipääsetavust saab hinnata mõne tunnuse järgi. Neid omadusi on armatuurlaual väga mugav kuvada.

Kõik teavad, mis on armatuurlauad. See on siis, kui heitsite ühe pilgu ekraanile, mis võttis kokku vajaliku teabe. Ja juba saab kohe kindlaks teha, kas andmebaasis on probleem või mitte.
Sellest lähtuvalt tuleks andmebaasi kättesaadavus ja muud põhinäitajad alati armatuurlauale panna, et see teave oleks alati teiega käepärast. Mõned lisadetailid, mis aitavad juba intsidentide uurimisel, mõne hädaolukorra uurimisel, tuleb need juba paigutada sekundaarsetele armatuurlaudadele või peidetud drilldown linkidesse, mis viivad kolmandate osapoolte seiresüsteemideni.

Näide ühest teadaolevast seiresüsteemist. See on väga lahe jälgimissüsteem. See kogub palju andmeid, kuid minu vaatenurgast on sellel armatuurlaudade kummaline kontseptsioon. Seal on link "Loo armatuurlaud". Kui aga loote armatuurlaua, loote kaheveerulise loendi ehk diagrammide loendi. Ja kui on vaja midagi vaadata, hakkad klõpsama, kerima, otsima hiirega soovitud diagrammi. Ja see võtab aega, st armatuurlaudu kui selliseid pole. Seal on ainult diagrammide loendid.

Mida tuleks nendele armatuurlaudadele lisada? Võite alustada sellisest tunnusest nagu reaktsiooniaeg. PostgreSQL-il on vaade pg_stat_statements. See on vaikimisi keelatud, kuid see on üks olulisi süsteemivaateid, mis tuleks alati lubada ja kasutada. See salvestab teabe kõigi andmebaasis käivitatud päringute kohta.

Sellest lähtuvalt saame lähtuda sellest, et saame võtta kõigi päringute täitmisaja kokku ja jagada päringute arvuga, kasutades ülaltoodud välju. Aga see on haiglas selline keskmine temperatuur. Saame tugineda teistele väljadele – minimaalne päringu täitmise aeg, maksimaalne ja mediaan. Ja saame isegi protsentiile ehitada, PostgreSQL-il on selleks vastavad funktsioonid. Ja me saame mõned numbrid, mis iseloomustavad meie andmebaasi reageerimisaega juba täidetud päringutele, st me ei täida võltsitud 'vali 1' päringut ja jälgime reageerimisaega, vaid analüüsime juba täidetud päringute reageerimisaega ja loosisime kas eraldi joonis või koostame selle põhjal graafiku.

Samuti on oluline jälgida süsteemi hetkel tekitatavate vigade arvu. Ja selleks saate kasutada pg_stat_andmebaasi vaadet. Me sihime välja xact_rollback. See väli ei näita mitte ainult andmebaasis esinevate tagasipööramiste arvu, vaid võtab arvesse ka vigade arvu. Suhteliselt saame selle näitaja kuvada oma armatuurlaual ja näha, kui palju vigu meil hetkel on. Kui vigu on palju, siis on see juba hea põhjus logidesse sisse vaadata ja vaadata, mis vead need on ja miks need tekivad ning seejärel investeerida ja need lahendada.

Saate lisada sellise asja nagu tahhomeeter. Need on tehingute arv sekundis ja päringute arv sekundis. Suhteliselt öeldes saate neid numbreid kasutada oma andmebaasi praeguse jõudlusena ja jälgida, kas taotlustes on tippe, tehinguid või vastupidi, andmebaas on alakoormatud, kuna mingi taustaprogramm kukkus ära. Oluline on alati seda joonist vaadata ja meeles pidada, et meie projekti jaoks on selline jõudlus normaalne ning ülalt ja all olevad väärtused on juba omamoodi problemaatilised ja arusaamatud, mis tähendab, et peame vaatama, miks sellised numbrid .

Tehingute arvu hindamiseks võime taas viidata pg_stat_andmebaasi vaatele. Tehingute arvu sekundis saamiseks saame lisada sissekannete arvu ja tagasipööramiste arvu.

Kõik saavad aru, et ühte tehingusse mahub mitu päringut? Seetõttu on TPS ja QPS veidi erinevad.

Päringute arvu sekundis saab pg_stat_statements ja lihtsalt arvutada kõigi täidetud päringute summa. Selge see, et me võrdleme praegust väärtust eelmisega, lahutame, saame delta, saame summa.

Soovi korral saate lisada täiendavaid mõõdikuid, mis aitavad samuti hinnata meie andmebaasi saadavust ja jälgida, kas seisakuid esines.

Üks neist mõõdikutest on tööaeg. Kuid PostgreSQL-i tööaeg on pisut keeruline. Ma ütlen teile, miks. Kui PostgreSQL käivitub, alustab see tööaja aruandlust. Aga kui mingi hetk töötas näiteks öösel mingi ülesanne, tuli OOM-killer ja lõpetas sunniviisiliselt PostgreSQL alamprotsessi, siis sel juhul lõpetab PostgreSQL kõikide klientide ühenduse, lähtestab killustatud mäluala ja alustab taastamist viimane kontrollpunkt. Ja kuni see kontrollpunktist taastumine kestab, ei aktsepteeri andmebaas ühendusi, st seda olukorda saab hinnata seisakuks. Kuid see ei lähtesta tööaja loendurit, sest see võtab postmasteri käivitamise aja arvesse juba esimesest hetkest. Seetõttu võib sellised olukorrad vahele jätta.

Samuti peaksite jälgima vaakumtöötajate arvu. Kõik teavad, mis on PostgreSQL-is autovaakum? See on huvitav PostgreSQL-i alamsüsteem. Sellest on kirjutatud palju artikleid, tehtud palju raporteid. Palju arutelu vaakumi üle, kuidas see peaks töötama. Paljud peavad seda vajalikuks kurjaks. Aga see on. See on mingi prügikoguja, mis puhastab ridade vananenud versioonid, mida ükski tehing ei vaja, ning vabastab tabelites ja indeksites ruumi uute ridade jaoks.

Miks peaks seda jälgima? Sest vaakum teeb vahel väga haiget. See kulutab palju ressursse ja klientide nõudmised hakkavad selle all kannatama.

Ja seda tuleks jälgida pg_stat_activity vaate kaudu, millest räägin järgmises osas. See vaade näitab praegust tegevust andmebaasis. Ja selle tegevuse kaudu saame jälgida praegu töötavate tolmuimejate arvu. Saame jälgida vaakumit ja näha, et kui oleme piiri ületanud, siis on võimalus uurida PostgreSQL-i seadeid ja kuidagi optimeerida vaakumi tööd.

Teine PostgreSQL-i omadus on see, et PostgreSQL on pikkadest tehingutest väga haige. Eriti tehingutest, mis pikalt rippuvad ja mitte midagi ei tee. Need on nn stat idle-in-transaction. Selline tehing hoiab lukke, see ei lase vaakumil töötada. Ja selle tulemusena - lauad paisuvad, nende suurus suureneb. Ja päringud, mis nende tabelitega töötavad, hakkavad töötama aeglasemalt, sest peate kühveldada kõik vanad ridade versioonid mälust kettale ja tagasi. Seetõttu tuleb jälgida ka aega, pikimate tehingute kestust, pikimaid vaakumitaotlusi. Ja kui näeme mõnda protsessi, mis on OLTP-koormuse puhul töötanud väga pikka aega, rohkem kui 10-20-30 minutit, siis peame neile tähelepanu pöörama ja sundima need lõpetama või optimeerima rakendust nii, et neid ei kutsuta ja nad ei ripu nii kaua. Analüütilise koormuse puhul on 10-20-30 minutit normaalne, on ka pikemaid.

Järgmisena on meil võimalus ühendatud klientidega. Kui oleme juba moodustanud armatuurlaua ja postitanud sellele peamised juurdepääsetavuse mõõdikud, saame sinna lisada ka lisateavet ühendatud klientide kohta.

Teave ühendatud klientide kohta on oluline, sest PostgreSQL-i seisukohast on kliente erinevat tüüpi. On häid kliente ja on halbu kliente.

Lihtne näide. Kliendi all pean silmas rakendust. Rakendus on andmebaasiga ühenduse loonud ja hakkab sinna kohe oma päringuid saatma, andmebaas töötleb ja täidab need ning tagastab tulemused kliendile. Need on head ja õiged kliendid.

On olukordi, et klient on ühenduses, hoiab ühendust, aga ei tee midagi. See on jõudeolekus.

Kuid on halbu kliente. Näiteks ühendas sama klient, avas tehingu, tegi midagi andmebaasis ja läks siis koodi sisse, et näiteks pääseda juurde välisele allikale või töödelda seal saadud andmeid. Kuid samal ajal ta tehingut ei lõpetanud. Ja tehing ripub andmebaasis ja hoiab lukku liinil. See on halb seisund. Ja kui äkki kuskil selle sees olev rakendus erandiga (Erand) kukub, siis võib tehing väga pikaks ajaks avatuks jääda. Ja see mõjutab otseselt PostgreSQL-i jõudlust. PostgreSQL töötab aeglasemalt. Seetõttu on oluline selliseid kliente õigeaegselt jälgida ja nende töö sunniviisiliselt lõpetada. Ja peate oma rakendust optimeerima, et selliseid olukordi ei tekiks.

Teised halvad kliendid ootavad kliente. Kuid olude sunnil muutuvad nad halvaks. Näiteks lihtne tühitehing: võib tehingu avada, mõnele reale lukud võtta, siis kukub kuhugi koodi sisse, jättes rippuva tehingu. Tuleb teine ​​klient, kes küsib samu andmeid, kuid ta satub lukku, kuna sellel rippuval tehingul on juba mõned vajalikud read lukud. Ja teine ​​tehing jääb ootusärevalt rippuma, kui esimene tehing on tehtud või selle administraator selle sunniviisiliselt sulgeb. Seega võivad pooleliolevad tehingud koguneda ja ületada andmebaasi ühenduse limiidi. Ja kui limiit on täis, ei saa rakendus enam andmebaasiga töötada. See on projekti jaoks juba eriolukord. Seetõttu tuleb halbu kliente jälgida ja neile õigeaegselt reageerida.

Jälle üks näide jälgimisest. Ja siin on korralik armatuurlaud. Ülevalt on info ühenduste kohta. DB ühendus - 8 tk. Ja ongi kõik. Meil puudub teave selle kohta, millised kliendid on aktiivsed, millised kliendid on lihtsalt jõude, mitte midagi ei tee. Rippuvate tehingute ja pooleliolevate ühenduste kohta info puudub ehk see on selline arv, mis näitab ühenduste arvu ja kõik. Ja siis arvake ise.

Seetõttu peate selle teabe jälgimisse lisamiseks kasutama süsteemivaadet pg_stat_activity. Kui veedate palju aega PostgreSQL-is, siis see on väga hea vaade, millest peaks saama teie sõber, sest see näitab hetketegevust PostgreSQL-is, st selles, mis toimub. Iga protsessi jaoks on eraldi rida, mis näitab selle protsessi infot: millisest hostist ühendus loodi, millise kasutaja all, mis nime all, millal tehingut alustati, millist päringut parasjagu täidetakse, millist päringut viimati täideti. Ja vastavalt sellele saame hinnata kliendi seisundit statistikavälja järgi. Suhteliselt saame selle välja järgi rühmitada ja saada need statistikad, mis praegu andmebaasis on, ja ühenduste arvu, mis selle statistikaga andmebaasis on. Ja juba saabunud numbrid saame saata oma monitooringule ja joonistada neile graafikud.
Samuti on oluline hinnata tehingu kestust. Olen juba öelnud, et oluline on hinnata vaakumide kestvust, aga samamoodi hinnatakse ka tehinguid. Seal on väljad xact_start ja query_start. Suhteliselt näitavad need tehingu algusaega ja päringu algusaega. Võtame funktsiooni now(), mis näitab praegust ajatemplit, ning lahutame tehingu ja päringu ajatemplid. Ja saame tehingu kestuse, päringu kestuse.

Kui näeme pikki tehinguid, peaksime need juba lõpule viima. OLTP-koormuse puhul on pikad tehingud juba pikemad kui 1-2-3 minutit. OLAP-i koormuse puhul on pikad tehingud normaalsed, aga kui need kestavad üle kahe tunni, siis on ka see märk, et meil on kuskil viltu.

Kui kliendid on andmebaasiga ühenduse loonud, hakkavad nad meie andmetega töötama. Nad pääsevad juurde tabelitele, pääsevad juurde indeksitele, et tabelist andmeid hankida. Ja oluline on hinnata, kuidas kliendid nende andmetega töötavad.

See on vajalik selleks, et hinnata meie töökoormust ja umbkaudselt mõista, millised tabelid meil on “kõige kuumemad”. Näiteks on see vajalik olukordades, kus tahame paigutada "kuumad" lauad mingisugusele kiirele SSD-mäluseadmele. Näiteks mõned arhiivitabelid, mida me pole pikka aega kasutanud, võib kanda mingisse “külma” arhiivi, SATA ketastele ja lasta neil seal elada, neile pääseb ligi vastavalt vajadusele.

See on kasulik ka anomaaliate tuvastamiseks pärast mis tahes väljalaseid ja juurutamist. Oletame, et projekt tõi välja mõne uue funktsiooni. Näiteks lisasime andmebaasiga töötamiseks uusi funktsioone. Ja kui koostame tabelite kasutamiseks graafikud, saame need anomaaliad nendel graafikutel hõlpsasti tuvastada. Näiteks värskendage sarivõtte või kustutage sarivõtte. See saab olema väga nähtav.

Samuti on võimalik tuvastada "ujuva" statistika anomaaliaid. Mida see tähendab? PostgreSQL-il on väga tugev ja väga hea päringuplaneerija. Ja arendajad pühendavad selle arendamisele palju aega. Kuidas ta töötab? Heade plaanide koostamiseks kogub PostgreSQL teatud ajavahemike ja teatud perioodilisusega statistikat andmete jaotuse kohta tabelitesse. Need on kõige sagedasemad väärtused: unikaalsete väärtuste arv, teave NULL-i kohta tabelis, palju teavet.

Selle statistika põhjal koostab planeerija mitu päringut, valib optimaalseima ja kasutab seda päringuplaani päringu enda täitmiseks ja andmete tagastamiseks.

Ja juhtub, et statistika "ujub". Kvaliteedi ja kvantiteedi andmed tabelis kuidagi muutusid, aga statistikat ei kogutud. Ja moodustatud plaanid ei pruugi olla optimaalsed. Ja kui meie plaanid osutuvad kogutava seire osas ebaoptimaalseteks, on tabelite järgi võimalik neid kõrvalekaldeid näha. Näiteks kuskil muutusid andmed kvalitatiivselt ja indeksi asemel hakati kasutama järjestikust tabelit läbimist, s.t. kui päring peab tagastama ainult 100 rida (piirang on 100), siis tehakse selle päringu jaoks täielik loend. Ja see mõjub tulemuslikkusele alati väga halvasti.

Ja me näeme seda seires. Ja juba vaadake seda päringut, tehke selle jaoks selgitus, koguge statistikat, koostage uus lisaindeks. Ja sellele probleemile juba vastata. Seetõttu on oluline.

Jälle üks näide jälgimisest. Ma arvan, et paljud inimesed tunnevad ta ära, sest ta on väga populaarne. Kes oma projektides kasutab Prometheus? Ja kes kasutab seda toodet koos Prometheusega? Fakt on see, et selle seire standardhoidlas on PostgreSQL-iga töötamiseks armatuurlaud - postgres_exporter Prometheus. Kuid siin on üks halb detail.

Tabeleid on mitu. Ja baidid on määratud ühikuna, st graafikuid on 5. Need on andmete sisestamine, andmete värskendamine, andmete kustutamine, andmete toomine ja andmete tagastamine. Baitid on määratud ühiku mõõtmena. Kuid tõsiasi on see, et PostgreSQL-i statistika tagastab andmed korteeži (ridadena). Ja vastavalt sellele on need graafikud väga hea viis oma töökoormust mitu korda, kümneid kordi alahinnata, sest korteež ei ole bait, korteež on string, see on palju baite ja see on alati muutuva pikkusega. See tähendab, et töökoormuse arvutamine baitides korteežide abil on ebareaalne või väga keeruline ülesanne. Seetõttu on armatuurlaua või sisseehitatud jälgimise kasutamisel alati oluline mõista, et see töötab õigesti ja tagastab teile õigesti hinnatud andmed.

Kuidas saada nende tabelite kohta statistikat? Selleks on PostgreSQL-il vaadete perekond. Ja põhivaade on pg_stat_user_tables. User_tables – see tähendab, et tabelid luuakse kasutaja nimel. Seevastu on süsteemivaateid, mida kasutab PostgreSQL ise. Ja seal on kokkuvõtlik tabel Alltables, mis sisaldab nii süsteemi kui ka kasutajat. Võite alustada ükskõik millisest neist, mis teile kõige rohkem meeldivad.

Ülaltoodud välju saab kasutada lisamiste, värskenduste ja kustutamiste arvu hindamiseks. Näidisarmatuurlaud, mida kasutasin, kasutab neid välju töökoormuse omaduste hindamiseks. Seetõttu saame ka neile tugineda. Kuid tasub meeles pidada, et need on kordused, mitte baitid, nii et me ei saa seda võtta ja baitideks muuta.

Nende andmete põhjal saame koostada nn TopN-tabelid. Näiteks Top-5, Top-10. Ja saate jälgida neid kuumi laudu, mida kasutatakse rohkem kui teisi. Näiteks 5 "kuuma" tabelit sisestamiseks. Ja nende TopN-tabelite järgi hindame oma töökoormust ja saame hinnata töökoormuse puhanguid pärast mis tahes väljalaseid ja värskendusi ning juurutamist.

Samuti on oluline hinnata tabeli suurust, sest mõnikord võtavad arendajad kasutusele uue funktsiooni ja meie tabelid hakkavad oma suurtes suurustes paisuma, kuna nad otsustasid lisada täiendava koguse andmeid, kuid ei ennustanud, kuidas see juhtuks. mõjutada andmebaasi suurust. Sellised juhtumid tulevad meilegi üllatusena.

Ja nüüd väike küsimus teile. Mis on küsimus, kui märkate andmebaasiserveri koormust? Mis on teie järgmine küsimus?

Kuid tegelik küsimus on järgmine. Milliseid taotlusi koormus põhjustab? See tähendab, et pole huvitav jälgida protsesse, mida koormus põhjustab. Selge on see, et kui host on andmebaasiga, siis andmebaas töötab seal ja on selge, et seal hävitatakse ainult andmebaasid. Kui avate Top, näeme seal nimekirja PostgreSQL-i protsessidest, mis midagi teevad. Ülevalt pole selge, mida nad teevad.

Sellest lähtuvalt peate leidma need päringud, mis põhjustavad kõige rohkem koormust, sest päringu häälestamine annab reeglina rohkem kasumit kui PostgreSQL-i konfigureerimine või operatsioonisüsteemi häälestamine või isegi riistvara häälestamine. Minu hinnangul on see umbes 80-85-90%. Ja seda tehakse palju kiiremini. Taotluse parandamine on kiirem kui konfiguratsiooni parandamine, taaskäivitamise ajastamine, eriti kui andmebaasi ei saa taaskäivitada, või riistvara lisamine. Lihtsam on päring kuhugi ümber kirjutada või indeks lisada, et sellest päringust parem tulemus saada.

Sellest lähtuvalt on vaja jälgida taotlusi ja nende piisavust. Võtame veel ühe näite jälgimisest. Ja ka siin näib olevat suurepärane jälgimine. Seal on info replikatsiooni kohta, on info läbilaskevõime, blokeerimise, ressursside kasutamise kohta. Kõik on korras, aga taotluste kohta info puudub. Pole selge, millised päringud meie andmebaasis töötavad, kui kaua need töötavad, kui palju neid päringuid on. Meil peab see teave jälgimisel alati olema.

Ja selle teabe saamiseks saame kasutada moodulit pg_stat_statements. Selle põhjal saate luua erinevat graafikat. Näiteks saate teavet kõige sagedasemate päringute kohta, st nende päringute kohta, mida kõige sagedamini täidetakse. Jah, pärast juurutamist on ka väga kasulik seda vaadata ja aru saada, kas taotluste arv on tõusnud.

Saate jälgida kõige pikemaid taotlusi, st neid, mille täitmine võtab kõige kauem aega. Need töötavad protsessoril, tarbivad I/O-d. Seda saame hinnata ka väljade total_time, mean_time, blk_write_time ja blk_read_time järgi.

Saame hinnata ja jälgida kõige raskemaid ressursikasutuse taotlusi, neid, mis loevad kettalt, neid, mis töötavad mäluga või, vastupidi, tekitavad mingisuguse kirjutuskoormuse.

Saame hinnata kõige heldemaid taotlusi. Need on päringud, mis tagastavad suure hulga ridu. Näiteks võib see olla mingi taotlus, kus nad unustasid limiidi seada. Ja see lihtsalt tagastab kogu tabeli sisu või päringu soovitud tabelites.

Samuti saate jälgida päringuid, mis kasutavad ajutisi faile või ajutisi tabeleid.

Ja meil on veel taustaprotsessid. Taustaprotsessid on peamiselt kontrollpunktid või neid nimetatakse ka kontrollpunktideks, need on autovaakum ja replikatsioon.

Jälle üks näide jälgimisest. Vasakul on vahekaart Hooldus, minge sellele ja loodetavasti näete midagi kasulikku. Aga siin on ainult vaakumi aeg ja statistika kogumine, ei midagi muud. See on väga kehv info, seega peab alati olema infot selle kohta, kuidas meie andmebaasis taustprotsessid töötavad ja kas nende töös on probleeme.

Kui vaatame kontrollpunkte, tuleb meeles pidada, et meie kontrollpunktid loputavad "määrdunud" lehti killustatud mälualast kettale ja loovad seejärel kontrollpunkti. Ja seda kontrollpunkti saab juba taastamise ajal kohana kasutada, kui PostgreSQL hädaolukorras ootamatult lõpetati.

Seetõttu peate kõigi "määrdunud" lehtede kettale loputamiseks tegema teatud koguse kirjutamist. Ja reeglina on see suure mälumahuga süsteemides palju. Ja kui me teeme kontrollpunkte väga sageli mõne lühikese intervalliga, siis ketta jõudlus langeb väga palju. Ja klientide taotlused kannatavad ressursside puudumise tõttu. Nad võistlevad ressursside pärast ja neil puudub tootlikkus.

Vastavalt sellele saame kindlaksmääratud väljadel oleva pg_stat_bgwriteri kaudu jälgida tekkivate kontrollpunktide arvu. Ja kui meil on teatud aja jooksul (10-15-20 minutiks, pooleks tunniks) palju kontrollpunkte, näiteks 3-4-5, siis võib see juba probleem olla. Ja juba tuleb vaadata andmebaasist, vaadata konfiguratsioonist, mis põhjustab sellise kontrollpunktide rohkuse. Võib-olla on tulemas mõni suur rekord. Koormust saame juba hinnata, sest oleme juba lisanud töökoormuse graafikud. Võime juba murdepunkti parameetreid muuta ja veenduda, et need päringu jõudlust oluliselt ei mõjuta.

Ma lähen uuesti autovaakumi juurde tagasi, sest see on selline asi, nagu ma ütlesin, mis võib hõlpsasti liita nii ketta kui ka päringu jõudluse, seega on alati oluline mõõta automaatvaakumi kogust.

Autovaakumtööliste arv andmebaasis on piiratud. Vaikimisi on neid kolm, nii et kui meil töötab andmebaasis kogu aeg kolm töötajat, siis see tähendab, et meie autovaakum on alakonfigureeritud, peame limiite tõstma, autovaakumi seaded üle vaatama ja juba konfiguratsiooni sisse ronima.
Oluline on hinnata, millised vaakumtöötajad meil töötavad. Kas käivitati kasutaja poolt, DBA tuli sisse ja käivitas kätega mingi vaakumi ja see tekitas koormuse. Meil on probleem. Või see on vaakumite arv, mis tehinguloendurit lahti keeravad. Mõne PostgreSQL-i versiooni puhul on need väga suured vaakumid. Ja nad saavad hõlpsasti jõudlust lisada, kuna nad lahutavad kogu tabeli ja skannivad kõiki selle tabeli plokke.

Ja muidugi vaakumide kestus. Kui meil on pikad vaakumid, mis töötavad väga kaua, siis see tähendab, et peaksime taas tähelepanu pöörama vaakumi konfiguratsioonile ja võib-olla selle seaded uuesti läbi vaatama. Kuna võib tekkida olukord, kui vaakum töötab laual pikka aega (3-4 tundi), kuid vaakumi töötamise ajal õnnestus tabelisse koguneda taas suur hulk surnud ridu. Ja niipea, kui vaakum läbi saab, on tal vaja see laud uuesti tolmuimejaga ära imeda. Ja jõuame olukorrani – lõpmatu vaakum. Ja sel juhul ei tule vaakum oma tööga toime ja tabelid hakkavad järk-järgult paisuma, kuigi kasulike andmete hulk selles jääb samaks. Seetõttu vaatame pikkades vaakumites alati konfiguratsiooni ja proovime seda optimeerida, kuid samal ajal, et kliendi soovide toimimine ei kannataks.

Nüüd pole praktiliselt ühtegi PostgreSQL-i installi, kus poleks voogesituse replikatsiooni. Replikatsioon on andmete ülekandmine põhiseadmest koopiasse.

Replikatsioon PostgreSQL-is on korraldatud tehingulogi kaudu. Ülem genereerib tehingulogi. Võrguühenduse tehingulogi läheb koopiasse, seejärel reprodutseeritakse see koopial. Kõik on lihtne.

Sellest lähtuvalt kasutatakse replikatsiooni viivituse jälgimiseks vaadet pg_stat_replication. Kuid see pole tema jaoks lihtne. Versioonis 10 on vaade läbinud mitmeid muudatusi. Esiteks on mõned väljad ümber nimetatud. Ja mõned väljad on lisatud. 10. versioonis ilmusid väljad, mis võimaldavad teil hinnata replikatsiooni viivitust sekundites. See on väga mugav. Enne versiooni 10 oli replikatsiooni viivitust võimalik hinnata baitides. See funktsioon jäi 10. versiooni, st saate valida, mis on teile mugavam - hinnata viivitust baitides või hinnata viivitust sekundites. Paljud teevad mõlemat.

Replikatsiooni viivituse hindamiseks peate aga teadma logi asukohta tehingus. Ja need tehingulogi asukohad on lihtsalt pg_stat_replication vaates. Suhteliselt öeldes saame kasutada funktsiooni pg_xlog_location_diff(), et võtta tehingulogis kaks punkti. Arvutage nendevaheline delta ja määrake replikatsiooni viivitus baitides. See on väga mugav ja lihtne.

Versioonis 10 nimetati see funktsioon ümber pg_wal_lsn_diff(). Üldiselt asendati see kõigis funktsioonides, vaadetes, utiliitides, kus sõna "xlog" kohtas, väärtusega "wal". Seda nii vaadetes kui ka funktsioonides. See on selline uuendus.

Lisaks lisati 10. versioonile read, mis näitavad konkreetselt viivitust. Need on kirjutamisviivitus, loputusviivitus, taasesituse viivitus. See tähendab, et neid asju on oluline jälgida. Kui näeme, et meil on replikatsiooniviivitus, peame uurima, miks see ilmus, kust see tuli ja probleem lahendama.

Süsteemi mõõdikutega on peaaegu kõik korras. Kui mis tahes monitooring sünnib, algab see süsteemi mõõdikutest. See on protsessorite, mälu, swapi, võrgu ja ketta kasutamine. Kuid sellegipoolest pole vaikimisi palju parameetreid seal.

Kui protsessi utiliseerimisega on kõik korras, siis on probleeme ketta utiliseerimisega. Reeglina lisavad seirearendajad ribalaiuse teavet. See võib olla iops või baitides. Kuid nad unustavad latentsusaja ja kettaseadmete kasutamise. Need on olulisemad parameetrid, mis võimaldavad meil hinnata, kui koormatud on meie kettad ja kui palju need aeglustuvad. Kui meil on kõrge latentsusaeg, tähendab see, et ketastega on probleeme. Kui meil on kõrge kasutusaste, tähendab see, et kettad ei saa hakkama. Need on pigem kvalitatiivsed omadused kui ribalaius.

Seda statistikat saab aga ka /proc failisüsteemist, nagu seda tehakse protsessori taaskasutuse puhul. Miks seda infot monitooringule ei lisata, ma ei tea. Kuid ikkagi on oluline, et see oleks teie jälgimises.

Sama kehtib ka võrguliideste kohta. Võrgu ribalaiuse kohta on teavet pakettidena, baitides, kuid sellest hoolimata puudub teave latentsuse ja kasutamise kohta, kuigi see on samuti kasulik teave.

Igal jälgimisel on oma puudused. Ja olenemata sellest, millist järelevalvet te kasutate, ei vasta see alati teatud kriteeriumidele. Kuid sellegipoolest need arenevad, lisatakse uusi funktsioone, uusi asju, nii et valige midagi ja lõpetage see.

Ja selleks, et lõpetada, peab alati olema ettekujutus, mida antud statistika tähendab ja kuidas sellega probleeme lahendada.

Ja mõned põhipunktid:

• Alati on vaja jälgida saadavust, omada armatuurlaudu, et saaks kiiresti hinnata, et baasiga on kõik korras.
• Halbade klientide väljarookimiseks ja nende tulistamiseks peab teil alati olema ettekujutus sellest, millised kliendid teie andmebaasiga töötavad.
• Oluline on hinnata, kuidas need kliendid andmetega töötavad. Teil peab olema ettekujutus oma töökoormusest.
• Oluline on hinnata, kuidas see töökoormus kujuneb, milliste päringute abil. Saate päringuid hinnata, neid optimeerida, ümber kujundada, nende jaoks indekseid koostada. See on väga tähtis.
• Taustprotsessid võivad klientide taotlusi negatiivselt mõjutada, mistõttu on oluline tagada, et nad ei kasutaks liiga palju ressursse.
• Süsteemi mõõdikud võimaldavad teil teha plaane skaleerimiseks ja serverite võimsuse suurendamiseks, seega on oluline ka neid jälgida ja hinnata.

Kui olete sellest teemast huvitatud, võite järgida neid linke.
http://bit.do/stats_collector on statistika koguja ametlik dokumentatsioon. Seal on kõigi statistiliste vaadete kirjeldus ja kõigi väljade kirjeldus. Saate neid lugeda, mõista ja analüüsida. Ja nende põhjal koostage oma diagrammid, lisage oma monitooringut.

Taotlege näiteid:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

See on meie ettevõtte hoidla ja minu oma. Neil on näidistaotlused. Päringuid valida* sarjast pole, midagi seal. Juba on olemas liitumistega valmispäringud, mis kasutavad huvitavaid funktsioone, mis võimaldavad toorarvudest teha loetavaid, mugavaid väärtusi, st need on baitid, aeg. Saate neid valida, vaadata, analüüsida, lisada oma monitooringutesse, koostada nende põhjal oma monitooringud.

küsimused

Küsimus: Ütlesite, et ei hakka brände reklaamima, aga ma ikka mõtlen – milliseid armatuurlaudu te oma projektides kasutate?
Vastus: Erinevatel viisidel. Juhtub, et tuleme kliendi juurde ja tal on juba oma monitooring. Ja nõustame klienti, mida on vaja tema jälgimisse lisada. Kõige hullem on olukord Zabbixiga. Kuna sellel pole TopN-graafika koostamise võimalust. Me ise kasutame Okmeetersest me konsulteerisime nende meestega jälgimise osas. Nad tegid meie TOR-i põhjal PostgreSQL-i jälgimist. Kirjutan oma lemmikloomaprojekti, mis kogub Prometheuse kaudu andmeid ja tõmbab need sisse grafana. Minu ülesandeks on teha Prometheuses oma eksportija ja seejärel kõik Grafanasse joonistada.

Küsimus: Kas AWR-i aruannetel või ... liitmikel on analooge? Kas olete millestki sellisest teadlik?
Vastus: Jah, ma tean, mis on AWR, see on lahe asi. Praegu on saadaval mitmesuguseid jalgrattaid, mis rakendavad ligikaudu järgmist mudelit. Teatud ajavahemike järel kirjutatakse mõned lähtejooned samasse PostgreSQL-i või eraldi salvestusruumi. Internetist võid googeldada, on. Üks sellise asja arendajatest istub sql.ru foorumis PostgreSQL-i lõimes. Seal saate ta kinni püüda. Jah, selliseid asju on, neid saab kasutada. pluss selles pgCenter Kirjutan ka asja, mis võimaldab sul sama teha.

PS1 Kui kasutate postgres_exporterit, siis millist juhtpaneeli te kasutate? Neid on mitu. Need on juba aegunud. Kas kogukond saab luua värskendatud malli?

PS2 eemaldatud pganalyze, kuna see on patenteeritud SaaS-i pakkumine, mis keskendub jõudluse jälgimisele ja automatiseeritud häälestamise soovitustele.

Küsitluses saavad osaleda ainult registreerunud kasutajad. Logi sissepalun.

Milline isehostitav postgresql-i jälgimine (koos armatuurlauaga) on teie arvates parim?

• 30,0%Zabbix + täiendused Aleksei Lesovskilt või zabbix 4.4 või 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 on patenteeritud SaaS – ei saa kustutada1

• 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 kasutajat hääletas. 26 kasutajat jäi erapooletuks.

Allikas: www.habr.com