PostgreSQL jälgimise alused. Aleksei Lesovski

Tutvustan teile Alexey Lesovski raporti "PostgreSQL monitooringu alused" tõlget.

Selles ettekandes räägib Alexey Lesovski PostgreSQL statistika peamistest punktidest, mida need tähendab ja miks need peavad olema monitooringus; millised graafikud peaksid olema monitoorimisel, kuidas neid lisada ja kuidas tõlgendada. Ettekanne on kasulik andmebasede administreerijatele, süsteemiadministraatoritele ja arendajatele, kes on huvitatud PostgreSQL vigaotsimisest.

Minu nimi on Alexey Lesovski, esindan ettevõtet Data Egret.

Veidi enda kohta. Alustasin kunagi ammu süsteemiadministraatorina.

Hallates erinevaid Linuxi süsteeme, tegelesin erinevate asjadega, mis olid seotud Linuxiga, st virtualiseerimise, monitoorimisega, töötasin proksidega jne. Kuid mingil hetkel hakkasin rohkem tegelema andmebaasidega, PostgreSQL'iga. See meeldis mulle väga. Ja mingil hetkel hakkasin PostgreSQL'le pühendama suurema osa oma tööajast. Nii ma aeglaselt muutusin PostgreSQL DBA-ks.

Ja kogu oma karjääri jooksul on mind alati huvitanud statistika, monitooringu ja telemeetria teemad. Kui olin süsteemiadministraator, tegelesin tihedalt Zabbixiga. Kirjutasin väikese komplekti skripte nagu zabbix-extensions. See oli omal ajal üsna populaarne. Seal sai monitoorida väga erinevaid olulisi asju, mitte ainult Linuxit, vaid ka teisi komponente.

Praegu tegelema PostgreSQL'iga. Kirjutan teistsugust asja, mis võimaldab töötada PostgreSQL statistika pealt. See kannab nime pgCenter (artikkel Habr's — PostgreSQL statistika muredeta ja pingeteta).

Lühike sissejuhatus. Millised olukorrad meie tellijatel, meie klientidel esinevad? Juhtub mõni häda, mis on seotud andmebaasiga. Ja kui andmebaas on juba taastatud, tuleb osakonna juht või arenduse juht ning ütleb: „Kallis, peaksime andmebaasi jälgima, sest juhtus midagi halba ja me peame tagama, et midagi sellist ei juhtuks tulevikus.“ Ja siin algab huvitav valikuprotsess jälgimissüsteemi valimiseks või olemasoleva jälgimissüsteemi kohandamiseks, et saaksime oma andmebaasi — PostgreSQL, MySQL või mõne muu — jälgida. Ja kolleegid hakkavad ettepanekuid tegema: „Ma olen kuulnud, et selline andmebaas on olemas. Kas me ei võiks seda kasutada?“ Kolleegid hakkavad omavahel vaidlema. Tulemuseks on, et valime mõne andmebaasi, kuid PostgreSQL-i jälgimine on seal nõrgalt esindatud ja alati peab midagi seadistama. Peame võtma GitHubist mingeid hoidlaid, need kloonima, skripte kohandama, kuidagi täiustama. Ja lõpuks muutub see käsitööks.

Seetõttu püüan ma selles ettekandes anda teile teavet, kuidas valida jälgimist mitte ainult PostgreSQL-i, vaid ka andmebaasi jaoks. Ja anda teadmised, mis aitavad teil teie jälgimist täiustada, et saada sellest kasu, et saaksite oma andmebaasi jälgida kasulikult ning õigeaegselt hoiatada võimalike probleemide eest, mis võivad tekkida.

Ja need ideed, mis selles ettekandes esitatakse, saab otse kohandada igasuguste andmebaaside jaoks, olgu need siis SÜB või noSQL. Seetõttu ei ole siin mitte ainult PostgreSQL, vaid ka palju retsepte, kuidas seda PostgreSQL-is teha. Esitatakse päringute näiteid, näiteid isenditest, mis on PostgreSQL-is jälgimiseks olemas. Ja kui teie SÜB-il on sarnased asjad, mis võimaldavad neid jälgimisse panna, saate neid samuti kohandada, lisada ja kõik on hästi.

Ettekandes ei räägi ma
mõõdikute edastamisest ja salvestamisest. Ma ei räägi midagi andmete töötlemise ja kasutajale esitamise kohta. Ja ma ei räägi midagi häirete seadistamisest.
Kuid loo käigus hakkan ma näitama erinevaid olemasolevaid monitooringute ekraanipilte ja mõningaid neist kritiseerima. Pean siiski silmas, et püüan brändide nimesid mitte mainida, et mitte tekitada neile toodetele reklaami või vastureklaami. Seega on kõik sarnased juhtumid juhuslikud ja jäävad teie fantaasiasse.

Esiteks mõistame, mis on monitooring. Monitooring on väga oluline asi, mida on hädasti vaja. Seda mõistetakse kõikjal. Kuid samal ajal ei kuulu monitooring äri toote hulka ega mõjuta otseselt ettevõtte kasumit, seetõttu pööratakse monitooringule alati aega alles siis, kui muud tööd on tehtud. Kui meil on aega, siis tegeleme monitooringuga, kui aega ei ole, siis OK, paneme selle ootele ja tulevikus tuleme nende ülesannete juurde tagasi.

Seetõttu meie praktikast, kui me tuleme klientide juurde, on monitooring sageli puudulik ja ei sisalda huvitavaid elemente, mis aitaksid meil andmebaasidega tööd paremini teha. Seetõttu on monitooringut alati vaja täiendada.

