Naslednja konferenca HighLoad++ bo 6. in 7. aprila 2020 v Sankt Peterburgu Podrobnosti in vstopnice . HighLoad++ Moskva 2018. Dvorana "Moskva". 9. november, 15:00. Teze in .
* Spremljanje - spletno in analitika.
* Osnovne omejitve platforme ZABBIX.
* Rešitev za skaliranje shranjevanja analitike.
* Optimizacija strežnika ZABBIX.
* Optimizacija uporabniškega vmesnika.
* Izkušnje z upravljanjem sistema pri obremenitvah z več kot 40k NVPS.
* Kratki zaključki.
Mihail Makurov (v nadaljevanju – MM): - Pozdravljeni vsi skupaj!
Maxim Chernetsov (v nadaljnjem besedilu - MCH): - Dober večer!
MM: – Naj vam predstavim Maxima. Max je nadarjen inženir, najboljši mrežni operater, kar jih poznam. Maxim se ukvarja z omrežji in storitvami, njihovim razvojem in delovanjem.
MCH: – In rad bi vam povedal o Mikhailu. Mikhail je razvijalec C. Za naše podjetje je napisal več rešitev za obdelavo prometa z visoko obremenitvijo. Živimo in delamo na Uralu, v mestu žilavih mož Čeljabinsku, v podjetju Intersvyaz. Naše podjetje je ponudnik storitev interneta in kabelske televizije za milijon ljudi v 16 mestih.
MM: – In treba je povedati, da je Intersvyaz veliko več kot le ponudnik, je IT podjetje. Večino naših rešitev izdeluje naš IT oddelek.
A: od strežnikov za obdelavo prometa do klicnega centra in mobilne aplikacije. Oddelek za informatiko zdaj šteje približno 80 ljudi z zelo, zelo različnimi kompetencami.
O Zabbixu in njegovi arhitekturi
MCH: – In zdaj bom poskušal postaviti osebni rekord in v eni minuti povedati, kaj je Zabbix (v nadaljnjem besedilu »Zabbix«).
Zabbix se pozicionira kot nadzorni sistem na ravni podjetja. Ima veliko funkcij, ki olajšajo življenje: napredna pravila stopnjevanja, API za integracijo, združevanje in samodejno zaznavanje gostiteljev in meritev. Zabbix ima tako imenovana orodja za skaliranje – proxy. Zabbix je odprtokodni sistem.
Na kratko o arhitekturi. Lahko rečemo, da je sestavljen iz treh komponent:
- Strežnik. Napisano v C. S precej zapleteno obdelavo in prenosom informacij med nitmi. V njej potekajo vse obdelave: od prejema do shranjevanja v bazo.
- Vsi podatki so shranjeni v bazi podatkov. Zabbix podpira MySQL, PostreSQL in Oracle.
- Spletni vmesnik je napisan v PHP. V večini sistemov je opremljen s strežnikom Apache, vendar deluje učinkoviteje v kombinaciji z nginx + php.
Danes bi radi povedali eno zgodbo iz življenja našega podjetja, povezano z Zabbixom...
Zgodba iz življenja podjetja Intersvyaz. Kaj imamo in kaj potrebujemo?
5 ali 6 mesecev nazaj. En dan po službi...
MCH: - Miša, zdravo! Vesela sem, da sem te uspela ujeti - sledi pogovor. Spet smo imeli težave s spremljanjem. Med večjo nesrečo je bilo vse počasno in ni bilo nobenih informacij o stanju omrežja. Na žalost se to ni zgodilo prvič. Rabim vašo pomoč. Poskrbimo, da bo naše spremljanje delovalo v vseh okoliščinah!
MM: - Toda najprej se sinhronizirajmo. Že nekaj let nisem pogledal tja. Kolikor se spomnim, smo pred približno 8 leti opustili Nagios in prešli na Zabbix. In zdaj se zdi, da imamo 6 močnih strežnikov in približno ducat posrednikov. Sem kaj zamešal?
MCH: - Skoraj. 15 strežnikov, od katerih so nekateri virtualni stroji. Najpomembneje pa je, da nas ne reši v trenutku, ko jo najbolj potrebujemo. Kot nesreča - strežniki se upočasnijo in ne vidite ničesar. Poskušali smo optimizirati konfiguracijo, vendar to ni zagotovilo optimalnega povečanja zmogljivosti.
MM: - To je jasno. Si kaj pogledal, si že kaj izbrskal od diagnostike?
MCH: – Prva stvar, s katero se morate ukvarjati, je baza podatkov. MySQL se nenehno nalaga, shranjuje nove metrike, in ko Zabbix začne generirati kup dogodkov, se baza podatkov preobremeni za dobesedno nekaj ur. O optimizaciji konfiguracije sem vam že povedal, a dobesedno letos so posodobili strojno opremo: strežniki imajo več kot sto gigabajtov pomnilnika in diskovna polja na SSD RAID-ih - dolgoročno nima smisla linearno rasti. Kaj počnemo?
MM: - To je jasno. Na splošno je MySQL zbirka podatkov LTP. Očitno ni več primeren za shranjevanje arhiva metrik naše velikosti. Ugotovimo.
MCH: - Dajmo!
Integracija Zabbix in Clickhouse kot rezultat hackathona
Čez nekaj časa smo prejeli zanimive podatke:
Večino prostora v naši podatkovni bazi je zasedel arhiv metrik, manj kot 1 % pa je bil uporabljen za konfiguracijo, predloge in nastavitve. Do takrat smo že več kot leto dni upravljali rešitev Big data, ki temelji na Clickhouse. Smer gibanja nam je bila očitna. Na našem spomladanskem Hackathonu sem napisal integracijo Zabbixa s Clickhouseom za strežnik in frontend. Takrat je Zabbix že imel podporo za ElasticSearch in odločili smo se, da jih primerjamo.
Primerjava Clickhouse in Elasticsearch
MM: – Za primerjavo smo ustvarili enako obremenitev, kot jo zagotavlja strežnik Zabbix, in pogledali, kako se bodo sistemi obnašali. Podatke smo pisali v paketih po 1000 vrstic z uporabo CURL. Vnaprej smo domnevali, da bo Clickhouse učinkovitejši za profil obremenitve kot Zabbix. Rezultati so celo presegli naša pričakovanja:
Pri enakih testnih pogojih je Clickhouse zapisal trikrat več podatkov. Hkrati sta oba sistema zelo učinkovito porabljala (majhno količino virov) pri branju podatkov. Toda Elastics je pri snemanju zahteval veliko količino procesorja:
Skupno je bil Clickhouse bistveno boljši od Elastixa glede porabe procesorja in hitrosti. Hkrati Clickhouse zaradi stiskanja podatkov porabi 11-krat manj trdega diska in izvede približno 30-krat manj diskovnih operacij:
MCH: – Da, Clickhouseovo delo z diskovnim podsistemom se izvaja zelo učinkovito. Za baze podatkov lahko uporabite ogromne diske SATA in dosežete hitrost pisanja več sto tisoč vrstic na sekundo. Sistem, ki je že pripravljen, podpira razdeljevanje, replikacijo in je zelo enostaven za konfiguracijo. Z njegovo uporabo skozi vse leto smo več kot zadovoljni.
Če želite optimizirati vire, lahko namestite Clickhouse poleg obstoječe glavne baze podatkov in s tem prihranite veliko časa procesorja in diskovnih operacij. Arhiv metrik smo premaknili v obstoječe gruče Clickhouse:
Glavno bazo MySQL smo toliko razbremenili, da smo jo lahko na enem računalniku združili s strežnikom Zabbix in opustili namenski strežnik za MySQL.
Kako poteka glasovanje v Zabbixu?
Pred 4 meseci
MM: – No, lahko pozabimo na težave z bazo?
MCH: - To je gotovo! Druga težava, ki jo moramo rešiti, je počasno zbiranje podatkov. Zdaj je vseh naših 15 proxy strežnikov preobremenjenih s SNMP in procesi anketiranja. In ni druge poti, razen nameščanja novih in novih strežnikov.
MM: - Super. Toda najprej nam povejte, kako poteka glasovanje v Zabbixu?
MCH: – Na kratko, obstaja 20 vrst metrik in ducat načinov, kako jih pridobiti. Zabbix lahko zbira podatke v načinu »zahteva-odgovor« ali čaka na nove podatke prek »Trapper Interface«.
Omeniti velja, da je v izvirnem Zabbixu ta metoda (Trapper) najhitrejša.
Obstajajo strežniki proxy za porazdelitev obremenitve:
Posredniki lahko izvajajo enake funkcije zbiranja kot strežnik Zabbix, prejemajo naloge od njega in pošiljajo zbrane meritve prek vmesnika Trapper. To je uradno priporočen način porazdelitve bremena. Proxyji so uporabni tudi za spremljanje oddaljene infrastrukture, ki deluje prek NAT ali počasnega kanala:
MM: – Z arhitekturo je vse jasno. Moramo pogledati vire ...
Nekaj dni kasneje
Zgodba o tem, kako je zmagal nmap fping
MM: "Mislim, da sem nekaj izkopal."
MCH: - Povej mi!
MM: – Ugotovil sem, da pri preverjanju razpoložljivosti Zabbix preveri največ 128 gostiteljev hkrati. Poskušal sem povečati to številko na 500 in odstraniti interval med paketi v njihovem pingu (ping) - to je podvojilo zmogljivost. Bi pa rad večje številke.
MCH: – V svoji praksi moram včasih preveriti razpoložljivost na tisoče gostiteljev in še nikoli nisem videl nič hitrejšega od nmapa za to. Prepričan sem, da je to najhitrejši način. Poskusimo! Moramo znatno povečati število gostiteljev na ponovitev.
MM: – Preverite več kot petsto? 600?
MCH: - Vsaj nekaj tisoč.
MM: - V REDU. Najpomembnejša stvar, ki sem jo želel povedati, je, da sem ugotovil, da se večina glasovanj v Zabbixu izvaja sinhrono. Vsekakor ga moramo spremeniti v asinhroni način. Potem lahko dramatično povečamo število meritev, ki jih zberejo anketarji, zlasti če povečamo število meritev na ponovitev.
MCH: - Super! In kdaj?
MM: – Kot običajno, včeraj.
MCH: – Primerjali smo obe različici fping in nmap:
Na velikem številu gostiteljev naj bi bil nmap do petkrat bolj učinkovit. Ker nmap preverja samo razpoložljivost in odzivni čas, smo izračun izgub premaknili na sprožilce in občutno zmanjšali intervale preverjanja razpoložljivosti. Ugotovili smo, da je optimalno število gostiteljev za nmap približno 4 tisoč na ponovitev. Nmap nam je omogočil trikratno znižanje stroškov procesorja za preverjanje razpoložljivosti in zmanjšanje intervala s 120 sekund na 10.
Optimizacija glasovanja
MM: »Potem smo začeli delati ankete. Zanimalo nas je predvsem zaznavanje SNMP in agenti. V Zabbixu se glasovanje izvaja sinhrono in sprejeti so bili posebni ukrepi za povečanje učinkovitosti sistema. V sinhronem načinu nerazpoložljivost gostitelja povzroči znatno poslabšanje anketiranja. Obstaja cel sistem stanj, obstajajo posebni procesi - tako imenovani nedosegljivi anketarji, ki delujejo samo z nedosegljivimi gostitelji:
To je komentar, ki prikazuje matriko stanja, vso kompleksnost sistema prehodov, ki so potrebni, da sistem ostane učinkovit. Poleg tega je samo sinhrono anketiranje precej počasno:
Zato na tisoče anketnih tokov na desetinah posrednikov ni moglo zbrati zahtevane količine podatkov za nas. Asinhrona izvedba ni rešila le težav s številom niti, ampak je tudi bistveno poenostavila sistem stanja nerazpoložljivih gostiteljev, saj je bil za poljubno število preverjenih v eni iteraciji pozivanja najdaljši čakalni čas 1 prekinitev:
Poleg tega smo spremenili in izboljšali sistem anketiranja za zahteve SNMP. Dejstvo je, da večina ljudi ne more odgovoriti na več zahtev SNMP hkrati. Zato smo naredili hibridni način, ko SNMP anketiranje istega gostitelja poteka asinhrono:
To se naredi za celoten paket gostiteljev. Ta način na koncu ni nič počasnejši od popolnoma asinhronega, saj je preverjanje ene in pol sto vrednosti SNMP še vedno veliko hitrejše od 1 časovne omejitve.
Naši poskusi so pokazali, da je optimalno število zahtev v eni iteraciji približno 8 tisoč z anketiranjem SNMP. Skupaj nam je prehod na asinhroni način omogočil, da smo zmogljivost glasovanja pospešili za 200-krat, nekaj stokrat.
MCH: – Posledične optimizacije glasovanja so pokazale, da se ne moremo samo znebiti vseh proxyjev, ampak tudi zmanjšati intervale za številna preverjanja in proxyji ne bodo več potrebni kot način za delitev bremena.
Pred približno tremi meseci
Spremenite arhitekturo - povečajte obremenitev!
MM: - No, Max, je čas, da postaneš produktiven? Potrebujem močan strežnik in dobrega inženirja.
MCH: - V redu, načrtujmo. Skrajni čas je, da se premaknemo z mrtve točke 5 tisoč metrik na sekundo.
Jutro po nadgradnji
MCH: - Miša, posodabljali smo se, a zjutraj smo se vrnili nazaj ... Uganete, kakšno hitrost nam je uspelo doseči?
MM: – največ 20 tisoč.
MCH: - Ja, 25! Na žalost smo tam, kjer smo začeli.
MM: Zakaj? Ste opravili kakšno diagnostiko?
MCH: - Ja seveda! Tukaj je na primer zanimiv vrh:
MM: - Poglejmo. Vidim, da smo preizkusili ogromno niti za glasovanje:
Toda hkrati sistema niso mogli reciklirati niti do polovice:
In skupna zmogljivost je precej majhna, približno 4 tisoč meritev na sekundo:
Še kaj drugega?
MCH: – Da, posnetek enega od anketarjev:
MM: – Tukaj lahko jasno vidite, da postopek glasovanja čaka na "semaforje". To so ključavnice:
MCH: - Nejasno.
MM: – Poglejte, to je podobno situaciji, ko poskuša skupina niti delati z viri, s katerimi lahko naenkrat dela samo ena. Potem lahko vse, kar lahko storijo, delijo ta vir skozi čas:
In skupna zmogljivost dela s takim virom je omejena s hitrostjo enega jedra:
Ta problem lahko rešite na dva načina.
Nadgradite strojno opremo stroja, preklopite na hitrejša jedra:
Ali pa spremenite arhitekturo in hkrati spremenite obremenitev:
MCH: – Mimogrede, na testnem stroju bomo uporabili manj jeder kot na bojnem, vendar so frekvenca na jedro 1,5-krat hitrejša!
MM: - Jasno? Pogledati morate kodo strežnika.
Podatkovna pot v strežniku Zabbix
MCH: – Da bi to ugotovili, smo začeli analizirati, kako se podatki prenašajo znotraj strežnika Zabbix:
Kul slika, kajne? Pojdimo skozi to korak za korakom, da bo bolj ali manj jasno. Za zbiranje podatkov so odgovorne niti in storitve:
Zbrane metrike prek vtičnice posredujejo upravitelju predprocesorja, kjer se shranijo v čakalno vrsto:
»Upravitelj predprocesorja« posreduje podatke svojim delavcem, ki izvajajo navodila za predprocesiranje in jih vračajo nazaj skozi isto vtičnico:
Po tem jih upravitelj predprocesorja shrani v predpomnilnik zgodovine:
Od tam jih vzamejo pogrezilci zgodovine, ki opravljajo precej funkcij: na primer računanje sprožilcev, polnjenje predpomnilnika vrednosti in, kar je najpomembneje, shranjevanje metrik v shrambo zgodovine. Na splošno je postopek zapleten in zelo zmeden.
MM: – Prva stvar, ki smo jo videli, je bila, da večina niti tekmuje za tako imenovani »konfiguracijski predpomnilnik« (pomnilniško območje, kjer so shranjene vse konfiguracije strežnika). Niti, odgovorne za zbiranje podatkov, še posebej veliko blokirajo:
... saj konfiguracija ne shranjuje samo metrik z njihovimi parametri, ampak tudi čakalne vrste, iz katerih anketarji jemljejo informacije o tem, kaj storiti naprej. Ko je veliko vprašalnikov in eden blokira konfiguracijo, drugi čakajo na zahteve:
Anketarji se ne smejo prepirati
Zato smo prvo, kar smo naredili, razdelili čakalno vrsto na 4 dele in omogočili anketarjem, da blokirajo te čakalne vrste, te dele hkrati, pod varnimi pogoji:
To je odstranilo konkurenco za konfiguracijski predpomnilnik in hitrost anketarjev se je znatno povečala. Potem pa smo naleteli na dejstvo, da je upravitelj predprocesorja začel kopičiti čakalno vrsto opravil:
Upravitelj predprocesorja mora imeti možnost določanja prioritet
To se je zgodilo v primerih, ko mu je manjkalo. Nato je lahko naredil le kopičenje zahtev iz procesov zbiranja podatkov in seštevanje njihovega medpomnilnika, dokler ni porabilo vsega pomnilnika in se zrušilo:
Za rešitev te težave smo dodali drugo vtičnico, ki je bila posebej namenjena delavcem:
Tako je imel upravitelj predprocesorja možnost, da določi prednost svojega dela in, če se vmesni pomnilnik poveča, je naloga upočasniti odstranitev, kar daje delavcem možnost, da vzamejo ta vmesni pomnilnik:
Potem smo ugotovili, da so eden od razlogov za upočasnitev delavci sami, saj so se potegovali za vir, ki je za njihovo delo popolnoma nepomemben. To težavo smo dokumentirali kot popravek napake in je bila že odpravljena v novih različicah Zabbixa:
Povečamo število vtičnic - dobimo rezultat
Poleg tega je sam upravitelj predprocesorja postal ozko grlo, saj je ena nit. Temeljil je na hitrosti jedra, kar je dalo največjo hitrost približno 70 tisoč metrik na sekundo:
Zato smo izdelali štiri delavce s štirimi kompleti vtičnic:
In to nam je omogočilo povečanje hitrosti na približno 130 tisoč metrik:
Nelinearnost rasti je razložena z dejstvom, da se je pojavila konkurenca za predpomnilnik zgodovine. Zanj so se potegovali 4 upravitelji predprocesorjev in potapljači zgodovine. Na tej točki smo na testnem stroju prejemali približno 130 tisoč metrik na sekundo, kar je izkoriščalo približno 95 % procesorja:
Pred približno 2,5 meseca
Zavrnitev skupnosti snmp je povečala NVP za enkrat in pol
MM: – Max, potrebujem nov testni avto! Ne sodimo več v sedanjo.
MCH: - Kaj imaš zdaj?
MM: – Sedaj – 130 NVP-jev in procesor, pripravljen za shranjevanje.
MCH: - Vau! kul! Čakaj, imam dve vprašanji. Po mojih izračunih je naša potreba okoli 15-20 tisoč metrik na sekundo. Zakaj potrebujemo več?
MM: "Želim dokončati delo." Rad bi videl, koliko lahko iztisnemo iz tega sistema.
MCH: - Ampak ...
MM: "Ampak to je neuporabno za posel."
MCH: - To je jasno. In drugo vprašanje: ali lahko to, kar imamo, podpiramo sami, brez pomoči razvijalca?
MM: - Mislim, da ne. Spreminjanje delovanja konfiguracijskega predpomnilnika je težava. Vpliva na spremembe v večini niti in ga je precej težko vzdrževati. Najverjetneje ga bo zelo težko vzdrževati.
MCH: "Potem potrebujemo neko alternativo."
MM: - Obstaja taka možnost. Lahko preidemo na hitra jedra, pri tem pa opustimo nov sistem zaklepanja. Še vedno bomo dosegli zmogljivost 60-80 tisoč meritev. Hkrati lahko pustimo vso preostalo kodo. Clickhouse in asinhrono glasovanje bo delovalo. In vzdrževati ga bo enostavno.
MCH: - Neverjetno! Predlagam, da se ustavimo tukaj.
Po optimizaciji strežniške strani smo končno lahko lansirali novo kodo v proizvodnjo. Opustili smo nekatere spremembe v korist preklopa na stroj s hitrimi jedri in zmanjšali število sprememb kode. Prav tako smo poenostavili konfiguracijo in odpravili makre v podatkovnih postavkah, kjer je to mogoče, saj uvajajo dodatno zaklepanje.
Na primer, opustitev makra snmp-community, ki ga pogosto najdemo v dokumentaciji in primerih, je v našem primeru omogočila dodatno pospešitev NVP za približno 1,5-krat.
Po dveh dneh proizvodnje
Odstranjevanje pojavnih oken zgodovine dogodkov
MCH: – Miša, sistem uporabljamo dva dni in vse deluje. Ampak samo takrat, ko vse deluje! Imeli smo načrtovano delo s prenosom dokaj velikega segmenta omrežja in spet smo z rokami preverili, kaj gre gor in kaj ne.
MM: - Ne more biti! Vse smo preverili 10-krat. Strežnik v trenutku obravnava celo popolno nedosegljivost omrežja.
MCH: - Ja, razumem vse: strežnik, baza podatkov, vrh, austat, dnevniki - vse je hitro ... Ampak pogledamo spletni vmesnik in na strežniku je procesor "na polici" in to:
MM: - To je jasno. Pazimo na splet. Ugotovili smo, da je v razmerah, ko je bilo veliko aktivnih incidentov, večina aktivnih pripomočkov začela delovati zelo počasi:
Razlog za to je bilo ustvarjanje pojavnih oken zgodovine incidentov, ki se ustvarijo za vsak element na seznamu. Zato smo opustili generiranje teh oken (zakomentirali 5 vrstic v kodi) in to je rešilo naše težave.
Čas nalaganja gradnikov, tudi ko so popolnoma nedostopni, se je zmanjšal z nekaj minut na za nas sprejemljivih 10-15 sekund, zgodovino pa si še vedno lahko ogledate s klikom na čas:
Po delu. 2 meseca nazaj
MCH: - Miša, odhajaš? Moramo govoriti.
MM: - Nisem nameraval. Spet kaj z Zabbixom?
MCH: - Ne, sprosti se! Hotel sem samo reči: vse deluje, hvala! Imam pivo.
Zabbix je učinkovit
Zabbix je dokaj univerzalen in bogat sistem in funkcije. Uporablja se lahko za majhne namestitve takoj, ko so potrebe vedno večje, ga je treba optimizirati. Za shranjevanje velikega arhiva metrik uporabite ustrezno shrambo:
- uporabite lahko vgrajena orodja v obliki integracije z Elasticsearch ali nalaganje zgodovine v besedilne datoteke (na voljo od različice 4);
- Izkoristite lahko naše izkušnje in integracijo s Clickhouse.
Če želite dramatično povečati hitrost zbiranja metrik, jih zberite z asinhronimi metodami in jih posredujte prek vmesnika trapperja na strežnik Zabbix; lahko pa uporabite popravek, da naredite anketarje Zabbix asinhrone.
Zabbix je napisan v C in je precej učinkovit. Reševanje več arhitekturnih ozkih grl vam omogoča, da dodatno povečate njegovo zmogljivost in po naših izkušnjah pridobite več kot 100 tisoč metrik na enoprocesorskem stroju.
Isti popravek Zabbix
MM: – Rad bi dodal nekaj točk. Celotno trenutno poročilo, vsi testi, številke so podane za konfiguracijo, ki jo uporabljamo. Zdaj iz njega jemljemo približno 20 tisoč metrik na sekundo. Če poskušate razumeti, ali bo to delovalo za vas, lahko primerjate. O čemer smo danes razpravljali, je objavljeno na GitHubu v obliki popravka:
Popravek vključuje:
- popolna integracija s Clickhouse (strežnik Zabbix in frontend);
- reševanje težav z upraviteljem predprocesorja;
- asinhrono anketiranje.
Popravek je združljiv z vsemi različicami 4, vključno z lts. Najverjetneje bo z minimalnimi spremembami deloval na različici 3.4.
Hvala za vašo pozornost.
vprašanja
Vprašanje iz občinstva (v nadaljevanju – A): – Dober dan! Povejte mi, prosim, ali imate načrte za intenzivno interakcijo z ekipo Zabbix ali z njimi z vami, tako da to ni popravek, ampak normalno delovanje Zabbixa?
MM: – Da, nekatere spremembe bomo zagotovo uvedli. Nekaj se bo zgodilo, nekaj bo ostalo v obližu.
A: – Najlepša hvala za odlično poročilo! Prosim, povejte mi, ali bo po uporabi popravka podpora Zabbixa ostala in kako nadaljevati posodabljanje na višje različice? Ali bo po vašem popravku možno posodobiti Zabbix na 4.2, 5.0?
MM: – O podpori ne morem reči ničesar. Če bi bil jaz tehnična podpora Zabbix, bi verjetno rekel ne, ker je to koda nekoga drugega. Kar zadeva kodno osnovo 4.2, je naše stališče: "S časom se bomo premaknili in posodobili se bomo na naslednjo različico." Zato bomo nekaj časa objavljali popravek za posodobljene različice. V poročilu sem že povedal: število sprememb z različicami je še vedno precej majhno. Mislim, da nam je prehod iz 3.4 na 4 vzel približno 15 minut, nekaj se je spremenilo, vendar ne zelo pomembno.
A: – Torej nameravate podpreti svoj popravek in ga lahko varno namestite v produkcijo ter v prihodnosti na nek način prejemate posodobitve?
MM: – Toplo priporočamo. To nam reši veliko težav.
MCH: – Še enkrat bi rad opozoril na dejstvo, da so spremembe, ki ne zadevajo arhitekture in ne zadevajo blokad ali čakalnih vrst, modularne, so v ločenih modulih. Tudi z manjšimi spremembami jih lahko enostavno vzdržujete.
MM: – Če vas zanimajo podrobnosti, potem »Clickhouse« uporablja tako imenovano zgodovinsko knjižnico. Je odvezan - je kopija podpore Elastics, torej jo je mogoče konfigurirati. Anketiranje spremeni le anketarje. Verjamemo, da bo to delovalo še dolgo.
A: - Najlepša hvala. Povejte mi, ali obstaja kakšna dokumentacija o opravljenih spremembah?
MM: – Dokumentacija je popravek. Očitno se z uvedbo Clickhousea, z uvedbo novih vrst anketarjev, pojavijo nove konfiguracijske možnosti. Povezava z zadnjega diapozitiva vsebuje kratek opis uporabe.
O zamenjavi fping z nmap
A: – Kako ste to končno uresničili? Lahko navedete konkretne primere: ali imate strapperje in zunanji scenarij? Zakaj se tako hitro preveri tako veliko število gostiteljev? Kako rudarite te gostitelje? Ali jih moramo nekako nahraniti v nmap, jih dobiti od nekod, vstaviti, nekaj zagnati?..
MM: - Kul. Zelo korektno vprašanje! Bistvo je to. Spremenili smo knjižnico (ICMP ping, del Zabbixa) za ICMP preverjanja, ki prikazujejo število paketov - en (1), koda pa poskuša uporabiti nmap. Se pravi, to je notranje delo Zabbixa, ki je postalo notranje delo pingerja. V skladu s tem ni potrebna nobena sinhronizacija ali uporaba trapperja. To je bilo storjeno namenoma, da je sistem ostal nedotaknjen in da se nam ni bilo treba ukvarjati s sinhronizacijo dveh sistemov baz podatkov: kaj preveriti, naložiti prek anketarja in ali je naše nalaganje pokvarjeno?.. To je veliko preprostejše.
A: – Ali deluje tudi za posrednike?
MM: – Da, vendar nismo preverili. Koda za glasovanje je enaka v Zabbixu in strežniku. Moralo bi delovati. Naj še enkrat poudarim: zmogljivost sistema je takšna, da proxyja ne potrebujemo.
MCH: – Pravilen odgovor na vprašanje je: "Zakaj potrebujete proxy s takim sistemom?" Samo zaradi NAT-a ali spremljanja preko kakšnega počasnega kanala...
A: – In Zabbix uporabljate kot alertor, če prav razumem. Ali pa so vašo grafiko (kjer je arhivski sloj) premaknili v drug sistem, na primer Grafana? Ali pa ne uporabljate te funkcije?
MM: – Še enkrat poudarjam: dosegli smo popolno integracijo. Zgodovino prelivamo v Clickhouse, a smo hkrati spremenili php frontend. Php frontend gre v Clickhouse in od tam naredi vso grafiko. Hkrati, če smo iskreni, imamo del, ki gradi podatke v drugih grafičnih prikazovalnih sistemih iz iste Clickhouse, iz istih podatkov Zabbix.
MCH: – Tudi v “Grafanu”.
Kako so se odločali o dodelitvi sredstev?
A: – Delite malo svoje notranje kuhinje. Kako je prišlo do odločitve, da je treba nameniti sredstva za resno predelavo izdelka? To so na splošno določena tveganja. In prosim, povejte mi, v kontekstu dejstva, da boste podpirali nove različice: kako je ta odločitev upravičena z vidika upravljanja?
MM: – Očitno nismo dobro povedali drame zgodovine. Znašli smo se v situaciji, ko je bilo treba nekaj narediti, in smo v bistvu šli z dvema vzporednima ekipama:
- Ena je bila uvedba sistema spremljanja z novimi metodami: spremljanje kot storitev, standardni nabor odprtokodnih rešitev, ki jih kombiniramo in nato poskušamo spremeniti poslovni proces, da bi deloval z novim sistemom spremljanja.
- Istočasno smo imeli navdušenega programerja, ki je to počel (o sebi). Tako se je zgodilo, da je zmagal.
A: – In kakšna je velikost ekipe?
MCH: - Ona je pred vami.
A: – Torej, kot vedno, potrebujete pasijonar?
MM: – Ne vem, kaj je pasijonar.
A: - V tem primeru očitno ti. Najlepša hvala, super ste.
MM: - Hvala.
O popravkih za Zabbix
A: – Ali je za sistem, ki uporablja proxyje (npr. v nekaterih porazdeljenih sistemih), mogoče prilagoditi in zakrpati recimo pollerje, proxyje in delno predprocesor samega Zabbixa; in njihova interakcija? Ali je mogoče optimizirati obstoječi razvoj za sistem z več posredniki?
MM: – Vem, da je strežnik Zabbix sestavljen s pomočjo proxyja (koda je prevedena in pridobljena). Tega nismo preizkusili v proizvodnji. O tem nisem prepričan, vendar mislim, da se upravitelj predprocesorja ne uporablja v proxyju. Naloga proxyja je, da vzame nabor metrik iz Zabbixa, jih združi (zapisuje tudi konfiguracijo, lokalno bazo podatkov) in jih vrne strežniku Zabbix. Strežnik bo nato izvedel predhodno obdelavo, ko ga prejme.
Zanimanje za pooblaščence je razumljivo. Bomo preverili. To je zanimiva tema.
A: – Ideja je bila naslednja: če lahko zakrpate anketarje, jih lahko zakrpate na proxyju in popravite interakcijo s strežnikom ter prilagodite predprocesor za te namene samo na strežniku.
MM: – Mislim, da je še bolj preprosto. Vzamete kodo, uporabite popravek, nato pa ga konfigurirate tako, kot želite – zberete proxy strežnike (na primer z ODBC) in razdelite popravljeno kodo po sistemih. Kjer je potrebno - zberite proxy, kjer je potrebno - strežnik.
A: – Najverjetneje vam ne bo treba dodatno krpati proxy prenosa na strežnik?
MCH: - Ne, to je standardno.
MM: – Pravzaprav ena od idej ni zvenela. Vedno smo ohranjali ravnovesje med eksplozijo idej in količino sprememb ter enostavnostjo podpore.
Nekaj oglasov 🙂
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com