A Zabbix egy megfigyelő rendszer. Mint minden más rendszernek, ez is három fő problémával szembesül az összes megfigyelőrendszer esetében: az adatok gyűjtése és feldolgozása, az előzmények tárolása és tisztítása.
Az adatok fogadásának, feldolgozásának és rögzítésének szakaszai időt vesznek igénybe. Nem sok, de nagy rendszereknél ez nagy késéseket eredményezhet. A tárolási probléma adathozzáférési probléma. Jelentésekhez, ellenőrzésekhez és triggerekhez használják. Az adatelérési késések szintén befolyásolják a teljesítményt. Amikor az adatbázisok növekednek, az irreleváns adatokat törölni kell. Az eltávolítás nehéz művelet, amely bizonyos erőforrásokat is felemészt.
A Zabbixban a gyűjtés és tárolás során fellépő késések problémáit gyorsítótárazás oldja meg: többféle gyorsítótár, gyorsítótár az adatbázisban. A harmadik probléma megoldására a gyorsítótárazás nem alkalmas, ezért a Zabbix TimescaleDB-t használt. Majd ő mesél róla Andrej Gushchin - műszaki támogató mérnök . Andrey több mint 6 éve támogatja a Zabbixet, és közvetlen tapasztalata van a teljesítmény terén.
Hogyan működik a TimescaleDB, milyen teljesítményt tud nyújtani a szokásos PostgreSQL-hez képest? Milyen szerepet játszik a Zabbix a TimescaleDB adatbázisban? Hogyan kezdjem el a nulláról, hogyan költözzünk át a PostgreSQL-ről, és melyik konfiguráció teljesít jobban? Mindezekről a vágás alatt.
Termelékenységi kihívások
Minden megfigyelő rendszer sajátos teljesítménybeli kihívásokkal néz szembe. Ezek közül háromról szólok: az adatgyűjtés és -feldolgozás, a tárolás és az előzmények törlése.
Gyors adatgyűjtés és feldolgozás. Egy jó felügyeleti rendszernek gyorsan kell fogadnia minden adatot, és a trigger kifejezések szerint – a kritériumai szerint – feldolgoznia. A feldolgozás után a rendszernek ezeket az adatokat is gyorsan el kell mentenie az adatbázisba későbbi felhasználás céljából.
Előzmények tárolása. Egy jó megfigyelő rendszernek adatbázisban kell tárolnia az előzményeket, és könnyű hozzáférést kell biztosítania a mérőszámokhoz. Az előzményeket jelentésekben, grafikonokban, triggerekben, küszöbértékekben és számított riasztási adatelemekben kell használni.
Előzmények törlése. Néha eljön a nap, amikor nincs szükség a mutatók tárolására. Miért van szüksége olyan adatokra, amelyeket 5 éve, egy-két hónapja gyűjtöttek: egyes csomópontokat töröltek, egyes gazdagépekre vagy metrikákra már nincs szükség, mert elavultak és már nem gyűjtik őket. Egy jó megfigyelő rendszernek tárolnia kell a múltbeli adatokat, és időről időre törölnie kell azokat, hogy az adatbázis ne növekedjen.
Az elavult adatok törlése kritikus probléma, amely nagyban befolyásolja az adatbázis teljesítményét.
Gyorsítótár a Zabbixban
A Zabbixban az első és a második hívást gyorsítótárazással oldják meg. A RAM az adatok gyűjtésére és feldolgozására szolgál. Tároláshoz - előzmények triggerekben, grafikonokban és számított adatelemekben. Az adatbázis oldalon található néhány gyorsítótár az alapvető kijelölésekhez, például grafikonokhoz.
A gyorsítótár a Zabbix szerver oldalán a következő:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Tekintsük őket részletesebben.
ConfigurationCache
Ez a fő gyorsítótár, ahol a mutatókat, gazdagépeket, adatelemeket, triggereket tároljuk – mindent, ami az előfeldolgozáshoz és az adatgyűjtéshez szükséges.
Mindezt a ConfigurationCache tárolja, hogy ne hozzon létre felesleges lekérdezéseket az adatbázisban. A szerver elindulása után frissítjük ezt a gyorsítótárat, létrehozunk és rendszeresen frissítjük a konfigurációkat.
Adatgyűjtés
A diagram elég nagy, de a lényeg benne van gyűjtők. Ezek különféle „pollerek” - összeszerelési folyamatok. Különböző típusú összeállításokért felelősek: SNMP-n, IPMI-n keresztül gyűjtenek adatokat, és mindezt továbbítják a PreProcessing-nek.
A gyűjtők narancssárga körvonalai vannak.
A Zabbix kiszámította az összesítési tételeket, amelyek az ellenőrzések összesítéséhez szükségesek. Ha megvannak, akkor közvetlenül a ValueCache-ből kérjük le az adatokat.
Előfeldolgozás HistoryCache
Minden gyűjtő a ConfigurationCache-t használja a feladatok fogadására. Ezután áthelyezik őket a PreProcessingba.
Az PreProcessing a ConfigurationCache segítségével fogadja az előfeldolgozási lépéseket. Ezeket az adatokat különféle módokon dolgozza fel.
Az adatok PreProcessing segítségével történő feldolgozása után a HistoryCache-be mentjük feldolgozás céljából. Ezzel véget ér az adatgyűjtés, és továbblépünk a Zabbix fő folyamatához - történelem szinkronizáló, mivel ez egy monolitikus építészet.
Megjegyzés: Az előfeldolgozás meglehetősen nehéz művelet. A 4.2-es verzióval átkerült a proxyra. Ha nagyon nagy Zabbixed van, sok adatelemmel és gyűjtési gyakorisággal, akkor ez nagyban megkönnyíti a munkát.
ValueCache, előzmények és trendek gyorsítótár
Az előzmények szinkronizálása az a fő folyamat, amely atomosan feldolgozza az egyes adatelemeket, azaz minden értéket.
Az előzmények szinkronizálója értékeket vesz a HistoryCache-ből, és ellenőrzi a konfigurációt a számításokhoz szükséges triggerek megléte érdekében. Ha léteznek, kiszámolja.
Az előzmények szinkronizálója létrehoz egy eseményt, eszkalációt riasztások létrehozásához, ha a konfiguráció megköveteli, és rögzíti a rekordokat. Ha vannak triggerek a későbbi feldolgozáshoz, akkor ezt az értéket a ValueCache-ben tárolja, hogy ne férhessen hozzá az előzménytáblázathoz. Így töltődik meg a ValueCache olyan adatokkal, amelyek szükségesek a triggerek és a számított elemek kiszámításához.
Az előzmények szinkronizálója minden adatot az adatbázisba ír, és az ír lemezre. A feldolgozási folyamat itt ér véget.
Gyorsítótárazás az adatbázisban
Az adatbázis oldalán különféle gyorsítótárak találhatók, amikor az eseményekről grafikonokat vagy jelentéseket szeretne megtekinteni:
Innodb_buffer_poola MySQL oldalon;shared_buffersa PostgreSQL oldalon;effective_cache_sizeaz Oracle oldalon;shared_poola DB2 oldalon.
Sok más gyorsítótár is létezik, de ezek a legfontosabbak minden adatbázisnál. Lehetővé teszik a lekérdezéshez gyakran szükséges adatok RAM-ban való tárolását. Ehhez saját technológiájuk van.
Az adatbázis teljesítménye kritikus
A Zabbix szerver folyamatosan adatokat gyűjt és ír. Újraindításkor az előzményekből is beolvas, hogy kitöltse a ValueCache-t. Szkripteket és jelentéseket használ Zabbix API, amely webes felületre épül. A Zabbix API hozzáfér az adatbázishoz, és lekéri a szükséges adatokat a grafikonokhoz, jelentésekhez, eseménylistákhoz és a legújabb problémákhoz.
A vizualizációhoz - grafana. Ez egy népszerű megoldás a felhasználók körében. Közvetlenül tud kéréseket küldeni a Zabbix API-n keresztül és az adatbázisba, és bizonyos versenyt hoz létre az adatok fogadásáért. Ezért az adatbázis finomabb és jobb hangolása szükséges ahhoz, hogy az eredmények és a tesztelés gyors legyen.
Házvezetőnő
A Zabbix harmadik teljesítménybeli kihívása a történelem törlése a Housekeeper segítségével. Minden beállítást követ - az adatelemek azt jelzik, hogy mennyi ideig kell tárolni a változások (trendek) dinamikáját napokban.
A TrendsCache-t menet közben számítjuk ki. Amikor az adatok megérkeznek, egy órán keresztül összesítjük és táblázatokba rögzítjük a trendváltozások dinamikájához.
A Housekeeper elindítja és törli az információkat az adatbázisból a szokásos „kiválasztások” segítségével. Ez nem mindig hatékony, amint az a belső folyamatok teljesítménygrafikonjaiból is látható.
A piros grafikon azt mutatja, hogy a History syncer folyamatosan foglalt. A tetején lévő narancssárga grafikon a Housekeeper, amely folyamatosan fut. Megvárja, amíg az adatbázis törli az összes általa megadott sort.
Mikor kell kikapcsolni a Házvezetőnőt? Például van egy „Tételazonosító”, és bizonyos időn belül törölnie kell az utolsó 5 ezer sort. Természetesen ez index alapján történik. De általában az adatkészlet nagyon nagy, és az adatbázis továbbra is olvassa a lemezről, és a gyorsítótárba helyezi. Ez mindig nagyon költséges művelet az adatbázis számára, és az adatbázis méretétől függően teljesítményproblémákhoz vezethet.
A házvezetőnő könnyen letiltható. A webes felületen van egy beállítás az „Általános adminisztráció” menüpontban a Housekeeper számára. Letiltjuk a belső Háztartást a belső trendelőzményekhez, és a továbbiakban nem kezeli.
A házvezetőnőt kikapcsolták, a grafikonokat kiegyenlítették - milyen problémák lehetnek ebben az esetben, és mi segíthet a harmadik teljesítményi kihívás megoldásában?
Partícionálás - particionálás vagy particionálás
A particionálás általában eltérő módon van konfigurálva minden felsorolt relációs adatbázisban. Mindegyiknek megvan a saját technológiája, de általában hasonlóak. Egy új partíció létrehozása gyakran bizonyos problémákhoz vezet.
A partíciókat általában a „beállítás” - az egy nap alatt létrehozott adatmennyiség - függvényében konfigurálják. A particionálást általában egy nap alatt adják ki, ez a minimum. Egy új tétel trendjeihez - 1 hónap.
Az értékek változhatnak, ha a „beállítás” nagyon nagy. Ha egy kis „beállítás” legfeljebb 5 000 nvps (új érték másodpercenként), a közepes 5 000 és 25 000 között van, akkor a nagy 25 000 nvps felett van. Ezek nagy és nagyon nagy telepítések, amelyek az adatbázis gondos konfigurálását igénylik.
Nagyon nagy telepítéseknél előfordulhat, hogy egy napos időszak nem optimális. Naponta 40 GB-os vagy nagyobb MySQL-partíciókat láttam. Ez egy nagyon nagy mennyiségű adat, amely problémákat okozhat, és csökkenteni kell.
Mit ad a particionálás?
Elválasztó táblák. Ezek gyakran külön fájlok a lemezen. A lekérdezési terv egy partíciót választ ki optimálisabban. Általában a partícionálást tartományonként használják – ez a Zabbix esetében is igaz. Ott „időbélyeget” használunk – a korszak kezdete óta eltelt idő. Ezek nálunk hétköznapi számok. Beállítja a nap elejét és végét – ez egy partíció.
Gyors eltávolítás - DELETE. Egy fájl/altábla van kiválasztva, nem pedig a törlendő sorok kiválasztása.
Jelentősen felgyorsítja az adatlekérést SELECT - egy vagy több partíciót használ a teljes tábla helyett. Ha két napos adatokhoz fér hozzá, akkor a rendszer gyorsabban kéri le az adatbázisból, mert csak egy fájlt kell betöltenie a gyorsítótárba, és vissza kell adnia, nem egy nagy táblát.
Gyakran sok adatbázist is felgyorsítanak INSERT — beillesztések a gyermektáblázatba.
IdőskálaDB
A 4.2-es verzió esetében figyelmünket a TimescaleDB-re fordítottuk. Ez a PostgreSQL kiterjesztése natív felülettel. A bővítmény hatékonyan működik az idősoros adatokkal anélkül, hogy elveszítené a relációs adatbázisok előnyeit. A TimescaleDB szintén automatikusan particionál.
A TimescaleDB-nek van egy koncepciója hipertabil (hipertábilis), amelyet Ön létrehoz. Tartalmaz darabokat - válaszfalak. A darabok automatikusan kezelt hypertable töredékek, amelyek nincsenek hatással más töredékekre. Minden darabnak megvan a maga időtartománya.
TimescaleDB vs PostgreSQL
A TimescaleDB nagyon hatékonyan működik. A bővítmény gyártói azt állítják, hogy korrektebb lekérdezés-feldolgozó algoritmust használnak, különösen inserts . Az adatkészlet-beszúrás méretének növekedésével az algoritmus állandó teljesítményt tart fenn.
200 millió sor után a PostgreSQL rendszerint jelentősen megereszkedik, és teljesítménye 0-ra csökken. A TimescaleDB lehetővé teszi, hogy hatékonyan illesszen be „beszúrásokat” tetszőleges mennyiségű adathoz.
Telepítés
A TimescaleDB telepítése minden csomag esetében meglehetősen egyszerű. BAN BEN minden részletesen le van írva - ez a hivatalos PostgreSQL-csomagoktól függ. A TimescaleDB manuálisan is felépíthető és lefordítható.
A Zabbix adatbázishoz egyszerűen aktiváljuk a kiterjesztést:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Aktiválod extension és hozza létre a Zabbix adatbázishoz. Az utolsó lépés egy hipertábla létrehozása.
Előzménytáblázatok migrálása a TimescaleDB-be
Ehhez van egy speciális funkció 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
A függvénynek három paramétere van. Első - táblázat az adatbázisban, amelyhez létre kell hozni egy hipertáblát. Második - mező, mely szerint létre kell hozni chunk_time_interval — a használandó partíciódarabok intervalluma. Az én esetemben az intervallum egy nap - 86 400.
Harmadik paraméter - migrate_data. Ha beállítod true, akkor az összes aktuális adat átkerül az előre létrehozott darabokba. magam használtam migrate_data. Körülbelül 1 TB-m volt, ami több mint egy óráig tartott. Néhány esetben a tesztelés során is töröltem a tároláshoz nem szükséges karaktertípusok történeti adatait, hogy ne vigyem át azokat.
Utolsó lépés - UPDATE: nál nél db_extension tegye timescaledbhogy az adatbázis megértse, hogy ez a kiterjesztés létezik. A Zabbix aktiválja, és helyesen használja a szintaxist és az adatbázis lekérdezéseit – azokat a szolgáltatásokat, amelyek a TimescaleDB számára szükségesek.
Hardver konfiguráció
Két szervert használtam. Első - VMware gép. Elég kicsi: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20 GHz-es processzor, 16 GB RAM és 200 GB-os SSD.
Telepítettem rá a PostgreSQL 10.8-at Debian 10.8-1.pgdg90+1 operációs rendszerrel és xfs fájlrendszerrel. Mindent minimálisan úgy konfiguráltam, hogy ezt az adatbázist használja, leszámítva azt, amit maga a Zabbix fog használni.
Ugyanezen a gépen volt egy Zabbix szerver, PostgreSQL ill rakodó ügynökök. 50 hatóanyagot használtam LoadableModulehogy nagyon gyorsan generáljon különböző eredményeket: számokat, karakterláncokat. Nagyon sok adattal töltöttem fel az adatbázist.
Kezdetben a konfiguráció tartalmazott 5 elem adatok állomásonként. Szinte minden elem tartalmazott egy triggert, hogy hasonló legyen a valódi telepítésekhez. Egyes esetekben több trigger is volt. Egy hálózati csomóponthoz voltak 3-000 trigger.
Adatelem frissítési időköz – 4-7 másodperc. Magát a terhelést úgy szabályoztam, hogy nem csak 50 szert használtam, hanem még több hozzáadásával. Illetve adatelemek segítségével dinamikusan beállítottam a terhelést és 4 s-ra csökkentettem a frissítési intervallumot.
PostgreSQL. 35 000 nvps
Az első futtatásom ezen a hardveren tiszta PostgreSQL-en volt - 35 ezer érték másodpercenként. Mint látható, az adatok beszúrása a másodperc töredékeibe telik – minden jó és gyors. Az egyetlen dolog, hogy egy 200 GB-os SSD lemez gyorsan megtelik.
Ez egy szabványos Zabbix szerver teljesítmény-műszerfal.
Az első kék grafikon a másodpercenkénti értékek száma. A jobb oldali második grafikon az összeállítási folyamatok betöltését mutatja. A harmadik a belső összeállítási folyamatok betöltése: a történelemszinkronizálók és a Housekeeper, ami már jó ideje fut itt.
A negyedik grafikon a HistoryCache használatát mutatja. Ez egyfajta puffer az adatbázisba való beillesztés előtt. A zöld ötödik grafikon a ValueCache-használatot mutatja, vagyis azt, hogy hány ValueCache-találat a triggerekhez – ez másodpercenként több ezer érték.
PostgreSQL. 50 000 nvps
Ezután a terhelést másodpercenként 50 ezer értékre növeltem ugyanazon a hardveren.
A Housekeeper-ből történő betöltéskor a 10 ezer érték beillesztése 2-3 másodpercig tartott.
A házvezetőnő már kezdi zavarni a munkát.
A harmadik grafikon azt mutatja, hogy általában véve a trapperek és a történelemszinkronizálók terhelése még mindig 60%. A negyedik grafikonon a HistoryCache már elég aktívan kezd feltöltődni a Housekeeper működése közben. 20%-a tele van, ami kb 0,5 GB.
PostgreSQL. 80 000 nvps
Ezután a terhelést másodpercenként 80 ezer értékre növeltem. Ez körülbelül 400 ezer adatelem és 280 ezer trigger.
Harminc előzmény-szinkron betöltési költsége már elég magas.
Különféle paramétereket is növeltem: előzményszinkronizálók, gyorsítótárak.
A hardveremen a történelem szinkronizálók terhelése a maximumra nőtt. A HistoryCache gyorsan megtelt adatokkal – a feldolgozásra szánt adatok felhalmozódtak a pufferben.
Ezalatt végig megfigyeltem a processzor, a RAM és egyéb rendszerparaméterek használatát, és azt tapasztaltam, hogy a lemezkihasználás a maximumon van.
A használatot elértem maximális lemezképesség ezen a hardveren és ezen a virtuális gépen. Ilyen intenzitással a PostgreSQL meglehetősen aktívan elkezdte kiüríteni az adatokat, és a lemeznek már nem volt ideje írni és olvasni.
Második szerver
Vettem egy másik szervert, amin már 48 processzor és 128 GB RAM volt. Behangoltam - 60-as történeti szinkronizálásra állítottam, és elfogadható teljesítményt értem el.
Valójában ez már a termelékenység határa, ahol tenni kell valamit.
TimescaleDB. 80 nvps
Fő feladatom a TimescaleDB képességeinek tesztelése Zabbix terhelés ellenében. A másodpercenkénti 80 ezer érték sok, a mutatók gyűjtésének gyakorisága (természetesen a Yandex kivételével) és egy meglehetősen nagy „beállítás”.
Minden grafikonon van egy zuhanás – pontosan ez az adatmigráció. A Zabbix szerver meghibásodásai után az előzményszinkronizáló betöltési profilja sokat változott - háromszor esett le.
A TimescaleDB lehetővé teszi az adatok közel háromszor gyorsabb beszúrását és kevesebb HistoryCache használatát.
Ennek megfelelően időben megkapja az adatokat.
TimescaleDB. 120 nvps
Ezután 500 ezerre növeltem az adatelemek számát. A fő feladat a TimescaleDB képességeinek tesztelése volt - 125 ezer értéket kaptam másodpercenként.
Ez egy működő „beállítás”, amely hosszú ideig működhet. De mivel a lemezem csak 1,5 TB volt, pár nap alatt feltöltöttem.
A legfontosabb dolog az, hogy ezzel egyidőben új TimescaleDB partíciók jöttek létre.
Ez a teljesítmény szempontjából teljesen észrevehetetlen. Amikor például a MySQL-ben partíciókat hoz létre, minden más. Ez általában éjszaka történik, mert blokkolja az általános beszúrást, a táblákkal való munkát, és szolgáltatásromlást idézhet elő. A TimescaleDB esetében nem ez a helyzet.
Példaként mutatok egy grafikont a közösség sok tagjából. A képen a TimescaleDB engedélyezve van, ennek köszönhetően csökkent a processzor io.weight használatának terhelése. A belső folyamatelemek felhasználása is csökkent. Ráadásul ez egy közönséges virtuális gép közönséges palacsintalemezeken, nem pedig SSD.
Álláspontja
A TimescaleDB jó megoldás kis "beállításokhoz", amelyek befolyásolják a lemez teljesítményét. Lehetővé teszi, hogy továbbra is jól működjön mindaddig, amíg az adatbázis a lehető leggyorsabban át nem kerül a hardverre.
A TimescaleDB könnyen konfigurálható, teljesítménynövekedést biztosít, jól működik a Zabbix és a előnyei vannak a PostgreSQL-lel szemben.
Ha PostgreSQL-t használsz, és nem tervezed megváltoztatni, ajánlom használja a PostgreSQL-t a TimescaleDB kiterjesztéssel a Zabbix-szal együtt. Ez a megoldás közepes "beállításig" hatékonyan működik.
Amikor azt mondjuk, hogy „nagy teljesítmény”, ezt értjük . Nem kell sokáig várnia, hogy megismerje azokat a technológiákat és gyakorlatokat, amelyek lehetővé teszik, hogy a szolgáltatások több millió felhasználót szolgáljanak ki. Lista november 7-re és 8-ra már összeállítottuk, de itt több is javasolható.
Iratkozzon fel a mi и , amelyben feltárjuk a közelgő konferencia jellemzőit, és megtudjuk, hogyan hozhatja ki a legtöbbet belőle.
Forrás: will.com