Andmebaasid on keerulised asjad, mida tuleb samuti monitooringu alla võtta, sest andmebaasid on teabehoidla. Ja teave on ettevõtte jaoks väga oluline, seda ei tohi mingil juhul kaotada. Kuid samas on andmebaasid ka väga keerulised tarkvarakomponendid. Need koosnevad paljusid komponente. Ja paljusid neist komponentidest tuleb monitooringu alla võtta.

Kui räägime konkreetselt PostgreSQL-ist, siis võib seda esitada kui sellist skeemi, mis koosneb paljusid komponente. Need komponendid suhtlevad üksteisega. Ja samal ajal on PostgreSQL-is nn Stats Collectori alamsüsteem, mis võimaldab koguda statistikat nende alamsüsteemide töö kohta ja anda administreerijale või kasutajale teatud liidese, et ta saaks seda statistikat vaadata.

See statistika on esitatud teatud funktsioonide ja vaadete (view) kogumina. Neid võib nimetada ka tabeliteks. See tähendab, et tavalise psql kliendi abil saate andmebaasiga ühendada, teha nendele funktsioonidele ja vaadetele SELECT-päringu ning saada juba konkreetseid numbreid PostgreSQL alamsüsteemide töö kohta.

Saate lisada need numbrid oma lemmik monitooringusüsteemi, koostada graafikuid, lisada funktsioone ja saada pikaajalist analüüsi.

Kuid ma ei kavatse selles raportis arutada kõiki neid funktsioone, sest see võib võtta terve päeva. Ma keskendun vaid kahele kuni neljale punktile ja räägin, kuidas need aitavad jälgimist paremaks muuta.

Ja kui rääkida andmebaasi jälgimisest, siis mida tuleks jälgida? Esiteks tuleb jälgida kättesaadavust, kuna andmebaas on teenus, mis pakub klientidele juurdepääsu andmetele, ja peame jälgima kättesaadavust, samuti mõningaid selle kvaliteetseid ja kvantitatiivseid omadusi.

Samuti tuleb jälgida kliente, kes meie andmebaasi ühenduvad, sest nad võivad olla nii normaalsed kliendid kui ka kahjulikud kliendid, kes võivad andmebaasile kahju tekitada. Neid tuleb samuti jälgida ja nende tegevust jälgida.

Kui kliendid ühenduvad andmebaasi, siis on ilmne, et nad hakkavad töötama meie andmetega, seega peame jälgima ka seda, kuidas kliendid andmetega töötavad: milliste tabelitega, vähemal määral milliste indexitega. See tähendab, et peame hindama töökoormust, mille meie kliendid tekitavad.

Kuid töökoormus koosneb muidugi päringutest. Rakendused ühenduvad andmebaasiga, kutsuvad andmeid välja päringute kaudu, seega on oluline hinnata, millised päringud meil andmebaasis on, jälgida nende adekvaatsust, et nad ei oleks valesti kirjutatud, ning mõningaid valikuid tuleks ümber kirjutada, et need töötaksid kiiremini ja parema jõudlusega.

Ja kuna me räägime andmebaasist, siis andmebaas tähendab alati taustprotsesse. Taustprotsessid aitavad säilitada andmebaasi jõudlust heas seisus, seega vajavad nad teatud hulga ressursse enda jaoks. Samuti võivad nad kattuda klientide päringute ressurssidega, seega võivad taustprotsesside intensiivne töö otseselt mõjutada klientide päringute jõudlust. Seega tuleb neid samuti jälgida ja vältida tasakaaluhäireid taustprotsesside osas.

Ja see kõik andmebaasi jälgimise osas jääb süsteemi meetrika. Kuid arvestades, et meie kogu infrastruktuur liigub peamiselt pilve, jäävad eraldi hosti süsteemi meetrikad alati tagaplaanile. Kuid andmebaasides on need endiselt olulised ja süsteemi meetrikate jälgimine on loomulikult samuti vajalik.

Süsteemi meetrikate osas on enam-vähem kõik hästi, kõik kaasaegsed jälgimissüsteemid toetavad neid meetrikaid, kuid üldiselt mõningaid komponente siiski puudub ja mõned asjad on vajalikud lisada. Nendest räägin ma samuti, paar slaidi on nende kohta.

Esimene plaani punkt on kättesaadavus. Mis on kättesaadavus? Kättesaadavus minu arusaama kohaselt tähendab andmebaasi võimet teenindada ühendusi, st andmebaas on aktiivne, see, nagu teenus, aktsepteerib klientide ühendusi. Ja seda kättesaadavust saab hinnata teatud omadustega. Need omadused on väga mugavad paneelidele välja toomiseks.

Kõik teavad, mis on paneelid. See on siis, kui heidad pilku ekraanile, kus on kokku koondatud vajalik teave. Ja sa saad kohe määrata - kas andmebaasis on probleem või mitte.
Seega andmebaasi kättesaadavus ja teised olulised omadused on alati vajalikud paneelidele väljatootmiseks, et see teave oleks käepärast ja alati sinu lähedal. Mõned lisadetailid, mis aitavad juhtumite uurimise, avariiolukordade uurimise puhul, peaksid minema teisejärgulistele paneelidele või olema peidetud drilldown-linkidesse, mis viivad kolmandate osapoolte jälgimissüsteemidesse.

