Jako moderní RDBMS přichází PostgreSQL s mnoha parametry pro jemné doladění. Jednou z oblastí, kterou je třeba zvážit, je, jak by měl PostgreSQL protokolovat své aktivity. Protokolování je při správě databáze Postgres často přehlíženo, a pokud není ignorováno, obvykle špatně nastaveno. K tomu dochází, protože většinu času je účel protokolování nejasný. Základní důvod protokolování je samozřejmě dobře znám, ale někdy chybí pochopení toho, jak budou protokoly používány.
Požadavky na protokolování každé organizace jsou jedinečné, a proto se také bude lišit způsob konfigurace protokolování PostgreSQL. To, co potřebuje společnost poskytující finanční služby zachytit do svých databázových protokolů, se bude lišit od toho, co musí zaznamenat společnost zabývající se kritickými zdravotními informacemi. A v některých případech mohou být podobné.
V tomto článku se budu zabývat některými základními postupy, jak získat to nejlepší z protokolů PostgreSQL. Tento blog není tvrdá a rychlá kniha pravidel; čtenáři jsou více než vítáni, aby se podělili o své myšlenky v sekci komentářů. Abychom z toho získali co nejlepší hodnotu, žádám čtenáře, aby se zamyslel nad tím, jak chtějí používat své protokoly databázového serveru PostgreSQL:
- Důvod dodržování právních předpisů, kdy je třeba zachytit konkrétní informace
- Audit zabezpečení, kde musí být uvedeny podrobnosti o konkrétní události
- Odstraňování problémů s výkonem, kde se mají zaznamenávat dotazy a jejich parametry
- Každodenní provozní podpora, kde je třeba sledovat stanovený počet metrik
S tím, co bylo řečeno, začněme.
Neprovádějte ruční změny v postgresql.conf
Jakékoli změny v souboru postgresql.conf by měly být provedeny pomocí systému správy konfigurace, jako je Puppet, Ansible nebo Chef. To zajišťuje sledovatelnost změn a v případě potřeby je lze bezpečně vrátit na předchozí verzi. To platí, když provádíte změny parametrů protokolování.
DBA často vytváří více kopií souboru postgresql.conf, každou s mírně odlišnými parametry, každou pro jiný účel. Ruční správa různých konfiguračních souborů je těžkopádný úkol, pokud není náchylný k chybám. Na druhou stranu může být systém správy konfigurace vytvořen tak, aby přejmenoval a používal různé verze souboru postgresql.conf na základě parametru, který je mu předán. Tento parametr bude určovat účel aktuální verze. Po dokončení potřeby lze starý konfigurační soubor vrátit zpět změnou stejného vstupního parametru.
Pokud například chcete protokolovat všechny příkazy spuštěné na vaší instanci PostgreSQL, lze použít konfigurační soubor s hodnotou parametru „log_statement=all“. Když není potřeba zaznamenávat všechny příkazy – třeba po cvičení řešení problémů – lze obnovit předchozí konfigurační soubor.
Použít samostatné soubory protokolu pro PostgreSQL
Doporučuji povolit nativní kolektor protokolování PostgreSQL během normálních operací. Chcete-li povolit nativní protokolování PostgreSQL, nastavte následující parametr na on:
logging_collector = onJsou pro to dva důvody:
Za prvé, v zaneprázdněných systémech nemusí operační systém konzistentně zaznamenávat zprávy PostgreSQL v syslog (za předpokladu instalace založené na nixu) a často zprávy zahazovat. S nativním protokolováním PostgreSQL se o zaznamenávání událostí stará samostatný démon. Když je PostgreSQL zaneprázdněn, tento proces odloží zápis do souborů protokolu, aby vlákna dotazů mohla dokončit. To může zablokovat celý systém, dokud nebude zapsána událost protokolu. Je proto užitečné zaznamenávat do protokolu méně podrobné zprávy (jak uvidíme později) a používat zkrácené předpony řádků protokolu.
Za druhé – a jak uvidíme později – protokoly by měly být shromažďovány, analyzovány, indexovány a analyzovány pomocí nástroje Správa protokolů. Pokud PostgreSQL zaznamenává své události do syslogu, bude to znamenat vytvoření další vrstvy filtrování a porovnávání vzorů v části Správa protokolů pro odfiltrování všech „šumových zpráv“. Vyhrazené soubory protokolu lze snadno analyzovat a indexovat pro události pomocí většiny nástrojů.
Nastavit cíl protokolu na stderr
Podívejme se na parametr „log_destination“. Může mít čtyři hodnoty:
log_destination = stderr | syslog | csv | eventlog
Pokud neexistuje dobrý důvod pro ukládání událostí protokolu ve formátu odděleném čárkami nebo protokolu událostí ve Windows, doporučuji tento parametr nastavit na stderr. Je to proto, že s cílem souboru CSV nebude mít vlastní hodnota parametru „log_line_prefix“ žádný účinek, a přesto lze předponu vytvořit tak, aby obsahovala cenné informace.
Na druhou stranu lze protokol CSV snadno importovat do databázové tabulky a později se na něj dotazovat pomocí standardního SQL. Někteří uživatelé PostgreSQL to považují za pohodlnější než zpracování raw log souborů. Jak uvidíme později, moderní řešení správy protokolů mohou nativně analyzovat protokoly PostgreSQL a automaticky z nich vytvářet smysluplné poznatky. U CSV musí být hlášení a vizualizace ručně prováděna uživatelem.
Nakonec záleží na vaší volbě. Pokud vám vyhovuje vytvářet si vlastní kanál zpracování dat pro načítání protokolů CSV do databázových tabulek, čištění a transformaci dat a vytváření vlastních sestav, které vyhovují vašim obchodním potřebám, pak se ujistěte, že „log_destination“ je nastaven na CSV.
Používejte smysluplné názvy souborů protokolu
Když jsou soubory protokolu PostgreSQL uloženy lokálně, nemusí se použití stylu pojmenování zdát nutné. Výchozí styl názvu souboru je „postgresql-%Y-%m-%d_%H%M%S.log“ pro protokoly neformátované ve formátu CSV, což je pro většinu případů dostačující.
Pojmenování se stává důležitým, když ukládáte soubory protokolu z více serverů do centrálního umístění, jako je vyhrazený server protokolu, připojený svazek NFS nebo sektor S3. V takovém případě doporučuji použít dva parametry:
log_directory log_filename
Chcete-li uložit soubory protokolu z více instancí na jedno místo, nejprve vytvořte samostatnou hierarchii adresářů pro každou instanci. Může to být něco jako následující:
/<Application_Name>/<Environment_Name>/<Instance_Name>
Každá instance PostgreSQL „log_directory“ pak může být nasměrována na její určenou složku.
Každá instance pak může používat stejnou hodnotu parametru „log_filename“. Výchozí hodnota vytvoří soubor jako
postgresql_2020-08-25_2359.log
Chcete-li použít smysluplnější název, nastavte „log_filename“ na něco takového:
log_filename = "postgresql_%A-%d-%B_%H%M"
Soubory protokolu pak budou pojmenovány takto:
postgresql_Saturday-23-August_2230
Použijte smysluplnou předponu řádku protokolu
Předpony řádku protokolu PostgreSQL mohou kromě samotné zprávy obsahovat nejcennější informace. Dokumentace Postgres ukazuje několik escape znaků pro konfiguraci předpony události protokolu. Tyto sekvence escape jsou za běhu nahrazeny různými hodnotami stavu. Některé aplikace jako pgBadger očekávají konkrétní předponu řádku protokolu.
Doporučuji do předpony zahrnout následující informace:
- Čas události (bez milisekund):%t
- Jméno nebo IP adresa vzdáleného klienta:%h
- Uživatelské jméno:%u
- Přístup k databázi:%d
- Název aplikace:%a
- ID procesu:%p
- Ukončování výstupu procesu bez relace:%q
- Číslo řádku protokolu pro každou relaci nebo proces, počínaje 1:%l
Abychom pochopili, o čem každé pole v prefixu je, můžeme před pole přidat malý doslovný řetězec. Hodnotu ID procesu tedy může předcházet doslovné „PID=“, název databáze může mít předponu „db=“ atd. Zde je příklad:
log_line_prefix = 'time=%t, pid=%p %q db=%d, usr=%u, client=%h , app=%a, line=%l '
V závislosti na tom, odkud událost přichází, bude předpona řádku protokolu ukazovat různé hodnoty. Procesy na pozadí i uživatelské procesy zaznamenají své zprávy do souboru protokolu. Pro systémové procesy jsem zadal %q, které potlačí jakýkoli text za ID procesu (%p). Jakákoli další relace zobrazí název databáze, uživatelské jméno, adresu klienta, název aplikace a očíslovaný řádek pro každou událost.
Za předponu řádku protokolu jsem také vložil jednu mezeru. Tento prostor odděluje předponu události protokolu od skutečné zprávy události. Nemusí to být mezera – lze použít cokoli jako dvojtečku (::), pomlčku (-) nebo jiný smysluplný oddělovač.
Také nastavte parametr „log_hostname“ na 1:
log_hostname = 1
Bez toho se zobrazí pouze IP adresa klienta. V produkčních systémech to bude obvykle adresa serveru proxy, nástroje pro vyrovnávání zatížení nebo sdružování připojení. Pokud neznáte IP adresy těchto systémů nazpaměť, může být užitečné zaznamenat jejich názvy hostitelů. Vyhledání DNS však také přidá čas navíc pro logovací démona k zápisu do souboru.
Dalším parametrem, který by měl být nastaven spolu s „log_line_prefix“ je „log_timezone“. Nastavení na místní časové pásmo serveru zajistí, že zaznamenané události budou snadno sledovatelné z jejich časového razítka, místo toho, abyste je nejprve převedli na místní čas. Ve fragmentu kódu níže nastavujeme log_timzeone na australské východní standardní časové pásmo:
log_timezone = 'Australia/Sydney'
Pouze protokolovat připojení
Dva parametry řídí, jak PostgreSQL zaznamenává připojení a odpojení klientů. Oba parametry jsou standardně vypnuty. Na základě bezpečnostních požadavků vaší organizace můžete chtít nastavit jeden z nich na 1 a druhý na 0 (pokud nepoužíváte nástroj jako pgBadger – o tom později).
log_connections = 1 log_disconnections = 0
Nastavení log_connections na 1 zaznamená všechna autorizovaná připojení i pokusy spojení. To je samozřejmě dobré pro bezpečnostní audit:útok hrubou silou lze snadno identifikovat z protokolů. Pokud je však toto nastavení povoleno, může rušné prostředí PostgreSQL s tisíci nebo dokonce stovkami krátkodobých platných připojení zaznamenat zaplavení souboru protokolu.
Může však také identifikovat problémy aplikace, které by jinak nemusely být zřejmé. Velký počet pokusů o připojení z mnoha různých platných klientských adres může znamenat, že instance potřebuje nástroj pro vyrovnávání zatížení nebo službu sdružování připojení. Velký počet pokusů o připojení z jediné adresy klienta může odhalit aplikaci s příliš mnoha vlákny, která vyžadují určitý typ omezení.
Protokolovat pouze operace DDL a DML
Hodně se diskutuje o tom, co by se mělo zaznamenávat do protokolu Postgres – tedy jaká by měla být hodnota parametru „log_statement“. Může mít tři hodnoty:
log_statement = 'off' | 'ddl' | 'mod' | 'all'
Může být lákavé nastavit toto na „vše“, aby se zachytil každý příkaz SQL spuštěný na serveru, ale ve skutečnosti to nemusí být vždy dobrý nápad.
Vytížené produkční systémy většinou spouštějí příkazy SELECT, někdy i tisíce za hodinu. Instance může fungovat naprosto dobře, bez jakýchkoli problémů s výkonem. Nastavení tohoto parametru na „all“ by v takových případech zbytečně zatížilo logovacího démona, protože musí zapsat všechny tyto příkazy do souboru.
Co však chcete zachytit, je jakékoli poškození dat nebo změny ve struktuře databáze, které způsobily nějaký typ problému. Nežádoucí nebo neautorizované změny databáze způsobují více aplikačních problémů než výběr dat; proto doporučuji nastavit tento parametr na „mod“. S tímto nastavením PostgreSQL zaznamená všechny změny DDL a DML do souboru protokolu.
Pokud je vaše instance PostgreSQL středně vytížená (desítky dotazů za hodinu), klidně nastavte tento parametr na „all“. Když řešíte problémy s pomalu běžícími dotazy SELECT nebo hledáte neoprávněný přístup k datům, můžete toto dočasně nastavit na „vše“. Některé aplikace jako pgBadger také očekávají, že toto nastavíte na „vše“.
Zaznamenat „varovné“ zprávy a nahoru
Pokud parametr „log_statement“ rozhoduje o tom, jaký typ příkazů bude zaznamenán, následující dva parametry určují, jak podrobná bude zpráva:
log_min_messages log_min_error_statement
Každá událost PostgreSQL má přidruženou úroveň zprávy. Úroveň zprávy může být cokoli od podrobného DEBUG po stručnou PANIC. Čím nižší úroveň, tím podrobnější je zpráva. Výchozí hodnota parametru „log_min_messages“ je „WARNING“. Doporučuji ji ponechat na této úrovni, pokud nechcete, aby byly protokolovány i informační zprávy.
Parametr „log_min_error_statement“ určuje, které příkazy SQL vyvolávající chybu budou protokolovány. Stejně jako „log_min_message“ bude zaznamenán každý příkaz SQL s úrovní závažnosti chyby stejnou nebo vyšší než hodnota uvedená v „log_min_error_statement“. Výchozí hodnota je „ERROR“ a doporučuji ponechat výchozí.
Ponechat parametry trvání protokolu ve výchozím nastavení
Pak máme následující dva parametry:
log_duration log_min_duration_statement
Parametr „log_duration“ má logickou hodnotu. Když je nastavena na 1, bude zaznamenána doba trvání každého dokončeného příkazu. Je-li nastaveno na 0, trvání příkazu nebude protokolováno. Toto je výchozí hodnota a doporučuji ji ponechat na 0, pokud nebudete řešit problémy s výkonem. Výpočet a zaznamenávání trvání příkazů dělá databázovému stroji práci navíc (bez ohledu na to, jak je malá), a když je extrapolován na stovky nebo tisíce dotazů, úspory mohou být značné.
Nakonec máme parametr „log_min_duration_statement“. Když je tento parametr nastaven (bez jednotek, bere se jako milisekundy), bude zaznamenána doba trvání jakéhokoli příkazu, která je stejná nebo delší než hodnota parametru. Nastavením hodnoty tohoto parametru na 0 se zaznamená doba trvání všech dokončených příkazů. Nastavení na -1 deaktivuje protokolování doby trvání příkazu. Toto je výchozí hodnota a doporučuji ji ponechat.
Tento parametr chcete nastavit na 0 pouze tehdy, když chcete vytvořit směrný plán výkonu pro často spouštěné dotazy. Mějte však na paměti, že pokud je nastaven parametr „log_statement“, protokolované příkazy se nebudou opakovat ve zprávách protokolu s dobou trvání. Budete tedy muset načíst soubory protokolu do databázové tabulky a poté spojit hodnoty ID procesu a ID relace z předpon řádku protokolu, abyste identifikovali související příkazy a jejich trvání.
Ať už to znamená jakékoli, jakmile budete mít základní linii pro každý často spouštěný dotaz, můžete nastavit parametr „log_min_duration_statement“ na nejvyšší z hodnot výchozího stavu. Nyní bude kandidátem na jemné doladění jakýkoli dotaz běžící déle, než je nejvyšší základní hodnota.
Ponechat výřečnost chybových zpráv na výchozí
Parametr „log_error_verbosity“ může mít tři možné hodnoty:
log_error_verbosity = terse | standard | verbose
Tento parametr řídí množství informací, které PostgreSQL zaznamená pro každou událost zaznamenanou v souboru protokolu. Pokud neladíte databázovou aplikaci, je nejlepší ponechat tento parametr na „výchozí“. Podrobný režim bude užitečný, když potřebujete zachytit název souboru nebo funkce a číslo řádku, který generoval chybu. Nastavením na „stručné“ potlačíte protokolování dotazu, což také nemusí být užitečné.
Najděte zásady rotace protokolů, které vyhovují vašim Případ použití
Doporučuji vytvořit zásadu rotace protokolu na základě velikosti nebo stáří souboru protokolu, ale ne obojího. Dva konfigurační parametry PostgreSQL určují, jak se archivují staré protokoly a jak se vytvářejí nové:
log_rotation_age = <number of minutes> log_rotation_size = <number of kilobytes>
Výchozí hodnota pro „log_rotration_age“ je 24 hodin a výchozí hodnota pro „log_rotation_size“ je 10 megabajtů.
Ve většině případů zásada rotace velikosti vždy nezaručuje, že poslední zpráva protokolu v archivovaném souboru protokolu bude zcela obsažena pouze v tomto souboru.
Pokud je „log_rotation_age“ udržován na výchozí hodnotě 24 hodin, každý soubor lze snadno identifikovat a individuálně prozkoumat, protože každý soubor bude obsahovat události za jeden den. Ani to však nezaručuje, že každý soubor bude samostatnou jednotkou protokolů za posledních 24 hodin. Někdy může dokončení dotazu s pomalým výkonem trvat déle než 24 hodin; události se mohou dít, když se starý soubor zavře a vygeneruje se nový. To se může stát během noční dávkové úlohy, což má za následek, že některé části dotazů budou zaznamenány do jednoho souboru a zbytek do jiného.
Naše doporučení je najít období rotace protokolu, které vyhovuje vašemu případ použití. Zkontrolujte časový rozdíl mezi dvěma po sobě jdoucími obdobími nejnižší aktivity (například mezi jednou sobotou a další). Poté můžete nastavit hodnotu „log_rotation_age“ na tento časový rozdíl a během jednoho z těchto období restartovat službu PostgreSQL. Tímto způsobem PostgreSQL otočí aktuální soubor protokolu, když nastane další období klidu. Pokud však mezi těmito obdobími potřebujete službu restartovat, rotace protokolu bude opět zkreslená. Poté budete muset tento proces opakovat. Ale stejně jako mnoho jiných věcí v PostgreSQL, pokus a omyl určí nejlepší hodnotu. Pokud používáte nástroj pro správu protokolů, nebude na stáří nebo velikosti rotace protokolu záležet, protože agent správce protokolů zpracuje každou událost ze souboru, jakmile bude přidán.
Používejte nástroje jako pgBadger
pgBadger je výkonný analyzátor protokolů PostgreSQL, který dokáže vytvářet velmi užitečné poznatky ze souborů protokolu Postgres. Jedná se o open-source nástroj napsaný v Perlu s velmi malou stopou ve stroji, kde běží. Nástroj se spouští z příkazového řádku a je dodáván s velkým množstvím možností. Jako vstup použije jeden nebo více protokolů a může vytvořit zprávu HTML s podrobnými statistikami o:
- Nejčastěji čekající dotazy.
- Dotazy generující většinu dočasných souborů nebo největší dočasné soubory
- Nejpomalejší běh dotazů
- Průměrná doba trvání dotazu
- Nejčastěji spouštěné dotazy
- Nejčastější chyby v dotazech
- Uživatelé a aplikace, kteří spouštějí dotazy
- Statistiky kontrolních bodů.
- Automatické vakuování a automatická analýza statistik.
- Statistiky uzamčení
- Chybové události (panika, fatální, chyba a varování).
- Profily připojení a relací (podle databáze, uživatele, aplikace)
- Profily relací
- Profily dotazů (typy dotazů, dotazy podle databáze/aplikace)
- I/O statistiky
- atd.
Jak jsem zmínil dříve, některé konfigurační parametry související s protokoly musí být povoleny, aby zachytily všechny události protokolu, aby mohl pgBadger tyto protokoly efektivně analyzovat. Protože to může vytvářet velké soubory protokolu s mnoha událostmi, měl by být pgBadger používán pouze k vytváření benchmarků nebo odstraňování problémů s výkonem. Po vygenerování podrobných protokolů lze konfigurační parametry změnit zpět na jejich původní hodnoty. Pro průběžnou analýzu protokolů je nejlepší použít specializovanou aplikaci pro správu protokolů.
Pokud vám vyhovuje dělat věci v příkazovém řádku a používat systémová zobrazení, měli byste použít pg_stat_statements. Ve skutečnosti by to mělo být povoleno v jakékoli produkční instalaci PostgreSQL.
pg_stat_statements je rozšíření PostgreSQL a nyní s výchozí instalací. Chcete-li to povolit, konfigurační parametr „shared_preload_libraries“ by měl mít jako jednu z hodnot pg_stat_statements. Poté jej lze nainstalovat jako jakékoli jiné rozšíření pomocí příkazu „CREATE EXTENSION“. Rozšíření vytváří pohled pg_stat_statement, který poskytuje cenné informace související s dotazem.
Získejte přehled pomocí aplikace pro správu protokolů
Na trhu existuje mnoho nástrojů pro správu protokolů a většina organizací dnes jeden nebo více používá. Ať už je k dispozici jakýkoli nástroj, doporučuji jej použít ke shromažďování a správě protokolů PostgreSQL.
Existuje pro to několik důvodů:
Je mnohem snazší analyzovat, analyzovat a odfiltrovat šum ze souborů protokolu pomocí automatického nástroje. Někdy může událost zahrnovat více souborů protokolu na základě doby trvání události a stáří nebo velikosti rotace protokolu. Díky správci protokolů je mnohem jednodušší mít tyto informace prezentovány jako celek.
Řešení správy protokolů dnes obvykle přicházejí s vestavěnou schopností analyzovat protokoly PostgreSQL. Některé také přicházejí s řídicími panely, které mohou zobrazovat nejběžnější metriky extrahované z těchto protokolů.
Většina moderních aplikací pro správu protokolů také nabízí výkonné funkce vyhledávání, filtrování, porovnávání vzorů, korelace událostí a analýzy trendů s podporou AI. To, co běžné oči nevidí, lze pomocí těchto nástrojů snadno zjistit.
A konečně, použití správce protokolů k ukládání protokolů PostgreSQL bude také znamenat, že události budou uloženy pro budoucí generace, i když budou původní soubory smazány omylem nebo úmyslně.
Přestože používání aplikace pro správu protokolů má zjevné výhody, mnoho organizací má omezení ohledně kde jejich klády mohou žít. Toto je typický případ řešení založených na SaaS, kde jsou protokoly často ukládány mimo geografické hranice organizace – něco, co nemusí být v souladu s regulačními požadavky.
V takových případech doporučuji vybrat si dodavatele s místní přítomností v datovém centru – pokud je to možné – nebo použít samostatně spravovaného správce protokolů hostovaného v síti organizace, jako je zásobník ELK.
Poslední slova
Logy serveru PostgreSQL mohou být zlatým dolem informací, pokud jsou správně nakonfigurovány. Trik spočívá v tom, určit, co se má protokolovat a kolik toho, a co je důležitější, otestovat, zda protokoly dokážou v případě potřeby poskytnout správné informace. Bude to otázka pokusů a omylů, ale to, o čem jsem tu dnes mluvil, by mělo dát docela slušný začátek. Jak jsem řekl na začátku, rád bych slyšel o vašich zkušenostech s konfigurací protokolování PostgreSQL pro optimální výsledky.