Zabbix monitorizazio sistema bat da. Beste edozein sistemak bezala, monitorizazio sistema guztien hiru arazo nagusi ditu: datuak biltzea eta prozesatzea, historia gordetzea eta garbitzea.
Datuak jasotzeko, prozesatzeko eta erregistratzeko faseek denbora behar dute. Ez da asko, baina sistema handi batean atzerapen handiak eragin ditzake. Biltegiratze-arazoa datuak sartzeko arazoa da. Txostenak, egiaztapenak eta abiarazleak egiteko erabiltzen dira. Datuen sarbidean latentziak ere eragina du errendimenduan. Datu-baseak hazten direnean, garrantzirik gabeko datuak ezabatu behar dira. Eragiketa zaila da kentzea, baliabide batzuk ere jaten dituena.
Zabbixen bilketa eta biltegiratzean atzerapen arazoak cachean konpontzen dira: hainbat cache mota, datu-basean cachea. Hirugarren arazoa konpontzeko, cachea ez da egokia, beraz, Zabbix-ek TimescaleDB erabili zuen. Berak kontatuko dizu Andrey Gushchin - Laguntza teknikoko ingeniaria . Andreyk 6 urte baino gehiago daramatza Zabbix laguntzen eta esperientzia zuzena du performancean.
Nola funtzionatzen du TimescaleDB, zer errendimendu eman dezake PostgreSQL arruntarekin alderatuta? Zein funtzio betetzen du Zabbixek TimescaleDB datu-basearentzat? Nola hasi hutsetik eta nola migratu PostgreSQL-tik eta zein konfigurazio du errendimendu hobea? Honi guztiari buruz ebakipean.
Produktibitatearen erronkak
Jarraipen-sistema bakoitzak errendimendu-erronka zehatzak ditu. Horietako hiruri buruz hitz egingo dut: datuen bilketa eta tratamendua, biltegiratzea eta historia garbitzea.
Datuen bilketa eta tratamendu azkarra. Jarraipen-sistema on batek datu guztiak azkar jaso eta abiarazte-adierazpenen arabera prozesatu behar ditu - bere irizpideen arabera. Prozesatu ondoren, sistemak datu hauek azkar gorde behar ditu datu-basean gero erabiltzeko.
Historia biltegiratzea. Jarraipen-sistema on batek historia datu-base batean gorde behar du eta neurketetarako sarbide erraza eman behar du. Historia beharrezkoa da txostenetan, grafikoetan, abiarazleetan, atalaseetan eta kalkulatutako alerta-datuen elementuetan erabiltzeko.
Historia garbitzea. Batzuetan, neurketak gorde behar ez dituzun egun bat iristen da. Zergatik behar dituzu duela 5 urte, hilabete bat edo bi bildutako datuak: nodo batzuk ezabatu dira, ostalari edo metrika batzuk ez dira beharrezkoak, zaharkituta daudelako eta ez direlako bildu. Jarraipen-sistema on batek datu historikoak gorde behar ditu eta noizean behin ezabatu behar ditu datu-basea hazi ez dadin.
Datu zaharkituak garbitzea datu-basearen errendimenduan eragin handia duen arazo kritikoa da.
Zabbixen cachean gordetzea
Zabbixen, lehenengo eta bigarren deiak cachea erabiliz ebazten dira. RAM datuak biltzeko eta prozesatzeko erabiltzen da. Biltegiratzeko - historia abiarazleetan, grafikoetan eta kalkulatutako datu-elementuetan. Datu-basearen aldean oinarrizko hautapenetarako caching batzuk daude, adibidez, grafikoak.
Zabbix zerbitzariaren beraren alboan gordetzea hau da:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Demagun xehetasun gehiago.
ConfigurationCache
Hau da neurketak, ostalariak, datu-elementuak eta abiarazleak gordetzen ditugun cache nagusia - Aurreprozesatzeko eta datuak biltzeko behar dugun guztia.
Hori guztia ConfigurationCache-n gordetzen da datu-basean alferrikako kontsultak ez sortzeko. Zerbitzaria abiarazi ondoren, cache hau eguneratzen dugu, konfigurazioak sortzen eta aldian-aldian eguneratzen ditugu.
Datu bilketa
Diagrama nahiko handia da, baina bertan dagoen gauza nagusia da hautatzaileak. Hauek hainbat "poller" dira - muntaketa-prozesuak. Hainbat muntaketa-motaz arduratzen dira: datuak SNMP, IPMI bidez biltzen dituzte, eta dena Aurreprozesaketara transferitzen dute.
Bildumatzaileak laranjaz marraztuta daude.
Zabbix-ek egiaztapenak bateratzeko behar diren agregazio-elementuak kalkulatu ditu. Badauzkagu, haien datuak zuzenean ValueCache-tik jasotzen ditugu.
Aurreprozesatzen historiaren cachea
Biltzaile guztiek ConfigurationCache erabiltzen dute lanak jasotzeko. Ondoren, Aurreprozesaketara transferitzen dituzte.
Aurreprozesamenduak ConfigurationCache erabiltzen du Aurreprozesatzeko urratsak jasotzeko. Datu horiek hainbat modutan prozesatzen ditu.
Aurreprozesatzea erabiliz datuak prozesatu ondoren, HistoryCache-n gordetzen ditugu prozesatzeko. Horrek datu bilketa amaitzen du eta Zabbixen prozesu nagusira pasatzen gara - historia sinkronizatzailea, arkitektura monolitikoa baita.
Oharra: Aurreprozesatzea nahiko eragiketa zaila da. 4.2 bertsioarekin proxyra eraman da. Zabbix oso handia baduzu, datu-elementu eta bilketa-maiztasun ugari dituena, horrek lana askoz errazten du.
ValueCache, historia eta joeren cachea
History Syncer datu-elementu bakoitza atomikoki prozesatzen duen prozesu nagusia da, hau da, balio bakoitza.
History Syncer-ek HistoryCache-tik balioak hartzen ditu eta konfigurazioa egiaztatzen du kalkuluetarako abiarazleen presentzia dagoela. Badaude, kalkulatzen du.
History Syncer-ek gertaera bat sortzen du, konfigurazioak eskatzen badu alertak sortzeko eskalatzea eta erregistroak. Ondorengo prozesatzeko abiarazleak badaude, balio hau ValueCache-n gordetzen du historia-taulara sartzeko. Hau da ValueCache abiarazleak eta kalkulatutako elementuak kalkulatzeko beharrezkoak diren datuekin betetzen da.
History Syncer-ek datu guztiak datu-basean idazten ditu eta diskoan idazten ditu. Prozesatzeko prozesua hemen amaitzen da.
Datu-basean cachean gordetzea
Datu-basean hainbat cache daude gertaeren grafikoak edo txostenak ikusi nahi dituzunean:
Innodb_buffer_poolMySQL aldean;shared_buffersPostgreSQL aldean;effective_cache_sizeOracle aldean;shared_poolDB2 aldean.
Beste hainbat cache daude, baina hauek dira datu-base guztietarako nagusiak. Kontsultetarako sarritan beharrezkoak diren datuak RAMan gordetzeko aukera ematen dute. Horretarako teknologia propioak dituzte.
Datu-basearen errendimendua funtsezkoa da
Zabbix zerbitzariak etengabe biltzen ditu datuak eta idazten ditu. Berrabiarazitakoan, historiatik ere irakurtzen du ValueCache-a betetzeko. Gidoiak eta txostenak erabiltzen ditu Zabbix APIa, Web interfaze batean eraikia. Zabbix APIa datu-basean sartzen da eta grafikoetarako, txostenetarako, gertaeren zerrendetarako eta azken gaietarako beharrezko datuak lortzen ditu.
bistaratzeko - Grafana. Gure erabiltzaileen artean irtenbide ezaguna da. Zabbix APIaren bidez eta datu-basera eskaerak zuzenean bidal ditzake, eta nolabaiteko lehiaketa sortzen du datuak jasotzeko. Hori dela eta, datu-basearen sintonizazio finagoa eta hobea behar da emaitzen eta proben entrega azkarrarekin bat egiteko.
housekeeper
Zabbixeko hirugarren errendimenduko erronka Housekeeper erabiliz historia garbitzea da. Ezarpen guztiak jarraitzen ditu - datu-elementuek egunetan aldaketen (joeren) dinamika zenbat denbora gorde behar duten adierazten dute.
TrendsCache hegan kalkulatzen dugu. Datuak iristen direnean, ordubetez batzen ditugu eta tauletan erregistratzen ditugu joera aldaketen dinamikarako.
Etxeko arduradunak datu baseko informazioa abiarazi eta ezabatzen du ohiko "hautaketak" erabiliz. Hau ez da beti eraginkorra, barne prozesuen errendimendu grafikoetan ikusten denez.
Grafiko gorrian Historia sinkronizatzailea etengabe lanpetuta dagoela erakusten du. Goiko grafiko laranja Housekeeper da, etengabe martxan dagoena. Datu-baseak zehaztutako errenkada guztiak ezabatzeko zain dago.
Noiz desgaitu behar duzu Housekeeper? Adibidez, "Item ID" bat dago eta azken 5 mila errenkadak ezabatu behar dituzu denbora jakin batean. Jakina, hori indizearen arabera gertatzen da. Baina normalean datu-multzoa oso handia da, eta datu-baseak oraindik diskotik irakurtzen du eta cachean sartzen du. Datu-basearentzat oso eragiketa garestia da beti eta, datu-basearen tamainaren arabera, errendimendu arazoak sor ditzake.
Etxeko arduraduna erraz desgaitzen da. Web interfazean "Administrazio orokorra" ezarpen bat dago Housekeeper-en. Barneko Etxegintza desgaitzen dugu barne-joeren historiarako eta jada ez du kudeatzen.
Etxeko arduraduna itzalita zegoen, grafikoak berdinduta - zer arazo egon litezke kasu honetan eta zer lagun dezake hirugarren errendimenduaren erronka konpontzen?
Partitioning - zatiketa edo zatiketa
Normalean, zatiketa modu ezberdin batean konfiguratzen da zerrendatu dudan datu-base erlazional bakoitzean. Bakoitzak bere teknologia du, baina oro har antzekoak dira. Partizio berri bat sortzeak arazo batzuk ekartzen ditu askotan.
Normalean, partizioak "konfigurazioaren" arabera konfiguratzen dira - egun batean sortzen den datu kopuruaren arabera. Oro har, zatiketa egun bakarrean ematen da, hau da gutxienekoa. Lote berri baten joeretarako - hilabete 1.
Balioak alda daitezke "konfigurazioa" oso handia bada. "Konfigurazio" txiki bat 5 nvps (segundoko balio berriak) artekoa bada, ertaina 000 eta 5 artekoa da, handi bat 000 nvps-tik gorakoa da. Datu-basea kontu handiz konfiguratu behar duten instalazio handiak eta oso handiak dira.
Instalazio oso handietan, baliteke egun bateko epea ez izatea egokiena. Egunero 40 GB edo gehiagoko MySQL partizioak ikusi ditut. Arazoak sor ditzakeen eta murriztu beharreko datu kopuru oso handia da.
Zer ematen du partizioak?
Banaketa taulak. Askotan diskoan fitxategi bereiziak dira. Kontsulta-planak partizio bat aukeratzen du modu egokiagoan. Normalean zatiketa barrutiaren arabera erabiltzen da - hori ere egia da Zabbix-entzat. Bertan "denbora-zigilua" erabiltzen dugu - garaiaren hasieratik denbora. Hauek zenbaki arruntak dira guretzat. Egunaren hasiera eta amaiera ezarri duzu - hau partizioa da.
Azkar kentzea - DELETE. Fitxategi/azpitaula bat hautatzen da, ezabatzeko errenkaden aukeraketa bat baino.
Datuen berreskurapena nabarmen bizkortzen du SELECT - partizio bat edo gehiago erabiltzen ditu, taula osoa baino. Bi eguneko datuak sartzen ari bazara, datu-basetik azkarrago berreskuratzen dira, fitxategi bat bakarrik kargatu behar duzulako cachean eta itzuli, ez taula handi bat.
Askotan datu-base asko ere azkartu egiten dira INSERT — txertaketak umeen mahaian.
Denbora eskalaDB
4.2 bertsiorako, TimescaleDB-ra jarri genuen arreta. Hau PostgreSQL-rako luzapena da jatorrizko interfazearekin. Luzapenak denbora serieko datuekin eraginkortasunez funtzionatzen du, datu-base erlazionalen abantailak galdu gabe. TimescaleDB-k ere automatikoki partitzen du.
TimescaleDB-k kontzeptu bat du hipertaula (hipertable) zuk sortzen duzun. Dauka puskak - zatiketak. Chunk-ak automatikoki kudeatutako hipertaula-zatiak dira, beste zati batzuetan eragiten ez dutenak. Zati bakoitzak bere denbora tartea du.
TimescaleDB vs PostgreSQL
TimescaleDB-k modu eraginkorrean funtzionatzen du. Luzapen-fabrikatzaileek eskaerak prozesatzeko algoritmo zuzenagoa erabiltzen dutela diote, bereziki txertaketak. Datu-multzoaren txertatze-tamaina hazi ahala, algoritmoak etengabeko errendimendua mantentzen du.
200 milioi errenkadaren ondoren, PostgreSQL normalean nabarmen jaisten hasten da eta errendimendua 0-raino galtzen du. TimescaleDB-k edozein datu-kopururako "txertaketak" modu eraginkorrean txertatzeko aukera ematen du.
Instalazio-
TimescaleDB instalatzea nahiko erraza da edozein paketerentzat. IN dena zehatz-mehatz deskribatzen da - PostgreSQL pakete ofizialen araberakoa da. TimescaleDB eskuz ere eraiki eta konpila daiteke.
Zabbix datu-baserako luzapena aktibatzen dugu:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Aktibatzen duzu extension eta sortu Zabbix datu-baserako. Azken urratsa hipertaula bat sortzea da.
Historia-taulak TimescaleDB-ra migratzen
Funtzio berezi bat dago horretarako 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
Funtzioak hiru parametro ditu. Lehenengoa - taula datu-basean, horretarako hipertaula bat sortu behar duzu. Bigarrena - eremu, horren arabera sortu behar duzu chunk_time_interval — erabili beharreko partizio zatien tartea. Nire kasuan, tartea egun batekoa da - 86.
Hirugarren parametroa - migrate_data. Ezarri baduzu true, orduan uneko datu guztiak aurrez sortutako zatietara transferitzen dira. Nik neuk erabili nuen migrate_data. TB inguru nuen, eta horrek ordubete baino gehiago behar izan zuen. Zenbait kasutan ere, probak zehar, biltegiratzeko beharrezkoak ez ziren karaktere-moten datu historikoak ezabatu ditut, horiek ez transferitzeko.
Azken urratsa - UPDATE: at db_extension jarri timescaledbdatu-baseak luzapen hori existitzen dela uler dezan. Zabbix-ek aktibatzen du eta behar bezala erabiltzen ditu datu-baserako sintaxia eta kontsultak - TimescaleDB-rako beharrezkoak diren ezaugarriak.
Hardwarearen konfigurazioa
Bi zerbitzari erabili ditut. Lehenengoa - VMware makina. Nahiko txikia da: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz prozesadore, 16 GB RAM eta 200 GB SSD bat.
PostgreSQL 10.8 instalatu nuen Debian 10.8-1.pgdg90+1 OS eta xfs fitxategi-sistemarekin. Dena gutxieneko konfiguratu dut datu-base jakin hau erabiltzeko, Zabbixek berak erabiliko duena kenduta.
Makina berean Zabbix zerbitzari bat zegoen, PostgreSQL eta karga-eragileak. Erabiltzen ari ziren 50 agente aktibo nituen LoadableModuleemaitza desberdinak oso azkar sortzeko: zenbakiak, kateak. Datu-basea datu askorekin bete nuen.
Hasieran jasotako konfigurazioa 5 elementu ostalari bakoitzeko datuak. Ia elementu guztiek abiarazle bat zuten benetako instalazioen antzekoa izateko. Zenbait kasutan abiarazle bat baino gehiago egon zen. Sareko nodo baterako zeuden 3-000 abiarazle.
Datu-elementua eguneratzeko tartea − 4 7-segundotan. Karga bera erregulatu nuen 50 agente ez ezik, gehiago gehituz. Gainera, datu-elementuak erabiliz, karga dinamikoki egokitu nuen eta eguneratze-tartea 4 s-ra murriztu nuen.
PostgreSQL. 35 nvps
Hardware honetan egin nuen lehen exekuzioa PostgreSQL hutsean izan zen - 35 mila balio segundoko. Ikus dezakezunez, datuak txertatzeko segundo baten zatiak behar dira - dena ona eta azkarra da. Gauza bakarra da 200 GB SSD disko bat azkar betetzen dela.
Hau Zabbix zerbitzariaren errendimendu-panel estandarra da.
Lehenengo grafiko urdina segundoko balio kopurua da. Eskuineko bigarren grafikoa eraikuntza prozesuen karga da. Hirugarrena barne-eraikuntza-prozesuak kargatzea da: historia-sinkronizatzaileak eta Housekeeper, denbora dezente daramana hemen exekutatzen.
Laugarren grafikoak HistoryCache-ren erabilera erakusten du. Datu-basean sartu aurretik buffer moduko bat da. Bosgarren grafiko berdeak ValueCache-ren erabilera erakusten du, hau da, ValueCache-ren zenbat hit abiarazleetarako - hau da, hainbat mila balio segundoko.
PostgreSQL. 50 nvps
Ondoren, karga segundoko 50 mila balioetara igo nuen hardware berean.
Housekeeper-etik kargatzean, 10 mila balio txertatzeak 2-3 segundo behar izan zituen.
Etxekozaina dagoeneko lanean oztopatzen hasi da.
Hirugarren grafikoak erakusten du, oro har, harrapatzaileen eta historia sinkronizatzaileen karga oraindik %60koa dela. Laugarren grafikoan, HistoryCache dagoeneko nahiko aktibo betetzen hasi da Housekeeper funtzionamenduan. %20 beteta dago, hau da, 0,5 GB inguru.
PostgreSQL. 80 nvps
Ondoren, karga segundoko 80 mila balioetara igo nuen. Hau gutxi gorabehera 400 mila datu-elementu eta 280 mila abiarazle dira.
Hogeita hamar historiako sinkronizatzaileen kargatzeko kostua nahiko altua da dagoeneko.
Hainbat parametro ere handitu ditut: historia-sinkronizatzaileak, cacheak.
Nire hardwarean, historia-sinkronizatzaileen karga gehienez handitu zen. HistoryCache azkar bete zen datuz - prozesatzeko datuak bufferean pilatu ziren.
Denbora honetan guztian prozesadorea, RAM eta sistemaren beste parametro batzuk nola erabiltzen ziren ikusi nuen, eta diskoaren erabilera maximoa zela ikusi nuen.
Erabilera lortu dut diskoaren gehienezko gaitasunak hardware honetan eta makina birtual honetan. Intentsitate horrekin, PostgreSQL datuak nahiko aktiboki garbitzen hasi zen, eta diskoak ez zuen jada idazteko eta irakurtzeko astirik.
Bigarren zerbitzaria
Beste zerbitzari bat hartu nuen, jada 48 prozesadore eta 128 GB RAM zituena. Sintonizatu nuen - 60 historiako sinkronizatzailea ezarri eta errendimendu onargarria lortu nuen.
Izan ere, hori da dagoeneko produktibitatearen muga, non zerbait egin behar den.
Denbora-eskalaDB. 80 nvps
Nire zeregin nagusia TimescaleDB-ren gaitasunak Zabbix kargaren aurka probatzea da. Segundoko 80 mila balio asko dira, metrikak biltzeko maiztasuna (Yandex izan ezik, noski) eta "konfigurazio" nahiko handia da.
Grafiko guztietan beherakada bat dago; hori da, hain zuzen, datuen migrazioa. Zabbix zerbitzarian hutsegiteen ondoren, historia-sinkronizatzailearen karga-profila asko aldatu zen - hiru aldiz jaitsi zen.
TimescaleDB-k datuak ia 3 aldiz azkarrago txertatzeko eta HistoryCache gutxiago erabiltzeko aukera ematen du.
Horren arabera, datuak garaiz jasoko dituzu.
Denbora-eskalaDB. 120 nvps
Ondoren, datu-elementuen kopurua 500 milara igo nuen. Zeregin nagusia TimescaleDB-ren gaitasunak probatzea izan zen - segundoko 125 mila balio kalkulatu nuen.
Denbora luzez funtziona dezakeen laneko "konfigurazioa" da. Baina nire diskoa 1,5 TB baino ez zenez, egun pare batean bete nuen.
Garrantzitsuena da aldi berean TimescaleDB partizio berriak sortu zirela.
Hau errendimendurako guztiz nabariezina da. MySQL-en partizioak sortzen direnean, adibidez, dena desberdina da. Hau normalean gauez gertatzen da txertatze orokorra blokeatzen duelako, taulekin lan egiten duelako eta zerbitzuaren degradazioa sor dezakeelako. Hau ez da TimescaleDB-ren kasua.
Adibide gisa, komunitateko askoren grafiko bat erakutsiko dut. Irudian, TimescaleDB gaituta dago, eta horri esker prozesadorean io.weight erabiltzearen karga jaitsi egin da. Barne prozesuko elementuen erabilera ere gutxitu egin zen. Gainera, makina birtual arrunt bat da pancake disko arruntetan, ez SSD bat.
Findings
TimescaleDB irtenbide ona da "konfigurazio" txikietarako, diskoaren errendimenduan eragina dutenak. Lanean ondo jarraitzeko aukera emango dizu datu-basea hardwarera ahalik eta azkarren migratu arte.
TimescaleDB konfiguratzeko erraza da, errendimendu-irabaziak ematen ditu, ondo funtzionatzen du Zabbix-ekin eta abantailak ditu PostgreSQLren aldean.
PostgreSQL erabiltzen baduzu eta aldatzeko asmorik ez baduzu, gomendatzen dizut erabili PostgreSQL TimescaleDB luzapenarekin Zabbix-ekin batera. Irtenbide honek eraginkortasunez funtzionatzen du "konfigurazio" ertaineraino.
"Errendimendu handiko" esaten dugunean esan nahi dugu . Ez duzu denbora asko itxaron beharko zerbitzuek milioika erabiltzaileri zerbitzua ematen dieten teknologiak eta praktikak ezagutzeko. Zerrenda azaroaren 7 eta 8rako dagoeneko bildu dugu, baina hemen gehiago iradoki daiteke.
Harpidetu gure и , eta bertan, datozen jardunaldien ezaugarriak ezagutarazi, eta horri etekinik handiena nola atera jakiteko.
Iturria: www.habr.com