Ühe tuntud jälgimissüsteemi näide. See on väga äge jälgimissüsteem. See kogub väga palju andmeid, kuid minu arvates on seal kummaline mõisted paneelide osas. Seal on link "loo paneel". Kuid kui sa lood paneeli, siis lood sa teatud loendi, mis koosneb kahest veerust, mingi graafikute loendi. Ja kui sul on vaja midagi vaadata, siis hakkad hiirega klikkima, kerima, otsima vajalikku graafikut. Ja selleks kulub aega, st tõelisi paneele ei ole. On vaid graafikute loendid.

Mida tuleks nende juhtpaneelide peale lisada? Võib alustada sellise näitajaga nagu reageerimisaeg. PostgreSQL-is on vaade pg_stat_statements. Vaikimisi on see välja lülitatud, kuid see on üks olulisemaid süsteemi vaateid, mis tuleks alati sisse lülitada ja kasutada. See salvestab teavet kõigi käideldud päringute kohta, mis on andmebaasis teostatud.

Seega, me saame lähtuda sellest, et võime võtta kokku kõigi päringute täitmise aja ja jagada selle päringute arvuga, kasutades eespool mainitud välju. Kuid see on justkui keskmine temperatuur haiglas. Saame lähtuda teistest väljadest – minimaalne päringu täitmise aeg, maksimaalne ja mediaan. Ja isegi saame koostada protsente, PostgreSQL-is on selleks vastavad funktsioonid. Saame välja tuua mõned numbrid, mis iseloomustavad meie andmebaasi reageerimisaega juba teostatud päringute põhjal, s.t. me ei tee vale päringut 'select 1' ja vaata reageerimisaega, vaid analüüsime vastuste aegu juba teostatud päringute põhjal ja esitleme kas eraldi numbrina või joonistame selle põhjal graafiku.

Samuti on oluline jälgida vigu, mida süsteem praegu genereerib. Selleks saame kasutada vaadet pg_stat_database. Me vaatame väljale xact_rollback. See väli näitab mitte ainult tabeli tagasivõtmise arvu, vaid arvestab ka vigade arvu. Ütleme nii, et saame selle numbri oma juhtpaneelile välja tuua ja vaadata, kui palju vigu meil praegu on. Kui vigu on palju, on see juba hea põhjus vaadata logisid ja näha, millised need vead on ja miks need juhtuvad, ning seejärel uurida ja lahendada need.

Saame lisada sellise asja nagu tahhomeeter. See on tehingute arv sekundis ja päringute arv sekundis. Ütleme nii, et võite neid numbreid kasutada oma andmebaasi praeguse jõudluse indikaatorina ja jälgida, kas on päringute või tehingute tippe, või vastupidi, et andmebaas on alatalletatud, sest mõni backend on kokku kukkunud. Seda numbrit on oluline alati jälgida ja meeles pidada, et meie projekti jaoks on selline jõudlus normaalne, samas kui kõrgemad ja madalamad väärtused on probleemsed ja arusaamatud, seega tuleb vaadata, miks sellised numbrid on.

Tehingute arvu hindamiseks võime jälle pöörduda pg_stat_database vaate poole. Saame liita commitide ja rollbackide arvu, et saada tehingute arv sekundis.

Kõik mõistavad, et ühte tehingusse võib kuuluda mitu päringut? Seetõttu on TPS ja QPS veidi erinevad.

Päringute arvu sekundis saab saada pg_stat_statements'ist ning lihtsalt arvutada välja kõikide täidetud päringute summa. On selge, et me võrdleme praegust väärtust varasemaga, lahutame selle, saame delta ja saame arvu.

Võime soovi korral lisada täiendavaid mõõdikuid, mis aitavad samuti hinnata meie andmebaasi kättesaadavust ja jälgida, kas on olnud mingit katkestust.

Üks neist mõõdikest on uptime. Kuid uptime PostgreSQL-is on veidi keeruline asi. Räägin, miks. Kui PostgreSQL käivitub, algab uptime arvestamine. Kuid kui mõnel hetkel, näiteks öösel, täideti mõni ülesanne, tuli OOM-killer ja sundis PostgreSQL-lt alamharu protsessi katkestama, siis sel juhul lõpetab PostgreSQL kõigi klientide ühendused, tühjendab sharding mälu ja alustab taastamist viimase kontrollpunkti juures. Ja kuni see taastamine kestab, ei võta andmebaas ühendusi, seega saab seda olukorda hinnata kui katkestust. Kuid samas uptime mõõdik ei nulli ennast, sest see arvestab postmaster'i käivitamise aega alates esimesest hetkes. Seetõttu võib selliseid olukordi mööda vaadata.

Samuti tuleb jälgida vakumeerimise töötlusprotsesside arvu. Kas kõik tunnevad autovacuum'i PostgreSQL-is? See on huvitav alamsüsteem PostgreSQL-is. Selle kohta on kirjutatud palju artikleid, peetud palju ettekandeid. Palju arutelusid vakumeerimise üle, kuidas see peaks töötama. Paljud peavad seda vältimatuks kurjuseks. Ja see on tõsi. See on omamoodi prügikasti koristaja, mis puhastab aegunud ridade versioonid, mis ei ole ühegi tehingu jaoks vajalikud, ja vabastab ruumi tabelites, indeksites uute ridade jaoks.

Miks tuleb seda jälgida? Sest vakumeerimine võib vahel olla väga valus. See sööb suure hulga ressursse ja kliendipäringud kannatavad selle tõttu.

