Základní monitorování PostgreSQL – část 1

Jaké metriky vašeho nasazení PostgreSQL byste měli sledovat? Cílem této série blogových příspěvků je poskytnout minimální počáteční sadu základních monitorovacích akcí, které byste měli implementovat, abyste zajistili zdraví a stabilitu vašich serverů Postgres.

První část pokrývá parametry na úrovni clusteru.

Část 1:Úroveň clusteru

V žargonu Postgres shluk je sada databází spravovaných jednou instancí serveru Postgres. Funkce jako replikace a archivace WAL na úrovni clusteru.

1. Rozsah ID transakce

Z pohledu normálního klienta se bude zdát, že datové soubory clusteru PostgreSQL obsahují snímek dat upravený poslední potvrzenou transakcí. Kvůli architektuře MVCC společnosti Postgres však fyzické soubory neobsahují pouze data pro nejnovější transakci, ale pro řadu transakcí končících tou nejnovější. (Pravidelné vysávání zbaví se dat pro starší transakce.)

Každá transakce má jedinečný 32bitový celočíselný identifikátor, který se nazýváID transakce . Z různých důvodů by měl být rozdíl mezi ID první a poslední transakce menší než 2, což je přibližně 2 miliardy. Udržování rozsahu hluboko pod tímto limitem je nutností – přečtěte si tento skutečný příběh o tom, co se stane jinak.

Akce:Průběžně sledujte rozsah ID transakce, upozorněte, pokud hodnota překročí nastavenou hranici.

Jak na to:

-- returns the first and last transactions IDs for the cluster
SELECT oldest_xid::text::int as first,
       regexp_replace(next_xid, '^[0-9]+:', '')::int-1 as last
  FROM pg_control_checkpoint();

-- returns the transaction ID range for each database
SELECT datname, age(datfrozenxid)
  FROM pg_database;

2. Počet backendů

Každý backend představuje buď klienta připojeného k serveru, nebo proces backendu systému (jako je automatický vysavač, zapisovač na pozadí atd.). Každý backend je také proces operačního systému, který spotřebovává zdroje operačního systému, jako je paměť, otevřené deskriptory souborů atd. Příliš mnoho backendů, obvykle kvůli příliš mnoha klientům nebo příliš mnoha dlouhotrvajícím dotazům, může vyvíjet tlak na zdroje OS a zpomalit dobu odezvy na dotazy u každého klienta.

Akce:Sledujte maximální počet backendů za každý den/týden, prozkoumejte rostoucí trendy.

Jak na to:

-- returns the count of currently running backends
SELECT count(*)
  FROM pg_stat_activity;

3. Neaktivní replikační sloty

Replikační sloty jsou označeny jako „neaktivní“, když se replikační klient připojený ke slotu odpojí. Neaktivní replikační sloty způsobí uchování souborů WAL, protože budou muset být odeslány klientovi, když se znovu připojí a sloty budou aktivní. První věcí, kterou byste měli zkontrolovat, zda počet souborů WAL neklesá, je zjistit, zda nemáte neaktivní replikační sloty.

Neaktivní replikační sloty jsou často výsledkem odstraněného záložního klienta, odebrání podřízeného zařízení, povýšení, převzetí služeb při selhání a podobně.

Akce:Průběžně kontrolujte neaktivní replikační sloty, případně upozorněte.

Jak na to:

-- returns the count of inactive replication slots
SELECT count(*)
  FROM pg_replication_slots
 WHERE NOT active;

4. Backendy čekající na zámky

Příkazy SQL mohou explicitně nebo implicitně způsobit, že ostatní příkazy SQL čekají. Například spuštění příkazu „SELECT .. FOR UPDATE“ explicitně deklaruje zámek pro vybrané řádky a spuštění příkazu „UPDATE“ umístí implicitní zámky s výhradním řádkem. narazí na zámek, bude muset počkat, dokud první příkaz neuvolní zámek, než bude pokračovat v jeho provádění.

To se může projevit jako pomalý výkon aplikace během týdenních spouštění zpráv, vypršení časového limitu transakcí/webových stránek a podobně.

I když se určitému množství zamykání nelze vyhnout, rostoucí trend backendů čekajících na uzamčení obvykle vyžaduje restrukturalizaci dotazů nebo aplikační logiky.

Akce:Sledujte maximální počet backendů čekajících na uzamčení během každého dne/týdne, prozkoumejte rostoucí trendy.

Jak na to:

-- returns the count of backends waiting on locks
SELECT count(*)
  FROM pg_stat_activity
 WHERE wait_event = 'Lock';

5. Backendy nečinné v transakci

Dlouhotrvající transakce nejsou ve světě PostgreSQL zrovna příjemné. Mohou způsobit nahromadění souborů WAL, zabránit automatickému a ručnímu vakuování a spotřebovat zdroje. Se skutečnými transakcemi, jejichž dokončení trvá dlouho, se nic moc dělat nedá, ale existují případy, jako jsou špatně se chovající aplikace/skripty a příležitostný klient psql, které transakce zahájí, ale neuzavřou. Backendy, které obsluhují takové klienty, se jeví jako „nečinné v transakci“.

Backendy, které jsou v transakci nečinné, by měly být detekovány a vypnuty dříve, než začnou ovlivňovat stabilitu systému.

Akce:Průběžně sledujte počet backendů nečinných v transakci a zkontrolujte, zda jsou nějaké nalezeny.

Jak na to:

-- returns the count of backends waiting on locks
SELECT count(*)
  FROM pg_stat_activity
 WHERE state = 'idle in transaction';

6. Prodleva replikace pro aktivní připojení

