Navrhujem, aby ste si prečítali prepis správy Alexeja Lesovského z Data Egret „Základy monitorovania PostgreSQL“
V tejto správe bude Alexey Lesovsky hovoriť o kľúčových bodoch postgresovej štatistiky, čo znamenajú a prečo by mali byť prítomné v monitorovaní; o tom, aké grafy by mali byť v monitorovaní, ako ich pridávať a ako ich interpretovať. Správa bude užitočná pre správcov databáz, systémových administrátorov a vývojárov, ktorí sa zaujímajú o riešenie problémov s Postgres.
Volám sa Alexey Lesovsky, zastupujem spoločnosť Data Egret.
Pár slov o sebe. Začínal som už dávno ako správca systému.
Spravoval som najrôznejšie linuxové systémy, pracoval som na rôznych veciach súvisiacich s Linuxom, t.j. virtualizácia, monitoring, pracoval som s proxy, atď. Ale v istom momente som začal viac pracovať s databázami, PostgreSQL. Mal som ho veľmi rád. A v určitom okamihu som začal pracovať na PostgreSQL väčšinu svojho pracovného času. A tak som sa postupne stal PostgreSQL DBA.
A počas mojej kariéry som sa vždy zaujímal o témy štatistiky, monitorovania a telemetrie. A keď som bol správcom systému, veľmi úzko som spolupracoval so Zabbixom. A napísal som malý súbor scenárov ako . Vo svojej dobe bol dosť populárny. A tam bolo možné sledovať veľmi rôzne dôležité veci, nielen Linux, ale aj rôzne komponenty.
Teraz pracujem na PostgreSQL. Už píšem ďalšiu vec, ktorá umožňuje pracovať so štatistikami PostgreSQL. To sa nazýva (článok o Habré - ).
Malá poznámka na úvod. Aké situácie majú naši zákazníci, naši klienti? V súvislosti s databázou došlo k nejakej nehode. A keď už je databáza obnovená, príde vedúci oddelenia alebo vedúci vývoja a hovorí: „Priatelia, musíme monitorovať databázu, pretože sa stalo niečo zlé a musíme tomu v budúcnosti zabrániť.“ A tu začína zaujímavý proces výberu monitorovacieho systému alebo prispôsobenia existujúceho monitorovacieho systému tak, aby ste mohli monitorovať svoju databázu – PostgreSQL, MySQL alebo niektoré ďalšie. A kolegovia začínajú navrhovať: „Počul som, že existuje taká a taká databáza. Poďme to využiť." Kolegovia sa začnú medzi sebou hádať. A nakoniec to dopadne tak, že vyberieme nejakú databázu, ale monitoring PostgreSQL je v nej prezentovaný dosť slabo a vždy musíme niečo pridávať. Vezmite si nejaké úložiská z GitHubu, naklonujte ich, prispôsobte skripty a nejako ich prispôsobte. A nakoniec to skončí akousi ručnou prácou.
Preto sa vám v tejto prednáške pokúsim priblížiť poznatky o tom, ako zvoliť monitoring nielen pre PostgreSQL, ale aj pre databázu. A poskytnúť vám znalosti, ktoré vám umožnia dokončiť vaše monitorovanie, aby ste z neho mali nejaký úžitok, aby ste mohli s výhodou monitorovať svoju databázu, aby ste mohli rýchlo predísť akýmkoľvek nadchádzajúcim núdzovým situáciám, ktoré môžu nastať.
A nápady, ktoré budú v tejto správe, môžu byť priamo prispôsobené akejkoľvek databáze, či už je to DBMS alebo noSQL. Preto neexistuje len PostgreSQL, ale v PostgreSQL bude veľa receptov, ako to urobiť. Budú tam príklady dotazov, príklady entít, ktoré má PostgreSQL na monitorovanie. A ak má váš DBMS rovnaké veci, ktoré vám umožňujú dať ich do monitorovania, môžete ich tiež prispôsobiť, pridať a bude to dobré.
Nebudem v správe
hovoriť o tom, ako doručovať a uchovávať metriky. Nebudem hovoriť nič o dodatočnom spracovaní údajov a ich prezentovaní používateľovi. A nepoviem nič o varovaní.
Ale ako príbeh napreduje, ukážem rôzne screenshoty existujúceho monitorovania a nejako ich kritizujem. Ale napriek tomu sa budem snažiť neuvádzať značky, aby som nevytvárala reklamu alebo antireklamu na tieto produkty. Preto sú všetky náhody náhodné a sú ponechané na vašej fantázii.
Po prvé, poďme zistiť, čo je monitorovanie. Monitorovanie je veľmi dôležitá vec. Každý tomu rozumie. Zároveň sa však monitorovanie netýka obchodného produktu a priamo neovplyvňuje zisk spoločnosti, takže čas je vždy pridelený monitorovaniu na zvyškovom základe. Ak máme čas, potom monitorujeme; ak nemáme čas, potom OK, zaradíme to do nevybavených vecí a jedného dňa sa k týmto úlohám vrátime.
Preto z našej praxe, keď prichádzame ku klientom, je monitoring často neúplný a nemá žiadne zaujímavosti, ktoré by nám pomohli lepšie pracovať s databázou. A preto je potrebné sledovanie vždy dokončiť.
Databázy sú také zložité veci, ktoré treba aj monitorovať, pretože databázy sú úložiskom informácií. A informácie sú pre spoločnosť veľmi dôležité, nemožno ich v žiadnom prípade stratiť. Zároveň sú však databázy veľmi zložité softvéry. Skladajú sa z veľkého množstva komponentov. A mnohé z týchto komponentov je potrebné sledovať.
Ak hovoríme konkrétne o PostgreSQL, potom môže byť reprezentovaný vo forme schémy, ktorá pozostáva z veľkého počtu komponentov. Tieto komponenty sa navzájom ovplyvňujú. A zároveň má PostgreSQL takzvaný Stats Collector subsystém, ktorý umožňuje zbierať štatistiky o fungovaní týchto subsystémov a poskytnúť akési rozhranie správcovi alebo používateľovi, aby si tieto štatistiky mohol prezerať.
Tieto štatistiky sú prezentované vo forme určitého súboru funkcií a zobrazení. Môžu sa nazývať aj tabuľky. To znamená, že pomocou bežného klienta psql sa môžete pripojiť k databáze, vybrať si tieto funkcie a zobrazenia a získať konkrétne čísla o prevádzke podsystémov PostgreSQL.
Tieto čísla môžete pridať do svojho obľúbeného monitorovacieho systému, kresliť grafy, pridávať funkcie a získavať analýzy z dlhodobého hľadiska.
V tejto správe sa však nebudem venovať všetkým týmto funkciám, pretože by to mohlo trvať celý deň. Doslova sa budem venovať dvom, trom alebo štyrom veciam a poviem vám, ako pomáhajú zlepšiť monitorovanie.
A ak hovoríme o monitorovaní databázy, čo je potrebné monitorovať? V prvom rade musíme sledovať dostupnosť, pretože databáza je služba, ktorá zabezpečuje prístup k dátam klientom a my potrebujeme dostupnosť monitorovať a tiež poskytovať niektoré jej kvalitatívne a kvantitatívne charakteristiky.
Musíme tiež monitorovať klientov, ktorí sa pripájajú k našej databáze, pretože môžu byť bežnými klientmi aj škodlivými klientmi, ktorí môžu poškodiť databázu. Tiež ich treba monitorovať a sledovať ich aktivity.
Keď sa klienti pripájajú k databáze, je zrejmé, že začínajú pracovať s našimi údajmi, preto musíme sledovať, ako klienti s údajmi pracujú: s akými tabuľkami av menšej miere aj s akými indexmi. To znamená, že musíme vyhodnotiť pracovnú záťaž, ktorú vytvárajú naši klienti.
Pracovná náplň však pozostáva, samozrejme, aj z požiadaviek. Aplikácie sa pripájajú k databáze, pristupujú k dátam pomocou dotazov, preto je dôležité vyhodnocovať, aké dotazy v databáze máme, sledovať ich primeranosť, či nie sú krivo napísané, že niektoré voľby treba prepísať a urobiť tak, aby fungovali rýchlejšie a s lepším výkonom.
A keďže hovoríme o databáze, v databáze sú vždy procesy na pozadí. Procesy na pozadí pomáhajú udržiavať výkon databázy na dobrej úrovni, takže na svoju činnosť vyžadujú určité množstvo zdrojov. A zároveň sa môžu prekrývať so zdrojmi požiadaviek klientov, takže chamtivé procesy na pozadí môžu priamo ovplyvniť výkon požiadaviek klientov. Preto ich treba tiež monitorovať a sledovať, aby nedochádzalo k skresleniam z hľadiska procesov na pozadí.
A to všetko z hľadiska monitorovania databázy zostáva v systémovej metrike. Ale vzhľadom na to, že väčšina našej infraštruktúry sa presúva do oblakov, systémové metriky jednotlivých hostiteľov vždy ustúpia do pozadia. No v databázach sú stále aktuálne a samozrejme je potrebné sledovať aj systémové metriky.
So systémovými metrikami je všetko viac-menej v poriadku, všetky moderné monitorovacie systémy už tieto metriky podporujú, no vo všeobecnosti niektoré komponenty stále nestačia a niektoré veci treba doplniť. Dotknem sa ich aj ja, bude o nich viacero diapozitívov.
Prvým bodom plánu je dostupnosť. Čo je prístupnosť? Dostupnosť v mojom chápaní je schopnosť základne obsluhovať pripojenia, t. j. základňa je zdvihnutá, ako služba prijíma pripojenia od klientov. A túto prístupnosť možno posúdiť podľa určitých charakteristík. Je veľmi vhodné zobraziť tieto charakteristiky na prístrojových doskách.
Každý vie, čo sú palubné dosky. Vtedy ste sa pozreli na obrazovku, na ktorej sú zhrnuté potrebné informácie. A môžete okamžite určiť, či je v databáze problém alebo nie.
Dostupnosť databázy a ďalšie kľúčové charakteristiky by preto mali byť vždy zobrazené na dashboardoch, aby ste tieto informácie mali vždy po ruke a k dispozícii. Niektoré ďalšie detaily, ktoré už pomáhajú pri vyšetrovaní incidentov, pri vyšetrovaní niektorých mimoriadnych situácií už musia byť umiestnené na sekundárnych palubných doskách alebo skryté v hĺbkových prepojeniach, ktoré vedú k monitorovacím systémom tretích strán.
Príklad jedného známeho monitorovacieho systému. Toto je veľmi skvelý monitorovací systém. Zbiera množstvo dát, no z môjho pohľadu má zvláštny koncept dashboardov. Existuje odkaz na „vytvoriť informačný panel“. Ale keď vytvoríte dashboard, vytvoríte zoznam dvoch stĺpcov, zoznam grafov. A keď sa potrebujete na niečo pozrieť, začnete klikať myšou, rolovať, hľadať požadovaný graf. A to si vyžaduje čas, t. j. neexistujú žiadne informačné panely ako také. Existujú iba zoznamy grafov.
Čo by ste mali pridať do týchto informačných panelov? Môžete začať s takou charakteristikou, ako je doba odozvy. PostgreSQL má pohľad pg_stat_statements. V predvolenom nastavení je vypnutá, ale je to jedno z dôležitých systémových zobrazení, ktoré by sa malo vždy povoliť a používať. Ukladá informácie o všetkých spustených dotazoch, ktoré boli vykonané v databáze.
Podľa toho môžeme vychádzať zo skutočnosti, že môžeme zobrať celkový čas vykonania všetkých požiadaviek a vydeliť ho počtom požiadaviek pomocou vyššie uvedených polí. Ale toto je priemerná teplota v nemocnici. Môžeme začať z iných polí – minimálny čas vykonania dotazu, maximum a medián. A dokonca môžeme vytvárať percentily; PostgreSQL má na to zodpovedajúce funkcie. A môžeme získať nejaké čísla, ktoré charakterizujú čas odozvy našej databázy pre už dokončené požiadavky, t. j. nevykonávame falošnú požiadavku „vyber 1“ a nepozeráme sa na čas odozvy, ale analyzujeme čas odozvy pre už dokončené požiadavky a žrebujeme buď samostatný údaj, alebo na základe neho zostavíme graf.
Dôležité je tiež sledovať počet chýb, ktoré systém aktuálne generuje. A na to môžete použiť pohľad pg_stat_database. Zameriavame sa na pole xact_rollback. Toto pole zobrazuje nielen počet zmien, ktoré sa vyskytujú v databáze, ale zohľadňuje aj počet chýb. Relatívne povedané, môžeme toto číslo zobraziť na našom informačnom paneli a zistiť, koľko chýb momentálne máme. Ak existuje veľa chýb, potom je to dobrý dôvod na to, aby ste sa pozreli do protokolov a zistili, aké chyby sú a prečo sa vyskytujú, a potom ich investujte a vyriešite.
Môžete pridať niečo ako tachometer. Ide o počet transakcií za sekundu a počet žiadostí za sekundu. Relatívne povedané, tieto čísla môžete použiť ako aktuálny výkon vašej databázy a sledovať, či sú špičky v požiadavkách, špičky v transakciách, alebo naopak, či nie je databáza vyťažená, pretože nejaký backend zlyhal. Je dôležité, aby ste sa vždy pozreli na toto číslo a zapamätali si, že pre náš projekt je tento druh výkonu normálny, ale hodnoty vyššie a nižšie sú už nejakým spôsobom problematické a nepochopiteľné, čo znamená, že sa musíme pozrieť na to, prečo sú tieto čísla tak vysoká.
Aby sme mohli odhadnúť počet transakcií, môžeme sa opäť odvolať na pohľad pg_stat_database. Môžeme pridať počet potvrdení a počet vrátení a získať počet transakcií za sekundu.
Chápe každý, že do jednej transakcie sa zmestí niekoľko požiadaviek? Preto sa TPS a QPS mierne líšia.
Počet požiadaviek za sekundu je možné získať z pg_stat_statements a jednoducho vypočítať súčet všetkých dokončených požiadaviek. Je jasné, že porovnáme aktuálnu hodnotu s predchádzajúcou, odčítame ju, dostaneme deltu a dostaneme množstvo.
V prípade potreby môžete pridať ďalšie metriky, ktoré tiež pomáhajú vyhodnotiť dostupnosť našej databázy a monitorovať, či nedošlo k výpadkom.
Jednou z týchto metrík je dostupnosť. Ale dostupnosť v PostgreSQL je trochu zložitejšia. Poviem ti prečo. Po spustení PostgreSQL sa začne hlásiť dostupnosť. Ale ak v určitom okamihu napríklad bežala nejaká úloha v noci, prišiel OOM-killer a násilne ukončil podriadený proces PostgreSQL, potom v tomto prípade PostgreSQL ukončí pripojenie všetkých klientov, obnoví oblasť štiepenej pamäte a začne obnovu z posledný kontrolný bod. A kým táto obnova z kontrolného bodu trvá, databáza neakceptuje spojenia, t.j. túto situáciu možno hodnotiť ako výpadok. Počítadlo doby prevádzky sa však nevynuluje, pretože berie do úvahy čas spustenia správcu pošty od prvého okamihu. Preto je možné takéto situácie preskočiť.
Mali by ste sledovať aj počet pracovníkov vysávača. Vie každý, čo je autovakuum v PostgreSQL? Toto je zaujímavý podsystém v PostgreSQL. Bolo o nej napísaných veľa článkov, vzniklo veľa reportáží. O vákuu a o tom, ako by malo fungovať, sa vedú mnohé diskusie. Mnohí to považujú za nutné zlo. Ale je to tak. Toto je druh analógu zberača odpadu, ktorý čistí zastarané verzie riadkov, ktoré nepotrebuje žiadna transakcia, a uvoľňuje miesto v tabuľkách a indexoch pre nové riadky.
Prečo to potrebujete sledovať? Pretože vákuum niekedy veľmi bolí. Spotrebúva veľké množstvo zdrojov a tým začínajú trpieť požiadavky klientov.
A mal by byť monitorovaný cez pohľad pg_stat_activity, o ktorom budem hovoriť v ďalšej časti. Toto zobrazenie zobrazuje aktuálnu aktivitu v databáze. A prostredníctvom tejto aktivity môžeme sledovať počet vysávačov, ktoré práve fungujú. Môžeme sledovať vysávače a vidíme, že ak sme prekročili limit, tak je to dôvod pozrieť sa do nastavení PostgreSQL a nejako optimalizovať fungovanie vysávača.
Ďalšia vec týkajúca sa PostgreSQL je, že PostgreSQL je veľmi chorý na dlhé transakcie. Najmä z transakcií, ktoré sa dlho motajú a nič nerobia. Ide o takzvaný stat idle-in-transaction. Takáto transakcia drží zámky a zabraňuje fungovaniu vákua. A v dôsledku toho sa tabuľky nafúknu a zväčšia. A dotazy, ktoré pracujú s týmito tabuľkami, začnú pracovať pomalšie, pretože musíte preniesť všetky staré verzie riadkov z pamäte na disk a späť. Preto je potrebné sledovať aj čas, trvanie najdlhších transakcií, najdlhšie požiadavky na vákuum. A ak vidíme niektoré procesy, ktoré sú spustené veľmi dlho, už viac ako 10-20-30 minút na zaťaženie OLTP, tak im treba venovať pozornosť a násilne ich ukončiť, prípadne optimalizovať aplikáciu tak, aby nie sú volané a nevisia tak dlho. Pre analytickú záťaž je normálnych 10-20-30 minút, sú aj dlhšie.
Ďalej máme možnosť s pripojenými klientmi. Keď už máme vytvorený dashboard a uverejňujeme na ňom kľúčové metriky dostupnosti, môžeme tam pridať aj ďalšie informácie o pripojených klientoch.
Informácie o pripojených klientoch sú dôležité, pretože z pohľadu PostgreSQL sú klienti odlišní. Sú dobrí klienti a sú zlí klienti.
Jednoduchý príklad. Klientom rozumiem aplikácii. Aplikácia sa pripojila k databáze a okamžite tam začne odosielať svoje požiadavky, databáza ich spracuje a vykoná a výsledky vráti klientovi. Sú to dobrí a korektní klienti.
Sú situácie, keď sa klient pripojil, drží pripojenie, ale nič nerobí. Je v nečinnom stave.
Ale sú aj zlí klienti. Ten istý klient sa napríklad pripojil, otvoril transakciu, urobil niečo v databáze a potom prešiel do kódu, napríklad aby sa dostal k externému zdroju alebo tam spracoval prijaté dáta. Transakciu však neuzavrel. A transakcia visí v databáze a je držaná v zámku na linke. Toto je zlý stav. A ak náhle aplikácia niekde v sebe zlyhá s výnimkou, transakcia môže zostať otvorená veľmi dlho. A to priamo ovplyvňuje výkon PostgreSQL. PostgreSQL bude pomalší. Preto je dôležité takýchto klientov včas sledovať a násilne ukončiť ich prácu. A aby k takýmto situáciám nedochádzalo, musíte svoju aplikáciu optimalizovať.
Ďalší zlí klienti sú čakajúci klienti. Ale stanú sa zlými kvôli okolnostiam. Napríklad jednoduchá nečinná transakcia: môže otvoriť transakciu, zablokovať niektoré riadky, potom niekde v kóde zlyhá a transakcia zostane visieť. Príde ďalší klient a požiada o rovnaké údaje, ale narazí na zámok, pretože táto zavesená transakcia už obsahuje zámky na niektorých požadovaných riadkoch. A druhá transakcia bude čakať, kým sa prvá transakcia dokončí alebo ju násilne uzavrie administrátor. Preto sa čakajúce transakcie môžu hromadiť a naplniť limit pripojenia k databáze. A keď je limit plný, aplikácia už nemôže pracovať s databázou. Pre projekt je to už núdzová situácia. Zlých klientov preto treba sledovať a včas na ne reagovať.
Ďalší príklad monitorovania. A tu je už slušná palubná doska. Informácie o spojeniach sú uvedené vyššie. DB pripojenie – 8 kusov. A to je všetko. Nemáme informácie o tom, ktorí klienti sú aktívni, ktorí klienti sú len nečinní, nič nerobia. Neexistujú žiadne informácie o čakajúcich transakciách a čakajúcich pripojeniach, t. j. toto je číslo, ktoré ukazuje počet pripojení a to je všetko. A potom hádajte sami.
Ak chcete pridať tieto informácie do monitorovania, musíte vstúpiť do systémového zobrazenia pg_stat_activity. Ak trávite veľa času v PostgreSQL, potom je to veľmi dobrý pohľad, ktorý by sa mal stať vaším priateľom, pretože zobrazuje aktuálnu aktivitu v PostgreSQL, teda to, čo sa v ňom deje. Pre každý proces existuje samostatný riadok, ktorý zobrazuje informácie o tomto procese: z ktorého hostiteľa bolo vytvorené pripojenie, pod akým používateľom, pod akým menom, kedy bola transakcia spustená, aká požiadavka práve prebieha, aká požiadavka bola naposledy vykonaná. A podľa toho môžeme vyhodnotiť stav klienta pomocou štatistického poľa. Relatívne povedané, môžeme zoskupiť podľa tohto poľa a získať tie štatistiky, ktoré sú momentálne v databáze a počet spojení, ktoré majú túto štatistiku v databáze. A už prijaté čísla vieme poslať do nášho monitoringu a na základe nich vykresliť grafy.
Dôležité je vyhodnotiť aj trvanie transakcie. Už som povedal, že je dôležité vyhodnocovať trvanie vákua, ale transakcie sa hodnotia rovnakým spôsobom. Existujú polia xact_start a query_start. Relatívne povedané, ukazujú čas začiatku transakcie a čas začiatku požiadavky. Vezmeme funkciu now(), ktorá zobrazuje aktuálnu časovú pečiatku, a odpočítame časovú pečiatku transakcie a požiadavky. A dostaneme trvanie transakcie, trvanie požiadavky.
Ak vidíme dlhé transakcie, mali by sme ich už dokončiť. Pri zaťažení OLTP sú dlhé transakcie už viac ako 1-2-3 minúty. Pre pracovné zaťaženie OLAP sú dlhé transakcie normálne, ale ak ich dokončenie trvá viac ako dve hodiny, je to tiež znak toho, že niekde máme odchýlku.
Keď sa klienti pripojí k databáze, začnú pracovať s našimi údajmi. Pristupujú k tabuľkám, pristupujú k indexom, aby získali údaje z tabuľky. A je dôležité vyhodnotiť, ako klienti interagujú s týmito údajmi.
Je to potrebné, aby sme zhodnotili našu pracovnú záťaž a zhruba pochopili, ktoré tabuľky sú pre nás „najhorúcejšie“. Napríklad je to potrebné v situáciách, keď chceme umiestniť „horúce“ stoly na nejaké rýchle úložisko SSD. Napríklad niektoré archívne tabuľky, ktoré sme dlho nepoužívali, je možné presunúť do nejakého „studeného“ archívu, na disky SATA a nechať ich tam žiť, bude sa k nim pristupovať podľa potreby.
To je tiež užitočné pri zisťovaní anomálií po akýchkoľvek vydaniach a nasadení. Povedzme, že projekt vydal nejakú novú funkciu. Pridali sme napríklad novú funkcionalitu pre prácu s databázou. A ak vykreslíme grafy používania tabuľky, môžeme tieto anomálie na týchto grafoch ľahko odhaliť. Napríklad aktualizovať zhluky alebo odstrániť zhluky. Bude to veľmi viditeľné.
Môžete tiež zistiť anomálie v „plávajúcich“ štatistikách. Čo to znamená? PostgreSQL má veľmi silný a veľmi dobrý plánovač dotazov. A vývojári venujú jeho vývoju veľa času. ako pracuje? Aby bolo možné robiť dobré plány, PostgreSQL zbiera štatistiky o distribúcii údajov v tabuľkách v určitom časovom intervale a s určitou frekvenciou. Toto sú najčastejšie hodnoty: počet jedinečných hodnôt, informácie o NULL v tabuľke, množstvo informácií.
Na základe týchto štatistík plánovač zostaví niekoľko dotazov, vyberie ten najoptimálnejší a tento plán dotazov použije na vykonanie samotného dotazu a vrátenie údajov.
A stáva sa, že štatistiky „plávajú“. Údaje o kvalite a kvantite sa v tabuľke nejako zmenili, ale štatistiky sa nezbierali. A vytvorené plány nemusia byť optimálne. A ak sa naše plány na základe zozbieraného monitorovania na základe tabuliek ukážu ako neoptimálne, budeme môcť tieto anomálie vidieť. Napríklad niekde sa dáta kvalitatívne zmenili a namiesto indexu sa začal používať sekvenčný prechod cez tabuľku, t.j. ak dotaz potrebuje vrátiť iba 100 riadkov (limit je 100), potom sa pre tento dotaz vykoná úplné vyhľadávanie. A to má vždy veľmi zlý vplyv na výkon.
A môžeme to vidieť pri monitorovaní. A už sa pozrite na tento dotaz, spustite jeho vysvetlenie, zbierajte štatistiky, vytvorte nový dodatočný index. A už reagujte na tento problém. Preto je to dôležité.
Ďalší príklad monitorovania. Myslím, že veľa ľudí ho spoznalo, pretože je veľmi populárny. Kto to používa vo svojich projektoch ? Kto používa tento produkt v spojení s Prometheus? Faktom je, že v štandardnom úložisku tohto monitorovania je dashboard pre prácu s PostgreSQL - Prometheus. Ale je tu jeden zlý detail.
Existuje niekoľko grafov. A bajty sú označené ako jednota, t.j. existuje 5 grafov. Sú to Vložiť údaje, Aktualizovať údaje, Vymazať údaje, Načítať údaje a Vrátiť údaje. Jednotkou merania sú bajty. Ide však o to, že štatistiky v PostgreSQL vracajú údaje v niciach (riadkoch). A preto sú tieto grafy veľmi dobrým spôsobom, ako podceniť svoju pracovnú záťaž niekoľkokrát, desiatky krát, pretože n-tica nie je bajt, n-tica je reťazec, má veľa bajtov a vždy má premenlivú dĺžku. To znamená, že výpočet pracovného zaťaženia v bajtoch pomocou n-tic je nereálna alebo veľmi náročná úloha. Preto, keď používate dashboard alebo vstavané monitorovanie, je vždy dôležité pochopiť, že funguje správne a vracia vám správne vyhodnotené údaje.
Ako získať štatistiky o týchto tabuľkách? Na tento účel má PostgreSQL určitú rodinu pohľadov. A hlavný pohľad je . User_tables – to znamená tabuľky vytvorené v mene používateľa. Naproti tomu existujú systémové pohľady, ktoré využíva samotný PostgreSQL. A je tu súhrnná tabuľka Alltables, ktorá zahŕňa systémové aj užívateľské. Môžete začať od ktorejkoľvek z nich, ktorá sa vám najviac páči.
Pomocou vyššie uvedených polí môžete odhadnúť počet vložení, aktualizácií a vymazaní. Príklad dashboardu, ktorý som použil, používa tieto polia na vyhodnotenie charakteristík pracovného zaťaženia. Preto môžeme stavať aj na nich. Je však potrebné pripomenúť, že ide o n-tice, nie o bajty, takže to nemôžeme robiť len v bajtoch.
Na základe týchto údajov môžeme zostaviť takzvané TopN tabuľky. Napríklad Top-5, Top-10. A môžete sledovať tie horúce stoly, ktoré sa recyklujú viac ako iné. Napríklad 5 „horúcich“ tabuliek na vkladanie. A pomocou týchto tabuliek TopN vyhodnotíme našu pracovnú záťaž a dokážeme vyhodnotiť návaly pracovnej záťaže po akýchkoľvek vydaniach, aktualizáciách a nasadení.
Je tiež dôležité vyhodnotiť veľkosť tabuľky, pretože vývojári niekedy zavádzajú novú funkciu a naše tabuľky sa začínajú zväčšovať vo svojich veľkých veľkostiach, pretože sa rozhodli pridať ďalšie množstvo údajov, ale nepredpovedali, ako to bude ovplyvňujú veľkosť databázy. Aj takéto prípady sú pre nás prekvapením.
A teraz malá otázka pre vás. Aká otázka vyvstáva, keď si všimnete zaťaženie databázového servera? Akú máte ďalšiu otázku?
Ale v skutočnosti vyvstáva otázka nasledovne. Aké požiadavky spôsobuje zaťaženie? To znamená, že nie je zaujímavé pozerať sa na procesy, ktoré sú spôsobené záťažou. Je jasné, že ak má hostiteľ databázu, tak tam tá databáza beží a je jasné, že sa tam budú likvidovať len databázy. Ak otvoríme Top, uvidíme tam zoznam procesov v PostgreSQL, ktoré niečo robia. Z Top nebude jasné, čo robia.
V súlade s tým musíte nájsť tie dopyty, ktoré spôsobujú najväčšie zaťaženie, pretože ladenie dopytov spravidla prináša väčší zisk ako ladenie konfigurácie PostgreSQL alebo operačného systému alebo dokonca ladenie hardvéru. Podľa môjho odhadu je to približne 80-85-90%. A to sa robí oveľa rýchlejšie. Je rýchlejšie opraviť požiadavku ako opraviť konfiguráciu, naplánovať reštart, najmä ak nie je možné reštartovať databázu, alebo pridať hardvér. Je jednoduchšie niekde prepísať dotaz alebo pridať index, aby ste z tohto dotazu získali lepší výsledok.
Podľa toho je potrebné sledovať požiadavky a ich primeranosť. Zoberme si ďalší príklad monitorovania. A zdá sa, že aj tu je výborný monitoring. Sú tam informácie o replikácii, sú tam informácie o priepustnosti, blokovaní, využití zdrojov. Všetko je v poriadku, ale neexistujú žiadne informácie o žiadostiach. Nie je jasné, aké dopyty bežia v našej databáze, ako dlho bežia, koľko týchto dopytov je. Tieto informácie musíme mať vždy pri našom monitorovaní.
A na získanie týchto informácií môžeme použiť modul pg_stat_statements. Na základe toho môžete zostaviť rôzne grafy. Môžete napríklad získať informácie o najčastejších dopytoch, teda o dopytoch, ktoré sa najčastejšie vykonávajú. Áno, po nasadení je tiež veľmi užitočné sa na to pozrieť a pochopiť, či došlo k nejakému nárastu požiadaviek.
Môžete monitorovať najdlhšie dopyty, teda tie, ktoré trvajú najdlhšie. Bežia na procesore, spotrebúvajú I/O. Môžeme to vyhodnotiť aj pomocou polí total_time, mean_time, blk_write_time a blk_read_time.
Dokážeme vyhodnocovať a monitorovať tie najťažšie požiadavky z hľadiska využitia zdrojov, tie, ktoré čítajú z disku, pracujú s pamäťou, alebo naopak vytvárajú nejakú tú zapisovaciu záťaž.
Dokážeme vyhodnotiť najštedrejšie požiadavky. Toto sú dopyty, ktoré vracajú veľký počet riadkov. Môže to byť napríklad nejaká požiadavka, kde zabudli nastaviť limit. A jednoducho vráti celý obsah tabuľky alebo dotazu cez dopytované tabuľky.
Môžete tiež monitorovať dotazy, ktoré používajú dočasné súbory alebo dočasné tabuľky.
A stále máme procesy na pozadí. Procesy na pozadí sú primárne kontrolné body alebo sa nazývajú aj kontrolné body, sú to autovakuum a replikácia.
Ďalší príklad monitorovania. Vľavo je karta Údržba, prejdite na ňu a dúfajte, že uvidíte niečo užitočné. Ale tu je len čas prevádzky vákua a zber štatistík, nič viac. Ide o veľmi slabé informácie, takže vždy potrebujeme mať informácie o tom, ako fungujú procesy na pozadí v našej databáze a či sa nevyskytujú nejaké problémy z ich práce.
Keď sa pozrieme na kontrolné body, mali by sme pamätať na to, že kontrolné body vyprázdnia špinavé stránky z oblasti rozbitej pamäte na disk a potom vytvoria kontrolný bod. A tento kontrolný bod sa potom môže použiť ako miesto na obnovenie, ak bol PostgreSQL náhle ukončený v núdzovej situácii.
Preto, aby ste vyprázdnili všetky „špinavé“ stránky na disk, musíte urobiť určité množstvo zápisu. A v systémoch s veľkým množstvom pamäte je to spravidla veľa. A ak robíme kontrolné body veľmi často v krátkom intervale, tak výkon disku veľmi výrazne klesne. A požiadavky klientov budú trpieť nedostatkom zdrojov. Budú súťažiť o zdroje a chýba im produktivita.
V súlade s tým môžeme prostredníctvom pg_stat_bgwriter pomocou špecifikovaných polí monitorovať počet kontrolných bodov, ktoré sa vyskytujú. A ak máme za určitý čas (za 10-15-20 minút, za pol hodinu) veľa kontrolných bodov, napríklad 3-4-5, tak to už môže byť problém. A už sa treba pozrieť do databázy, pozrieť do konfigurácie, čo spôsobuje takú hojnosť kontrolných bodov. Možno sa deje nejaké veľké nahrávanie. Už vieme vyhodnotiť záťaž, pretože sme už pridali aj grafy záťaže. Parametre kontrolných bodov už môžeme vyladiť a uistiť sa, že výrazne neovplyvnia výkon dotazu.
Opäť sa vraciam k automatickému vákuovaniu, pretože je to taká vec, ako som už povedal, ktorá môže ľahko sčítať výkon disku aj dotazu, takže je vždy dôležité odhadnúť veľkosť automatického vákua.
Počet pracovníkov autovakuovania v databáze je obmedzený. Štandardne sú tri, takže ak v databáze pracujú vždy traja pracovníci, znamená to, že naše autovákuovanie nie je nakonfigurované, musíme zvýšiť limity, upraviť nastavenia autovákua a dostať sa do konfigurácie.
Dôležité je zhodnotiť, akých vysávačov máme. Buď to bolo spustené od používateľa, DBA prišiel a manuálne spustil nejaký druh vákua, a to vytvorilo záťaž. Máme nejaký problém. Alebo toto je počet vákuov, ktoré odskrutkujú počítadlo transakcií. Pre niektoré verzie PostgreSQL sú to veľmi ťažké vysávače. A môžu ľahko sčítať výkon, pretože prečítajú celú tabuľku, naskenujú všetky bloky v tejto tabuľke.
A, samozrejme, trvanie vysávania. Ak máme vysávače s dlhou životnosťou, ktoré bežia veľmi dlho, znamená to, že opäť musíme venovať pozornosť konfigurácii vysávača a možno prehodnotiť jeho nastavenie. Pretože môže nastať situácia, keď vákuum na stole pracuje dlhšiu dobu (3-4 hodiny), no počas doby pôsobenia podtlaku sa v stole stihlo opäť nahromadiť veľké množstvo mŕtvych riadkov. A akonáhle je vysávanie dokončené, potrebuje tento stôl povysávať znova. A dostávame sa k situácii – nekonečnému vákuu. A v tomto prípade vákuum nezvláda svoju prácu a tabuľky sa postupne začínajú zväčšovať, hoci objem užitočných údajov v ňom zostáva rovnaký. Preto sa pri dlhom vysávaní vždy pozeráme na konfiguráciu a snažíme sa ju optimalizovať, no zároveň tak, aby neutrpel výkon požiadaviek klientov.
V súčasnosti prakticky neexistuje inštalácia PostgreSQL, ktorá by nemala streamingovú replikáciu. Replikácia je proces presunu údajov z hlavného servera do repliky.
Replikácia v PostgreSQL sa vykonáva prostredníctvom protokolu transakcií. Sprievodca vygeneruje protokol transakcií. Protokol transakcií prechádza cez sieťové pripojenie k replike a potom sa reprodukuje v replike. Je to jednoduché.
V súlade s tým sa na monitorovanie oneskorenia replikácie používa pohľad pg_stat_replication. Ale nie všetko je s ňou jednoduché. Vo verzii 10 prešiel pohľad niekoľkými zmenami. Po prvé, niektoré polia boli premenované. A pribudli aj niektoré polia. Vo verzii 10 sa objavili polia, ktoré umožňujú odhadnúť oneskorenie replikácie v sekundách. Je to veľmi pohodlné. Pred verziou 10 bolo možné odhadnúť oneskorenie replikácie v bajtoch. Táto možnosť zostáva vo verzii 10, t.j. môžete si vybrať, čo je pre vás pohodlnejšie - odhadnúť oneskorenie v bajtoch alebo odhadnúť oneskorenie v sekundách. Veľa ľudí robí oboje.
Aby ste však mohli vyhodnotiť oneskorenie replikácie, musíte poznať pozíciu protokolu v transakcii. A tieto pozície protokolu transakcií sú presne v zobrazení pg_stat_replication. Relatívne povedané, pomocou funkcie pg_xlog_location_diff() môžeme získať dva body v protokole transakcií. Vypočítajte deltu medzi nimi a získajte oneskorenie replikácie v bajtoch. Je to veľmi pohodlné a jednoduché.
Vo verzii 10 bola táto funkcia premenovaná na pg_wal_lsn_diff(). Vo všeobecnosti vo všetkých funkciách, zobrazeniach a pomôckach, kde sa slovo „xlog“ objavilo, bolo nahradené hodnotou „wal“. Platí to pre pohľady aj funkcie. Toto je taká inovácia.
Navyše vo verzii 10 boli pridané riadky, ktoré konkrétne ukazujú oneskorenie. Ide o oneskorenie pri zápise, oneskorenie spustenia, oneskorenie pri opakovanom prehrávaní. To znamená, že je dôležité tieto veci sledovať. Ak zistíme, že došlo k oneskoreniu replikácie, musíme zistiť, prečo sa objavil, odkiaľ prišiel a problém vyriešiť.
So systémovými metrikami je takmer všetko v poriadku. Keď sa začne akékoľvek monitorovanie, začína sa systémovými metrikami. Ide o likvidáciu procesorov, pamäte, swapu, siete a disku. Mnohé parametre však v predvolenom nastavení nie sú.
Ak je všetko v poriadku s procesom recyklácie, potom sú problémy s recykláciou diskov. Vývojári monitorovania spravidla pridávajú informácie o priepustnosti. Môže byť v iopoch alebo bajtoch. Zabúdajú však na latenciu a vyťaženie diskových zariadení. Toto sú dôležitejšie parametre, ktoré nám umožňujú vyhodnotiť, ako sú naše disky zaťažené a ako pomalé sú. Ak máme vysokú latenciu, znamená to, že sú nejaké problémy s diskami. Ak máme vysoké využitie, znamená to, že disky nezvládajú. To sú lepšie vlastnosti ako priepustnosť.
Okrem toho je možné tieto štatistiky získať aj zo súborového systému /proc, ako sa to robí v prípade recyklačných procesorov. Neviem, prečo sa tieto informácie nepridávajú do monitorovania. Ale napriek tomu je dôležité mať to vo svojom monitorovaní.
To isté platí pre sieťové rozhrania. Existujú informácie o priepustnosti siete v paketoch, v bajtoch, ale napriek tomu nie sú žiadne informácie o latencii a žiadne informácie o využití, aj keď sú to tiež užitočné informácie.
Akékoľvek monitorovanie má nevýhody. A bez ohľadu na to, aký druh monitorovania použijete, vždy nebude spĺňať niektoré kritériá. Ale napriek tomu sa vyvíjajú, pribúdajú nové funkcie a nové veci, tak si niečo vyberte a dokončite.
A aby ste mohli skončiť, musíte mať vždy predstavu o tom, čo poskytnuté štatistiky znamenajú a ako ich môžete použiť na riešenie problémov.
A niekoľko kľúčových bodov:
- Vždy by ste mali sledovať dostupnosť a mať k dispozícii dashboardy, aby ste mohli rýchlo posúdiť, či je s databázou všetko v poriadku.
- Vždy musíte mať predstavu o tom, s čím klienti pracujú s vašou databázou, aby ste mohli vyradiť zlých klientov a zostreliť ich.
- Je dôležité vyhodnotiť, ako títo klienti pracujú s dátami. Musíte mať predstavu o svojej pracovnej záťaži.
- Je dôležité vyhodnotiť, ako sa táto záťaž tvorí, pomocou akých dopytov. Dotazy môžete vyhodnocovať, môžete ich optimalizovať, refaktorovať, vytvárať pre ne indexy. Je to veľmi dôležité.
- Procesy na pozadí môžu negatívne ovplyvniť požiadavky klientov, preto je dôležité sledovať, či nevyužívajú príliš veľa zdrojov.
- Systémové metriky vám umožňujú vytvárať plány na škálovanie a zvyšovanie kapacity vašich serverov, preto je dôležité ich tiež sledovať a vyhodnocovať.
Ak vás táto téma zaujíma, môžete sledovať tieto odkazy.
- toto je oficiálna dokumentácia od zberateľa štatistík. Je tu popis všetkých štatistických pohľadov a popis všetkých polí. Môžete si ich prečítať, pochopiť a analyzovať. A na ich základe zostavte svoje grafy a pridajte ich do monitorovania.
Príklady žiadostí:
Toto je naše firemné úložisko a moje vlastné. Obsahujú príklady dopytov. Nie sú tam žiadne dopyty zo série select*. Existujú už hotové dopyty so spojeniami, ktoré využívajú zaujímavé funkcie, ktoré umožňujú premeniť nespracované čísla na čitateľné, pohodlné hodnoty, t. j. ide o bajty, čas. Môžete si ich vyzdvihnúť, pozrieť sa na ne, analyzovať, pridať do monitorovania, zostaviť na nich svoje monitorovanie.
otázky
Otázka: Povedali ste, že nebudete inzerovať značky, ale aj tak by ma zaujímalo – aký druh dashboardov používate vo svojich projektoch?
Odpoveď: Líši sa. Stáva sa, že prídeme k zákazníkovi a ten už má svoj monitoring. A zákazníkovi poradíme, čo je potrebné pridať k jeho monitorovaniu. Najhoršia situácia je so Zabbixom. Pretože nemá schopnosť vytvárať grafy TopN. Sami používame , pretože sme s týmito chlapmi konzultovali monitorovanie. Monitorovali PostgreSQL na základe našich technických špecifikácií. Píšem svoj vlastný pet-projekt, ktorý zbiera dáta cez Prometheus a vykresľuje ich . Mojou úlohou je vytvoriť si vlastného exportéra v Prometheus a potom všetko vykresliť v Grafane.
Otázka: Existujú nejaké analógy správ AWR alebo... agregácie? Viete o niečom takom?
odpoveď: Áno, viem čo je AWR, je to super vec. V súčasnosti existuje množstvo bicyklov, ktoré implementujú približne nasledujúci model. V určitom časovom intervale sa niektoré základné línie zapíšu do rovnakého PostgreSQL alebo do samostatného úložiska. Môžete si ich vygoogliť na internete, sú tam. Jeden z vývojárov takejto veci sedí na fóre sql.ru vo vlákne PostgreSQL. Môžete ho tam chytiť. Áno, sú také veci, dajú sa použiť. Navyše vo svojom Tiež píšem vec, ktorá vám umožňuje robiť to isté.
PS1 Ak používate postgres_exporter, aký informačný panel používate? Je ich viacero. Sú už zastarané. Možno komunita vytvorí aktualizovanú šablónu?
PS2 Odstránený pganalyze, pretože ide o vlastnú ponuku SaaS, ktorá sa zameriava na monitorovanie výkonu a návrhy automatického ladenia.
Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prosím.
Ktoré vlastné hosťované monitorovanie postgresql (s dashboardom) považujete za najlepšie?
-
30,0%Zabbix + doplnky od Alexeyho Lesovského alebo zabbix 4.4 alebo 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 je proprietárne SaaS - nemôžem ho odstrániť1
-
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
Hlasovalo 10 užívateľov. 26 užívateľov sa zdržalo hlasovania.
Zdroj: hab.com