Ja tuleks jälgida selle aktiivsust pg_stat_activity vaate kaudu, millest ma räägin järgmises osas. See vaade näitab praegust tegevust andmebaasis. Selle tegevuse kaudu saame jälgida, kui palju vaakume on hetkel töös. Saame jälgida vaakume ja näha, et kui meil on ületatud piirang, siis on see põhjus vaadata PostgreSQL seadeid ja kuidas vaakumi tööd optimeerida.

Teine PostgreSQL omadus on see, et PostgreSQL kannatab väga pikkaealiste tehingute all. Eriti tehingute, mis on pikka aega aktiivsed, kuid ei tee midagi. Need on nn stat idle-in-transaction tehingud. Selline tehing hoiab blokeeringuid ja takistab vaakumi tööd. Tagajärjeks on see, et tabelid paisuvad, nende suurus suureneb. Ja päringud, mis töötavad nende tabelitega, hakkavad töötama aeglasemalt, sest tuleb vanu ridade versioone mälust kettale ja tagasi kaevama. Seetõttu on oluline jälgida ka pikkade tehingute aega, kõige pikemate vaakumipäringute aega. Ja kui me näeme mingeid protsesse, mis töötavad juba väga pikka aega, rohkem kui 10-20-30 minutit OLTP-koormuse jaoks, siis tuleb neile tähelepanu pöörata ja need kas sulgeda sundkorras või optimeerida rakendust, et need ei kutsuks üles ja ei seisaks liiga kaua. Ala-analyytika koormuse jaoks on 10-20-30 minutit normaalne, seal võib olla ka veelgi pikemaid.

Järgmine on variant ühendatud klientidega. Kui oleme juba koostanud juhtpaneeli, ja seni, kuni oleme sellele välja riputanud võtmeprotsendid saadavusest, saame sinna lisada ka täiendavat teavet ühendatud klientide kohta.

Teave ühendatud klientide kohta on oluline, sest PostgreSQL vaatepunktist on kliendid erinevad. On häid kliente ja halbu kliente.

Lihtne näide. Klient, mida ma mõistan, on rakendus. Rakendus on ühendatud andmebaasi ja saadab sinna kohe oma päringud, andmebaas töötleb neid ja täidab, tulemused tagastatakse kliendile. Need on head ja õiged kliendid.

Mõnikord juhtub, et klient on ühendatud, hoiab ühendust, kuid ei tee selle samal ajal midagi. Ta on idle olekus.

Kuid on ka halbu kliente. Näiteks, kui klient ühendub, avab tehingu, teeb midagi andmebaasis ja seejärel liigub koodi, et pöörduda välise allika poole või teha seal andmete töötlemist. Kuid ta ei sule tehingut. Ja tehing jääb andmebaasi rippuma ja hoiab rida lukus. See on halb olukord. Kui rakendus peaks kuskil eksitama (Exception), siis võib tehing jääda avatud väga kauaks. Ja see mõjutab otseselt PostgreSQLi jõudlust. PostgreSQL töötab aeglasemalt. Seetõttu on oluline selliseid kliente õigeaegselt jälgida ja nende töö lõpetada. Samuti on vajalik oma rakendust optimeerida, et sarnaseid olukordi vältida.

Teised halvad kliendid on ootel kliendid. Kuid nad muutuvad halbadeks asjaolude tõttu. Näiteks tavaline seisev tehing: klient võib avada tehingu, võtta lukud mõnele reale, kuid seejärel kukub see kuskil koodis ja jääb riputama. Kui teine klient küsib samu andmeid, siis ta seisab silmitsi lukustusega, kuna see rippuv tehing juba hoiab lukke mõnedele vajalikule reale. Ja teine tehing jääb ootama, kuni esimene tehing lõpetatakse või selle administraator sunniviisiliselt suletakse. Seega, ootavad tehingud võivad koguneda ja ületada andmebaasi ühenduste piiri. Ja kui piir on ületatud, ei saa rakendus andmebaasi enam kasutada. See on projekti jaoks juba kriitiline olukord. Seetõttu tuleb halbu kliente jälgida ja neile õigeaegselt reageerida.

Teine näide jälgimisest. Ja siin on korralik armatuurlaud. Ülemises osas on teave ühenduste kohta. DB connection – 8 tükki. Ja see on kõik. Meil ei ole teavet selle kohta, millised kliendid on aktiivsed, millised kliendid lihtsalt ootavad, ei tee midagi. Ei ole teavet riputatud tehingute ja ootavate ühenduste kohta, st see on lihtsalt number, mis näitab ühenduste arvu ja kõik. Edasi mõelge ise.

Seega, et lisada see teave jälgimisele, tuleb pöörduda süsteemi vaate pg_stat_activity poole. Kui veedate palju aega PostgreSQLis, on see väga hea vaade, mis peaks saama teie sõbraks, kuna see näitab hetkeaktiivsust PostgreSQLis, st mis seal toimub. Iga protsessi kohta on eraldi rida, mis näitab teavet selle protsessi kohta: milliselt hostilt on ühendus tehtud, kumba kasutajat kasutatakse, millise nimega, millal tehing käivitati, mis päring hetkel käib ja milline päring käidi viimati. Seega saame kliendi seisundit hinnata väljaande stat järgi. Ütlemisi võib selle väljaande põhjal grupeerida ja saada need stat’id, mis andmebaasis on hetkel olemas, ja ühenduste arvu, mis antud stat’iga andmebaasi siseneb. Saadud numbreid saame edastada meie jälgimisele ja joonistada neist graafikuid.
Samuti on oluline hinnata tehingu kestvust. Olen juba öelnud, et on oluline hinnata vakumeid, kuid tehinguid hinnatakse samamoodi. On väljaanded xact_start ja query_start. Need, ütleme nii, näitavad tehingu ja päringu käivitamise aega. Me võtame funktsiooni now(), mis näitab praegust ajamärki, ja lahutame tehingu ja päringu timestamp’id. Nii saame tehingu kestvuse ja päringu kestvuse.

