Zabbix is in tafersjochsysteem. Lykas elk oar systeem hat it trije haadproblemen fan alle tafersjochsystemen: gegevens sammelje en ferwurkje, skiednis opslaan en wiskje.
De stadia fan it ûntfangen, ferwurkjen en opnimmen fan gegevens nimme tiid. Net folle, mar foar in grut systeem kin dit resultearje yn grutte fertragingen. It opslachprobleem is in kwestje fan tagong ta gegevens. Se wurde brûkt foar rapporten, kontrôles en triggers. Fertragingen foar gegevenstagong beynfloedzje ek prestaasjes. As de databank groeit, moatte irrelevante gegevens wiske wurde. Wiskje is in swiere operaasje dy't ek wat boarnen opfet.
Samling en opslach fertraging problemen yn Zabbix wurde oplost troch caching: ferskate soarten caches, caching yn de databank. Om it tredde probleem op te lossen is caching net geskikt, dus TimescaleDB waard brûkt yn Zabbix. Sil der oer fertelle Andrey Gushchin - technyske stipe yngenieur . Andrey hat Zabbix foar mear as 6 jier stipe en is direkt belutsen by prestaasjes.
Hoe wurket TimescaleDB, hokker prestaasjes kin it jaan yn ferliking mei gewoane PostgreSQL? Hokker rol spilet Zabbix yn TimescaleDB? Hoe fanôf it begjin te begjinnen en hoe te migrearjen fan PostgreSQL en hokker konfiguraasjeprestaasjes is better? Dit alles ûnder de besuniging.
Performance Challenges
Elk tafersjochsysteem stiet foar bepaalde prestaasjesútdagings. Ik sil prate oer trije fan harren: gegevens sammeljen en ferwurkjen, opslach, skiednis skjinmeitsjen.
Snelle gegevenssammeling en ferwurking. In goed tafersjochsysteem moat alle gegevens fluch ûntfange en ferwurkje neffens trigger-útdrukkingen - neffens eigen kritearia. Nei ferwurking moat it systeem dizze gegevens ek fluch opslaan yn 'e databank om se letter te brûken.
Skiednis opslach. In goed tafersjochsysteem moat skiednis yn in databank opslaan en maklike tagong jaan ta metriken. De skiednis is nedich om te brûken yn rapporten, grafiken, triggers, drompels en berekkene warskôgingsitems.
Skiednis wiskje. Soms komt der in dei dat jo gjin metriken hoege te bewarjen. Wêrom hawwe jo gegevens nedich dy't 5 jier lyn sammele binne, in moanne as twa: guon knopen binne fuortsmiten, guon hosts of metriken binne net mear nedich, om't se ferâldere binne en net mear sammele. In goed tafersjochsysteem moat histoaryske gegevens opslaan en sa no en dan wiskje, sadat de databank net groeit.
Ferâldere gegevens opromje is in netste probleem dat in grutte ynfloed hat op databankprestaasjes.
Caching yn Zabbix
Yn Zabbix wurde de earste en twadde opropen oplost mei caching. RAM wurdt brûkt om gegevens te sammeljen en te ferwurkjen. Foar opslach - skiednis yn triggers, grafiken en berekkene items. Oan 'e DB-kant is d'r wat caching foar basisseleksjes, lykas grafiken.
Caching oan 'e kant fan' e Zabbix-tsjinner sels is:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Meitsje se yn mear detail.
ConfigurationCache
Dit is de haadcache wêryn wy metriken, hosts, gegevensitems, triggers opslaan - alles wat nedich is foar PreProcessing en foar gegevenssammeling.
Dit alles wurdt opslein yn 'e ConfigurationCache om gjin ûnnedige fragen yn' e databank te meitsjen. Nei't de tsjinner begjint, fernije wy dizze cache, meitsje en periodyk bywurkje konfiguraasjes.
Data kolleksje
It skema is frij grut, mar it wichtichste ding yn it is samlers. Dit binne ferskate "pollers" - assemblage prosessen. Se binne ferantwurdlik foar ferskate soarten gearkomsten: se sammelje gegevens fia SNMP, IPMI, en drage it allegear oer nei PreProcessing.
Plukkers binne sirkels yn oranje.
Zabbix hat aggregaasje-items berekkene dy't nedich binne om kontrôles te aggregearjen. As wy se hawwe, nimme wy de gegevens foar har direkt fan 'e ValueCache.
PreProcessing HistoryCache
Alle samlers brûke de ConfigurationCache om banen te ûntfangen. Dan jouwe se se troch nei PreProcessing.
PreProcessing brûkt ConfigurationCache om PreProcessing-stappen te krijen. It ferwurket dizze gegevens op ferskate manieren.
Nei it ferwurkjen fan de gegevens mei PreProcessing, bewarje wy it yn 'e HistoryCache om it te ferwurkjen. Dit foltôget de gegevenssammeling en wy geane troch nei it haadproses yn Zabbix - skiednis syngronisaasje, sa't it in monolityske arsjitektuer is.
Opmerking: PreProcessing is in frij swiere operaasje. Sûnt v 4.2 is it ferpleatst nei in proxy. As jo in hiel grutte Zabbix mei in grut oantal items en kolleksje frekwinsje, dan makket dit dingen in stik makliker.
ValueCache, skiednis en trends-cache
Skiednissyngronisaasje is it haadproses dat elk gegevenselemint atomysk ferwurket, dat is elke wearde.
Skiednissyngronisaasje nimt wearden fan HistoryCache en kontrolearret konfiguraasje foar triggers foar berekkeningen. As se binne - berekkent.
Skiednissyngronisaasje makket in evenemint, eskalearret om warskôgings te meitsjen as nedich troch konfiguraasje, en records. As d'r triggers binne foar fierdere ferwurking, dan ûnthâldt it dizze wearde yn 'e ValueCache om net te ferwizen nei de skiednistabel. Dit is hoe't de ValueCache is fol mei de gegevens dy't nedich binne om triggers, berekkene items te berekkenjen.
Skiednissyngronisaasje skriuwt alle gegevens nei de databank, en it skriuwt nei skiif. It ferwurkingsproses einiget hjir.
DB caching
D'r binne ferskate caches oan 'e DB-kant as jo nei grafiken of eveneminterapporten wolle sjen:
Innodb_buffer_pooloan 'e MySQL-kant;shared_buffersoan 'e PostgreSQL-kant;effective_cache_sizeoan 'e kant fan' e Oracle;shared_pooloan DB2.
D'r binne in protte oare caches, mar dit binne de wichtichste foar alle databases. Se tastean jo te hâlden gegevens yn RAM dat is faak nedich foar queries. Se hawwe har eigen technology foar dit.
Databankprestaasjes is kritysk
Zabbix-tsjinner sammelet konstant gegevens en skriuwt it op. As it opnij starte, lêst it ek út 'e skiednis om de ValueCache te foljen. Skripten en rapporten brûkt Zabbix API, dat is boud op basis fan 'e webynterface. De Zabbix API makket tagong ta de databank en hellet de nedige gegevens op foar grafiken, rapporten, evenemintelisten en resinte problemen.
Foar fisualisaasje - grafana. Dit is in populêre oplossing ûnder ús brûkers. Se kin direkt ferstjoere fersiken fia de Zabbix API en nei de databank, en makket in bepaalde concurrency foar it krijen fan gegevens. Dêrom is in fynere en bettere database-tuning nedich om te passen by de rappe levering fan resultaten en testen.
Húshâldster
De tredde útfieringsútdaging yn Zabbix is skiednis skjinmeitsje mei Housekeeper. It respektearret alle ynstellingen - de gegevenseleminten jouwe oan hoe lang de dynamyk fan feroaringen (trends) yn dagen te bewarjen.
TrendsCache wy berekkenje op 'e flecht. As de gegevens binnenkomme, aggregearje wy it yn ien oere en sette se yn tabellen foar de dynamyk fan trendwizigingen.
Húshâldster begjint en ferwideret ynformaasje út de databank mei de gewoane "selektearje". Dit is net altyd effisjint, wat kin wurde begrepen út 'e prestaasjesgrafiken fan ynterne prosessen.
De reade grafyk lit sjen dat de Histoarje syncer is konstant drok. De oranje kaart oan de top is Housekeeper, dy't hieltyd rint. It wachtet op de databank om alle rigen te wiskjen dy't it hat oantsjutte.
Wannear moatte jo húshâldster útskeakelje? Bygelyks, d'r is in "Item ID" en jo moatte de lêste 5 tûzen rigels yn in bepaalde tiid wiskje. Fansels bart dit troch yndeksen. Mar meastal de dataset is hiel grut, en de databank noch lêst fan de skiif en set it yn it cache. Dit is altyd in heul djoere operaasje foar de databank en kin, ôfhinklik fan de grutte fan de databank, liede ta prestaasjesproblemen.
Húshâldster is ienfâldich út te skeakeljen. Yn 'e webynterface is d'r in ynstelling yn "Bestjoer algemien" foar húshâldster. Skeakelje ynterne húshâlding út foar ynterne trendskiednis en it kontrolearret dit net mear.
Húshâldster is útskeakele, grafiken binne gelyk - wat kinne de problemen yn dit gefal wêze en wat kin helpe by it oplossen fan 'e tredde prestaasjesútdaging?
Partitioning - partitioning of partitioning
Partitioning wurdt meastal konfigurearre op in oare wize op elke relational databank dat ik haw neamd. Elk hat syn eigen technology, mar se binne fergelykber, yn 't algemien. It meitsjen fan in nije partysje liedt faak ta bepaalde problemen.
Typysk wurde partysjes konfigureare ôfhinklik fan 'e "opset" - de hoemannichte gegevens dy't yn ien dei makke wurde. As regel, Partitioning wurdt ynsteld yn ien dei, dit is it minimum. Foar nije partition trends - 1 moanne.
De wearden kinne feroarje yn it gefal fan in heul grutte "opset". As in lytse "opset" oant 5 nvps (nije wearden per sekonde) is, is in gemiddelde fan 000 oant 5, dan is in grutte boppe 000 nvps. Dit binne grutte en heul grutte ynstallaasjes dy't soarchfâldige konfiguraasje fan 'e databank sels fereaskje.
Op tige grutte ynstallaasjes kin ien dei net optimaal wêze. Ik haw MySQL-partysjes sjoen fan 40 GB of mear per dei. Dit is in heul grutte hoemannichte gegevens dy't liede kinne ta problemen en moatte wurde fermindere.
Wat jout Partitioning?
Partitioning tabellen. Faak binne dit aparte triemmen op skiif. It queryplan selekteart ien partition optimaler. Gewoanlik wurdt partitionearring brûkt troch berik - dit is ek wier foar Zabbix. Wy brûke dêr "tiidstempel" - de tiid sûnt it begjin fan it tiidrek. Wy hawwe reguliere nûmers. Jo sette it begjin en ein fan 'e dei yn - dit is in partysje.
Fluch fuortheljen - DELETE. Ien triem/subtabel is selektearre, net in seleksje fan rigen foar wiskjen.
Fersnelt de sampling fan gegevens signifikant SELECT - brûkt ien of mear partysjes, net de hiele tabel. As jo tagong krije ta twa dagen âlde gegevens, hellet it it rapper út 'e databank, om't jo it allinich yn 'e cache hoege te laden en mar ien bestân werom te jaan, net in grutte tabel.
Faak binne in protte databases ek flugger INSERT - ynfoegje yn it bern tafel.
TiidskaalDB
Foar v 4.2 draaiden wy ús oandacht nei TimescaleDB. Dit is in PostgreSQL-útwreiding mei in native ynterface. De tafoeging wurket effisjint mei tiidreeksgegevens sûnder de foardielen fan relasjonele databases te ferliezen. TimescaleDB ek automatysk partysjes.
TimescaleDB hat in konsept hypertabel (hypertabel) dat jo meitsje. Yn it binne brokken - partysjes. Brokken binne automatysk behearde fragminten fan in hypertabel dy't gjin ynfloed hawwe op oare fragminten. Elke brok hat syn eigen tiidberik.
TimescaleDB vs PostgreSQL
TimescaleDB is echt effisjint. De produsinten fan 'e tafoeging beweare dat se in mear korrekte query-ferwurkingsalgoritme brûke, benammen inserts . As de grutte fan 'e dataset-ynfoegje groeit, behâldt it algoritme konstante prestaasjes.
Nei 200 miljoen rigen begjint PostgreSQL meastentiids in protte te sakjen en prestaasje te ferliezen nei 0. TimescaleDB kinne jo effisjint ynfoegje "inserts" mei alle hoemannichte gegevens.
ynstelling
It ynstallearjen fan TimescaleDB is maklik genôch foar alle pakketten. YN alles is detaillearre - it hinget ôf fan 'e offisjele PostgreSQL-pakketten. TimescaleDB kin ek mei de hân boud en kompilearre wurde.
Foar de Zabbix-database aktivearje wy gewoan de tafoeging:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
jo aktivearje extension en meitsje it foar de Zabbix-database. De lêste stap is om in hypertabel te meitsjen.
Skiednistabellen migrearje nei TimescaleDB
Der is in spesjale funksje foar dit. 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
De funksje hat trije parameters. Earste - tabel yn databankDe wêrfoar jo in hypertabel meitsje wolle. Twadde - fjild, neffens dêr't it nedich is om te meitsjen chunk_time_interval - ynterval fan partition brokken te brûken. Yn myn gefal is it ynterval ien dei - 86.
De tredde parameter is migrate_data. As ynsteld true, dan wurde alle aktuele gegevens oerbrocht nei foarôf oanmakke brokken. Ik sels haw brûkt migrate_data. Ik hie sawat 1TB dy't mear as in oere naam. Sels yn guon gefallen haw ik by it testen de histoaryske gegevens fan karaktertypen wiske, dy't opsjoneel binne foar opslach, om se net oer te dragen.
Lêste stap - UPDATE: yn db_extension sette timescaledbsadat de databank begrypt dat d'r dizze útwreiding is. Zabbix aktivearret it en brûkt de syntaksis en queries al nei de databank korrekt - dy funksjes dy't nedich binne foar TimescaleDB.
Hardware konfiguraasje
Ik brûkte twa servers. Earste - VMware masine. It is lyts genôch: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 GB RAM en in 200 GB SSD drive.
Ik ynstallearre PostgreSQL 10.8 derop mei Debian OS 10.8-1.pgdg90+1 en xfs-bestânsysteem. Ik konfigureare alles minimaal om dizze bepaalde databank te brûken, minus wat Zabbix sels sil brûke.
Op deselde masine wie der in Zabbix-tsjinner, PostgreSQL en load aginten. Ik hie 50 aktive aginten dy't brûkten LoadableModuleom ferskate resultaten heul fluch te generearjen: sifers, snaren. Ik fol de databank mei in soad gegevens.
Yn earste ynstânsje befette de konfiguraasje 5 items gegevens per host. Hast elk elemint befette in trigger om it te meitsjen as echte ynstallaasjes. Yn guon gefallen wie der mear as ien trigger. Ien netwurk knooppunt hie 3-000 triggers.
Item update ynterval - 4-7 sekonden. Ik regele de lading sels troch in gebrûk net allinnich 50 aginten, mar tafoegjen fan mear. Ek, mei help fan gegevens eleminten, ik dynamysk regele de lading en redusearre it update ynterval nei 4 s.
PostgreSQL. 35 nvps
Myn earste run op dizze hardware wie op pure PostgreSQL - 35 tûzen wearden per sekonde. Sa't jo sjen kinne, nimt it ynfoegjen fan gegevens fraksjes fan in sekonde - alles is goed en fluch. It iennichste ding is dat it 200 GB SSD-stasjon gau foltôget.
Dit is in standert dashboard fan Zabbix-serverprestaasjes.
De earste blauwe grafyk is it oantal wearden per sekonde. De twadde grafyk oan 'e rjochterkant is it laden fan bouprosessen. De tredde is it laden fan ynterne bouprosessen: histoarje-syncers en Housekeeper, dy't hjir al in skoft rint.
De fjirde grafyk lit it gebrûk fan HistoryCache sjen. Dit is in soarte fan buffer foardat jo yn 'e databank ynfoegje. De griene fyfde grafyk toant it gebrûk fan ValueCache, dat is, hoefolle ValueCache-hits foar triggers binne ferskate tûzen wearden per sekonde.
PostgreSQL. 50 nvps
Doe fergrutte ik de lading nei 50 tûzen wearden per sekonde op deselde hardware.
By it laden fan Housekeeper naam it ynfoegjen fan 10 tûzen wearden 2-3 sekonden.
Húshâldster begjint al yn 'e wei te stean.
De tredde grafyk lit sjen dat, yn 't algemien, it laden fan trappers en skiednissyngronisaasjes noch altyd op it nivo fan 60% is. Op de fjirde grafyk begjint de HistoryCache tidens de wurking fan Housekeeper al aardich aktyf te foljen. It is 20% fol - oer 0,5 GB.
PostgreSQL. 80 nvps
Doe fergrutte ik de lading nei 80 tûzen wearden per sekonde. Dit is sawat 400 tûzen gegevenseleminten en 280 tûzen triggers.
De laden ynfoegje fan tritich histoarje-syncers is al frij heech.
Ik haw ek ferskate parameters ferhege: skiednissyngronisaasje, caches.
Op myn hardware is it laden fan histoarje-syncers ta it maksimum tanommen. HistoryCache fol mei gegevens - de buffer hat gegevens sammele foar ferwurking.
Al dizze tiid, Ik seach hoe't de prosessor, RAM en oare systeem parameters waarden brûkt, en fûn dat skiif benutten wie maksimum.
Ik haw gebrûk makke fan maksimum skiif kapasiteit op dizze hardware en op dizze firtuele masine. Mei sa'n yntinsiteit begon PostgreSQL gegevens frij aktyf te dumpen, en de skiif hie gjin tiid mear om te skriuwen en te lêzen.
Twadde tsjinner
Ik naam in oare tsjinner dy't hie al 48 processors en 128 GB RAM. Ik haw it ôfstimd - set 60 skiednissyngronisaasje yn, en berikke akseptabele prestaasjes.
Eins is dit al in prestaasjelimyt dêr't wat dien wurde moat.
timescaledb. 80 nvps
Myn haadtaak is om de mooglikheden fan TimescaleDB te testen tsjin in Zabbix-lading. 80 tûzen wearden per sekonde is in protte, de frekwinsje fan it sammeljen fan metriken (útsein Yandex, fansels) en in frij grutte "opset".
D'r is in dip op elke grafyk - dit is gewoan in gegevensmigraasje. Nei de mislearrings yn 'e Zabbix-tsjinner is it ladenprofyl fan' e skiednissyngronisaasje in protte feroare - it foel trije kear.
TimescaleDB lit jo gegevens hast 3 kear rapper ynfoegje en minder HistoryCache brûke.
Dêrom sille jo gegevens op 'e tiid ûntfange.
timescaledb. 120 nvps
Dêrnei fergrutte ik it oantal gegevens items nei 500 tûzen. De wichtichste taak wie om de mooglikheden fan TimescaleDB te kontrolearjen - ik krige in berekkene wearde fan 125 tûzen wearden per sekonde.
Dit is in wurkjende "opset" dy't in lange tiid kin duorje om te wurkjen. Mar om't myn skiif mar 1,5 TB wie, haw ik it yn in pear dagen fol.
It wichtichste, nije TimescaleDB-partysjes waarden tagelyk makke.
Foar prestaasjes is dit folslein net te merken. As partysjes makke wurde yn MySQL, bygelyks, binne dingen oars. Dit bart normaal nachts, om't it algemiene ynfoegje, tabelmanipulaasje blokkearret en degradaasje fan 'e tsjinst kin meitsje. Dit is net it gefal mei TimescaleDB.
Bygelyks, ik sil sjen litte ien grafyk út de set yn mienskip. Op 'e foto is TimescaleDB ynskeakele, wêrtroch't de lading op it gebrûk fan io.weight op' e prosessor is fallen. It gebrûk fan eleminten fan ynterne prosessen is ek ôfnommen. Boppedat is dit in gewoane firtuele masine op gewoane pankoekskiven, en net in SSD.
befinings
TimescaleDB is in goede oplossing foar lytse "ynstellings", dy't rêste op 'e prestaasjes fan' e skiif. It sil jo tastean om goed te wurkjen oant de databank rapper nei hardware wurdt migrearre.
TimescaleDB is maklik yn te stellen, jout in prestaasje ympuls, wurket goed mei Zabbix en hat foardielen boppe PostgreSQL.
As jo PostgreSQL brûke en net fan plan binne it te feroarjen, dan advisearje ik brûke PostgreSQL mei TimescaleDB-útwreiding yn kombinaasje mei Zabbix. Dizze oplossing wurket effektyf oant medium "opset".
Wy sizze "hege prestaasjes" - wy bedoele . It sil net lang duorje foardat jo de technologyen en praktiken leare kennen dy't de tsjinsten mooglik meitsje om miljoenen brûkers te tsjinjen. List foar 7 en 8 novimber hawwe wy al opsteld, mar mear kin wurde foarsteld.
Ynskriuwe op ús и , wêryn't wy de funksjes fan 'e kommende konferinsje iepenbierje, en útfine hoe't jo it measte út kinne krije.
Boarne: www.habr.com