Zabbix je nadzorni sistem. Kot vsak drug sistem se sooča s tremi glavnimi težavami vseh nadzornih sistemov: zbiranje in obdelava podatkov, shranjevanje zgodovine in njeno čiščenje.
Faze prejemanja, obdelave in beleženja podatkov zahtevajo čas. Ni veliko, toda za velik sistem lahko to povzroči velike zamude. Težava pri shranjevanju je težava pri dostopu do podatkov. Uporabljajo se za poročila, preverjanja in sprožitve. Na zmogljivost vplivajo tudi zamude pri dostopu do podatkov. Ko se zbirke podatkov povečajo, je treba nepomembne podatke izbrisati. Odstranjevanje je težka operacija, ki požre tudi nekaj sredstev.
Težave z zamudami med zbiranjem in shranjevanjem v Zabbixu rešuje predpomnjenje: več vrst predpomnilnikov, predpomnjenje v podatkovni bazi. Za rešitev tretje težave predpomnjenje ni primerno, zato je Zabbix uporabil TimescaleDB. Povedal vam bo o tem Andrej Guščin - inženir tehnične podpore . Andrey podpira Zabbix že več kot 6 let in ima neposredne izkušnje z delovanjem.
Kako deluje TimescaleDB, kakšno zmogljivost lahko zagotovi v primerjavi z običajnim PostgreSQL? Kakšno vlogo igra Zabbix za bazo podatkov TimescaleDB? Kako začeti iz nič in kako migrirati iz PostgreSQL in katera konfiguracija ima boljšo zmogljivost? O vsem tem pod rezom.
Izzivi produktivnosti
Vsak nadzorni sistem se sooča s posebnimi izzivi pri delovanju. Govoril bom o treh: zbiranje in obdelava podatkov, shranjevanje in brisanje zgodovine.
Hitro zbiranje in obdelava podatkov. Dober nadzorni sistem bi moral hitro sprejemati vse podatke in jih obdelovati glede na prožilne izraze – po svojih kriterijih. Po obdelavi mora sistem tudi te podatke hitro shraniti v bazo za kasnejšo uporabo.
Shranjevanje zgodovine. Dober nadzorni sistem bi moral zgodovino shranjevati v bazi podatkov in omogočati enostaven dostop do meritev. Zgodovina je potrebna za uporabo v poročilih, grafih, sprožilcih, pragovih in izračunanih opozorilnih podatkih.
Brisanje zgodovine. Včasih pride dan, ko vam meritev ni treba shranjevati. Zakaj potrebujete podatke, ki so bili zbrani pred 5 leti, mesecem ali dvema: nekatera vozlišča so bila izbrisana, nekateri gostitelji ali metrike niso več potrebni, ker so zastareli in se ne zbirajo več. Dober nadzorni sistem bi moral shranjevati zgodovinske podatke in jih občasno brisati, da se zbirka podatkov ne poveča.
Čiščenje zastarelih podatkov je kritična težava, ki močno vpliva na zmogljivost baze podatkov.
Predpomnjenje v Zabbixu
V Zabbixu sta prvi in drugi klic rešena s predpomnjenjem. RAM se uporablja za zbiranje in obdelavo podatkov. Za shranjevanje - zgodovina v sprožilcih, grafih in izračunanih podatkovnih elementih. Na strani baze podatkov je nekaj predpomnjenja za osnovne izbire, na primer grafe.
Predpomnjenje na strani samega strežnika Zabbix je:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Razmislite o njih bolj podrobno.
ConfigurationCache
To je glavni predpomnilnik, kjer shranjujemo metrike, gostitelje, podatkovne postavke, sprožilce – vse, kar potrebujemo za predprocesiranje in zbiranje podatkov.
Vse to je shranjeno v ConfigurationCache, da ne ustvarja nepotrebnih poizvedb v bazi podatkov. Po zagonu strežnika posodobimo ta predpomnilnik, ustvarimo in občasno posodabljamo konfiguracije.
Zbiranje podatkov
Diagram je precej velik, vendar je glavna stvar v njem zbiralci. To so različni “pollerji” - montažni procesi. Odgovorni so za različne vrste montaž: zbirajo podatke preko SNMP, IPMI in vse skupaj prenesejo v PreProcessing.
Zbiralniki so obrobljeni z oranžno barvo.
Zabbix je izračunal elemente združevanja, ki so potrebni za združevanje pregledov. Če jih imamo, pridobimo podatke zanje neposredno iz predpomnilnika vrednosti.
Predobdelava predpomnilnika zgodovine
Vsi zbiralniki uporabljajo ConfigurationCache za prejemanje opravil. Nato jih prenesejo v Preprocessing.
Preprocessing uporablja ConfigurationCache za prejemanje korakov PreProcessing. Te podatke obdeluje na različne načine.
Po obdelavi podatkov s funkcijo PreProcessing jih shranimo v HistoryCache za obdelavo. S tem se zbiranje podatkov konča in preidemo na glavni proces v Zabbixu - sinhronizator zgodovine, saj gre za monolitno arhitekturo.
Opomba: Predobdelava je precej težka operacija. Z različico 4.2 je bil premaknjen na proxy. Če imate zelo velik Zabbix z velikim številom podatkovnih elementov in pogostostjo zbiranja, potem to močno olajša delo.
ValueCache, predpomnilnik zgodovine in trendov
Sinhronizator zgodovine je glavni proces, ki atomsko obdeluje vsak podatkovni element, to je vsako vrednost.
Sinhronizator zgodovine vzame vrednosti iz HistoryCache in preveri konfiguracijo za prisotnost sprožilcev za izračune. Če obstajajo, izračuna.
Sinhronizator zgodovine ustvari dogodek, stopnjevanje za ustvarjanje opozoril, če to zahteva konfiguracija, in zapise. Če obstajajo sprožilci za naknadno obdelavo, shrani to vrednost v ValueCache, da ne dostopa do tabele zgodovine. Tako se ValueCache napolni s podatki, ki so potrebni za izračun sprožilcev in izračunanih elementov.
Sinhronizator zgodovine zapiše vse podatke v bazo podatkov, ta pa na disk. Postopek obdelave se tukaj konča.
Predpomnjenje v bazi podatkov
Na strani baze podatkov so na voljo različni predpomnilniki, ko si želite ogledati grafe ali poročila o dogodkih:
Innodb_buffer_poolna strani MySQL;shared_buffersna strani PostgreSQL;effective_cache_sizena strani Oracle;shared_poolna strani DB2.
Obstaja veliko drugih predpomnilnikov, vendar so ti glavni za vse zbirke podatkov. Omogočajo shranjevanje podatkov v RAM, ki so pogosto potrebni za poizvedbe. Za to imajo svoje tehnologije.
Učinkovitost baze podatkov je kritična
Strežnik Zabbix nenehno zbira podatke in jih zapisuje. Ko se znova zažene, bere tudi iz zgodovine, da zapolni ValueCache. Uporablja skripte in poročila Zabbix API, ki je zgrajen na spletnem vmesniku. Zabbix API dostopa do baze podatkov in pridobi potrebne podatke za grafe, poročila, sezname dogodkov in najnovejše težave.
Za vizualizacijo - grafana. To je priljubljena rešitev med našimi uporabniki. Lahko neposredno pošilja zahteve prek Zabbix API in v bazo podatkov ter ustvarja določeno konkurenco za prejemanje podatkov. Zato je potrebna natančnejša in boljša nastavitev podatkovne baze, da bo ustrezala hitri dostavi rezultatov in testiranju.
Gospodinja
Tretji izziv glede zmogljivosti v Zabbixu je brisanje zgodovine s pomočjo Housekeeperja. Sledi vsem nastavitvam - podatkovni elementi kažejo, kako dolgo naj se hrani dinamika sprememb (trendov) v dnevih.
TrendsCache izračunavamo sproti. Ko prispejo podatki, jih eno uro agregiramo in beležimo v tabele za dinamiko sprememb trenda.
Housekeeper zažene in izbriše podatke iz podatkovne baze z običajnimi “selecti”. To ni vedno učinkovito, kar je razvidno iz grafov uspešnosti notranjih procesov.
Rdeči graf prikazuje, da je sinhronizator zgodovine nenehno zaseden. Oranžni graf na vrhu je Housekeeper, ki se nenehno izvaja. Počaka, da zbirka podatkov izbriše vse vrstice, ki jih je določil.
Kdaj morate onemogočiti Housekeeper? Na primer, obstaja "ID predmeta" in v določenem času morate izbrisati zadnjih 5 tisoč vrstic. Seveda se to zgodi po indeksu. Toda običajno je nabor podatkov zelo velik in zbirka podatkov še vedno bere z diska in ga shrani v predpomnilnik. To je vedno zelo draga operacija za bazo podatkov in lahko, odvisno od velikosti baze podatkov, povzroči težave z zmogljivostjo.
Housekeeper je enostavno onemogočiti. V spletnem vmesniku je nastavitev v »Splošni administraciji« za Housekeeper. Onemogočimo notranje gospodinjstvo za notranjo zgodovino trendov in ga ne upravlja več.
Housekeeper je bil izklopljen, grafi so izravnani - kakšne težave bi lahko bile v tem primeru in kaj bi lahko pomagalo rešiti tretji izziv zmogljivosti?
Pregrajevanje - pregrajevanje ali pregrajevanje
Običajno je particioniranje konfigurirano na drugačen način za vsako relacijsko bazo podatkov, ki sem jo navedel. Vsak ima svojo tehnologijo, vendar so si na splošno podobni. Ustvarjanje nove particije pogosto povzroči določene težave.
Običajno so particije konfigurirane glede na "nastavitev" - količino podatkov, ustvarjenih v enem dnevu. Praviloma se particija izda v enem dnevu, to je minimum. Za trende nove serije - 1 mesec.
Vrednosti se lahko spremenijo, če je "nastavitev" zelo velika. Če je majhna "nastavitev" do 5 nvps (nove vrednosti na sekundo), srednja je od 000 do 5, potem je velika nad 000 nvps. To so velike in zelo velike namestitve, ki zahtevajo skrbno konfiguracijo baze podatkov.
Pri zelo velikih napravah obdobje enega dneva morda ni optimalno. Videl sem particije MySQL s 40 GB ali več na dan. To je zelo velika količina podatkov, ki lahko povzroči težave in jih je treba zmanjšati.
Kaj daje particioniranje?
Predelne mize. Pogosto so to ločene datoteke na disku. Načrt poizvedbe izbere eno particijo bolj optimalno. Običajno se particioniranje uporablja glede na obseg - to velja tudi za Zabbix. Tam uporabljamo "časovni žig" - čas od začetka dobe. To so za nas običajne številke. Nastavite začetek in konec dneva - to je particija.
Hitra odstranitev - DELETE. Izbrana je ena datoteka/podtabela namesto izbora vrstic za brisanje.
Bistveno pospeši pridobivanje podatkov SELECT - uporablja eno ali več particij namesto celotne tabele. Če dostopate do podatkov, ki so stari dva dni, se hitreje pridobijo iz baze podatkov, ker morate v predpomnilnik naložiti samo eno datoteko in jo vrniti, ne pa velike tabele.
Pogosto so številne podatkovne baze tudi pospešene INSERT — vstavitve v podrejeno tabelo.
Časovni okvirDB
Za različico 4.2 smo pozornost usmerili na TimescaleDB. To je razširitev za PostgreSQL z izvornim vmesnikom. Razširitev učinkovito deluje s podatki časovnih vrst, ne da bi pri tem izgubila prednosti relacijskih baz podatkov. TimescaleDB tudi samodejno particionira.
TimescaleDB ima koncept hipertabela (hipertabelo), ki jo ustvarite. Vsebuje kosi - predelne stene. Kosi so samodejno upravljani fragmenti hipertabel, ki ne vplivajo na druge fragmente. Vsak kos ima svoj časovni razpon.
TimescaleDB proti PostgreSQL
TimescaleDB deluje zelo učinkovito. Proizvajalci razširitve trdijo, da uporabljajo pravilnejši algoritem za obdelavo poizvedb, zlasti inserts . Ko velikost vstavljenega nabora podatkov raste, algoritem ohranja konstantno zmogljivost.
Po 200 milijonih vrstic PostgreSQL običajno začne znatno padati in izgubi zmogljivost na 0. TimescaleDB vam omogoča učinkovito vstavljanje »vložkov« za poljubno količino podatkov.
Namestitev
Namestitev TimescaleDB je dokaj enostavna za kateri koli paket. IN vse je podrobno opisano - odvisno od uradnih paketov PostgreSQL. TimescaleDB je mogoče zgraditi in prevesti tudi ročno.
Za zbirko podatkov Zabbix preprosto aktiviramo razširitev:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Aktiviraš extension in ga ustvarite za bazo podatkov Zabbix. Zadnji korak je ustvariti hipertabelo.
Selitev zgodovinskih tabel v TimescaleDB
Za to obstaja posebna funkcija 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
Funkcija ima tri parametre. prvi - tabela v bazi podatkov, za kar morate ustvariti hipertabelo. drugi - polje, po katerem morate ustvariti chunk_time_interval — interval razdelitvenih kosov, ki se bodo uporabili. V mojem primeru je interval en dan - 86.
Tretji parameter - migrate_data. Če nastavite true, potem se vsi trenutni podatki prenesejo v vnaprej ustvarjene kose. Sam sem ga uporabljal migrate_data. Imel sem približno 1 TB, kar je trajalo več kot eno uro. Tudi v nekaterih primerih sem med testiranjem izbrisal zgodovinske podatke tipov znakov, ki niso bili potrebni za shranjevanje, da jih ne bi prenesel.
Zadnji korak - UPDATE: ob db_extension postaviti timescaledbtako da baza podatkov razume, da ta razširitev obstaja. Zabbix ga aktivira in pravilno uporablja sintakso in poizvedbe v bazi podatkov - tiste funkcije, ki so potrebne za TimescaleDB.
Konfiguracija strojne opreme
Uporabil sem dva strežnika. prvi - Stroj VMware. Je precej majhen: 20 procesorjev Intel® Xeon® CPU E5-2630 v 4 @ 2.20 GHz, 16 GB RAM-a in 200 GB SSD.
Nanj sem namestil PostgreSQL 10.8 z OS Debian 10.8-1.pgdg90+1 in datotečnim sistemom xfs. Vse sem minimalno konfiguriral za uporabo te posebne baze podatkov, brez tistega, kar bo uporabljal sam Zabbix.
Na istem stroju je bil strežnik Zabbix, PostgreSQL in sredstva za obremenitev. Imel sem 50 aktivnih učinkovin, ki so jih uporabljali LoadableModuleza zelo hitro ustvarjanje različnih rezultatov: številk, nizov. Bazo sem napolnil z veliko podatki.
Sprva je konfiguracija vsebovala 5 elementov podatkov na gostitelja. Skoraj vsak element je vseboval sprožilec, da bi bil podoben pravim instalacijam. V nekaterih primerih je bilo več kot en sprožilec. Za eno omrežno vozlišče je bilo 3-000 sprožilcev.
Interval posodobitve podatkovne postavke − 4-7 sekund. Samo obremenitev sem uravnaval tako, da sem uporabil ne samo 50 sredstev, ampak jih dodal še več. Prav tako sem z uporabo podatkovnih elementov dinamično prilagodil obremenitev in zmanjšal interval posodabljanja na 4 s.
PostgreSQL. 35 nvps
Moj prvi zagon na tej strojni opremi je bil na čistem PostgreSQL - 35 tisoč vrednosti na sekundo. Kot lahko vidite, vstavljanje podatkov traja delčke sekunde - vse je dobro in hitro. Edino, da se 200 GB SSD disk hitro napolni.
To je standardna nadzorna plošča zmogljivosti strežnika Zabbix.
Prvi modri graf je število vrednosti na sekundo. Drugi graf na desni je nalaganje gradbenih procesov. Tretji je nalaganje notranjih gradbenih procesov: history syncers in Housekeeper, ki se tukaj izvaja že kar nekaj časa.
Četrti graf prikazuje uporabo predpomnilnika HistoryCache. To je neke vrste medpomnilnik pred vstavljanjem v bazo podatkov. Zeleni peti graf prikazuje uporabo ValueCache, to je, koliko zadetkov ValueCache za sprožilce - to je več tisoč vrednosti na sekundo.
PostgreSQL. 50 nvps
Nato sem povečal obremenitev na 50 tisoč vrednosti na sekundo na isti strojni opremi.
Pri nalaganju iz Housekeeperja je vstavljanje 10 tisoč vrednosti trajalo 2-3 sekunde.
Gospodinja se že začenja vmešavati v delo.
Tretji graf kaže, da je na splošno obremenitev lovilnikov in sinhronizatorjev zgodovine še vedno 60-odstotna. V četrtem grafu se HistoryCache med delovanjem Housekeeperja že precej aktivno polni. Zapolnjen je 20%, kar je približno 0,5 GB.
PostgreSQL. 80 nvps
Nato sem obremenitev povečal na 80 tisoč vrednosti na sekundo. To je približno 400 tisoč podatkovnih elementov in 280 tisoč sprožilcev.
Stroški nalaganja tridesetih sinhronizatorjev zgodovine so že precej visoki.
Povečal sem tudi različne parametre: sinhronizatorje zgodovine, predpomnilnike.
Na moji strojni opremi se je nalaganje sinhronizatorjev zgodovine povečalo na maksimum. HistoryCache se je hitro napolnil s podatki - podatki za obdelavo so se nabrali v medpomnilniku.
Ves ta čas sem opazoval porabo procesorja, RAM-a in drugih sistemskih parametrov in ugotovil, da je izkoriščenost diska največja.
Uporabo sem dosegel največje zmogljivosti diska na tej strojni opremi in na tem virtualnem stroju. S tako intenzivnostjo je PostgreSQL začel precej aktivno izpirati podatke in disk ni imel več časa za pisanje in branje.
Drugi strežnik
Vzel sem drug strežnik, ki je že imel 48 procesorjev in 128 GB RAM-a. Uglasil sem ga – nastavil na 60 zgodovinskih sinhronizatorjev in dosegel sprejemljivo zmogljivost.
Pravzaprav je to že meja produktivnosti, kjer je treba nekaj narediti.
TimescaleDB. 80 nvps
Moja glavna naloga je preizkusiti zmogljivosti TimescaleDB glede na obremenitev Zabbix. 80 tisoč vrednosti na sekundo je veliko, pogostost zbiranja meritev (razen za Yandex, seveda) in precej velika "nastavitev".
V vsakem grafu je padec – prav to je selitev podatkov. Po okvarah v strežniku Zabbix se je profil nalaganja sinhronizatorja zgodovine zelo spremenil - padel je trikrat.
TimescaleDB omogoča skoraj 3-krat hitrejše vstavljanje podatkov in manjšo uporabo predpomnilnika HistoryCache.
V skladu s tem boste podatke prejeli pravočasno.
TimescaleDB. 120 nvps
Nato sem povečal število podatkovnih elementov na 500 tisoč.Glavna naloga je bila preizkusiti zmogljivosti TimescaleDB - prejel sem izračunano vrednost 125 tisoč vrednosti na sekundo.
To je delujoča "nastavitev", ki lahko deluje dolgo časa. Ker pa je imel moj disk samo 1,5 TB, sem ga napolnil v parih dneh.
Najpomembneje je, da so bile hkrati ustvarjene nove particije TimescaleDB.
To je za delovanje popolnoma neopazno. Ko so na primer particije ustvarjene v MySQL, je vse drugače. To se običajno zgodi ponoči, ker blokira splošno vstavljanje, delo s tabelami in lahko povzroči poslabšanje storitve. To ne velja za TimescaleDB.
Kot primer bom prikazal en graf od mnogih v skupnosti. Na sliki je omogočen TimescaleDB, zaradi česar je obremenitev procesorja pri uporabi io.weight padla. Zmanjšala se je tudi uporaba notranjih procesnih elementov. Poleg tega je to navaden virtualni stroj na navadnih palačinkah, ne SSD.
Ugotovitve
TimescaleDB je dobra rešitev za majhne "namestitve", ki vplivajo na zmogljivost diska. Omogočil vam bo nadaljnje dobro delo, dokler baza podatkov ne bo čim hitreje preseljena na strojno opremo.
TimescaleDB je enostaven za konfiguracijo, omogoča izboljšanje zmogljivosti, dobro deluje z Zabbixom in ima prednosti pred PostgreSQL.
Če uporabljate PostgreSQL in ga ne nameravate spremeniti, priporočam uporabite PostgreSQL z razširitvijo TimescaleDB v povezavi z Zabbixom. Ta rešitev deluje učinkovito do srednje "nastavitve".
Ko rečemo "visoka zmogljivost", mislimo . Ne bo vam treba dolgo čakati, da spoznate tehnologije in prakse, ki omogočajo, da storitve služijo milijonom uporabnikov. Seznam za 7. in 8. november smo že zbrali, ampak tukaj se lahko predlaga več.
Naročite se na naše и , v katerem razkrivamo značilnosti prihajajoče konference in ugotavljamo, kako iz nje potegniti največ.
Vir: www.habr.com