Kui näeme pikki tehinguid, peame need lõpetama. OLTP-koormuse korral on pikad tehingud need, mis kestavad üle 1-2-3 minuti.. OLAP-koormuse korral on pikad tehingud normaalsed, kuid kui need kestavad üle kahe tunni, siis on see samuti märk sellest, et kuskil on meil moonutus.

Kui kliendid on andmebaasiga ühendatud, hakkavad nad töötama meie andmetega. Nad pöörduvad tabelite poole, nad pöörduvad indekste poole, et saada andmeid tabelist. On oluline hinnata, kuidas kliendid nende andmetega töötavad.

See on vajalik meie töökoormuse hindamiseks ja selleks, et mõista, millised tabelid on kõige "kuumemad". Näiteks on see kasulik olukordades, kus soovime "kuumad" tabelid paigutada kiirele SSD salvestusse. Samas võivad vanad arhiivtabelid, mida me enam ei kasuta, minna „külmale“ arhiivi SATA-diskidele, kus nad võivad jääda ootele, ning nendele juurdepääs toimub vajadusel.

See on samuti kasulik erinevate anomaaliate tuvastamiseks pärast uute versioonide ja juurutuste väljatoomist. Oleta, et projekt tutvustas uut funktsiooni. Näiteks lisati uus funktsionaalsus andmebaasiga töötamiseks. Kui me koostame tabelite kasutamise graafikud, saame nende graafikute pealt kergesti tuvastada need anomaaliad, näiteks uuenduste (update) või kustutuste (delete) tõusud. See on väga selgelt jälgitav.

Samuti saab tuvastada anomaaliaid "kallistatud" statistikast. Mida see tähendab? PostgreSQL-il on väga tugev ja hea päringute planeerija. Arendajad pühendavad palju aega selle arendamisele. Kuidas see töötab? Heade plaanide koostamiseks kogub PostgreSQL teatud ajavahemike järel statistikat tabelite andmete jaotuse kohta. See sisaldab kõige sagedasemaid väärtusi: unikaalsete väärtuste arv, teave NULL väärtuste kohta tabelis ja palju muud teavet.

Selle statistika põhjal koostab planeerija mitu päringut, valib kõige optimaalse või sobivama ning kasutab seda päringute plaani päringu täitmiseks ja andmete tagastamiseks.

Kuid võib juhtuda, et statistika "ujub". Tabelis on andmete kvaliteet ja hulk muutunud, kuid statistika ei ole selle ajaga uuendatud. Kujundatud plaanid võivad osutuda mitte-optimaalseteks. Ja kui meie plaanid osutuvad mitte-optimaalseteks kogutud jälgimise põhjal, tabelite osas, saame näha neid anomaaliaid. Näiteks on kusagil andmed kvaliteetselt muutunud ja koos indeksi kasutamisega kasutatakse järjestikku tabeli läbilugemist, st kui päring peab tagastama vaid 100 rida (on seatud piirmäär limit 100), siis selle päringu jaoks teostatakse täielik läbilugemine. Ja see mõjutab alati tulemuslikkust väga negatiivselt.

Ja saame seda jälgida monitoorimises. Saame vaadata sellele päringule, teostada explain'i, koguda statistikat, luua uue täiendava indeksi ja reageerida sellele probleemile. Seetõttu on see oluline.

Teine monitoorimise näide. Ma arvan, et paljud tunnevad seda, kuna see on väga populaarne. Kes kasutab seda oma projektides? Prometheus? А кто использует этот продукт совместно с Prometheus? Дело в том, что в стандартном репозитории этого мониторинга есть дашборд для работы с PostgreSQL – postgres_exporter Prometheus. Kuid siin on üks halb pool.

On mitmeid graafikuid. Ja mõõtühikuna on näidatud baite, st seal on 5 graafikut: Insert data, Update data, Delete data, Fetch data ja Return data. Kuid statistika PostgreSQL-is tagastab andmed tuple'is (rea kujul). Seetõttu on need graafikud väga hea viis teie töökoormuse alahindamiseks mitmekordselt, kümnetesse kordades, sest tuple ei ole bait, tuple on rida, mis on palju baite ja on alati muutuva pikkusega. Seega, töökoormuse arvutamine baidides kasutades tuplesid on ebarealistlik ülesanne või väga keeruline. Seetõttu, kui kasutate armatuurlauda või sisseehitatud monitooringut, on alati oluline mõista, et see töötab õigesti ja tagastab teile täpselt hinnatud andmed.

Kuidas saada statistikat nende tabelite kohta? Selleks on PostgreSQL-is teatud vaate perede rühm. Peamine vaade on pg_stat_user_tables. User_tables – see tähendab, et tabelid on loodud kasutaja nimel. Vastandina on süsteemivaatet, mida kasutab PostgreSQL ise. Ja on kokkuvõtte tabel Alltables, mis hõlmab nii süsteemis kui ka kasutaja tabelit. Saate tugineda ükskõik millisele, mis teile rohkem meeldib.

Ülaltoodud väljade põhjal on võimalik hinnata insertide, update'ide ja delete'ide arvu. See armatuurlaud, mida ma kasutasin, kasutab just neid välju töökoormuse omaduste hindamiseks. Seetõttu saame ka neid kasutada. Kuid tuleb meeles pidada, et need on tuples, mitte baidid, seega ei saa me lihtsalt võtta ja teha seda baidideks.

