Na obranu sar (a jak jej nakonfigurovat)

Dovolte mi diskutovat o tématu, které není ve své podstatě specifické pro PostgreSQL, ale s nímž se pravidelně setkávám při zkoumání problémů na zákaznických systémech, hodnocení „podporovatelnosti“ těchto systémů atd. Je důležité mít řešení pro monitorování systémových metrik a rozumně je nakonfigurovat a proč sar je stále můj oblíbený nástroj (alespoň na Linuxu).

O důležitosti monitorování

Za prvé, monitorování základních systémových metrik (CPU, I/O, paměť) je nesmírně důležité. Je trochu zvláštní upozorňovat na to v diskusích s jinými inženýry, ale řekl bych, že 1 z 10 inženýrů si myslí, že monitorování ve skutečnosti nepotřebují. Zdůvodnění obvykle probíhá takto:

Skutečné monitorování zvyšuje režii, o tom není pochyb. Ale je to pravděpodobně zanedbatelné ve srovnání s tím, co aplikace dělá. Vlastně sar ve skutečnosti nepřidává žádné další vybavení, pouze čte čítače z nernelu, počítá delty a zapisuje je na disk. Možná bude potřebovat nějaké místo na disku a I/O (v závislosti na počtu CPU a disků), ale to je tak vše.

Například shromažďování statistik za sekundu na počítači s 32 jádry a více disky vytvoří ~5 GB nezpracovaných dat za den, ale komprimuje se extrémně dobře, často na ~5-10%). A v top je to sotva vidět . Rozlišení za sekundu je trochu extrémní a použití 5 nebo 10 sekund dále sníží režii.

Takže ne, ukázalo se, že režie ve skutečnosti není platným důvodem, proč nepovolit monitorování.

Náklady vs. přínosy

Ještě důležitější je však:"Kolik režie eliminuji tím, že nepovolím monitorování?" je špatná otázka. Místo toho byste se měli ptát:„Jaké výhody mám z monitorování? Převažují přínosy nad náklady?“

Již víme, že náklady (režijní náklady) jsou poměrně malé nebo zcela zanedbatelné. jaké jsou výhody? Podle mých zkušeností jsou monitorovací data skutečně neocenitelná.

Za prvé vám umožňuje prozkoumat problémy – pohled na hromadu grafů a hledání náhlých změn je překvapivě efektivní a často vás přivede přímo ke správnému problému. Podobně je velmi užitečné porovnávání aktuálních dat (shromážděných během vydání) se základní linií (shromážděná, když je vše v pořádku), a nemožné, pokud povolíte monitorování pouze tehdy, když se něco pokazí.

Za druhé vám umožňuje vyhodnotit trendy a identifikovat potenciální problémy dříve, než vás skutečně zasáhnou. Kolik CPU používáš? Roste časem využití procesoru? Existují nějaké podezřelé vzorce ve využití paměti? Na tyto otázky můžete odpovědět, pouze pokud máte zavedeno monitorování.

Proč sar je můj oblíbený nástroj

Předpokládejme, že jsem vás přesvědčil, že monitorování je důležité a měli byste to rozhodně udělat. Ale proč je sar náš oblíbený nástroj, když existují různé efektní alternativy, jak on-premise, tak cloudové?

• Je součástí všech distribucí a jeho instalace/nastavení je triviální. Díky tomu je poměrně snadné přesvědčit lidi, aby to umožnili.
• Je přímo na počítači. Pokud tedy připojíte SSH ke stroji, můžete také získat monitorovací data.
• Používá jednoduchý textový výstup. Data triviálně zpracujte – importujte je do databáze, analyzujte, připojte k lístku podpory. To je dost obtížné s jinými nástroji, které obecně neumožňují snadno exportovat data, zobrazují pouze grafy a/nebo výrazně omezují analýzu, kterou můžete provádět atd.

Přiznávám, že něco z toho pochází ze skutečnosti, že pracuji pro společnost poskytující služby PostgreSQL jiným společnostem (ať už je to podpora 24×7 nebo Remote DBA. Obvykle tedy máme jen velmi omezený přístup k zákaznickým systémům (většinou jen databázové servery a nic víc). To znamená, že mít všechna důležitá data na samotném databázovém serveru, přístupná přes prostý SSH, je extrémně pohodlná a eliminuje zbytečné zpáteční cesty pouze za účelem vyžádání dalšího kusu dat z jiného systému. Což šetří čas i rozum na obou stranách.

Máte-li ke správě mnoho systémů, pravděpodobně dáte přednost řešení monitorování, které shromažďuje data z mnoha strojů na jedno místo. Ale pro mě sar stále vyhrává.

Jak to tedy nakonfigurovat?

Zmínil jsem instalaci a povolení sar (nebo spíše sysstat , což je balíček obsahující sar ) je velmi jednoduchý. Bohužel výchozí konfigurace je poněkud špatná. Po instalaci sysstat , něco takového najdete v /etc/cron.d/sysstat (nebo kdekoli, kde vaše distribuce ukládá cron konfigurace):

*/10 * * * * root /usr/lib64/sa/sa1 1 1

To v podstatě říká sa1 Příkaz se bude provádět každých 10 minut a během 1 sekundy shromáždí jeden vzorek. Jsou zde dva problémy. Za prvé, 10 minut je poměrně nízké rozlišení. Zadruhé, vzorek pokrývá pouze 1 sekundu z 600, takže zbývajících 9:59 do něj skutečně zahrnuto není. To je poněkud v pořádku pro dlouhodobé trendy, kde stačí náhodné vzorkování s nízkým rozlišením. Pro jiné účely budete pravděpodobně muset místo toho udělat něco takového:

* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1

Která shromažďuje jeden vzorek za minutu a každý vzorek pokrývá jednu minutu. -S XALL znamená, že by měly být shromažďovány všechny statistiky, včetně přerušení, jednotlivých blokových zařízení a oddílů atd. Viz man sadc pro více podrobností.

Shrnutí

Takže, abych tento příspěvek shrnul do několika jednoduchých bodů:

• Měli byste mít sledování, i když si myslíte, že to nepotřebujete. Jakmile narazíte na problémy, je příliš pozdě.
• Náklady na monitorování jsou pravděpodobně zanedbatelné, ale rozhodně mnohem nižší než přínosy monitorování údajů.
• sar je pohodlné a velmi efektivní. Možná v budoucnu použijete něco jiného, ​​ale je to dobrý první krok.
• Výchozí konfigurace není nijak zvlášť skvělá (nízké rozlišení, 1sekundové ukázky). Zvažte zvýšení rozlišení.

Jedna věc, kterou jsem nezmínil, je sar zabývá pouze systémovými metrikami – CPU, disky, paměť, procesy, nikoli statistikami PostgreSQL. Určitě byste měli sledovat i tuto část zásobníku, samozřejmě.