Zabbix je monitorovací systém. Ako každý iný systém čelí trom hlavným problémom všetkých monitorovacích systémov: zber a spracovanie údajov, ukladanie histórie a jej čistenie.
Fázy prijímania, spracovania a zaznamenávania údajov si vyžadujú určitý čas. Nie veľa, ale pre veľký systém to môže viesť k veľkým oneskoreniam. Problém s úložiskom je problém s prístupom k údajom. Používajú sa na správy, kontroly a spúšťače. Latencie v prístupe k údajom tiež ovplyvňujú výkon. Keď sa databázy rozrastú, irelevantné údaje sa musia vymazať. Odstránenie je náročná operácia, ktorá tiež spotrebuje určité zdroje.
Problémy oneskorenia pri zbere a ukladaní v Zabbixe rieši cachovanie: niekoľko typov skrýš, cachovanie v databáze. Na vyriešenie tretieho problému nie je vhodné ukladanie do vyrovnávacej pamäte, preto Zabbix použil TimescaleDB. On ti o tom povie Andrej Guščin - inžinier technickej podpory . Andrey podporuje Zabbix už viac ako 6 rokov a má priame skúsenosti s výkonom.
Ako funguje TimescaleDB, aký výkon môže poskytnúť v porovnaní s bežným PostgreSQL? Akú úlohu hrá Zabbix pre databázu TimescaleDB? Ako začať od nuly a ako migrovať z PostgreSQL a ktorá konfigurácia má lepší výkon? O tom všetkom pod rezom.
Výzvy v oblasti produktivity
Každý monitorovací systém čelí špecifickým výkonnostným výzvam. Budem hovoriť o troch z nich: zber a spracovanie údajov, uchovávanie a čistenie histórie.
Rýchly zber a spracovanie dát. Dobrý monitorovací systém by mal rýchlo prijať všetky dáta a spracovať ich podľa spúšťacích výrazov – podľa svojich kritérií. Po spracovaní musí systém aj tieto údaje rýchlo uložiť do databázy pre neskoršie použitie.
Ukladanie histórie. Dobrý monitorovací systém by mal uchovávať históriu v databáze a poskytovať jednoduchý prístup k metrikám. Históriu je potrebné použiť v prehľadoch, grafoch, spúšťačoch, prahových hodnotách a vypočítaných položkách údajov výstrah.
Vymazáva sa história. Niekedy príde deň, keď nepotrebujete ukladať metriky. Prečo potrebujete údaje, ktoré boli zhromaždené pred 5 rokmi, mesiacom alebo dvoma: niektoré uzly boli odstránené, niektorí hostitelia alebo metriky už nie sú potrebné, pretože sú zastarané a už sa nezbierajú. Dobrý monitorovací systém by mal uchovávať historické údaje a z času na čas ich vymazávať, aby sa databáza nerozrastala.
Vyčistenie zastaraných údajov je kritickým problémom, ktorý výrazne ovplyvňuje výkon databázy.
Ukladanie do vyrovnávacej pamäte v Zabbix
V Zabbixe sa prvé a druhé volanie rieši pomocou vyrovnávacej pamäte. RAM sa používa na zber a spracovanie údajov. Pre uloženie - história v spúšťačoch, grafoch a vypočítaných dátových prvkoch. Na strane databázy je ukladanie do vyrovnávacej pamäte pre základné výbery, napríklad grafy.
Ukladanie do vyrovnávacej pamäte na strane samotného servera Zabbix je:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Zvážte ich podrobnejšie.
ConfigurationCache
Toto je hlavná vyrovnávacia pamäť, kde ukladáme metriky, hostiteľov, dátové položky, spúšťače – všetko, čo potrebujeme na predbežné spracovanie a zber údajov.
Toto všetko je uložené v ConfigurationCache, aby nevznikali zbytočné dotazy v databáze. Po spustení servera aktualizujeme túto vyrovnávaciu pamäť, vytvárame a pravidelne aktualizujeme konfigurácie.
Zber dát
Diagram je pomerne veľký, ale hlavná vec v ňom je zberači. Ide o rôzne „pollery“ - montážne procesy. Sú zodpovední za rôzne typy zostavovania: zbierajú údaje cez SNMP, IPMI a všetky ich prenášajú do predbežného spracovania.
Kolektory sú označené oranžovou farbou.
Zabbix vypočítal agregačné položky, ktoré sú potrebné na agregáciu kontrol. Ak ich máme, získavame pre ne údaje priamo z ValueCache.
Preprocessing HistoryCache
Všetci kolektory používajú ConfigurationCache na prijímanie úloh. Potom ich prenesú do predbežného spracovania.
Predspracovanie používa ConfigurationCache na prijímanie krokov predspracovania. Tieto údaje spracováva rôznymi spôsobmi.
Po spracovaní údajov pomocou PreProcessing ich uložíme do HistoryCache na spracovanie. Tým sa zber údajov končí a prejdeme k hlavnému procesu v Zabbixe – synchronizátor histórie, keďže ide o monolitickú architektúru.
Poznámka: Predspracovanie je pomerne náročná operácia. Vo verzii 4.2 bol presunutý na proxy. Ak máte veľmi veľký Zabbix s veľkým počtom dátových prvkov a frekvenciou zberu, potom to značne uľahčuje prácu.
ValueCache, vyrovnávacia pamäť histórie a trendov
Synchronizátor histórie je hlavný proces, ktorý atómovo spracováva každý dátový prvok, teda každú hodnotu.
Synchronizátor histórie preberá hodnoty z HistoryCache a kontroluje konfiguráciu na prítomnosť spúšťačov pre výpočty. Ak existujú, vypočíta sa.
Synchronizátor histórie vytvorí udalosť, eskaláciu na vytvorenie upozornení, ak to vyžaduje konfigurácia, a záznamy. Ak existujú spúšťače pre následné spracovanie, uloží túto hodnotu do ValueCache, aby sa nedostala do tabuľky histórie. Takto sa ValueCache naplní údajmi, ktoré sú potrebné na výpočet spúšťačov a vypočítaných prvkov.
Synchronizátor histórie zapisuje všetky údaje do databázy a tá zapisuje na disk. Proces spracovania tu končí.
Ukladanie do vyrovnávacej pamäte v databáze
Na strane databázy sú rôzne vyrovnávacie pamäte, keď si chcete prezerať grafy alebo správy o udalostiach:
Innodb_buffer_poolna strane MySQL;shared_buffersna strane PostgreSQL;effective_cache_sizena strane Oracle;shared_poolna strane DB2.
Existuje mnoho ďalších kešiek, ale tieto sú hlavné pre všetky databázy. Umožňujú vám ukladať údaje do pamäte RAM, ktoré sú často potrebné pre dotazy. Majú na to svoje technológie.
Výkon databázy je kritický
Server Zabbix neustále zbiera údaje a zapisuje ich. Po reštarte tiež načítava z histórie, aby naplnila ValueCache. Používa skripty a zostavy Zabbix API, ktorý je postavený na webovom rozhraní. Zabbix API pristupuje k databáze a získava potrebné údaje pre grafy, správy, zoznamy udalostí a najnovšie vydania.
Pre vizualizáciu - grafana. Toto je obľúbené riešenie medzi našimi používateľmi. Môže priamo posielať požiadavky cez Zabbix API a do databázy a vytvára určitú konkurenciu pre prijímanie dát. Preto je potrebné jemnejšie a lepšie vyladenie databázy, aby zodpovedala rýchlemu dodaniu výsledkov a testovaniu.
Gazdiná
Treťou výkonnostnou výzvou v Zabbix je čistenie histórie pomocou Housekeepera. Dodržiava všetky nastavenia – dátové prvky udávajú, ako dlho sa má uchovávať dynamika zmien (trendov) v dňoch.
Vypočítavame TrendsCache za behu. Keď údaje prídu, agregujeme ich za jednu hodinu a zaznamenávame do tabuliek pre dynamiku zmien trendov.
Housekeeper spustí a vymaže informácie z databázy pomocou obvyklých „výberov“. To nie je vždy efektívne, ako vidno z grafov výkonnosti interných procesov.
Červený graf ukazuje, že synchronizátor histórie je neustále zaneprázdnený. Oranžový graf v hornej časti je Housekeeper, ktorý neustále beží. Čaká, kým databáza vymaže všetky riadky, ktoré zadal.
Kedy by ste mali vypnúť Housekeeper? Napríklad existuje „ID položky“ a v určitom čase musíte vymazať posledných 5 XNUMX riadkov. Samozrejme, toto sa deje indexom. Zvyčajne je však súbor údajov veľmi veľký a databáza stále číta z disku a ukladá ho do vyrovnávacej pamäte. Pre databázu je to vždy veľmi nákladná operácia a v závislosti od veľkosti databázy môže viesť k problémom s výkonom.
Housekeeper sa dá ľahko vypnúť. Vo webovom rozhraní je v časti „Administration general“ nastavenie pre Housekeeper. Deaktivujeme interné Housekeeping pre históriu interných trendov a už ho nespravuje.
Housekeeper bol vypnutý, grafy vyrovnané – aké problémy by v tomto prípade mohli nastať a čo by mohlo pomôcť vyriešiť tretiu výkonnostnú výzvu?
Partitioning - rozdelenie alebo rozdelenie
Typicky je rozdelenie na oddiely nakonfigurované iným spôsobom v každej relačnej databáze, ktorú som uviedol. Každý z nich má svoju vlastnú technológiu, ale vo všeobecnosti sú podobné. Vytvorenie nového oddielu často vedie k určitým problémom.
Oddiely sa zvyčajne konfigurujú v závislosti od „nastavenia“ - množstva údajov, ktoré sa vytvorí za jeden deň. Rozdelenie sa spravidla vydáva za jeden deň, čo je minimum. Pre trendy novej šarže - 1 mesiac.
Hodnoty sa môžu zmeniť, ak je „nastavenie“ veľmi veľké. Ak je malé „nastavenie“ až 5 000 nvps (nové hodnoty za sekundu), stredné je od 5 000 do 25 000, potom veľké je nad 25 000 nv/s. Ide o veľké a veľmi rozsiahle inštalácie, ktoré si vyžadujú starostlivú konfiguráciu databázy.
Pri veľmi veľkých inštaláciách nemusí byť obdobie jedného dňa optimálne. Videl som oddiely MySQL s veľkosťou 40 GB alebo viac za deň. Ide o veľmi veľké množstvo údajov, ktoré môže spôsobiť problémy a je potrebné ich zredukovať.
Čo prináša rozdelenie?
Rozdeľovacie stoly. Často ide o samostatné súbory na disku. Plán dotazov vyberie jeden oddiel optimálnejšie. Rozdelenie na oddiely sa zvyčajne používa podľa rozsahu – to platí aj pre Zabbix. Používame tam „časovú pečiatku“ - čas od začiatku éry. Sú to pre nás bežné čísla. Nastavíte začiatok a koniec dňa – toto je oddiel.
Rýchle odstránenie - DELETE. Vyberie sa jeden súbor/podtabuľka, nie výber riadkov na odstránenie.
Výrazne urýchľuje získavanie dát SELECT - používa jeden alebo viac oddielov, nie celú tabuľku. Ak pristupujete k údajom starým dva dni, získavajú sa z databázy rýchlejšie, pretože do vyrovnávacej pamäte stačí načítať jeden súbor a vrátiť ho, nie veľkú tabuľku.
Mnoho databáz je často tiež zrýchlených INSERT — vloženia do detskej tabuľky.
Časová mierkaDB
Vo verzii 4.2 sme obrátili našu pozornosť na TimescaleDB. Toto je rozšírenie pre PostgreSQL s natívnym rozhraním. Rozšírenie efektívne pracuje s údajmi časových radov, bez straty výhod relačných databáz. TimescaleDB sa tiež rozdeľuje automaticky.
TimescaleDB má koncept hypertable (hypertable), ktoré vytvoríte. Obsahuje kúsky - priečky. Chunky sú automaticky spravované hypertable fragmenty, ktoré neovplyvňujú iné fragmenty. Každý blok má svoj vlastný časový rozsah.
TimescaleDB vs PostgreSQL
TimescaleDB funguje naozaj efektívne. Výrobcovia rozšírenia tvrdia, že používajú presnejší algoritmus spracovania dotazov, najmä inserts . Keď veľkosť vloženia množiny údajov rastie, algoritmus si zachováva konštantný výkon.
Po 200 miliónoch riadkov PostgreSQL zvyčajne začne výrazne klesať a stratí výkon na 0. TimescaleDB vám umožňuje efektívne vkladať „vložky“ pre ľubovoľné množstvo údajov.
Inštalácia
Inštalácia TimescaleDB je pomerne jednoduchá pre akýkoľvek balík. IN všetko je podrobne popísané - závisí to od oficiálnych balíkov PostgreSQL. TimescaleDB je možné zostaviť a zostaviť aj manuálne.
Pre databázu Zabbix jednoducho aktivujeme rozšírenie:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Aktivujete extension a vytvorte ho pre databázu Zabbix. Posledným krokom je vytvorenie hypertabuľky.
Migrácia tabuliek histórie do TimescaleDB
Na to existuje špeciálna funkcia 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
Funkcia má tri parametre. Najprv - tabuľky v databáze, pre ktorý musíte vytvoriť hypertabuľku. druhá - poľa, podľa ktorého treba vytvárať chunk_time_interval — interval segmentov, ktoré sa majú použiť. V mojom prípade je interval jeden deň - 86 400.
Tretí parameter - migrate_data. Ak nastavíte true, potom sa všetky aktuálne údaje prenesú do vopred vytvorených blokov. Sám som to používal migrate_data. Mal som asi 1 TB, čo trvalo vyše hodiny. Dokonca v niektorých prípadoch som počas testovania vymazal historické dáta typov postáv, ktoré neboli potrebné na uloženie, aby som ich nepreniesol.
Posledný krok - UPDATE: in db_extension dať timescaledbaby databáza pochopila, že toto rozšírenie existuje. Zabbix ho aktivuje a správne používa syntax a dotazy do databázy – tie funkcie, ktoré sú potrebné pre TimescaleDB.
Hardvérová konfigurácia
Použil som dva servery. Najprv - Stroj VMware. Je pomerne malý: 20 procesorov Intel® Xeon® CPU E5-2630 v 4 @ 2.20 GHz, 16 GB RAM a 200 GB SSD.
Nainštaloval som naň PostgreSQL 10.8 s OS Debian 10.8-1.pgdg90+1 a súborovým systémom xfs. Všetko som nakonfiguroval minimálne na používanie tejto konkrétnej databázy, mínus to, čo použije samotný Zabbix.
Na tom istom stroji bol server Zabbix, PostgreSQL a zaťažovacích agentov. Mal som 50 aktívnych látok, ktoré som používal LoadableModuleveľmi rýchlo generovať rôzne výsledky: čísla, reťazce. Databázu som naplnil množstvom údajov.
Spočiatku obsahovala konfigurácia 5 000 prvkov údaje na hostiteľa. Takmer každý prvok obsahoval spúšť, aby bol podobný skutočným inštaláciám. V niektorých prípadoch bol spúšťač viac ako jeden. Pre jeden sieťový uzol boli 3 000 – 7 000 spúšťačov.
Interval aktualizácie údajovej položky − 4 7-sekúnd. Samotnú záťaž som reguloval tak, že som použil nielen 50 agentov, ale pridal som ďalších. Taktiež som pomocou dátových prvkov dynamicky upravil záťaž a skrátil interval aktualizácie na 4 s.
PostgreSQL. 35 000 nvps
Moje prvé spustenie na tomto hardvéri bolo na čistom PostgreSQL - 35 tisíc hodnôt za sekundu. Ako vidíte, vkladanie údajov trvá zlomky sekundy - všetko je dobré a rýchle. Jedine, že 200 GB SSD disk sa rýchlo zaplní.
Toto je štandardný panel výkonu servera Zabbix.
Prvý modrý graf predstavuje počet hodnôt za sekundu. Druhý graf vpravo je načítavanie procesov zostavovania. Tretím je načítanie interných procesov zostavovania: synchronizátory histórie a Housekeeper, ktorý tu beží už dosť dlho.
Štvrtý graf ukazuje využitie HistoryCache. Toto je druh vyrovnávacej pamäte pred vložením do databázy. Zelený piaty graf ukazuje využitie ValueCache, to znamená, koľko ValueCache zasiahne spúšťače – to je niekoľko tisíc hodnôt za sekundu.
PostgreSQL. 50 000 nvps
Potom som zvýšil zaťaženie na 50 tisíc hodnôt za sekundu na rovnakom hardvéri.
Pri načítaní z Housekeepera vloženie 10 2 hodnôt trvalo 3-XNUMX sekundy.
Domáca už začína prekážať v práci.
Tretí graf ukazuje, že vo všeobecnosti je zaťaženie traperov a synchronizátorov histórie stále na úrovni 60 %. V štvrtom grafe sa HistoryCache už začína pomerne aktívne napĺňať počas prevádzky Housekeeper. Je plná na 20 %, čo je približne 0,5 GB.
PostgreSQL. 80 000 nvps
Potom som zvýšil zaťaženie na 80 tisíc hodnôt za sekundu. Ide približne o 400 tisíc dátových prvkov a 280 tisíc spúšťačov.
Náklady na načítanie tridsiatich historických synchronizátorov sú už dosť vysoké.
Zvýšil som aj rôzne parametre: synchronizátory histórie, vyrovnávacie pamäte.
Na mojom hardvéri sa zaťaženie synchronizátorov histórie zvýšilo na maximum. HistoryCache sa rýchlo zaplnila dátami - dáta na spracovanie sa nahromadili vo vyrovnávacej pamäti.
Celý ten čas som pozoroval, ako sa využíva procesor, RAM a ďalšie systémové parametre a zistil som, že využitie disku je maximálne.
Dosiahol som využitie maximálne možnosti disku na tomto hardvéri a na tomto virtuálnom stroji. S takouto intenzitou začal PostgreSQL dosť aktívne splachovať dáta a disk už nemal čas na zápis a čítanie.
Druhý server
Vzal som si ďalší server, ktorý už mal 48 procesorov a 128 GB RAM. Vyladil som to - nastavil som na synchronizáciu histórie 60 a dosiahol prijateľný výkon.
V skutočnosti je to už hranica produktivity, kde treba niečo urobiť.
Časová mierkaDB. 80 000 nvps
Mojou hlavnou úlohou je otestovať schopnosti TimescaleDB proti zaťaženiu Zabbix. 80 XNUMX hodnôt za sekundu je veľa, frekvencia zhromažďovania metrík (samozrejme okrem Yandexu) a pomerne veľké „nastavenie“.
V každom grafe je prepad – to je práve migrácia dát. Po zlyhaniach servera Zabbix sa profil načítania synchronizátora histórie veľmi zmenil - trikrát klesol.
TimescaleDB vám umožňuje vkladať dáta takmer 3-krát rýchlejšie a používať menej HistoryCache.
V súlade s tým budete údaje dostávať včas.
Časová mierkaDB. 120 000 nvps
Potom som zvýšil počet dátových prvkov na 500 tisíc Hlavnou úlohou bolo otestovať schopnosti TimescaleDB - dostala som vypočítanú hodnotu 125 tisíc hodnôt za sekundu.
Toto je pracovné „nastavenie“, ktoré môže fungovať dlho. Ale kedze mal disk len 1,5 TB, zaplnil som ho za par dni.
Najdôležitejšie je, že zároveň boli vytvorené nové oddiely TimescaleDB.
Z hľadiska výkonu je to úplne nepostrehnuteľné. Pri vytváraní oddielov napríklad v MySQL je všetko inak. To sa zvyčajne stáva v noci, pretože to blokuje všeobecné vkladanie, prácu s tabuľkami a môže spôsobiť degradáciu služby. Toto nie je prípad TimescaleDB.
Ako príklad uvediem jeden graf z mnohých v komunite. Na obrázku je povolená TimescaleDB, vďaka čomu klesla záťaž na používanie io.weight na procesore. Znížilo sa aj používanie vnútorných procesných prvkov. Navyše ide o obyčajný virtuálny stroj na obyčajných palacinkových diskoch, nie o SSD.
Závery
TimescaleDB je dobré riešenie pre malé „nastavenie“, ktoré ovplyvňujú výkon disku. Umožní vám pokračovať v dobrej práci, kým nebude databáza čo najrýchlejšie migrovaná na hardvér.
TimescaleDB sa ľahko konfiguruje, poskytuje zvýšenie výkonu, dobre spolupracuje so Zabbixom a má výhody oproti PostgreSQL.
Ak používate PostgreSQL a neplánujete ho meniť, odporúčam použite PostgreSQL s rozšírením TimescaleDB v spojení so Zabbixom. Toto riešenie funguje efektívne až po strednú „nastavenie“.
Keď hovoríme „vysoký výkon“, myslíme tým . Nebudete musieť dlho čakať, kým sa dozviete o technológiách a postupoch, ktoré umožňujú službám slúžiť miliónom používateľov. Zoznam na 7. a 8. november sme už zostavili, ale tu možno navrhnúť viac.
Prihláste sa na odber nášho и , v ktorej odhalíme črty pripravovanej konferencie a zistíme, ako z nej vyťažiť maximum.
Zdroj: hab.com