Nende andmete põhjal saame luua nn TopN-tabeleid. Näiteks Top-5, Top-10. Ja saab jälgida neid kuumaid tabeleid, mida kasutatakse rohkem kui teisi. Näiteks 5 "kuuma" tabelit sisestamise osas. Ja nende TopN-tabelite põhjal hindame oma töökoormust ja suudame hinnata töökoormuse piike pärast erinevaid väljalaskmisi, uuendusi ja deploy'e.

Samuti on oluline hinnata tabeli suurust, sest mõnikord arendajad kasutavad uut funktsionaalsust ning meie tabelid hakkavad suurendama oma mahtu, kuna otsustatakse lisada veel andmeid, kuid ei prognoosita, kuidas see mõjutab andmebaasi suurust. Sellised olukorrad võivad meie jaoks olla üllatuseks.

Ja nüüd on teil üks väike küsimus. Milline küsimus tekib, kui märkate andmebaasi serveri koormust? Milline järgmine küsimus te tahate esitada?

Aga tegelikult tekib järgnev küsimus. Millised päringud põhjustavad koormust? Ehk ei ole huvitav vaadata protsesse, mis koormust tekitavad. On selge, et kui host on andmebaasiga, siis seal töötab andmebaas ja seal ongi ainult andmebaasid. Kui me avame Top'i, siis näeme seal PostgreSQL protsesside nimekirja, mis midagi teevad. Top'ist ei ole selge, mida nad teevad.

Seega tuleb tuvastada need päringud, mis põhjustavad kõrgeima koormuse, kuna päringute häälestamine toob tavaliselt rohkem kasu kui PostgreSQL või operatsioonisüsteemi konfigureerimine või isegi riistvara häälestamine. Minu hinnangul on see umbes 80-85-90%. Ja seda on palju kiiremini teha. Kiirem on parandada päringut kui konfigureerida, planeerida taaskäivitust, eriti kui andmebaasi ei saa taaskäivitada, või lisada riistvara. Lihtsam on kuskil päringut ümber kirjutada või lisada indeks, et saada parem tulemus.

Seega on vajalik jälgida päringute adekvaatsust. Võtame teise näite jälgimisest. Ja siin tundub ka imeline jälgimine. On teave replikatsiooni, läbilaskevõime, lukustuste, ressursside kasutamise kohta. Kõik on suurepärane, kuid puudub teave päringute kohta. Ei ole selge, millised päringud meie andmebaasis täidetakse, kui kaua nad kestavad ja kui palju neid on. Me peame alati jälgimises olema selle teabe olemasolu.

Ja selle teabe saamiseks saame kasutada pg_stat_statements moodulit. Selle alusel on võimalik koostada erinevaid graafikuid. Näiteks saame saada teavet kõige sagedasemate päringute kohta, st nende päringute kohta, mis täidetakse kõige rohkem. Jah, pärast juurutamisi on samuti väga kasulik sellele pilku heita ja aru saada, kas päringutes on toimunud mõni järsk tõus.

Saame jälgida kõige pikemaid päringuid, st neid päringuid, mis täidetakse kõige kauem. Need kasutavad protsessorit ja nad tarbivad sisendi-väljundi ressursse. Saame neid samuti hinnata total_time, mean_time, blk_write_time ja blk_read_time väljade kaudu.

Saame hinnata ja jälgida kõige ressursimahukamaid päringuid, mis loevad kettalt, kas kasutavad mälu või vastupidi, genereerivad kirjutuskoormust.

Saame hinnata ka kõige heldemaid päringuid. Need on päringud, mis tagastavad suurt hulka ridu. Näiteks võib see olla mõni päring, millele ei pandud piiri ja see tagastab lihtsalt kogu tabeli sisu või päringute sisu, mis on küsitud tabelitest.

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

Ja meil on jäänud taustaprotsessid. Taustaprotsessid, eelkõige kontrollpunktid või neid nimetatakse ka kontrollpunktideks, on autovakuu ja replikatsioon.

Teine näide jälgimisest. Vasakul on hooldushulga vahekaart, läheme sinna ja loodame näha midagi kasulikku. Kuid siin on vaid vakkuumi ja statistika kogumise tööaeg, mitte rohkem. See on väga vaene teave, seetõttu on alati oluline omada teavet selle kohta, kuidas meie andmebaasi taustaprotsessid toimivad ja kas nende töö on tekitanud probleeme.

Kui vaatame kontrollpunkte, siis tuleb meeles pidada, et kontrollpunktid kirjutavad „räpased“ lehed killustatud mälust kettale ja loovad seejärel kontrollpunkti. Ja see kontrollpunkt võib hiljem kasutada punktina taastamiseks, kui PostgreSQL peaks ootamatult sulgema.

Seega, et kõik "räpast" lehte kettale kirjutada, on vajalik teatud kirjutamise maht. Ja tavaliselt on süsteemides, kus on suur mälumaht, see väga suur. Ja kui meil on kontrollpunktid väga sageli lühikese aja jooksul, siis kettasuuruse tootlikkus langeb oluliselt. Ja kliendi päringud kannatavad ressursside nappuse all. Nad võitlevad ressursside nimel ja neil puudub tootlikkus.