Pokud existují aktivní klienti streamování replikace (jako jsou aktivní pohotovostní režimy) nebo aktivní klienti logické replikace, Postgres spustí systémový backend nazvanýWAL sender pro každého aktivního (připojeného) klienta. Odesílatel WAL je odpovědný za odeslání dat záznamu WAL, která klient potřebuje.

Replikační klienti se obvykle snaží co nejvíce držet krok s primárním. Občas však může být rychlost generování WAL na primární straně vyšší než rychlost, jakou je klient schopen je spotřebovat. To má za následek zpoždění replikace pro každé připojení replikace.

PostgreSQL poskytuje mechanismus dotazování na zpoždění zápisu (počet bajtů odeslaných, ale nezapsaných na disk klienta), zpoždění zarovnání (počet zapsaných, ale nevyprázdněných bajtů na disk klienta) a zpoždění přehrávání (počet bajtů vyprázdněných, ale nepřehraných na klientský disk databázové soubory) pro každého aktivního odesílatele WAL.

Akce:Průběžně sledujte zpoždění replikace u aktivních připojení a upozorněte, pokud hodnoty překročí nastavené prahové hodnoty.

Jak na to:

-- returns the write, flush and replay lags per WAL sender, as described above
SELECT write_lsn - sent_lsn AS write_lag,
       flush_lsn - write_lsn AS flush_lag,
       replay_lsn - flush_lsn AS replay_lag
  FROM pg_stat_replication;

7. Prodleva replikace pro sloty replikace

Nejen, že se replikační klienti mohou zpožďovat, ale mohou také zcela zmizet kvůli haváriím, změnám topologie nebo lidské chybě. Může to být také záměrné, kdy klienti nejsou vždy online.

Pokud je klient zálohován replikačním slotem, pak všechny soubory WAL potřebné k tomu, aby klient mohl pokračovat od bodu, kde skončil, jsou uchovány PostgreSQL. Soubory WAL budou uchovávány po neomezenou dobu – neexistuje způsob, jak nastavit limit. Když se klient znovu připojí, všechna uchovaná data musí být streamována nejprve klientovi, což může zahrnovat velký diskový a síťový provoz na primárním serveru. Z těchto důvodů byste měli sledovat zpoždění také na úrovni slotu.

(Poznámka:Proces odesílatele WAL se spouští pouze tehdy, když je klient připojen, a ukončí se, když se klient odpojí. Metoda odesílatele WAL, která měří, jak daleko je klient, nefunguje, když je klient odpojen.)

Akce:Nepřetržitě sledujte zpoždění replikace pro logické sloty replikace a varujte, pokud hodnoty překročí nastavenou prahovou hodnotu.

Jak na to:

-- returns the replication slot lag in bytes
-- (works only for logical replication slots)
SELECT pg_current_wal_lsn() - confirmed_flush_lsn
  FROM pg_replication_slots;

8. Počet souborů WAL

Správa souborů WAL může být obtěžující, zvláště pokud máte klienty pro archivaci WAL nebo streamingové replikační klienty. Počet souborů WAL se může začít zvyšovat bez zjevného důvodu, proces archivace WAL nemusí držet krok s rychlostí generování WAL a celková velikost souboru WAL může dosáhnout terabajtů.

Minimálně musíte sledovat počet souborů WAL přítomných v adresáři databáze a zajistit, aby počet vypadal přiměřeně vašemu nasazení.

Akce:Průběžně sledujte počet souborů WAL, upozorněte, pokud hodnota překročí nastavenou hranici.

Jak na to:

-- returns the number of WAL files present in the pg_wal directory (v10+)
SELECT count(*)
  FROM pg_ls_waldir();

-- same, for v9.x
SELECT count(*)
  FROM pg_ls_dir('pg_xlog')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}$';

-- can also count the files physically present in $DBDIR/pg_wal
-- /bin/ls -l $DBDIR/pg_wal | grep -c '^-'

9. Počet souborů WAL připravených k archivaci

Když je povolena archivace WAL, PostgreSQL vyvolá uživatelský skript pokaždé, když je vygenerován nový soubor WAL. Předpokládá se, že skript „archivuje“ jeden soubor WAL, pro který byl vyvolán (obvykle ho zkopíruje na jiný server nebo do bucketu S3). být archivován hromadí.

Akce:Průběžně sledujte počet souborů připravených k archivaci WAL, upozorněte, pokud hodnota překročí nastavenou hranici.

Jak na to:

-- returns the number of WAL files ready to be archived (v12+)
SELECT count(*)
  FROM pg_ls_archive_statusdir()
 WHERE name ~ '^[0-9A-F]{24}.ready$';

-- same, for v10+
SELECT count(*)
  FROM pg_ls_dir('pg_wal/archive_status')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';

-- same, for v9.x
SELECT count(*)
  FROM pg_ls_dir('pg_xlog/archive_status')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';

-- can also count the *.ready files physically present in $DBDIR/pg_wal/archive_status
-- /bin/ls -l $DBDIR/pg_wal/archive_status | grep -c .ready

Shromažďování těchto metrik

Výše uvedené části poskytují příkazy SQL pro extrahování potřebných metrik ze spuštěného serveru Postgres. Pokud nechcete psát skripty sami, podívejte se na open source nástroj pgmetrics. Může shromažďovat výše uvedené metriky a další a hlásit je v textových formátech a formátech JSON.

Zprávy pgmetrics můžete přímo zasílat naší komerční nabídce pgDash, která tyto zprávy ukládá a zpracovává za účelem zobrazení grafů a provádění výstrah.

Další

Další části této série budou pokrývat metriky na úrovni databáze, tabulky, indexu a systému. Zůstaňte naladěni!