Zabbix je monitorovací systém. Jako každý jiný systém čelí třem hlavním problémům všech monitorovacích systémů: sběr a zpracování dat, ukládání historie a její vymazání.
Fáze přijímání, zpracovávání a zaznamenávání dat vyžadují určitý čas. Nic moc, ale u velkého systému to může mít za následek velké zpoždění. Problém úložiště je otázkou přístupu k datům. Používají se pro zprávy, kontroly a spouštěče. Výkon také ovlivňují zpoždění přístupu k datům. Když se databáze rozroste, irelevantní data musí být smazána. Odstranění je náročná operace, která také spotřebovává některé zdroje.
Problémy se zpožděním shromažďování a ukládání v Zabbix jsou řešeny ukládáním do mezipaměti: několik typů mezipamětí, ukládání do mezipaměti v databázi. K vyřešení třetího problému není vhodné ukládání do mezipaměti, proto byla v Zabbixu použita TimescaleDB. Bude o tom vyprávět Andrej Guščin - inženýr technické podpory . Andrey podporuje Zabbix přes 6 let a přímo se podílí na výkonu.
Jak funguje TimescaleDB, jaký výkon může poskytnout ve srovnání s běžným PostgreSQL? Jakou roli hraje Zabbix v TimescaleDB? Jak začít od nuly a jak migrovat z PostgreSQL a jaký výkon konfigurace je lepší? To vše pod řezem.
Výkonnostní výzvy
Každý monitorovací systém čelí určitým výkonnostním výzvám. Budu mluvit o třech z nich: sběr a zpracování dat, ukládání, čištění historie.
Rychlý sběr a zpracování dat. Dobrý monitorovací systém by měl rychle přijímat všechna data a zpracovávat je podle spouštěcích výrazů – podle vlastních kritérií. Po zpracování musí systém také tato data rychle uložit do databáze, aby je mohl později použít.
Ukládání historie. Dobrý monitorovací systém by měl uchovávat historii v databázi a poskytovat snadný přístup k metrikám. Historii je třeba použít v sestavách, grafech, spouštěcích mechanismech, prahových hodnotách a počítaných položkách výstrah.
Vymazání historie. Někdy přijde den, kdy nepotřebujete ukládat metriky. Proč potřebujete data, která byla shromážděna před 5 lety, měsícem nebo dvěma: některé uzly byly odstraněny, někteří hostitelé nebo metriky již nejsou potřeba, protože jsou zastaralé a již se neshromažďují. Dobrý monitorovací systém by měl uchovávat historická data a čas od času je mazat, aby se databáze nerozrůstala.
Vyčištění zastaralých dat je ožehavým problémem, který má velký dopad na výkon databáze.
Ukládání do mezipaměti v Zabbix
V Zabbix se první a druhé volání řeší pomocí ukládání do mezipaměti. RAM se používá ke sběru a zpracování dat. Pro uložení - historie ve triggerech, grafech a kalkulovaných položkách. Na straně DB je nějaké ukládání do mezipaměti pro základní výběry, jako jsou grafy.
Ukládání do mezipaměti na straně samotného serveru Zabbix je:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Zvažte je podrobněji.
ConfigurationCache
Toto je hlavní mezipaměť, do které ukládáme metriky, hostitele, datové položky, spouštěče – vše, co je potřeba pro PreProcessing a pro sběr dat.
To vše je uloženo v ConfigurationCache, aby nevznikaly zbytečné dotazy v databázi. Po spuštění serveru tuto mezipaměť aktualizujeme, vytváříme a pravidelně aktualizujeme konfigurace.
Sběr dat
Schéma je poměrně velké, ale hlavní věc v něm je sběratelé. Jde o různé „pollery“ – montážní procesy. Jsou zodpovědní za různé typy sestavení: shromažďují data přes SNMP, IPMI a všechna je přenášejí do PreProcessing.
Sběrače jsou zakroužkovány oranžově.
Zabbix vypočítal agregační položky, které jsou potřebné k agregaci kontrol. Pokud je máme, bereme pro ně data přímo z ValueCache.
Předzpracování HistoryCache
Všichni kolektory používají ConfigurationCache k přijímání úloh. Poté je předají do Předzpracování.
PreProcessing používá ConfigurationCache k získání kroků PreProcessing. Tato data zpracovává různými způsoby.
Po zpracování dat pomocí PreProcessing je uložíme do HistoryCache, abychom je mohli zpracovat. Tím je sběr dat dokončen a přejdeme k hlavnímu procesu v Zabbix - synchronizátor historie, jelikož se jedná o monolitickou architekturu.
Poznámka: Předzpracování je poměrně náročná operace. Od verze 4.2 byl přesunut na proxy. Pokud máte velmi velký Zabbix s velkým počtem položek a četností sběru, pak je to mnohem jednodušší.
Mezipaměť ValueCache, historie a trendy
Synchronizátor historie je hlavní proces, který atomicky zpracovává každý datový prvek, tedy každou hodnotu.
Synchronizátor historie přebírá hodnoty z HistoryCache a kontroluje konfiguraci pro spouštěče pro výpočty. Pokud jsou - počítá.
Synchronizátor historie vytvoří událost, eskaluje, aby vytvořil výstrahy, pokud to vyžaduje konfigurace, a zaznamená. Pokud existují spouštěče pro další zpracování, pak si pamatuje tuto hodnotu ve ValueCache, aby se neodkazovalo na tabulku historie. Takto se ValueCache plní daty, která jsou potřebná k výpočtu triggerů, počítaných položek.
Synchronizátor historie zapisuje všechna data do databáze a ta zapisuje na disk. Proces zpracování zde končí.
DB cache
Na straně DB jsou různé cache, když se chcete podívat na grafy nebo reporty událostí:
Innodb_buffer_poolna straně MySQL;shared_buffersna straně PostgreSQL;effective_cache_sizena straně Oracle;shared_poolna straně DB2.
Existuje mnoho dalších keší, ale tyto jsou hlavní pro všechny databáze. Umožňují vám uchovávat data v paměti RAM, která jsou často potřebná pro dotazy. Mají na to vlastní technologii.
Výkon databáze je kritický
Server Zabbix neustále sbírá data a zapisuje je. Po restartu také čte z historie, aby naplnil ValueCache. Použití skriptů a sestav Zabbix API, který je postaven na bázi webového rozhraní. Zabbix API přistupuje k databázi a získává potřebná data pro grafy, zprávy, seznamy událostí a poslední problémy.
Pro vizualizaci - grafana. Toto je oblíbené řešení mezi našimi uživateli. Může přímo odesílat požadavky přes Zabbix API a do databáze a vytváří určitou souběžnost pro získávání dat. Proto je zapotřebí jemnější a lepší vyladění databáze, aby odpovídalo rychlému poskytování výsledků a testování.
Hospodyně
Třetí výkonnostní výzvou v Zabbix je čištění historie s Housekeeperem. Respektuje veškerá nastavení – datové prvky udávají, jak dlouho ukládat dynamiku změn (trendů) ve dnech.
TrendsCache počítáme za běhu. Když data přijdou, agregujeme je za jednu hodinu a vložíme do tabulek pro dynamiku změn trendů.
Hospodyně spustí a odebere informace z databáze obvyklými „výběry“. To není vždy efektivní, což lze pochopit z grafů výkonnosti interních procesů.
Červený graf ukazuje, že synchronizátor historie je neustále zaneprázdněn. Oranžový graf nahoře je Housekeeper, který neustále běží. Čeká, až databáze smaže všechny řádky, které zadala.
Kdy byste měli vypnout hospodyni? Existuje například „ID položky“ a je třeba smazat posledních 5 tisíc řádků v určitém čase. To se samozřejmě děje pomocí indexů. Ale obvykle je datová sada velmi velká a databáze stále čte z disku a ukládá jej do mezipaměti. To je pro databázi vždy velmi nákladná operace a v závislosti na velikosti databáze může vést k problémům s výkonem.
Hospodyně lze jednoduše vypnout. Ve webovém rozhraní je v části „Obecná správa“ nastavení pro Housekeeper. Zakažte interní správu historie interních trendů a již to neřídí.
Hospodyně byla deaktivována, grafika se vyrovnala – jaké by mohly být v tomto případě problémy a co může pomoci při řešení třetí výkonnostní výzvy?
Partitioning - rozdělení nebo rozdělení
Rozdělení je obvykle nakonfigurováno jiným způsobem v každé relační databázi, kterou jsem uvedl. Každý má svou vlastní technologii, ale obecně jsou podobné. Vytvoření nového oddílu často vede k určitým problémům.
Oddíly se obvykle konfigurují v závislosti na „nastavení“ – množství dat, které se vytvoří za jeden den. Zpravidla se Partitioning nastavuje za jeden den, to je minimum. Pro nové trendy rozdělení — 1 měsíc.
Hodnoty se mohou změnit v případě velmi rozsáhlého „nastavení“. Pokud je malá „nastavení“ až 5 000 nvps (nové hodnoty za sekundu), průměrná je od 5 000 do 25 000, pak velká je nad 25 000 nvps. Jedná se o velké a velmi rozsáhlé instalace, které vyžadují pečlivou konfiguraci samotné databáze.
U velmi velkých instalací nemusí být jeden den optimální. Viděl jsem oddíly MySQL o velikosti 40 GB nebo více za den. Jedná se o velmi velké množství dat, které může vést k problémům a mělo by být redukováno.
Co dává rozdělení?
Rozdělovací tabulky. Často se jedná o samostatné soubory na disku. Plán dotazů vybere jeden oddíl optimálněji. Obvykle se rozdělení používá podle rozsahu – to platí i pro Zabbix. Používáme tam "timestamp" - čas od počátku epochy. Máme pravidelná čísla. Nastavíte začátek a konec dne – jedná se o oddíl.
Rychlé odstranění - DELETE. Je vybrán jeden soubor/podtabulka, nikoli výběr řádků k odstranění.
Výrazně zrychluje vzorkování dat SELECT - používá jeden nebo více oddílů, nikoli celou tabulku. Pokud přistupujete k dva dny starým datům, načte je z databáze rychleji, protože je stačí načíst do mezipaměti a vrátit pouze jeden soubor, nikoli velkou tabulku.
Často se také zrychlí mnoho databází INSERT - vkládá do dětského stolu.
Časová osa DB
U verze 4.2 jsme obrátili naši pozornost na TimescaleDB. Toto je rozšíření PostgreSQL s nativním rozhraním. Rozšíření efektivně pracuje s daty časových řad, aniž by ztratilo výhody relačních databází. TimescaleDB také automaticky rozděluje oddíly.
TimescaleDB má koncept hypertable (hypertable), kterou vytvoříte. V něm jsou kousky - příčky. Bloky jsou automaticky spravované fragmenty hypertabulky, které neovlivňují jiné fragmenty. Každý blok má svůj vlastní časový rozsah.
TimescaleDB vs PostgreSQL
TimescaleDB je opravdu efektivní. Výrobci rozšíření tvrdí, že používají přesnější algoritmus zpracování dotazů, zejména inserts . Jak velikost vložky datové sady roste, algoritmus si udržuje konstantní výkon.
Po 200 milionech řádků se PostgreSQL obvykle začne hodně propadat a ztrácet výkon na 0. TimescaleDB umožňuje efektivně vkládat „vklady“ s libovolným množstvím dat.
Instalace
Instalace TimescaleDB je dostatečně snadná pro všechny balíčky. V vše je podrobné - záleží na oficiálních balíčcích PostgreSQL. TimescaleDB lze také sestavit a zkompilovat ručně.
Pro databázi Zabbix jednoduše aktivujeme rozšíření:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
aktivujete extension a vytvořte jej pro databázi Zabbix. Posledním krokem je vytvoření hypertabulky.
Migrace tabulek historie do TimescaleDB
K tomu slouží speciální funkce. create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
Funkce má tři parametry. První - tabulky v databáziObjekt, pro který chcete vytvořit hypertabulku. Druhý - pole, podle kterého je třeba tvořit chunk_time_interval — interval oddílů, které se mají použít. V mém případě je interval jeden den - 86 400.
Třetím parametrem je migrate_data. Pokud je nastaveno true, pak se všechna aktuální data přenesou do předem vytvořených bloků. Sám jsem použil migrate_data. Měl jsem asi 1TB, což trvalo přes hodinu. Dokonce jsem v některých případech při testování vymazal historická data typů postav, která jsou volitelné pro uložení, abych je nepřenášela.
Poslední krok - UPDATE: na db_extension dát timescaledbaby databáze pochopila, že existuje toto rozšíření. Zabbix jej aktivuje a správně používá syntaxi a dotazy již do databáze - ty funkce, které jsou pro TimescaleDB nezbytné.
Konfigurace hardwaru
Použil jsem dva servery. První - Stroj VMware. Je dostatečně malý: 20 procesorů Intel® Xeon® E5-2630 v 4 @ 2.20 GHz, 16 GB RAM a 200 GB SSD disk.
Nainstaloval jsem na něj PostgreSQL 10.8 s OS Debian 10.8-1.pgdg90+1 a souborovým systémem xfs. Vše jsem konfiguroval minimálně pro použití této konkrétní databáze, mínus to, co bude používat samotný Zabbix.
Na stejném stroji byl server Zabbix, PostgreSQL a zatěžovací agenty. Měl jsem 50 aktivních agentů, které jsem použil LoadableModulevelmi rychle generovat různé výsledky: čísla, řetězce. Naplnil jsem databázi spoustou dat.
Zpočátku konfigurace obsahovala 5 000 položek data na hostitele. Téměř každý prvek obsahoval spoušť, aby to vypadalo jako skutečné instalace. V některých případech byl spouštěč více než jeden. Jeden síťový uzel měl 3 000-7 000 spouštěčů.
Interval aktualizace položky − 4 7-sekund. Samotné zatížení jsem reguloval tak, že jsem použil nejen 50 agentů, ale přidal jsem další. Také jsem pomocí datových prvků dynamicky reguloval zátěž a zkrátil interval aktualizace na 4s.
PostgreSQL. 35 000 nvps
Můj první běh na tomto hardwaru byl na čistém PostgreSQL - 35 tisíc hodnot za sekundu. Jak vidíte, vkládání dat trvá zlomky sekund – vše je v pořádku a rychlé. Jediné, co je, že 200GB SSD disk se rychle zaplní.
Toto je standardní řídicí panel výkonu serveru Zabbix.
První modrý graf je počet hodnot za sekundu. Druhý graf vpravo je načítání procesů sestavení. Třetím je načítání interních procesů sestavení: synchronizátorů historie a Housekeeper, které zde běží už poměrně dlouho.
Čtvrtý graf ukazuje využití HistoryCache. Jedná se o jakýsi buffer před vložením do databáze. Zelený pátý graf ukazuje využití ValueCache, to znamená, kolik hodnot ValueCache pro spouštěče je několik tisíc hodnot za sekundu.
PostgreSQL. 50 000 nvps
Poté jsem zvýšil zátěž na 50 tisíc hodnot za sekundu na stejném hardwaru.
Při načítání z Housekeepera vložení 10 tisíc hodnot trvalo 2-3 sekundy.
Hospodyně už začíná překážet.
Třetí graf ukazuje, že obecně je vytížení trapperů a synchronizátorů historie stále na úrovni 60 %. Na čtvrtém grafu se HistoryCache za provozu Housekeepera již začíná poměrně aktivně plnit. Je zaplněná z 20 % – asi 0,5 GB.
PostgreSQL. 80 000 nvps
Poté jsem zvýšil zátěž na 80 tisíc hodnot za sekundu. Jedná se přibližně o 400 tisíc datových prvků a 280 tisíc triggerů.
Načítací vložka třiceti synchronizátorů historie je už dost vysoká.
Také jsem zvýšil různé parametry: synchronizátory historie, mezipaměti.
Na mém hardwaru se načítání synchronizátorů historie zvýšilo na maximum. HistoryCache se rychle zaplnil daty - vyrovnávací paměť nashromáždila data pro zpracování.
Celou tu dobu jsem sledoval, jak se využívá procesor, RAM a další systémové parametry a zjistil jsem, že využití disku je maximální.
Využil jsem maximální kapacita disku na tomto hardwaru a na tomto virtuálním počítači. S takovou intenzitou začal PostgreSQL celkem aktivně vyhazovat data a disk už neměl čas na zápis a čtení.
Druhý server
Vzal jsem další server, který již měl 48 procesorů a 128 GB RAM. Vyladil jsem to - nastavil synchronizátor historie 60 a dosáhl přijatelného výkonu.
To už je vlastně limit výkonu, kde je potřeba něco udělat.
timescaledb. 80 000 nvps
Mým hlavním úkolem je otestovat schopnosti TimescaleDB proti zatížení Zabbix. 80 tisíc hodnot za sekundu je hodně, frekvence shromažďování metrik (samozřejmě kromě Yandexu) a poměrně velké „nastavení“.
Na každém grafu je propad – jedná se pouze o migraci dat. Po selháních na serveru Zabbix se načítací profil synchronizátoru historie hodně změnil - třikrát spadl.
TimescaleDB umožňuje vkládat data téměř 3krát rychleji a používat méně HistoryCache.
V souladu s tím obdržíte data včas.
timescaledb. 120 000 nvps
Poté jsem zvýšil počet datových položek na 500 125. Hlavním úkolem bylo prověřit možnosti TimescaleDB – dostal jsem vypočítanou hodnotu XNUMX tisíc hodnot za sekundu.
Toto je funkční „nastavení“, které může trvat dlouho. Ale jelikož můj disk měl jen 1,5 TB, zaplnil jsem ho za pár dní.
A co je nejdůležitější, současně se vytvářely nové oddíly TimescaleDB.
Pro výkon je to naprosto nepostřehnutelné. Když jsou oddíly vytvořeny například v MySQL, věci jsou jiné. To se obvykle děje v noci, protože to blokuje obecné vkládání, manipulaci s tabulkami a může způsobit degradaci služby. To není případ TimescaleDB.
Ukážu například jeden graf ze sady v komunitě. Na obrázku je povolen TimescaleDB, díky kterému klesla zátěž na využití io.weight na procesoru. Snížilo se také využívání prvků interních procesů. Navíc se jedná o obyčejný virtuální stroj na obyčejných palačinkových discích, nikoli o SSD.
Závěry
TimescaleDB je dobré řešení pro malá "nastavení", které spočívají na výkonu disku. Umožní vám dobře pracovat, dokud nebude databáze migrována na hardware rychleji.
TimescaleDB se snadno nastavuje, zvyšuje výkon, dobře funguje se Zabbix a má výhody oproti PostgreSQL.
Pokud používáte PostgreSQL a neplánujete jej měnit, pak doporučuji použijte PostgreSQL s rozšířením TimescaleDB ve spojení se Zabbixem. Toto řešení funguje efektivně až do středního „nastavení“.
Říkáme „vysoký výkon“ – myslíme . Nebude to dlouho trvat, než se seznámíte s technologiemi a postupy, které umožňují službám sloužit milionům uživatelů. Seznam na 7. a 8. listopadu jsme již sestavili, ale lze navrhnout více.
Přihlaste se k odběru и , ve kterém odhalíme rysy nadcházející konference a zjistíme, jak z ní vytěžit maximum.
Zdroj: www.habr.com