Seega, kaudu pg_stat_bgwriter saame nimetatud valdkondade kaudu jälgida tekkivate kontrollpunktide arvu. Ja kui meil on teatud ajavahemiku jooksul (10-15-20 minuti jooksul, pool tundi) väga palju kontrollpunkte, näiteks 3-4-5, siis see võib juba olla probleem. Ja tuleb vaadata andmebaasi, vaadata konfiguratsiooni, mis põhjustab sellist kontrollpunktide hulga. Võib-olla toimub mingisugune suur kirjutamine. Töökohustuse põhjal saame juba hinnata, kuna meil on töökoormuse graafikud juba lisatud. Me saame juba seadistada kontrollpunktide parameetreid ja teha nii, et need ei mõjuta päringute tootlikkust liiga palju.

Ma tulen taas autovacuum'i juurde, sest see on asi, nagu ma juba ütlesin, mis võib oluliselt mõjutada nii kõvaketaste kui ka päringute tootlikkust, seega on alati oluline hinnata autovacuum'i arvu.

Andmebaasis on autovacuum'i töömeeste arv piiratud. Vaikimisi on neid kolm, seega kui meil on kogu aeg kolm töömeest andmebaasis, tähendab see, et meie autovacuum on vale seadistusega, limiidid tuleb tõsta, autovacuum'i seadeid tuleb üle vaadata ja minna konfiguratsiooni.
Oluline on hinnata, millised autovacuum'i töötajad meil on. Kas see on käivitatud kasutaja poolt, DBA tuli ja käivitas käsitsi mingisuguse autovacuum'i, ja see tekitas koormuse. Meil tekkis mõni probleem. Või on see autovacuum'i hulk, mis keerab tehingute loendit. Mõnede PostgreSQL versioonide jaoks on need väga rasked autovacuum'id. Ja need võivad kergesti mõjutada tootlikkust, kuna nad loevad kogu tabeli täielikult, skaneerivad kõik plokid selles tabelis.

Ja, ja ja vaak või jooksul. Kui meil on pikad vaakumid, mis töötavad väga kaua, siis see tähendab, et peaksime uuesti vaatama vaakumi konfiguratsiooni ja võib-olla selle seadeid üle vaatama. Sest võib tekkida olukord, kus vaakum töötab tabeli kallal kaua (3-4 tundi), kuid selle töö jooksul on tabelisse kogunenud taas suur hulk surnud ridu. Ja niipea kui vaakum lõpetab, peab see tabelit uuesti vaakumeerima. Ja me saame olukorra – lõputu vaakum. Ja sellisel juhul ei suuda vaakum oma tööd täita ning tabelid hakkavad järk-järgult suurenenud mõõtmeid omandama, kuigi kasulik andmemaht jääb samaks. Seetõttu vaatame pikade vaakumite korral alati konfiguratsiooni ja püüame seda optimeerida, kuid samas mitte kannatada kliendi päringute jõudluse all.

Praegu ei ole praktiliselt ühtegi PostgreSQL installatsiooni, kus ei oleks voogedastust. Replikatsioon on andmete edastamise protsess meistrilt kopeerimisele.

Replikatsioon PostgreSQL-is on korraldatud läbi tehinguajaloos. Meister genereerib tehinguajaloo. Tehinguajalugu edastatakse võrguühenduse kaudu kopeerimisele, seejärel kopeerimisel see taastatakse. Kõik on lihtne.

Seega kasutatakse replikatsiooni viivituse jälgimiseks vaadet pg_stat_replication. Kuid see ei ole nii lihtne. Versioonis 10 on vaade läbi teinud mitmeid muudatusi. Esiteks, mõned väljad on ümber nimetatud. Ja mõned väljad on lisatud. 10. versioonis on ilmunud väljad, mis võimaldavad hinnata replikatsiooni viivitust sekundites. See on väga mugav. Enne versiooni 10 oli võimalik hinnata replikatsiooni viivitust baitides. See võimalus jäi alles ka 10. versioonis, st saate valida, mis teile mugavam on – hinnata viivitust baitides või sekundites. Paljud teevad mõlemat.

Kuid siiski, et hinnata replikatsiooni viivitust, on vaja teada ajalugu tehingus. Ja need tehinguajaloo positsioonid ongi vaates pg_stat_replication. Ütleme, et saame pg_xlog_location_diff() funktsiooni kaudu võtta kaks punkti tehinguajaloos. Arvutada nende vahelise erinevuse ja saada replikatsiooni viivitus baitides. See on väga mugav ja lihtne.

10. versioonis nimetati see funktsioon ümber pg_wal_lsn_diff(). Üldiselt asendati kõikides funktsioonides, vaadatud, utiliitides, kus esines sõna «xlog», see sõnaga «wal». See kehtib nii vaadatud kui ka funktsioonide puhul. See on selline uuendus.

10. versioonis lisandus ka rida, mis näitab konkreetset viivitust. Need on write lag, flush lag, replay lag. Teisisõnu, neid asju on oluline jälgida. Kui näeme replikatsiooni viivitust, tuleb uurida, miks see ilmus, kust see tuli ja probleem lahendada.

Süsteemi mõõdikud on enamasti korras. Iga jälgimise alguses alustatakse süsteemi mõõdikutega. Need on protsessorite, mälu, swap, võrgu ja ketta kasutuse määr. Siiski ei ole seal palju parameetreid vaikimisi.

