Navrhuji, abyste se seznámili s přepisem zprávy Alexey Lesovského z Data Egret „Základy monitorování PostgreSQL“
V této zprávě bude Alexey Lesovsky hovořit o klíčových bodech postgresové statistiky, co znamenají a proč by měly být zahrnuty do monitorování; o tom, jaké grafy by měly být v monitorování, jak je přidávat a jak interpretovat. Zpráva bude užitečná pro správce databází, systémové administrátory a vývojáře, kteří se zajímají o řešení problémů s Postgres.
Jmenuji se Alexey Lesovsky a zastupuji Data Egret.
Pár slov o sobě. Začínal jsem kdysi dávno jako správce systému.
Spravoval jsem všemožné různé Linuxy, dělal jsem různé věci související s Linuxem, tedy virtualizaci, monitoring, práci s proxy atd. Ale v určitém okamžiku jsem se začal více věnovat databázím, PostgreSQL. Moc se mi líbil. A v určitém okamžiku jsem se většinu svého pracovního času začal zabývat PostgreSQL. A tak jsem se postupně stal PostgreSQL DBA.
A po celou svou kariéru mě vždy zajímala témata statistiky, monitoringu, telemetrie. A když jsem byl správcem systému, velmi tvrdě jsem na Zabbixu pracoval. A napsal malou sadu skriptů jako . Ve své době byl docela populární. A tam bylo možné sledovat velmi různé důležité věci, nejen Linux, ale i různé komponenty.
Teď už dělám PostgreSQL. Již píšu další věc, která umožňuje pracovat se statistikami PostgreSQL. To se nazývá (článek o Habré - ).
Malý úvod. Jaké jsou situace s našimi zákazníky, s našimi klienty? S databází je spojena nějaká nehoda. A když už je databáze obnovena, přijde vedoucí oddělení nebo vedoucí vývoje a říká: „Přátelé, měli bychom databázi sledovat, protože se stalo něco špatného a je potřeba, aby se to v budoucnu nestávalo.“ A zde začíná zajímavý proces výběru monitorovacího systému nebo přizpůsobení stávajícího monitorovacího systému tak, abyste mohli sledovat svou databázi – PostgreSQL, MySQL nebo některé další. A kolegové začnou nabízet: „Slyšel jsem, že existuje taková a taková databáze. Pojďme toho využít." Kolegové se mezi sebou začnou hádat. A nakonec to dopadá tak, že si vybereme nějakou databázi, ale monitoring PostgreSQL je v ní zastoupen dost špatně a musíme pořád něco dodělávat. Vezměte nějaká úložiště z GitHubu, naklonujte je, přizpůsobte skripty, nějak je vylaďte. A nakonec to spadne do nějaké ruční práce.
Proto se vám v tomto reportu pokusím předat nějaké poznatky, jak zvolit monitoring nejen pro PostgreSQL, ale i pro databázi. A poskytnout znalosti, které vám umožní dokončit monitorování, abyste z něj měli nějaký užitek, abyste mohli s výhodou monitorovat svou databázi, abyste včas zabránili jakýmkoli nadcházejícím mimořádným situacím, které mohou nastat.
A ty nápady, které budou v této zprávě, mohou být přímo přizpůsobeny jakékoli databázi, ať už je to DBMS nebo noSQL. Proto zde nejen PostgreSQL, ale bude mnoho receptů, jak to udělat v PostgreSQL. Budou tam příklady dotazů, příklady entit, které má PostgreSQL ke sledování. A pokud má vaše DBMS stejné věci, které vám umožňují dát je do monitorování, můžete je také přizpůsobit, přidat a bude to v pořádku.
nebudu se hlásit
mluvit o tom, jak doručovat a ukládat metriky. Neřeknu nic o následném zpracování dat a jejich poskytování uživateli. A o upozornění nic neřeknu.
Ale v průběhu příběhu ukážu různé screenshoty existujících monitoringů, nějak je budu kritizovat. Přesto se budu snažit značky nejmenovat, abych na tyto produkty nevytvářel reklamu či antireklamu. Proto jsou všechny náhody náhodné a zůstávají na vaší fantazii.
Nejprve si ujasněme, co je sledování. Monitorování je velmi důležitá věc. Každý tomu rozumí. Zároveň ale sledování nesouvisí s obchodním produktem a neovlivňuje přímo zisky společnosti, takže sledování je vždy věnován čas na zbytkové bázi. Pokud máme čas, tak se věnujeme monitoringu, pokud není čas, tak OK, dáme to do backlogu a někdy se k těmto úkolům vrátíme.
Proto z naší praxe, kdy přicházíme za klienty, je monitoring často nedostatečně rozvinutý a nemá žádné zajímavosti, které by nám pomohly lépe pracovat s databází. A proto je vždy nutné sledování dokončit.
Databáze jsou tak složité věci, které musíte také sledovat, protože databáze jsou úložištěm informací. A informace jsou pro firmu velmi důležité, nelze je nijak ztratit. Ale zároveň jsou databáze velmi komplexní software. Skládají se z mnoha komponent. A mnoho z těchto složek je třeba sledovat.
Pokud mluvíme konkrétně o PostgreSQL, pak jej lze reprezentovat jako takové schéma, které se skládá z velkého množství komponent. Tyto komponenty se vzájemně ovlivňují. A zároveň má PostgreSQL tzv. Stats Collector subsystém, který umožňuje sbírat statistiky o provozu těchto subsystémů a poskytuje administrátorovi nebo uživateli rozhraní, aby si tyto statistiky mohl prohlížet.
Tato statistika je prezentována ve formě nějaké sady funkcí a pohledů (view). Mohou být také nazývány tabulkami. To znamená, že pomocí běžného klienta psql se můžete připojit k databázi, vybrat tyto funkce a pohledy a získat konkrétní čísla o fungování subsystémů PostgreSQL.
Tato čísla můžete přidat do svého oblíbeného monitorovacího systému, kreslit grafy, přidávat funkce a získávat analýzy z dlouhodobého hlediska.
V této zprávě se ale nebudu věnovat všem těmto funkcím bez výjimky, protože to může trvat celý den. Budu odkazovat doslova na dvě, tři nebo čtyři věci a řeknu vám, jak pomáhají zlepšit monitorování.
A pokud mluvíme o sledování databáze, co by se mělo sledovat? V první řadě musíme hlídat dostupnost, protože databáze je služba, která klientům poskytuje přístup k datům a my potřebujeme dostupnost hlídat a také poskytovat některé její kvalitativní a kvantitativní charakteristiky.
Musíme také monitorovat klienty, kteří se připojují k naší databázi, protože mohou být jak běžnými klienty, tak škodlivými klienty, kteří mohou databázi poškodit. Také je třeba je sledovat a sledovat.
Když se klienti připojují k databázi, je zřejmé, že začínají pracovat s našimi daty, takže musíme sledovat, jak klienti s daty pracují: s jakými tabulkami, v menší míře s jakými indexy. To znamená, že musíme vyhodnotit pracovní zátěž, kterou vytvářejí naši klienti.
Pracovní náplň ale tvoří samozřejmě také požadavky. Aplikace se připojují k databázi, přistupují k datům pomocí dotazů, proto je důležité vyhodnotit, jaké dotazy v databázi máme, sledovat jejich přiměřenost, zda nejsou křivé, že je potřeba některé volby přepsat a udělat tak, aby fungovaly rychleji a s lepším výkonem.
A protože mluvíme o databázi, databáze jsou vždy procesy na pozadí. Procesy na pozadí udržují výkon databáze na dobré úrovni, takže pro svůj běh vyžadují určité množství zdrojů. A zároveň se mohou překrývat se zdroji požadavků klientů, takže chamtivá práce procesů na pozadí může přímo ovlivnit výkon požadavků klientů. Proto je také třeba je sledovat a sledovat, aby nedocházelo k deformacím z hlediska procesů na pozadí.
A to je vše, pokud jde o sledování databáze, zůstává v systémové metrice. Ale vzhledem k tomu, že z větší části jde celá naše infrastruktura do cloudu, systémové metriky jednotlivého hostitele vždy ustoupí do pozadí. Ale v databázích jsou stále aktuální a samozřejmě je nutné sledovat i systémové metriky.
Se systémovými metrikami je vše víceméně v pořádku, všechny moderní monitorovací systémy již tyto metriky podporují, ale obecně platí, že některé komponenty stále nestačí a některé věci je potřeba doplnit. Také se jich dotknu, bude o nich několik snímků.
Prvním bodem plánu je dostupnost. Co je přístupnost? Dostupnost v mém chápání je schopnost základny obsluhovat připojení, to znamená, že základna je zvednutá, jako služba přijímá připojení od klientů. A tuto přístupnost lze hodnotit některými charakteristikami. Tyto vlastnosti je velmi vhodné zobrazit na přístrojových deskách.
Každý ví, co jsou palubní desky. To je, když jste se podívali na obrazovku, která shrnula potřebné informace. A již můžete okamžitě zjistit, zda je v databázi problém nebo ne.
Dostupnost databáze a další klíčové charakteristiky by proto měly být vždy uvedeny na řídicích panelech, abyste tyto informace měli vždy po ruce. Některé další podrobnosti, které již pomáhají při vyšetřování incidentů, při vyšetřování některých mimořádných situací, je již třeba umístit na sekundární řídicí panely nebo je skrýt v hloubkových odkazech, které vedou k monitorovacím systémům třetích stran.
Příklad jednoho známého monitorovacího systému. Toto je velmi skvělý monitorovací systém. Sbírá spoustu dat, ale z mého pohledu má zvláštní pojetí dashboardů. Je zde odkaz „Vytvořit řídicí panel“. Když ale vytvoříte řídicí panel, vytvoříte seznam se dvěma sloupci, seznam grafů. A když se potřebujete na něco podívat, začnete klikat, rolovat, hledat požadovaný graf myší. A to vyžaduje čas, tj. neexistují žádné řídicí panely jako takové. Existují pouze seznamy grafů.
Co by mělo být přidáno k těmto dashboardům? Můžete začít s takovou charakteristikou, jako je doba odezvy. PostgreSQL má pohled pg_stat_statements. Ve výchozím nastavení je zakázáno, ale je to jeden z důležitých systémových zobrazení, který by měl být vždy povolen a používán. Ukládá informace o všech spuštěných dotazech, které byly v databázi provedeny.
V souladu s tím můžeme vycházet ze skutečnosti, že můžeme vzít celkovou dobu provedení všech požadavků a vydělit ji počtem požadavků pomocí výše uvedených polí. Ale to je taková průměrná teplota v nemocnici. Můžeme stavět na dalších polích – minimální doba provádění dotazu, maximální a medián. A dokonce umíme vytvářet percentily, PostgreSQL k tomu má odpovídající funkce. A můžeme získat nějaká čísla, která charakterizují dobu odezvy naší databáze pro již dokončené požadavky, tj. neprovádíme falešný požadavek „select 1“ a hlídáme dobu odezvy, ale analyzujeme dobu odezvy pro již dokončené požadavky a losujeme buď samostatný obrázek, nebo na jeho základě sestavíme graf.
Důležité je také sledovat počet chyb, které systém aktuálně generuje. A k tomu můžete použít pohled pg_stat_database. Zaměřujeme se na pole xact_rollback. Toto pole zobrazuje nejen počet vrácení zpět, ke kterým v databázi dojde, ale také zohledňuje počet chyb. Relativně řečeno, můžeme toto číslo zobrazit na našem dashboardu a zjistit, kolik chyb v tuto chvíli máme. Pokud je chyb hodně, pak už je to dobrý důvod podívat se do protokolů a zjistit, o jaké chyby se jedná a proč k nim dochází, a poté je investovat a řešit.
Můžete přidat něco jako tachometr. Jedná se o počet transakcí za sekundu a počet požadavků za sekundu. Relativně řečeno, tato čísla můžete použít jako aktuální výkon vaší databáze a sledovat, zda jsou špičky v požadavcích, špičky v transakcích, nebo naopak databáze není vytížená, protože odpadl nějaký backend. Je důležité se vždy dívat na toto číslo a pamatovat si, že pro náš projekt je takový výkon normální a hodnoty výše a níže jsou již poněkud problematické a nepochopitelné, což znamená, že se musíme podívat, proč taková čísla .
Abychom odhadli počet transakcí, můžeme se opět obrátit na pohled pg_stat_database. Můžeme přidat počet potvrzení a počet vrácení zpět, abychom získali počet transakcí za sekundu.
Každý chápe, že několik požadavků se vejde do jedné transakce? Proto se TPS a QPS mírně liší.
Počet požadavků za sekundu lze získat z pg_stat_statements a jednoduše vypočítat součet všech provedených požadavků. Je jasné, že aktuální hodnotu porovnáme s předchozí, odečteme, dostaneme delta, dostaneme částku.
Pokud si přejete, můžete přidat další metriky, které také pomáhají posoudit dostupnost naší databáze a sledovat, zda došlo k výpadkům.
Jednou z těchto metrik je dostupnost. Ale dostupnost v PostgreSQL je trochu složitější. Řeknu vám proč. Když se PostgreSQL spustí, začne hlásit dostupnost. Ale pokud v určitém okamžiku například v noci běžela nějaká úloha, přišel OOM-killer a násilně ukončil podřízený proces PostgreSQL, pak v tomto případě PostgreSQL ukončí připojení všech klientů, resetuje oblast sharded paměti a zahájí obnovu z poslední kontrolní bod. A zatímco tato obnova z kontrolního bodu trvá, databáze nepřijímá připojení, to znamená, že tuto situaci lze hodnotit jako výpadek. To však nevynuluje počítadlo doby provozuschopnosti, protože bere v úvahu čas, kdy byl správce pošty spuštěn od prvního okamžiku. Proto lze takové situace přeskočit.
Měli byste také sledovat počet vysavačů. Každý ví, co je autovakuum v PostgreSQL? Jedná se o zajímavý subsystém v PostgreSQL. Bylo o tom napsáno mnoho článků, vzniklo mnoho zpráv. Spousta diskuzí o vakuu, jak by to mělo fungovat. Mnozí to považují za nutné zlo. Ale je. Toto je nějaký druh garbage collectoru, který čistí zastaralé verze řádků, které nejsou potřeba pro žádnou z transakcí, a uvolňuje místo v tabulkách a indexech pro nové řádky.
Proč by to mělo být sledováno? Protože vakuum někdy hodně bolí. Spotřebovává to velké množství zdrojů a požadavky klientů tím začínají trpět.
A měl by být monitorován prostřednictvím pohledu pg_stat_activity, o kterém budu mluvit v další části. Toto zobrazení zobrazuje aktuální aktivitu v databázi. A prostřednictvím této aktivity můžeme sledovat počet vysavačů, které právě fungují. Můžeme monitorovat vakuum a uvidíme, že pokud jsme překročili limit, pak je příležitost podívat se do nastavení PostgreSQL a nějak optimalizovat provoz vakua.
Další vlastností PostgreSQL je, že PostgreSQL je velmi nemocný dlouhými transakcemi. Zejména z transakcí, které dlouho visí a nic nedělají. Jedná se o tzv. stat idle-in-transaction. Taková transakce drží zámky, brání fungování vakua. A ve výsledku - stoly bobtnají, zvětšují se. A dotazy, které s těmito tabulkami pracují, začnou fungovat pomaleji, protože je potřeba všechny staré verze řádků přesouvat z paměti na disk a zpět. Proto je také třeba sledovat čas, trvání nejdelších transakcí, nejdelší požadavky na vakuum. A pokud vidíme nějaké procesy, které běží velmi dlouho, déle než 10-20-30 minut na zatížení OLTP, pak je třeba se jim věnovat a donutit je ukončit, případně optimalizovat aplikaci tak, aby nejsou voláni a nevisí tak dlouho. Pro analytickou zátěž je normální 10-20-30 minut, jsou i delší.
Dále máme možnost s připojenými klienty. Když jsme již vytvořili dashboard, zveřejnili na něm klíčové metriky přístupnosti, můžeme tam přidat i další informace o připojených klientech.
Informace o připojených klientech jsou důležité, protože z pohledu PostgreSQL existují různé typy klientů. Jsou dobří klienti a jsou špatní klienti.
Jednoduchý příklad. Klientem mám na mysli aplikaci. Aplikace se připojila k databázi a okamžitě tam začne odesílat své požadavky, databáze je zpracuje a provede a vrátí výsledky klientovi. Jsou to dobří a správní klienti.
Jsou situace, kdy je klient připojen, udržuje připojení, ale nic nedělá. Je v klidovém stavu.
Ale jsou špatní klienti. Ten samý klient se například připojil, otevřel transakci, provedl něco v databázi a pak přešel do kódu, například aby se dostal k externímu zdroji nebo tam zpracoval přijatá data. Zároveň ale transakci neuzavřel. A transakce visí v databázi a drží zámek na lince. To je špatný stav. A pokud najednou aplikace někde uvnitř spadne na výjimku (Exception), pak transakce může zůstat otevřená velmi dlouho. A to přímo ovlivňuje výkon PostgreSQL. PostgreSQL poběží pomaleji. Proto je důležité takové klienty včas sledovat a násilně ukončit jejich práci. A je třeba optimalizovat aplikaci tak, aby k takovým situacím nedocházelo.
Další špatní klienti jsou čekající klienti. Ale stanou se špatnými kvůli okolnostem. Například jednoduchá nečinná transakce: může otevřít transakci, zablokovat některé řádky, pak spadne někam do kódu a zanechá visící transakci. Přijde další klient, požádá o stejná data, ale narazí na zámek, protože ta zavěšená transakce již drží zámky na některých nezbytných řádcích. A druhá transakce bude viset v očekávání, až bude první transakce dokončena nebo ji její správce násilně uzavře. Nevyřízené transakce se tak mohou hromadit a překročit limit připojení k databázi. A když je limit plný, aplikace již nemůže s databází pracovat. Pro projekt je to již nouzový stav. Špatné zákazníky je proto třeba sledovat a včas na ně reagovat.
Další příklad sledování. A tady je slušná palubní deska. Jsou zde informace o spojeních shora. DB připojení - 8 kusů. A to je všechno. Nemáme informace o tom, kteří klienti jsou aktivní, kteří klienti jsou jen nečinní, nic nedělají. Neexistují žádné informace o pozastavených transakcích a čekajících připojeních, tj. toto je takový údaj, který ukazuje počet připojení a je to. A pak hádejte sami.
Chcete-li tedy přidat tyto informace do monitorování, musíte se podívat na systémový pohled pg_stat_activity. Pokud trávíte hodně času v PostgreSQL, pak je to velmi dobrý pohled, který by se měl stát vaším přítelem, protože ukazuje aktuální aktivitu v PostgreSQL, tedy co se v něm děje. Pro každý proces existuje samostatný řádek, který zobrazuje informace o tomto procesu: z jakého hostitele bylo navázáno připojení, pod jakým uživatelem, pod jakým jménem, kdy byla transakce zahájena, jaký požadavek se aktuálně provádí, jaký požadavek byl proveden naposledy. A podle toho můžeme vyhodnotit stav klienta pomocí pole stat. Relativně řečeno, můžeme seskupit podle tohoto pole a získat ty statistiky, které jsou nyní v databázi a počet spojení, která jsou s touto statistikou v databázi. A již přijatá čísla můžeme poslat do našeho monitoringu a kreslit na ně grafy.
Důležité je také vyhodnotit dobu trvání transakce. Už jsem řekl, že je důležité vyhodnocovat dobu trvání vakua, ale stejně se hodnotí i transakce. Existují pole xact_start a query_start. Relativně řečeno ukazují čas zahájení transakce a čas zahájení požadavku. Vezmeme funkci now(), která ukazuje aktuální časové razítko, a odečteme časové razítko transakce a požadavku. A dostaneme dobu trvání transakce, dobu trvání požadavku.
Pokud vidíme dlouhé transakce, měli bychom je již dokončit. V případě zatížení OLTP jsou dlouhé transakce již více než 1-2-3 minuty. Pro zátěž OLAP jsou dlouhé transakce normální, ale pokud běží déle než dvě hodiny, pak je to také známka toho, že máme někde výchylku.
Jakmile se klienti připojí k databázi, začnou pracovat s našimi daty. Přistupují k tabulkám, přistupují k indexům, aby získali data z tabulky. A důležité je vyhodnotit, jak zákazníci s těmito daty pracují.
To je nezbytné, abychom mohli vyhodnotit naši pracovní zátěž a zhruba pochopit, které stoly máme „nejžhavější“. To je například nutné v situacích, kdy chceme umístit „horké“ stoly na nějaké rychlé SSD úložiště. Například některé archivní tabulky, které jsme dlouho nepoužívali, lze přenést do jakéhosi „studeného“ archivu, na SATA disky a nechat je tam žít, bude se k nim přistupovat podle potřeby.
Je také užitečné pro detekci anomálií po vydáních a nasazeních. Řekněme, že projekt zavedl nějakou novou funkci. Přidali jsme například novou funkcionalitu pro práci s databází. A pokud sestavíme grafy pro použití tabulek, můžeme tyto anomálie na těchto grafech snadno odhalit. Můžete například aktualizovat série nebo odstranit série. Bude to hodně vidět.
Je také možné odhalit anomálie "plovoucích" statistik. Co to znamená? PostgreSQL má velmi silný a velmi dobrý plánovač dotazů. A jeho vývoji věnují vývojáři spoustu času. Jak pracuje? Aby bylo možné vytvořit dobré plány, PostgreSQL shromažďuje statistiky o distribuci dat v tabulkách s určitým časovým intervalem, s určitou periodicitou. Toto jsou nejčastější hodnoty: počet jedinečných hodnot, informace o NULL v tabulce, mnoho informací.
Na základě těchto statistik plánovač sestaví několik dotazů, vybere ten nejoptimálnější a pomocí tohoto plánu dotazů provede samotný dotaz a vrátí data.
A stává se, že statistika „plave“. Údaje o kvalitě a kvantitě se v tabulce nějak změnily, ale statistiky se nesbíraly. A vytvořené plány nemusí být optimální. A pokud se naše plány z hlediska shromažďovaného monitoringu ukážou jako neoptimální, podle tabulek budeme moci tyto anomálie vidět. Někde se například data kvalitativně změnila a místo indexu se začalo používat sekvenční průchod tabulkou, tzn. pokud dotaz potřebuje vrátit pouze 100 řádků (existuje limit 100), bude pro tento dotaz proveden úplný výčet. A to má vždy velmi špatný vliv na výkon.
A můžeme to vidět na monitoringu. A už se podívejte na tento dotaz, proveďte vysvětlení, shromážděte statistiky, vytvořte nový další index. A už na tento problém reagovat. Proto je důležité.
Další příklad sledování. Myslím, že ho spousta lidí uznává, protože je velmi oblíbený. Kdo používá ve svých projektech ? A kdo používá tento produkt ve spojení s Prometheus? Faktem je, že ve standardním úložišti tohoto monitorování je dashboard pro práci s PostgreSQL - Prometheus. Ale je tu jeden špatný detail.
Existuje několik grafů. A bajty jsou specifikovány jako jednota, tj. existuje 5 grafů. Jsou to Vložit data, Aktualizovat data, Smazat data, Načíst data a Vrátit data. Bajty jsou určeny jako rozměr jednotky. Faktem ale je, že statistiky v PostgreSQL vrací data v n-tici (řádcích). A v souladu s tím jsou tyto grafy velmi dobrým způsobem, jak podcenit vaši zátěž několikrát, mnohokrát, protože n-tice není bajt, n-tice je řetězec, je to hodně bajtů a vždy má proměnnou délku. To znamená, že výpočet zátěže v bajtech pomocí n-tic je nerealistický nebo velmi obtížný úkol. Když tedy používáte dashboard nebo vestavěný monitoring, je vždy důležité pochopit, že funguje správně a vrací vám správně vyhodnocená data.
Jak získat statistiky o těchto tabulkách? K tomu má PostgreSQL rodinu pohledů. A hlavní pohled je . User_tables - to znamená, že tabulky jsou vytvořeny jménem uživatele. Naproti tomu existují systémové pohledy, které využívá samotný PostgreSQL. A je tu souhrnná tabulka Alltables, která zahrnuje systém i uživatele. Můžete začít od kterékoli z nich, která se vám líbí nejvíce.
Výše uvedená pole lze použít k odhadu počtu vložení, aktualizací a odstranění. Příklad řídicího panelu, který jsem použil, používá tato pole k vyhodnocení charakteristik pracovního zatížení. Proto na nich můžeme také stavět. Ale stojí za to pamatovat, že se jedná o n-tice, ne o bajty, takže to nemůžeme vzít a udělat z toho bajty.
Na základě těchto dat můžeme sestavit tzv. TopN-tabulky. Například Top-5, Top-10. A můžete sledovat ty horké stoly, které jsou využívány více než ostatní. Například 5 "horkých" tabulek pro vložení. A podle těchto tabulek TopN hodnotíme naši pracovní zátěž a dokážeme vyhodnotit návaly zátěže po vydáních, aktualizacích a nasazeních.
Je také důležité vyhodnotit velikost tabulky, protože někdy vývojáři zavedou novou funkci a naše tabulky začnou bobtnat ve svých velkých velikostech, protože se rozhodli přidat další množství dat, ale nepředvídali, jak to bude ovlivnit velikost databáze. I takové případy jsou pro nás překvapením.
A teď malá otázka pro vás. Jaká je otázka, když zaznamenáte zatížení databázového serveru? Jaká je vaše další otázka?
Ale skutečná otázka je následující. Jaké požadavky způsobuje zatížení? To znamená, že není zajímavé sledovat procesy, které zátěž způsobuje. Je jasné, že pokud je hostitel s databází, tak tam databáze běží a je jasné, že se tam budou likvidovat pouze databáze. Pokud otevřeme Top, uvidíme tam seznam PostgreSQL procesů, které něco dělají. Z vrcholu nebude jasné, co dělají.
V souladu s tím musíte najít ty dotazy, které způsobují největší zatížení, protože ladění dotazů zpravidla přináší větší zisk než konfigurace PostgreSQL nebo ladění operačního systému nebo dokonce ladění hardwaru. Podle mého odhadu je to asi 80-85-90%. A to se dělá mnohem rychleji. Je rychlejší opravit požadavek než opravit konfiguraci, naplánovat restart, zejména pokud nelze restartovat databázi, nebo přidat hardware. Je jednodušší dotaz někam přepsat nebo přidat index, abyste z tohoto dotazu získali lepší výsledek.
V souladu s tím je nutné sledovat požadavky a jejich přiměřenost. Vezměme si další příklad monitorování. A i zde se zdá být výborný monitoring. Jsou tam informace o replikaci, jsou tam informace o propustnosti, blokování, využití zdrojů. Všechno je v pořádku, ale nejsou žádné informace o žádostech. Není jasné, jaké dotazy běží v naší databázi, jak dlouho běží, kolik těchto dotazů je. Tyto informace potřebujeme mít vždy v monitorování.
A k získání těchto informací můžeme použít modul pg_stat_statements. Na jeho základě můžete stavět různé grafiky. Můžete například získat informace o nejčastějších požadavcích, tedy o těch, které jsou nejčastěji prováděny. Ano, po nasazení je také velmi užitečné se na to podívat a pochopit, zda došlo k nějakému nárůstu požadavků.
Můžete sledovat nejdelší dotazy, tedy ty, které běží nejdéle. Běží na procesoru, spotřebovávají I/O. Můžeme to také vyhodnotit pomocí polí total_time, mean_time, blk_write_time a blk_read_time.
Dokážeme vyhodnocovat a sledovat ty nejtěžší požadavky z hlediska využití zdrojů, ty, které čtou z disku, ty, které pracují s pamětí, nebo naopak vytvářejí nějakou tu zátěž pro zápis.
Dokážeme vyhodnotit ty nejštědřejší požadavky. Jedná se o dotazy, které vracejí velký počet řádků. Může to být například nějaký druh požadavku, kde zapomněli nastavit limit. A pouze vrátí celý obsah tabulky nebo dotazu na požadované tabulky.
A můžete také sledovat dotazy, které používají dočasné soubory nebo dočasné tabulky.
A stále máme procesy na pozadí. Procesy na pozadí jsou primárně kontrolní body nebo se jim také říká kontrolní body, jedná se o autovakuum a replikaci.
Další příklad sledování. Vlevo je karta Údržba, přejděte na ni a doufejte, že uvidíte něco užitečného. Ale tady jen doba vakua a sběr statistik, nic jiného. To je velmi špatná informace, takže vždy potřebujete mít informace o tom, jak fungují procesy na pozadí v naší databázi a zda z jejich práce nejsou nějaké problémy.
Když se podíváme na kontrolní body, je třeba mít na paměti, že naše kontrolní body vyprázdní „špinavé“ stránky z oblasti rozbité paměti na disk a poté vytvoří kontrolní bod. A tento kontrolní bod lze již použít jako místo při obnově, pokud by byl PostgreSQL náhle v nouzi ukončen.
V souladu s tím, abyste vyprázdnili všechny "špinavé" stránky na disk, musíte provést určité množství zápisu. A na systémech s velkým množstvím paměti je to zpravidla hodně. A pokud budeme dělat kontrolní body velmi často v nějakém krátkém intervalu, pak výkon disku velmi poklesne. A požadavky klientů budou trpět nedostatkem zdrojů. Budou soutěžit o zdroje a postrádají produktivitu.
V souladu s tím můžeme prostřednictvím pg_stat_bgwriter na zadaných polích sledovat počet kontrolních bodů, které se vyskytují. A pokud máme hodně checkpointů na určitou dobu (na 10-15-20 minut, na půl hodiny), třeba 3-4-5, tak to už může být problém. A už je potřeba se podívat do databáze, podívat se do konfigurace, co způsobuje takovou hojnost kontrolních bodů. Možná přijde nějaká velká deska. Už můžeme vyhodnotit vytížení, protože jsme již přidali grafy vytížení. Parametry bodu přerušení již můžeme vyladit a zajistit, aby výrazně neovlivnily výkon dotazu.
Znovu se vracím k automatickému vakuování, protože je to ten druh věci, jak jsem řekl, který může snadno sčítat výkon disku i dotazu, takže je vždy důležité měřit množství autovakua.
Počet pracovníků autovakuování v databázi je omezený. Standardně jsou tři, takže pokud nám v databázi neustále pracují tři pracovníci, tak to znamená, že naše autovakuum je nedokonfigurované, musíme zvednout limity, upravit nastavení autovakua a už vlézt do konfigurace.
Důležité je vyhodnotit, kteří vysavači u nás pracují. Buď to bylo spuštěno od uživatele, přišel DBA a spustil nějaký druh vakua rukama, a to vytvořilo zátěž. Máme nějaký problém. Nebo je to počet vakuů, které odšroubují počítadlo transakcí. Pro některé verze PostgreSQL se jedná o velmi těžké vysavače. A mohou snadno přidat výkon, protože odečítají celou tabulku a skenují všechny bloky v této tabulce.
A samozřejmě délka vakuování. Pokud máme dlouhé vysavače, které běží velmi dlouho, pak to znamená, že bychom měli opět věnovat pozornost konfiguraci vakua a možná přehodnotit jeho nastavení. Protože může nastat situace, kdy vakuum pracuje na stole delší dobu (3-4 hodiny), ale během práce vakua se opět podařilo nahromadit velké množství mrtvých řádků v stole. A jakmile vysávání skončí, potřebuje tento stůl vysát znovu. A dostáváme se do situace – nekonečného vakua. A v tomto případě vakuum nezvládá svou práci a tabulky se začnou postupně zvětšovat, i když množství užitečných dat v něm zůstává stejné. Proto se v dlouhém vakuu vždy podíváme na konfiguraci a snažíme se ji optimalizovat, ale zároveň tak, aby neutrpěl výkon požadavků klientů.
Nyní prakticky neexistuje instalace PostgreSQL, kde by nebyla streamovaná replikace. Replikace je proces přenosu dat z hlavního serveru do repliky.
Replikace v PostgreSQL je uspořádána prostřednictvím transakčního protokolu. Master generuje transakční protokol. Protokol transakcí na síťovém připojení přejde do repliky a poté je reprodukován v replice. Všechno je jednoduché.
V souladu s tím se ke sledování zpoždění replikace používá pohled pg_stat_replication. Ale není to pro ni jednoduché. Ve verzi 10 prošel pohled několika změnami. Za prvé, některá pole byla přejmenována. A přibyla i některá pole. V 10. verzi se objevila pole, která umožňují vyhodnotit zpoždění replikace v sekundách. Je to velmi pohodlné. Před verzí 10 bylo možné odhadnout zpoždění replikace v bajtech. Tato funkce zůstala v 10. verzi, tedy můžete si vybrat, co je pro vás pohodlnější - vyhodnotit zpoždění v bytech nebo vyhodnotit zpoždění v sekundách. Mnozí dělají obojí.
Chcete-li však vyhodnotit zpoždění replikace, musíte znát pozici protokolu v transakci. A tyto pozice transakčního protokolu jsou pouze v pohledu pg_stat_replication. Relativně řečeno, můžeme použít funkci pg_xlog_location_diff() k získání dvou bodů v transakčním protokolu. Vypočítejte rozdíl mezi nimi a získejte zpoždění replikace v bajtech. Je to velmi pohodlné a jednoduché.
Ve verzi 10 byla tato funkce přejmenována na pg_wal_lsn_diff(). Obecně platí, že ve všech funkcích, pohledech, utilitách, kde se slovo „xlog“ objevilo, bylo nahrazeno hodnotou „wal“. A to jak v pohledech, tak ve funkcích. To je taková inovace.
Navíc v 10. verzi byly přidány řádky, které konkrétně ukazují zpoždění. Jedná se o zpoždění zápisu, zpoždění spláchnutí, zpoždění přehrávání. To znamená, že je důležité tyto věci sledovat. Pokud vidíme, že máme zpoždění replikace, musíme prozkoumat, proč se objevilo, odkud se vzalo, a problém vyřešit.
Se systémovými metrikami je téměř vše v pořádku. Když se zrodí jakékoli monitorování, začíná se systémovými metrikami. Jedná se o využití procesorů, paměti, swapu, sítě a disku. Mnoho parametrů zde ale ve výchozím nastavení není.
Pokud je vše v pořádku s likvidací procesu, pak jsou problémy s likvidací disku. Vývojáři monitorování zpravidla přidávají informace o šířce pásma. Může být v iops nebo bajtech. Zapomínají ale na latenci a využití diskových zařízení. To jsou důležitější parametry, které nám umožňují vyhodnotit, jak jsou naše disky zatížené a jak moc se zpomalují. Pokud máme vysokou latenci, znamená to, že jsou nějaké problémy s disky. Pokud máme vysoké vytížení, tak to znamená, že to disky nezvládnou. To jsou spíše kvalitativní charakteristiky než šířka pásma.
Tyto statistiky však lze také získat ze systému souborů /proc, jak se to dělá při recyklaci procesoru. Proč tato informace není přidána do monitoringu, nevím. Ale i tak je důležité mít to ve svém monitoringu.
Totéž platí pro síťová rozhraní. Existují informace o šířce pásma sítě v paketech, v bajtech, ale přesto zde nejsou žádné informace o latenci a žádné informace o využití, i když je to také užitečná informace.
Jakékoli sledování má své nevýhody. A bez ohledu na to, jaký druh monitorování provedete, vždy nebude splňovat určitá kritéria. Ale přesto se vyvíjejí, přibývají nové funkce, nové věci, tak si něco vyberte a dodělejte to.
A abyste mohli skončit, musíte mít vždy představu, co daná statistika znamená a jak s ní můžete řešit problémy.
A několik klíčových bodů:
- Vždy je potřeba hlídat dostupnost, mít dashboardy, abyste mohli rychle posoudit, že je se základnou vše v pořádku.
- Vždy musíte mít představu o tom, jací klienti pracují s vaší databází, abyste mohli vyřadit špatné klienty a zastřelit je.
- Je důležité vyhodnotit, jak tito klienti s daty pracují. Musíte mít představu o své pracovní zátěži.
- Je důležité vyhodnotit, jak se tato zátěž tvoří, pomocí jakých dotazů. Dotazy můžete vyhodnocovat, můžete je optimalizovat, refaktorovat, sestavovat pro ně indexy. Je to velmi důležité.
- Procesy na pozadí mohou negativně ovlivnit požadavky klientů, takže je důležité zajistit, aby nevyužívaly příliš mnoho zdrojů.
- Systémové metriky vám umožňují vytvářet plány pro škálování, pro zvýšení kapacity vašich serverů, takže je důležité je také sledovat a vyhodnocovat.
Pokud vás toto téma zajímá, můžete sledovat tyto odkazy.
je oficiální dokumentace od sběratele statistik. Je zde popis všech statistických pohledů a popis všech polí. Můžete je číst, pochopit a analyzovat. A na jejich základě si sestavte vlastní grafy, přidejte do svého sledování.
Příklady žádostí:
Toto je naše firemní úložiště a moje vlastní. Mají vzorové žádosti. Nejsou tam žádné dotazy z select* ze série, něco tam. Existují již hotové požadavky se spojeními, které využívají zajímavé funkce, které vám umožňují vytvářet čitelné a pohodlné hodnoty z nezpracovaných čísel, to znamená, že se jedná o bajty, čas. Můžete si je vybrat, sledovat, analyzovat, přidávat je do svých sledování, vytvářet si na nich vlastní sledování.
otázky
Otázka: Řekl jste, že nebudete inzerovat značky, ale přesto mě zajímá – jaké dashboardy používáte ve svých projektech?
Odpověď: Různými způsoby. Stává se, že přijedeme k zákazníkovi a ten už má svůj monitoring. A zákazníkovi poradíme, co je potřeba k jeho monitoringu přidat. Nejhorší situace je se Zabbixem. Protože nemá schopnost vytvářet grafiku TopN. Sami používáme protože jsme s těmito lidmi konzultovali monitorování. Prováděli monitorování PostgreSQL na základě našeho TOR. Píšu svůj vlastní pet-projekt, který sbírá data přes Prometheus a vtahuje je dovnitř . Mým úkolem je udělat si vlastního exportéra v Prometheu a pak vše nakreslit v Grafaně.
Otázka: Existují nějaké analogy zpráv AWR nebo ... agregace? Víte o něčem takovém?
Odpověď: Ano, vím co je AWR, je to super věc. V současné době existuje celá řada jízdních kol, která implementují přibližně následující model. V určitém časovém intervalu jsou některé základní linie zapsány do stejného PostgreSQL nebo do samostatného úložiště. Můžete si je vygooglit na internetu, jsou. Jeden z vývojářů takové věci sedí na fóru sql.ru ve vláknu PostgreSQL. Můžete ho tam chytit. Ano, takové věci jsou, dají se použít. plus ve svém Také píšu věc, která vám umožňuje udělat totéž.
PS1 Pokud používáte postgres_exporter, jaký dashboard používáte? Je jich několik. Jsou již zastaralé. Může komunita vytvořit aktualizovanou šablonu?
PS2 Odstraněno pganalyze, protože je to proprietární nabídka SaaS, která se zaměřuje na sledování výkonu a návrhy automatického ladění.
Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. , prosím.
Které monitorování postgresql s vlastním hostitelem (s řídicím panelem) je podle vás nejlepší?
-
30,0%Zabbix + doplňky od Alexey Lesovského nebo zabbix 4.4 nebo 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ární SaaS – nelze odstranit1
-
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živatelů. 26 uživatelů se zdrželo hlasování.
Zdroj: www.habr.com