Hurrengo HighLoad++ konferentzia 6ko apirilaren 7an eta 2020an ospatuko da San Petersburgon Xehetasunak eta sarrerak
* Jarraipena - online eta analitika.
* ZABBIX plataformaren oinarrizko mugak.
* Biltegiratze analitikoa eskalatzeko irtenbidea.
* ZABBIX zerbitzariaren optimizazioa.
* Interfazearen optimizazioa.
* Esperientzia sistema funtzionatzen 40k NVPS baino gehiagoko kargapean.
* Ondorio laburrak.
Mikhail Makurov (aurrerantzean - MM): - Kaixo guztioi!
Maxim Chernetsov (aurrerantzean - MCH): - Arratsalde on!
MM: – Utzidazu Maxim aurkezten. Max talentu handiko ingeniaria da, ezagutzen dudan saregilerik onena. Maxim sare eta zerbitzuetan parte hartzen du, haien garapenean eta funtzionamenduan.
MCH: – Eta Mikeli buruz esan nahiko nizuke. Mikhail C garatzailea da. Karga handiko trafikoa prozesatzeko hainbat soluzio idatzi zituen gure enpresarentzat. Uraletan bizi eta lan egiten dugu, Chelyabinsk gizon gogorren hirian, Intersvyaz konpainian. Gure enpresa Internet eta kable bidezko telebista zerbitzuen hornitzailea da milioi bat pertsonarentzat 16 hiritan.
MM: – Eta esan beharra dago Intersvyaz hornitzaile bat baino askoz gehiago dela, IT enpresa bat dela. Gure soluzio gehienak gure IT sailak egiten ditu.
eta: trafikoa prozesatzen duten zerbitzarietatik dei-zentro batera eta aplikazio mugikor batera. Informatika sailak 80 bat pertsona ditu gaur egun gaitasun oso-oso anitzak dituztenak.
Zabbix eta bere arkitekturari buruz
MCH: – Eta orain saiatuko naiz erregistro pertsonal bat ezartzen eta minutu batean esaten zer den Zabbix (aurrerantzean "Zabbix").
Zabbix-ek enpresa-maila kanpoko monitorizazio-sistema gisa kokatzen du. Bizitza errazten duten funtzio ugari ditu: eskalatze-arau aurreratuak, integraziorako, taldekatzeko eta ostalari eta neurgailuak automatikoki hautemateko APIa. Zabbix-ek eskalatzeko tresnak deiturikoak ditu - proxyak. Zabbix kode irekiko sistema bat da.
Arkitekturari buruz laburki. Hiru osagaiz osatuta dagoela esan dezakegu:
- Zerbitzaria. C-n idatzia. Hari arteko informazioa prozesatzeko eta transferentzia nahiko konplexuarekin. Prozesamendu guztia bertan egiten da: jasotzetik datu basera gorde arte.
- Datu guztiak datu-basean gordetzen dira. Zabbix-ek MySQL, PostreSQL eta Oracle onartzen ditu.
- Web interfazea PHPn idatzita dago. Sistema gehienetan Apache zerbitzari batekin dator, baina eraginkorrago funtzionatzen du nginx + php-rekin konbinatuta.
Gaur Zabbixekin lotutako gure enpresaren bizitzako istorio bat kontatu nahiko genuke...
Intersvyaz konpainiaren bizitzako istorio bat. Zer daukagu eta zer behar dugu?
Duela 5 edo 6 hilabete. Lanaren ondoren egun batean...
MCH: - Misha, kaixo! Pozten naiz zu harrapatzea lortu nuelako - elkarrizketa bat dago. Berriro ere arazoak izan ditugu monitorizazioan. Istripu handi batean dena motel joan zen eta sarearen egoerari buruzko informaziorik ez zegoen. Zoritxarrez, ez da hau gertatzen den lehen aldia. Zure laguntza behar dut. Egin dezagun gure jarraipena inondik inora!
MM: - Baina sinkroniza dezagun lehenik. Duela urte pare bat ez dut hara begiratu. Gogoratzen dudanez, Nagios abandonatu eta Zabbixera aldatu genuen duela 8 bat urte. Eta orain 6 zerbitzari indartsu eta dozena bat proxy ditugula dirudi. Zerbait nahasten al dut?
MCH: - Ia. 15 zerbitzari, horietako batzuk makina birtualak. Garrantzitsuena da ez gaituela salbatzen gehien behar dugun momentuan. Istripu bat bezala - zerbitzariak moteltzen dira eta ezin duzu ezer ikusten. Konfigurazioa optimizatzen saiatu ginen, baina honek ez zuen errendimendu-igoera optimoa eman.
MM: - Garbi dago. Zerbait begiratu al duzu, dagoeneko atera al duzu zerbait diagnostikotik?
MCH: – Aurre egin behar duzun lehenengo gauza datu-basea da. MySQL etengabe kargatzen da, metrika berriak gordez, eta Zabbix gertaera mordoa sortzen hasten denean, datu-basea ordu batzuetan overdrive sartzen da literalki. Dagoeneko konfigurazioa optimizatzeari buruz esan nizuen, baina literalki aurten hardwarea eguneratu dute: zerbitzariek ehun gigabyte baino gehiagoko memoria eta disko-matrize dituzte SSD RAIDetan - ez du zentzurik epe luzera linealki haztea. Zer egiten dugu?
MM: - Garbi dago. Orokorrean, MySQL LTP datu-base bat da. Dirudienez, jada ez da egokia gure tamainako metrika artxibo bat gordetzeko. Asma dezagun.
MCH: - Goazen!
Zabbix eta Clickhouse-ren integrazioa hackatonaren ondorioz
Denbora pixka bat igaro ondoren datu interesgarriak jaso genituen:
Gure datu-baseko espazio gehiena metrika artxiboak hartzen zuen eta % 1 baino gutxiago erabili zen konfiguraziorako, txantiloietarako eta ezarpenetarako. Ordurako, Clickhousen oinarritutako Big data irtenbidea martxan jarri genuen urtebete baino gehiago. Mugimenduaren norabidea agerikoa zen guretzat. Gure udaberriko Hackathonean, Zabbix-en integrazioa Clickhouse-rekin idatzi nuen zerbitzarirako eta frontenderako. Garai hartan, Zabbixek jada bazeukan ElasticSearch-erako laguntza, eta horiek alderatzea erabaki genuen.
Clickhouse eta Elasticsearch-en alderaketa
MM: – Konparazio baterako, Zabbix zerbitzariak eskaintzen duen karga bera sortu dugu eta sistemak nola jokatuko luketen aztertu dugu. Datuak 1000 lerroko multzotan idatzi ditugu, CURL erabiliz. Zabbix-ek egiten duen karga-profilerako Clickhouse eraginkorragoa izango zela uste genuen aldez aurretik. Emaitzek gure itxaropenak ere gainditu zituzten:
Proba baldintza berdinetan, Clickhousek hiru aldiz datu gehiago idatzi zituen. Aldi berean, bi sistemek oso modu eraginkorrean kontsumitzen zuten (baliabide kopuru txiki bat) datuak irakurtzerakoan. Baina Elastics-ek prozesadore kopuru handia behar zuen grabatzerakoan:
Guztira, Clickhouse Elastix baino nabarmen handiagoa zen prozesadorearen kontsumoari eta abiadurari dagokionez. Aldi berean, datuen konpresioa dela eta, Clickhousek 11 aldiz gutxiago erabiltzen du disko gogorrean eta 30 aldiz gutxi gorabehera diskoko eragiketa gutxiago egiten ditu:
MCH: - Bai, Clickhouse-ren lana disko azpisistemarekin oso modu eraginkorrean inplementatzen da. Datu-baseetarako SATA disko handiak erabil ditzakezu eta segundoko ehunka mila lerroko idazketa-abiadura lor dezakezu. Kutxaz kanpoko sistemak zatiketa, erreplikazioa onartzen du eta oso erraza da konfiguratzen. Urte osoan zehar bere erabilerarekin pozik baino gehiago gaude.
Baliabideak optimizatzeko, Clickhouse instala dezakezu lehendik dagoen datu-base nagusiaren ondoan eta, horrela, CPU denbora eta disko eragiketa asko aurreztu. Neurrien artxiboa lehendik dauden Clickhouse klusteretara eraman dugu:
MySQL datu-base nagusia hainbeste arindu genuen, makina batean Zabbix zerbitzariarekin konbinatu genezakeen eta MySQLrako zerbitzari dedikatua alde batera utzi genezakeen.
Nola funtzionatzen du galdeketak Zabbixen?
Duela 4 hilabete
MM: – Beno, ahaztu al gaitezke oinarriarekin dituen arazoak?
MCH: - Hori bai! Ebatzi behar dugun beste arazo bat datu bilketa motela da. Orain gure 15 proxy zerbitzari guztiak SNMP eta galdeketa prozesuekin gainkargatuta daude. Eta ez dago zerbitzari berriak eta berriak instalatzea izan ezik.
MM: - Bikaina. Baina lehenik eta behin, esan iezaguzu nola funtzionatzen duen galdeketak Zabbixen?
MCH: – Laburbilduz, 20 metrika mota eta horiek lortzeko dozena bat modu daude. Zabbix-ek datuak bil ditzake bai "eskaera-erantzun" moduan, edo "Trapper Interface" bidez datu berriak itxaron.
Azpimarratzekoa da jatorrizko Zabbixen metodo hau (Trapper) dela azkarrena.
Karga banatzeko proxy zerbitzariak daude:
Proxiek Zabbix zerbitzariaren bilketa-funtzio berberak egin ditzakete, bertatik zereginak jasoz eta bildutako neurketak Trapper interfazearen bidez bidaliz. Hau da karga banatzeko ofizialki gomendatutako modua. Proxyak ere erabilgarriak dira NAT edo kanal motel baten bidez funtzionatzen duten urruneko azpiegiturak monitorizatzeko:
MM: – Arkitekturarekin dena argi dago. Iturburuei begiratu behar diegu...
Egun pare bat geroago
nmap fping-ak irabazi zuenaren istorioa
MM: "Uste dut zerbait zulatu dudala".
MCH: - Esaidazu!
MM: – Deskubritu nuen erabilgarritasuna egiaztatzean, Zabbix-ek gehienez 128 ostalari egiaztatzen dituela aldi berean. Zenbaki hau 500era handitzen eta paketeen arteko tartea kentzen saiatu nintzen haien ping-ean (ping) - honek errendimendua bikoiztu zuen. Baina kopuru handiagoak nahiko nituzke.
MCH: – Nire praktikan, batzuetan milaka ostalariren erabilgarritasuna egiaztatu behar dut, eta ez dut inoiz ikusi nmap baino azkarragorik horretarako. Ziur nago hau dela biderik azkarrena. Proba dezagun! Iterazio bakoitzeko ostalari kopurua nabarmen handitu behar dugu.
MM: – Bostehun baino gehiago egiaztatu? 600?
MCH: - Gutxienez mila pare bat.
MM: - ADOS. Esan nahi nuen gauzarik garrantzitsuena da aurkitu dudala Zabbixen inkesta gehienak modu sinkronikoan egiten direla. Zalantzarik gabe, modu asinkronora aldatu behar dugu. Orduan ikaragarri handitu dezakegu galdetzaileek bildutako metrika kopurua, batez ere iterazio bakoitzeko metrika kopurua handitzen badugu.
MCH: - Bikaina! Eta noiz?
MM: – Ohi bezala, atzo.
MCH: - Fping eta nmap-en bi bertsioak alderatu ditugu:
Ostalari kopuru handi batean, nmap bost aldiz eraginkorragoa izango zela espero zen. nmap-ek erabilgarritasuna eta erantzun-denbora soilik egiaztatzen dituenez, galeren kalkulua abiarazleetara eraman dugu eta erabilgarritasuna egiaztatzeko tarteak nabarmen murriztu ditugu. nmap-erako ostalari kopuru optimoa iterazio bakoitzeko 4 mila ingurukoa dela aurkitu dugu. Nmap-ek erabilgarritasun egiaztapenen CPU kostua hiru aldiz murrizteko eta tartea 120 segundotik 10era murrizteko aukera eman zigun.
Botoen optimizazioa
MM: «Orduan hasi ginen galdeketak egiten. Batez ere SNMP detekzioa eta agenteak interesatzen zitzaizkigun. Zabbixen galdeketak modu sinkronikoan egiten dira eta sistemaren eraginkortasuna areagotzeko neurri bereziak hartu dira. Modu sinkronoan, ostalariaren erabilgarritasunik ezak inkestaren degradazio handia eragiten du. Estatuen sistema oso bat dago, prozesu bereziak daude: iristezinak diren galdetzaileak, ostalari helduekin soilik lan egiten dutenak:
Egoera-matrizea erakusten duen iruzkin bat da, sistema eraginkorra izan dadin beharrezkoa den trantsizio-sistemaren konplexutasun guztia. Horrez gain, galdeketa sinkronikoa bera nahiko motela da:
Hori dela eta, milaka proxy-ren milaka inkesta-korrontek ezin izan digute beharrezko datu-kopurua bildu. Inplementazio asinkronoak hari-kopuruaren arazoak ez ezik, erabilgarri ez dauden ostalarien egoera sistema nabarmen sinplifikatu zuen, galdeketa-iterazio batean egiaztatutako edozein zenbakirentzat, gehienezko itxaron-denbora 1 denbora-muga izan baitzen:
Gainera, SNMP eskaeren galdeketa sistema aldatu eta hobetu dugu. Kontua da jende gehienak ezin dituela SNMP eskaera anitzei aldi berean erantzun. Hori dela eta, modu hibrido bat egin dugu, ostalari beraren SNMP galdeketa modu asinkronoan egiten denean:
Hau ostalari pakete osorako egiten da. Modu hau, azken finean, ez da guztiz asinkronoa baino motelagoa, ehun eta erdi SNMP balioen galdeketa denbora-muga 1 baino askoz azkarragoa baita oraindik.
Gure esperimentuek frogatu dute iterazio bakarreko eskaera-kopuru optimoa gutxi gorabehera 8 mila dela SNMP bozketarekin. Guztira, modu asinkronorako trantsizioak 200 aldiz, ehunka aldiz, inkestaren errendimendua bizkortu ahal izan digu.
MCH: – Ondorioz, inkestaren optimizazioek erakutsi zuten proxy guztiak kentzeaz gain, egiaztapen askotarako tarteak murriztu ditzakegula, eta proxyak ez dira gehiago beharko karga partekatzeko modu gisa.
Duela hiru hilabete inguru
Aldatu arkitektura - handitu karga!
MM: - Beno, Max, produktiboa izateko garaia da? Zerbitzari indartsu bat eta ingeniari on bat behar ditut.
MCH: - Ados, planifikatu dezagun. Garaia da segundoko 5 mila metriko hildako puntutik pasatzeko.
Berrikuntzaren ondoren goizean
MCH: - Misha, eguneratu ginen, baina goizerako atzera egin genuen... Asmatu zein abiadura lortu genuen?
MM: – 20 mila gehienez.
MCH: - Bai, 25! Zoritxarrez, hasi ginen tokian gaude.
MM: - Zergatik? Diagnostikorik egin al duzu?
MCH: - Bai ziur! Hona hemen, adibidez, top interesgarri bat:
MM: - Ikus dezagun. Ikusten dut galdeketa hari ugari probatu ditugula:
Baina, aldi berean, ezin zuten sistema erdira ere birziklatu:
Eta errendimendu orokorra nahiko txikia da, segundoko 4 mila metriko inguru:
Ba al dago beste ezer?
MCH: – Bai, hautesleetako baten arraza:
MM: – Hemen argi eta garbi ikusten da galdeketa prozesua “semaforoen” zain dagoela. Hauek dira sarrailak:
MCH: - Ez dago argi.
MM: – Begira, hari mordoa aldi berean bakar-bakarrik lan egin dezakeen baliabideekin lan egiten saiatzen diren egoera baten antzekoa da. Ondoren, egin dezaketen guztia denboran zehar baliabide hau partekatzea da:
Eta baliabide horrekin lan egitearen errendimendu osoa nukleo baten abiadurak mugatzen du:
Arazo hau konpontzeko bi modu daude.
Berritu makinaren hardwarea, aldatu nukleo azkarragoetara:
Edo aldatu arkitektura eta, aldi berean, karga aldatu:
MCH: – Bide batez, probako makinan borrokan baino nukleo gutxiago erabiliko ditugu, baina maiztasun 1,5 aldiz azkarragoak dira nukleo bakoitzeko!
MM: - Garbitu? Zerbitzariaren kodea begiratu behar duzu.
Datuen bidea Zabbix zerbitzarian
MCH: – Hori asmatzeko, datuak Zabbix zerbitzariaren barruan nola transferitzen diren aztertzen hasi ginen:
Irudi polita, ezta? Goazen pausoz pauso gutxi gora behera argi uzteko. Datuak biltzeaz arduratzen diren hariak eta zerbitzuak daude:
Bildutako neurketak socket baten bidez igortzen dituzte Aurreprozesadorearen kudeatzaileari, eta ilara batean gordetzen dira:
"Aurreprozesadorearen kudeatzaileak" datuak transmititzen dizkie bere langileei, hauek aurreprozesatzeko jarraibideak exekutatzen dituzte eta socket beretik itzultzen dituzte:
Horren ondoren, aurreprozesadorearen kudeatzaileak historiaren cachean gordetzen ditu:
Hortik aurrera historiako sinkerek hartzen dituzte, funtzio asko betetzen dituztenak: adibidez, abiarazleak kalkulatzea, balio-cachea betetzea eta, batez ere, neurketak historiaren biltegian gordetzea. Oro har, prozesua konplexua eta oso nahasia da.
MM: – Ikusi genuen lehenengo gauza izan zen hari gehienek “konfigurazio-cachea” deritzonerako lehiatzen zirela (zerbitzariaren konfigurazio guztiak gordetzen diren memoria-eremua). Datuak biltzeaz arduratzen diren hariek blokeo handia egiten dute bereziki:
...konfigurazioak parametroekin neurketak ez ezik, ilarak ere gordetzen baititu inkestagileek ondoren zer egin behar duten jakiteko. Galdetzaile asko daudenean eta batek konfigurazioa blokeatzen duenean, besteak eskaeren zain daude:
Hautesleek ez lukete gatazkarik izan behar
Hori dela eta, egin genuen lehenengo gauza ilara 4 zatitan banatu eta inkestagileei ilara hauek, zati hauek aldi berean, blokeatzeko aukera ematea izan zen, baldintza seguruetan:
Horrek konfigurazio-cacherako lehia kendu zuen, eta inkestaren abiadura nabarmen handitu zen. Baina gero, aurreprozesadorearen kudeatzailea lan ilara bat pilatzen hasi zela topatu genuen:
Aurreprozesadorearen kudeatzaileak lehentasunak emateko gai izan behar du
Hau errendimendu falta zen kasuetan gertatu zen. Orduan egin zezakeen guztia datuak biltzeko prozesuetako eskaerak pilatu eta haien bufferra gehitzea zen, memoria guztia kontsumitu eta huts egin arte:
Arazo hau konpontzeko, langileei bereziki eskainitako bigarren socket bat gehitu dugu:
Horrela, aurreprozesadorearen arduradunak bere lana lehenesteko aukera izan zuen eta, buffera hazten bada, zeregina kentzea moteltzea da, langileei buffer hori hartzeko aukera emanez:
Orduan, moteltzearen arrazoietako bat langileak eurak zirela deskubritu genuen, euren lanerako guztiz garrantzirik gabeko baliabide baten alde lehiatzen baitziren. Arazo hau akatsen konponketa gisa dokumentatu dugu, eta dagoeneko konpondu da Zabbix-en bertsio berrietan:
Socket kopurua handitzen dugu - emaitza lortzen dugu
Gainera, aurreprozesadorearen kudeatzailea bera botila-lepo bihurtu zen, hari bat baita. Nukleoaren abiaduran oinarritzen zen, segundoko 70 mila metriko gehienezko abiadura emanez:
Horregatik, lau langile egin genituen, lau entxufe multzorekin:
Eta horrek abiadura gutxi gorabehera 130 mila metrikora igotzeko aukera eman zigun:
Hazkundearen ez-linealtasuna historia katxearen lehia agertu izanak azaltzen du. 4 aurreprozesadore kudeatzaile eta historiako sinkers lehiatu ziren. Une honetan, gutxi gorabehera 130 mila metrika jasotzen ari ginen segundoko proba-makinan, prozesadorearen % 95ak gutxi gorabehera erabiltzen:
Duela 2,5 hilabete inguru
Snmp-komunitatearen uko egiteak NVPak bider eta erdi handitu zituen
MM: – Max, probako auto berri bat behar dut! Oraingoan jada ez gara sartzen.
MCH: - Zer daukazu orain?
MM: – Orain – 130k NVP eta apaletarako prest dagoen prozesadorea.
MCH: - Aupa! Ederra! Itxaron, bi galdera ditut. Nire kalkuluen arabera, gure beharra segundoko 15-20 mila metriko ingurukoa da. Zergatik behar dugu gehiago?
MM: "Lana amaitu nahi dut". Ikusi nahiko nuke sistema honetatik zenbat atera dezakegun.
MCH: - Baina…
MM: "Baina negozioetarako alferrikakoa da".
MCH: - Garbi dago. Eta bigarren galdera: orain daukaguna gure kabuz onartzen al dezakegu, garatzaile baten laguntzarik gabe?
MM: - Ez dut uste. Konfigurazio cachearen funtzionamendua aldatzea arazo bat da. Hari gehienetan aldaketak eragiten ditu eta nahiko zaila da mantentzea. Seguruenik, oso zaila izango da mantentzea.
MCH: "Orduan alternatiba mota bat behar dugu".
MM: - Halako aukera dago. Nukleo azkarretara alda gaitezke, blokeo sistema berria alde batera utzita. Oraindik 60-80 mila metriko errendimendua lortuko dugu. Aldi berean, gainerako kodea utzi dezakegu. Clickhouse eta inkesta asinkronoak funtzionatuko dute. Eta mantentzea erraza izango da.
MCH: - Harrigarria! Hemen gelditzea proposatzen dut.
Zerbitzariaren aldea optimizatu ondoren, azkenean kode berria ekoizpenera abiarazi ahal izan genuen. Aldaketa batzuk alde batera utzi genituen nukleo azkarrak dituen makina batera aldatzearen eta kode aldaketa kopurua gutxitzearen alde. Konfigurazioa ere sinplifikatu dugu eta datu-elementuetan makroak ezabatu ditugu ahal den neurrian, blokeo gehigarria sartzen baitute.
Esaterako, dokumentazioan eta adibideetan sarritan aurkitzen den snmp-community makroa alde batera utzita, gure kasuan NVP-ak 1,5 aldiz gehiago bizkortzea posible egin zuen.
Bi egun produkzioan egon ondoren
Gertaeren historiaren pop-up-ak kentzea
MCH: - Misha, bi egun daramatzagu sistema erabiltzen, eta dena funtzionatzen du. Baina dena funtzionatzen duenean bakarrik! Sarearen zati handi samarra transferitzeko lanak aurreikusita genituen, eta berriro eskuekin egiaztatu genuen zer igo zen eta zer ez.
MM: - Ezin! Dena 10 aldiz egiaztatu genuen. Zerbitzariak sarearen erabilgarritasun osoa ere kudeatzen du berehala.
MCH: - Bai, dena ulertzen dut: zerbitzaria, datu-basea, goia, austat, erregistroak - dena azkarra da... Baina web interfazeari begiratzen diogu, eta prozesadore bat dago "apalategian" zerbitzarian eta hau:
MM: - Garbi dago. Ikus dezagun weba. Intzidentzia aktibo ugari zeuden egoera batean, zuzeneko widget gehienak oso poliki hasi zirela ikusi genuen:
Horren arrazoia zerrendako elementu bakoitzerako sortzen diren gertakarien historiako pop-up-ak sortzea izan da. Hori dela eta, leiho hauen sorrera utzi genuen (kodean 5 lerro iruzkintzen ziren), eta honek gure arazoak konpondu zituen.
Widget-ak kargatzeko denbora, guztiz erabilgarri egon ez arren, hainbat minututik 10-15 segundo onargarrietara murriztu da, eta historia oraindik ikus daiteke denboran klik eginez:
Lanaren ostean. duela 2 hilabete
MCH: - Misha, zoaz? Hitz egin behar dugu.
MM: - Ez nuen asmorik. Zabbixekin berriro zerbait?
MCH: - Ez, lasai! Esan nahi nuen: dena dabil, eskerrik asko! Garagardo bat hartu dut.
Zabbix eraginkorra da
Zabbix sistema eta funtzio nahiko unibertsala eta aberatsa da. Instalazio txikietarako erabil daiteke kaxatik kanpo, baina beharrak hazten diren heinean, optimizatu egin behar da. Neurrien artxibo handi bat gordetzeko, erabili biltegiratze egoki bat:
- integratutako tresnak erabil ditzakezu Elasticsearch-ekin integratzeko edo testu-fitxategietara historia kargatzeko (XNUMX bertsiotik eskuragarri);
- Clickhouse-rekin dugun esperientzia eta integrazioa aprobetxatu dezakezu.
Metrikoak biltzeko abiadura nabarmen handitzeko, bildu metodo asinkronoak erabiliz eta transmititu trapper interfazearen bidez Zabbix zerbitzariari; edo adabaki bat erabil dezakezu Zabbix pollers asinkronoak egiteko.
Zabbix C-n idatzita dago eta nahiko eraginkorra da. Hainbat arkitektura-botoi konpontzeak bere errendimendua are gehiago areagotzeko aukera ematen du eta, gure esperientziaren arabera, 100 mila metrika baino gehiago lortzeko prozesadore bakarreko makina batean.
Zabbix adabaki bera
MM: – Puntu pare bat gehitu nahi ditut. Egungo txosten osoa, proba guztiak, zenbakiak erabiltzen ditugun konfiguraziorako ematen dira. Orain gutxi gorabehera 20 mila metrika hartzen ari gara segundoko. Horrek funtzionatuko dizun ulertzen saiatzen ari bazara, alderatu dezakezu. Gaur eztabaidatutakoa GitHub-en argitaratzen da adabaki moduan:
Adabakiak honako hauek ditu:
- Integrazio osoa Clickhouse-rekin (bai Zabbix zerbitzaria eta frontend-a);
- aurreprozesadorearen kudeatzailearekin arazoak konpontzea;
- galdeketa asinkronoa.
Adabakia 4. bertsio guztiekin bateragarria da, lts barne. Seguruenik, aldaketa minimoekin 3.4 bertsioan funtzionatuko du.
Eskerrik asko zure arretagatik.
Zure galderak
Entzuleen galdera (aurrerantzean – A): – Arratsalde on! Mesedez, esaidazu, ba al duzu interakzio intentsiborako planik Zabbix taldearekin edo haiekin zurekin, hau ez da adabaki bat izan, Zabbixen portaera normala baizik?
MM: – Bai, zalantzarik gabe aldaketa batzuk egingo ditugu. Zerbait gertatuko da, zerbait geratuko da adabakian.
eta: - Mila esker txosten bikainagatik! Mesedez, esaidazu, adabakia aplikatu ondoren, Zabbixen laguntza mantenduko dela eta nola jarraitu bertsio altuagoetara eguneratzen? Posible al da Zabbix eguneratzea zure adabakiaren ondoren 4.2, 5.0ra?
MM: - Ezin dut ezer esan laguntzari buruz. Zabbixen laguntza teknikoa banintz, ziurrenik ezetz esango nuke, hau beste norbaiten kodea delako. 4.2 kode-baseari dagokionez, gure jarrera hau da: "Denborarekin mugituko gara, eta hurrengo bertsioan eguneratuko gara". Hori dela eta, denbora pixka bat eguneratutako bertsioetarako adabaki bat argitaratuko dugu. Txostenean jada esan nuen: bertsioekin egindako aldaketa kopurua nahiko txikia da oraindik. Uste dut 3.4tik 4rako trantsizioak 15 minutu inguru behar izan zigula.Hor zerbait aldatu zen, baina ez oso garrantzitsua.
eta: - Beraz, zure adabakia onartzeko asmoa duzu eta segurtasunez instalatu dezakezu ekoizpenean eta nolabait eguneratzeak jaso ditzakezu etorkizunean?
MM: - Biziki gomendatzen dugu. Horrek arazo asko konpontzen dizkigu.
MCH: – Berriro ere, arreta jarri nahi dut arkitekturari dagozkion aldaketak eta blokeoak edo ilarak ez dituztenak modularrak direla, modulu bereizietan daudela. Nahiz eta aldaketa txikiak egin nahiko erraz mantendu ditzakezu.
MM: – Xehetasunak interesatzen bazaizkizu, “Clickhouse”-k historia liburutegia deritzona erabiltzen du. Askatuta dago - Elastics euskarriaren kopia bat da, hau da, konfiguragarria da. Inkestak hautesleak soilik aldatzen ditu. Horrek denbora luzez funtzionatuko duela uste dugu.
eta: - Mila esker. Esadazu, ba al dago egindako aldaketen dokumentaziorik?
MM: – Dokumentazioa adabaki bat da. Jakina, Clickhouse-ren sarrerarekin, pollers mota berriak sartuta, konfigurazio aukera berriak sortzen dira. Azken diapositibako estekak deskribapen labur bat du nola erabili.
fping nmap-ekin ordezkatzeari buruz
eta: – Nola gauzatu zenuen azkenean hau? Adibide zehatzak eman ditzakezu: strappers eta kanpoko gidoirik al duzu? Zer lortzen da hain azkar egiaztatzen ostalari kopuru handi bat? Nola ateratzen dituzu ostalari hauek? Nolabait nmap egiteko elikatu behar al ditugu, nonbaitetik atera, sartu, zerbait exekutatu?...
MM: - Cool. Oso galdera zuzena! Kontua hau da. Liburutegia (ICMP ping, Zabbix-en zatia) aldatu dugu ICMP egiaztapenetarako, pakete kopurua adierazten dutenak - bat (1), eta kodea nmap erabiltzen saiatzen da. Hau da, hau da Zabbixen barne lana, pingeraren barne lana bihurtu dena. Horrenbestez, ez da sinkronizaziorik edo tranparik erabili behar. Hau nahita egin zen, sistema osorik uzteko eta bi datu-base sistemen sinkronizazioari aurre egin beharrik ez izateko: zer egiaztatu, poller bidez igo eta gure igoera hautsita al dago?.. Hau askoz errazagoa da.
eta: – Proxietarako ere funtzionatzen du?
MM: - Bai, baina ez dugu egiaztatu. Bozketa kodea berdina da bai Zabbix-en eta baita zerbitzarian ere. Lan egin beharko luke. Azpimarra dezadan berriro ere: sistemaren errendimendua proxyrik behar ez dugulako.
MCH: – Galderaren erantzun zuzena hau da: "Zergatik behar duzu proxy bat horrelako sistema batekin?" NAT edo kanal motel baten bidez monitorizatzeagatik bakarrik...
eta: – Eta Zabbix erabiltzen duzu alergitzaile gisa, ondo ulertzen badut. Edo zure grafikoak (artxibo-geruza dagoen tokian) beste sistema batera eraman dira, Grafana adibidez? Edo ez al duzu funtzionalitate hau erabiltzen?
MM: – Beste behin azpimarratuko dut: erabateko integrazioa lortu dugu. Historia isurtzen ari gara Clickhousen, baina aldi berean php frontend-a aldatu dugu. Php frontend-a Clickhouse-ra doa eta hortik grafiko guztiak egiten ditu. Aldi berean, egia esateko, Clickhouse bereko beste bistaratze-sistema grafikoetan datuak eraikitzen dituen zati bat dugu, Zabbixeko datu beretik.
MCH: – “Grafan”-en ere bai.
Nola hartu ziren baliabideen esleipenari buruzko erabakiak?
eta: – Partekatu barruko sukaldetik apur bat. Nola hartu zen produktuaren prozesamendu seriorako baliabideak bideratzea beharrezkoa zela erabakia? Horiek, oro har, zenbait arrisku dira. Eta mesedez, esaidazu, bertsio berriak onartzen dituzula kontuan hartuta: nola justifikatzen du erabaki honek kudeaketaren ikuspuntutik?
MM: – Dirudienez, historiaren drama ez dugu oso ondo kontatu. Zerbait egin behar zen egoera batean aurkitzen ginen, eta funtsean bi talde paralelorekin joan ginen:
- Bata monitorizazio sistema bat abian jarri zen metodo berriak erabiliz: monitorizazioa zerbitzu gisa, kode irekiko soluzioen multzo estandar bat, konbinatzen ditugunak eta gero negozio-prozesua aldatzen saiatzen gara monitorizazio sistema berriarekin lan egiteko.
- Aldi berean, hau (bere buruz) egiten ari zen programatzaile gogotsu bat genuen. Gertatu zen irabazi zuela.
eta: – Eta zein da taldearen tamaina?
MCH: - Zure aurrean dago.
eta: – Beraz, beti bezala, sutsu bat behar duzu?
MM: – Ez dakit zer den sutsu bat.
eta: - Kasu honetan, itxuraz, zuk. Mila esker, izugarria zara.
MM: - Eskerrik asko.
Zabbixen adabakiei buruz
eta: – Proxyak erabiltzen dituen sistema baterako (adibidez, sistema banatu batzuetan), posible al da egokitzea eta adabakitzea, esate baterako, pollers, proxyak eta partzialki Zabbixen beraren aurreprozesadorea; eta haien elkarrekintza? Posible al da lehendik dauden garapenak optimizatzea proxy anitz dituen sistema baterako?
MM: – Badakit Zabbix zerbitzaria proxy baten bidez muntatzen dela (kodea konpilatu eta lortzen dela). Ez dugu hau probatu ekoizpenean. Ez nago ziur honetaz, baina uste dut prozesadorearen kudeatzailea ez dela erabiltzen proxyan. Proxyaren zeregina da Zabbix-etik metrika-multzo bat hartu, bateratzea (konfigurazioa ere erregistratzen du, datu-base lokala) eta Zabbix zerbitzariari itzultzea. Zerbitzariak berak egingo du aurreprozesatzea jasotzen duenean.
Proxyekiko interesa ulergarria da. Egiaztatu egingo dugu. Gai interesgarria da hau.
eta: – Ideia hau zen: pollers-ak adabaki ahal badituzu, proxy-an adabaki ditzakezu eta zerbitzariarekiko elkarrekintza adabaki dezakezu, eta aurreprozesadorea helburu horietarako zerbitzarian bakarrik egokitu.
MM: - Are sinpleagoa dela uste dut. Kodea hartu, adabaki bat aplikatu eta behar duzun moduan konfiguratzen duzu - bildu proxy zerbitzariak (adibidez, ODBCrekin) eta banatu adabakitako kodea sistema guztietan. Beharrezkoa denean - bildu proxy bat, beharrezkoa denean - zerbitzari bat.
eta: - Seguruenik, ez al duzu proxy transmisioa zerbitzariari adabaki beharrik izango?
MCH: - Ez, estandarra da.
MM: – Izan ere, ideiaren batek ez zuen soinurik izan. Ideien eztandaren eta aldaketen eta laguntza erraztasunaren arteko oreka mantendu dugu beti.
Iragarki batzuk 🙂
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz,
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik
Iturria: www.habr.com