Kui protsesside kasutus on korras, siis ketta kasutuses on probleeme. Reeglina lisavad jälgimisriistade arendajad teavet läbilaskvuse kohta. See võib olla iops või baitides. Kuid nad unustavad latentsuse ja ketta seadmete kasutuse. Need on olulisemad parameetrid, mis võimaldavad hinnata, kui palju meie kettad on koormatud ja kui palju nad peatumisi tekitavad. Kui meil on kõrge latentsus, tähendab see, et kettaga on mingeid probleeme. Kui meil on kõrge kasutus, tähendab see, et kettad ei suuda hakkama saada. Need on kvaliteetsemad omadused kui läbilaskvus.

Kuigi seda statistikat saab ka failisüsteemist /proc, nagu seda tehakse protsessorite kasutuse puhul. Miks seda teavet ei lisata jälgimistesse, ma ei tea. Siiski on oluline, et see oleks teie jälgimises.

Sama kehtib võrguinterfeisside kohta. Võrgu läbilaskvuse kohta on teavet pakettide ja baitide kaupa, kuid siiski puudub teave latentsuse ja kasutuse kohta, kuigi see on samuti kasulik teave.

Igal jälgimisel on puudused. Ükskõik millist jälgimist te võtate, see ei vasta alati mingitele kriteeriumidele. Siiski arenevad nad, lisatakse uusi funktsioone, uusi asju, seega valige midagi ja täiustage seda.

Ja et täiustada, tuleb alati teada, mida annab antud statistika ja kuidas selle abil probleeme lahendada.

Ja paar võtmehetke:

• Alati on oluline jälgida saadavust, et teil oleksid juhtpaneelid, kust kiiresti hinnata, kas andmebaas on korras.
• Alati on oluline teada, kes kliendid töötavad teie andmebaasi kallal, et filtreerida välja halvad kliendid ja neist vabaneda.
• Oluline on hinnata, kuidas need kliendid andmetega töötavad. Tuleb omada arusaama oma töökoormusest.
• Oluline on hinnata, kuidas see töökoormus tekib, milliste päringute kaudu. Te saate hinnata päringuid, optimeerida neid, refaktoreerida, luua neile indekseid. See on väga oluline.
• Taustprotsessid võivad negatiivselt mõjutada kliendi päringuid, seega on oluline jälgida, et need ei kasutaks liiga palju ressursse.
• Süsteemilised mõõdud võimaldavad teil koostada plaani skaleerimiseks, suurendades oma serverite võimsust, seega on oluline ka neid jälgida ja hinnata.

Kui see teema teid huvitab, siis võite tutvuda nende linkidega.
http://bit.do/stats_collector – see on ametlik dokumentatsioon statistika kogumise kohta. Seal on kirjeldus kõigist statistika vaadetest ja kõigist väljadest. Te saate neid lugeda, mõista ja analüüsida. Ja juba nende põhjal koostada oma graafikud, lisada oma jälgimisse.

Päringute näited:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

See on meie ettevõtte repositoorium ja minu isiklik. Neis on näited päringutest. Seal pole päringuid, nagu select* from midagi. Seal on juba valmis päringud, kus on kasutatud liiteid ja huvitavaid funktsioone, mis võimaldavad toorandmetest luua loetavaid ja mugavaid väärtusi, st need on baitides, ajas. Te saate neid käsitsi uurida, vaadata, analüüsida, lisada oma jälgimisse, koostada nende põhjal oma jälgimisse.

Küsimused

Küsimus: Te ütlesite, et te ei reklaami kaubamärke, aga mind ikkagi huvitab – milliseid juhtpaneele te oma projektides kasutate?
Vastus: Erinevalt. Juhtub, et me tuleme kliendi juurde ja tal on juba oma jälgimine olemas. Ja me anname kliendile nõu, mida oma jälgimisele lisada. Halvim on olukord Zabbiхiga. Sest tal pole võimalust koostada TopN-graafikuid. Me kasutame ise Okmeter, sest me andsime neile nõu jälgimise osas. Nad koostasid PostgreSQL-i jälgimise meie spetsifikatsiooni põhjal. Ma kirjutan oma isiklikku projekti, mis kogub andmeid Prometheuse kaudu ja joonistab need välja. Grafana. Mul on ülesanne luua Prometheus'esse oma eksporter ja hiljem kõik joonistada Grafanas.

Küsimus: Kas on olemas mingeid AWR-aruannete või ... aggregeerimise analooge? Kas olete teadlik millestki sellisest?
Vastus: Jah, ma tean, mis on AWR, see on päris äge asi. Praegusel hetkel on erinevaid lahendusi, mis rakendavad enam-vähem järgmist mudelit. Teatud aja intervallide järel kirjutatakse mõned aluseks olevad andmed samasse PostgreSQL-i või eraldi andmehoidlasse. Neid saab internetist otsida, need on olemas. Üks selle asja arendajatest on sql.ru foorumis PostgreSQL teemas, teda võib sealt üles leida. Jah, selliseid lahendusi on, neid saab kasutada. Peale selle pgCenter ma ka kirjutan asja, mis võimaldab teha sama.

P.S.1 Kui kasutate postgres_exporter'it, siis missugust armatuurlauad te kasutate? Need on mitmed. Need on juba vananenud. Kas kogukond võiks luua uuendatud malli?

P.S.2 Eemaldasin pganalyze, kuna see on patenteeritud SaaS, mis keskendub tulemuslikkuse jälgimisele ja automaatsetele seadistamise soovitustele.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Millist self-hosted PostgreSQL'i jälgimist (armatuurlauaga) peate parimaks?

• 30,0%Zabbix + Alexei Lesovski täiendused 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 kustutada.

• 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

Hääletas 10 kasutajat. Peatus 26 kasutajat.

Allikas: habr.com