Najnja konferenca HighLoad++ bo potekala 6. in 7. aprila 2020 v Sankt Peterburgu. Podrobnosti in vstopnice . HighLoad++ Moskva 2018. Dvorana „Moskva“. 9. novembra, ob 15:00. Povzetki in .
* Spremljanje – na spletu in analiza.
* Glavne omejitve platforme ZABBIX.
* Rešitev za skaliranje skladišča analitike.
* Optimizacija strežnika ZABBIX.
* Optimizacija uporabniškega vmesnika.
* Izkušnje z uporabo sistema pri obremenitvah nad 40k NVPS.
* Na kratko ugotovitve.
Mikhail Makurov (nadalje – MM): – Vsem pozdrav!
Maxim Chernetsov (nadalje – MČ): – Dober dan!
MM: – Dovolite mi, da predstavim Maxima. Max je nadarjen inženir, najboljši omrežni strokovnjak, ki ga poznam. Maxim se ukvarja z omrežji in storitvami, njihovim razvojem in uporabo.
MČ: – Rad bi predstavil Mihaila. Mihail je razvijalec v programskem jeziku C. Napisal je več rešitev za obdelavo prometa z visoko obremenitvijo za naše podjetje. Živimo in delamo na Uralu, v mestu trdnih moških Čeljabinsku, v podjetju „Intersvyaz“. Naše podjetje je ponudnik internetnih in kabelskih televizijskih storitev za milijon ljudi v 16 mestih.
MM: – In treba je omeniti, da je „Intersvyaz“ mnogo več kot le ponudnik, to je IT-podjetje. Večina našega dela je rezultat truda našega IT oddelka.
O: od strežnikov, ki obdelujejo promet, do klicnega centra in mobilne aplikacije. V IT oddelku je trenutno okoli 80 ljudi z zelo raznoliko znanjem.
O Zabbixu in njegovi arhitekturi
MČ: – Zdaj bom poskusil postaviti osebni rekord in v eni minuti povedati, kaj je Zabbix (nadalje – „Zabbix“).
„Zabbix“ se pozicionira kot sistem za spremljanje „iz škatle“ na ravni podjetja. Ima veliko funkcij, ki olajšajo življenje: napredna pravila eskalacije, API za integracijo, grupiranje in samodejno odkrivanje gostiteljev in metrik. V „Zabbixu“ so tako imenovana sredstva za skaliranje – proxy. „Zabbix“ je sistem z odprtokodnim izvorom.
Na kratko o arhitekturi. Lahko rečemo, da se sestavi iz treh komponent:
- Strežnik. Napisan je v jeziku C. Z dovolj zapleteno obdelavo in prenosom informacij med nitmi. Vsa obdelava poteka tam: od prejemanja do shranjevanja v podatkovno bazo.
- Vsi podatki se shranjujejo v bazi. „Zabbix“ podpira MySQL, PostgreSQL in Oracle.
- Web vmesnik je napisan v PHP. Večina sistemov se dobavlja s strežnikom Apache, vendar deluje bolj učinkovito v kombinaciji nginx + php.
Danes bi želeli deliti eno zgodbo iz življenja naše podjetja, povezano z 'Zabbix'...
Zgodba iz življenja podjetja 'Intersvyaz'. Kaj imamo in kaj potrebujemo?
Pred 5 ali 6 meseci. Enkrat po službi...
MČ: – Miša, živjo! Vesel sem, da te lahko ujame, imamo pogovor. Spet smo imeli težave z nadzorom. Med večjo okvaro je vse zastalo, informacije o stanju omrežja pa ni bilo. Na srečo se to ne dogaja prvič. Potrebujem tvojo pomoč. Poglejva, kako lahko naš nadzor deluje v vseh okoliščinah!
MM: – Ampak najprej se uskladiva. Tja že nekaj let nisem pogledal. Kolikor se spomnim, smo pred približno 8 leti opustili Nagios in prešli na 'Zabbix'. In zdaj imamo, zdi se, 6 močnih strežnikov in približno deset proxyjev. Nič ne zmešam?
MČ: – Skoraj. 15 strežnikov, od katerih je del virtualnih strojev. Najpomembneje je, da nas to ne reši v trenutku, ko to najbolj potrebujemo. Ob okvari – strežniki upočasnijo, vse je nevidno. Poskusili smo optimizirati konfiguracijo, a optimalnega povečanja učinkovitosti to ne prinaša.
MM: – Razumem. Ali ste že kaj pogledali, kaj ste odkrili s diagnostiko?
MČ: – Prvo, s čimer se moramo ukvarjati, je ravno DB. MySQL je že tako nenehno obremenjen, ker shranjuje nove metrik, in ko 'Zabbix' začne ustvarjati kup dogodkov – baza se dobesedno zaduši za nekaj ur. O optimizaciji konfiguracije sem ti že povedal, letos pa smo dobesedno posodobili strojno opremo: strežniki imajo več kot sto gigabajtov pomnilnika in diskovne enote na SSD RAID-ih - nadaljnje linearno povečanje nima smisla. Kaj bomo naredili?
MM: – Razumem. Na splošno je MySQL LTP-baza. Očitno ta več ne ustreza shranjevanju arhiva metrik naše velikosti. Oglejva se.
MČ: – Poglejva!
Integracija Zabbix in Clickhouse kot rezultat hackathona
Po nekaj časa smo dobili zanimive podatke:
Večina mesta v naši bazi je bila zasedena s arhivom meritev, manj kot 1 % pa je bilo porabljenega za konfiguracije, predloge in nastavitve. Takrat smo že več kot leto dni uporabljali rešitev Big Data na osnovi Clickhouse. Usmeritev razvoja nam je bila jasna. Na našem pomladnem ‘Hackathonu’ sem napisal integracijo Zabbixa s Clickhouse za strežnik in frontend. Takrat je Zabbix že podpiral ElasticSearch in odločili smo se, da ju primerjamo.
Primerjava Clickhouse in Elasticsearch
MM: – Za primerjavo smo generirali obremenitev, ki jo zagotavlja Zabbix strežnik, in opazovali, kako se bosta sistemi obnesla. Podatke smo zapisovali po serijah po 1000 vrstic in uporabljali CURL. Vnaprej smo predpostavljali, da bo Clickhouse bolj učinkovit za tisto vrsto obremenitve, ki jo ustvarja Zabbix. Rezultati so celo presegli naša pričakovanja:
V enakih pogojih je Clickhouse zapisal trikrat več podatkov. Obe sistemi sta pri branju podatkov zelo učinkovito porabili malo virov. A za ElasticSearch je pri zapisovanju potrebovala veliko procesorske moči:
Skupaj je Clickhouse znatno presegel ElasticSearch po porabi procesorja in hitrosti. Hkrati zaradi stiskanja podatkov Clickhouse uporablja 11-krat manj prostora na trdem disku in izvaja približno 30-krat manj diskovnih operacij:
MČ: – Da, delo z diskovnim sistemom pri Clickhouse je zelo učinkovito. Za baze lahko uporabite ogromne SATA diske in dosežete hitrosti zapisovanja v stotinah tisoč vrstic na sekundo. Sistem ‘iz škatle’ podpira sharding, replikacijo in je zelo enostaven za nastavitev. Z njegovo uporabo smo več kot zadovoljni že eno leto.
Za optimizacijo virov lahko Clickhouse namestite poleg obstojne glavne baze in tako prihranite ogromno procesorskega časa in diskovnih operacij. Arhiv meritev smo premestili na obstoječe Clickhouse grozde:
Dovolj smo razbremenili glavno MySQL bazo, da smo jo lahko združili na enem računalniku z Zabbix strežnikom in se odpovedali namenskemu strežniku za MySQL.
Kako deluje polling v Zabbixu?
Pred 4 meseci
MM: – No, o težavah z bazo lahko pozabimo?
MČ: – To je točno! Naloga, ki jo moramo rešiti, je počasno zbiranje podatkov. Zdaj je vseh naših 15 proxy strežnikov obremenjenih s procesi SNMP in polnjenja. In ni druge izbire kot dodati nove in nove strežnike.
MM: – Odlično. Ampak povej mi najprej, kako deluje polnjenje v 'Zabbixu'?
MČ: – Na kratko, obstaja 20 vrst metrike in ducat načinov njihovega pridobivanja. 'Zabbix' lahko zbira podatke bodisi v načinu 'vprašanje – odgovor', bodisi pričakuje nove podatke preko 'Trap interface'.
Omeniti velja, da je v izvirnem 'Zabbixu' ta način (Trapper) – najhitrejši.
Obstajajo proxy strežniki za razdelitev obremenitve:
Proxy lahko opravljajo enake funkcije zbiranja kot 'Zabbix' strežnik, saj prejmejo naloge od njega in pošljejo zbrane metrike prav skozi Trap-interfejs. To je uradno priporočena metoda za razdelitev obremenitve. Prav tako so proxy koristni za spremljanje oddaljene infrastrukture, ki deluje preko NAT ali počasnega kanala:
MM: – Z arhitekturo je vse jasno. Moramo pogledati izvorne kode...
Par dni kasneje
Pripoved o tem, kako je nmap fping zmagal
MM: – Zdi se, da sem nekaj izkopal.
MČ: – Povej!
MM: – Odkrijem, da pri preverjanju dostopnosti 'Zabbix' preveri največ 128 gostiteljev hkrati. Poskusil sem povečati to številko na 500 in odstranil interval med paketi v njihovem ping (ping) – to je povečalo učinkovitost za dvakrat. Ampak želel bi še večje številke.
MČ: – V svoji praksi včasih preverjam dostopnost tisoč gostiteljev, in nič hitrejšega od nmapa do zdaj nisem srečal. Prepričan sem, da je to najhitrejši način. Poskusimo to! Moramo znatno povečati število gostiteljev na eno iteracijo.
MM: – Preveriti več kot petsto? 600?
MČ: – Vsaj nekaj tisoč.
MM: – Okej. Najpomembnejše, kar sem hotel reči: odkril sem, da je večina polnjenja v 'Zabbixu' izvedena sinhrono. Obvezno ga moramo prenoviti v asinhroni način. Takrat bomo lahko radikalno povečali število metrik, ki jih zbirajo zbiralci, še posebej, če povečamo število metrik na eno iteracijo.
MČ: – Super! In kdaj?
MM: – Kot običajno, včeraj.
MČ: – Primerjali smo obe različici fping in nmap:
Na številnih gostiteljih je bil nmap pričakovano do petkrat učinkovitejši. Ker nmap preverja le dostopnost in čas odziva, smo štetje izgub prenesli na sprožilce in močno skrajšali intervale preverjanja dostopnosti. Optimalno število gostiteljev za nmap je bilo uvrščeno okoli 4000 v eni iteraciji. Nmap nam je omogočil, da smo stroške CPU za preverjanje dostopnosti znižali trikrat in skrajšali interval s 120 sekund na 10.
Optimizacija poliranja
MM: – Nato smo se lotili polirnikov. V glavnem nas je zanimala snemanja SNMP in agenti. V "Zabbixu" je poliranje izvedeno sinhrono, sprejeti so bili posebni ukrepi za povečanje učinkovitosti sistema. V sinhronem načinu nedostopnost gostiteljev povzroča znatno degradacijo poliranja. Obstaja cela sistem stanj, obstajajo posebni procesi – t.i. unreachable-polirniki, ki delujejo le z nedostopnimi gostitelji:
To je komentar, ki prikazuje matriko stanj, vso kompleksnost sistemskih prehodov, ki so potrebni, da sistem ostane učinkovit. Poleg tega je samo sinhrono poliranje dovolj počasi:
Zato tisoči tokov polirnikov na desetih proxy-jih niso mogli zbrati potrebne količine podatkov. Asinhrona realizacija ni rešila le težav s številom tokov, ampak je tudi znatno poenostavila sistem stanj nedostopnih gostiteljev, saj je pri katerem koli številu, preverjenem v eni iteraciji poliranja, največje časovno čakanje znašalo 1 časovno omejitev:
Dodatno smo modificirali, izboljšali sistem poliranja za SNMP-izpraševanja. Dejstvo je, da večina ne more hkrati odgovarjati na več SNMP-izpraševanj. Zato smo uvedli hibridni način, kjer SNMP-poliranje istega gostitelja poteka asinhrono:
To se izvaja za celotno serijo gostiteljev. Tak način v končni fazi ni počasnejši od popolnoma asinhronega, saj je vprašanje polt stoletja SNMP-vrednosti še vedno precej hitrejše od 1 časovne omejitve.
Naši eksperimenti so pokazali, da je optimalno število izpraševanj v eni iteraciji – približno 8000 pri SNMP-poliranju. Prehod na asinhroni način je skupno omogočil 200-kratno povečanje učinkovitosti poliranja, več sto krat.
MČ: – Prejete optimizacije polling-a so pokazale, da se lahko znebimo vseh proxy-jev in skrajšamo intervale za mnoge preverbe, proxy-ji pa ne bodo več potrebni kot način razporejanja obremenitve.
Pred približno tremi meseci
Spremeni arhitekturo – povečaj obremenitev!
MM: – No, Max, čas je za produktivno delo? Potrebujem zmogljiv strežnik in dobrega inženirja.
MČ: – Dobro, načrtujmo. Že dolgo je čas, da premaknemo tisto mrtvo točko pri 5000 metrikah na sekundo.
Jutro po nadgradnji
MČ: – Miša, posodobili smo se, a se smo do jutra vrnili nazaj… Ugani, kakšne hitrosti smo dosegli?
MM: – Maksimalno 20 tisoč.
MČ: – Aha, 25! Na žalost smo tam, kjer smo začeli.
MM: – Zakaj tako? Ste naredili kakšno diagnostiko?
MČ: – Da, seveda! Tukaj, na primer, zanimiv top:
MM: – Poglejmo. Vidim, da smo poskusili z ogromno število tokov polninga:
A kljub temu nismo mogli niti polovice izkoristiti sistema:
In skupna zmogljivost je kar majhna, okoli 4000 metrik na sekundo:
Je še kaj drugega?
MČ: – Da, strace enega od pollerjev:
MM: – Tukaj je jasno vidno, da proces polninga čaka na 'semaforje'. To so zaklepi:
MČ: – Ne razumem.
MM: – Poglej, to je podobno situaciji, ko skuša veliko tokov delati z virom, s katerim lahko hkrati deluje le en. Takrat lahko vse, kar lahko počnejo, je deljenje tega vira po časovnih obdobjih:
In skupna zmogljivost dela s takim virom je omejena s hitrostjo enega jedra:
Takšno težavo lahko rešimo na dva načina.
Nadgraditi opremo naprave, preiti na hitrejša jedra:
Ali pa spremeniti arhitekturo in istočasno – obremenitev:
MČ: – Mimogrede, na testni napravi bomo uporabili manjše število jeder kot na produkcijski, vendar so zato 1,5-krat hitrejša po frekvenci na jedro!
MM: – Jasno? Moramo pogledati kodo strežnika.
Pot podatkov v strežniku Zabbix
MČ: – Da bi to razumeli, smo začeli analizirati, kako se podatki prenašajo znotraj strežnika 'Zabbix':
Super slika, kajne? Pojdimo čez to korak za korakom, da bo bolje jasno. Obstajajo tokovi in storitve, odgovorne za zbiranje podatkov:
Zbrane metrike posredujejo prek socket-a v Preprocessor manager, kjer so shranjene v čakalni vrsti:
Preprocesor-učitelj' posreduje podatke svojim delavcem, ki izvršujejo navodila za predobdelavo in jih vračajo nazaj prek istega socket-a:
Nato preprocesor menedžer je sačuvao u kešu istorije:
Odande ih uzimaju istorijski sinhronizatori, koji obavljaju mnoštvo funkcija: na primer, proračun okidača, popunjavanje keša vrednosti i, što je najvažnije, čuvanje metrika u skladištu istorije. Ukupno, proces je složen i prilično zamršen.
MM: – Prvo što smo primetili je da se većina tokova takmiči za takozvani 'konfiguracijski keš' (oblast memorije u kojoj se čuvaju sve server konfiguracije). Posebno mnogo blokada prave tokovi odgovorni za prikupljanje podataka:
…jer se u konfiguraciji čuvaju ne samo metrike sa njihovim parametrima, već i redovi iz kojih polleri uzimaju informacije o tome šta im dalje raditi. Kada je pollera puno, a jedan blokira konfiguraciju, ostali čekaju upite:
Polleri ne bi trebali sukobljavati
Zato smo prvo što smo uradili podelili red na 4 dela i dozvolili pollerima, u sigurnim uslovima, da blokiraju te redove, te delove istovremeno:
To je uklonilo konkurenciju za konfiguracijski keš, a brzina rada pollera se značajno povećala. Ali tada smo se suočili sa problemom da je preprocesor menedžer počeo da gomila red zadataka:
Preprocesor menedžer treba da zna kako da postavi prioritete
To se dešavalo u slučajevima kada mu je nedostajalo performansi. Tada je sve što je mogao da radi – da gomila zahteve od procesa prikupljanja podataka i smešta ih u bafer dok ne pojede svu memoriju i padne:
Da bismo rešili ovaj problem, dodali smo drugi soket, koji je bio posebno dodeljen radnicima:
Na taj način, preprocesor menedžer dobio je mogućnost da prioritizuje svoj rad i u slučaju širenja bafera da uspori prikupljanje, dajući radnicima mogućnost da uzmu taj bafer:
Zatim smo otkrili da je jedan od uzroka usporavanja bio sam radnici, pošto su se takmičili za potpuno nevažan resurs za njihov rad. Ovaj problem smo rešili bug-fix-om, i u novim verzijama 'Zabbix-a' je već rešen:
Povećanjem broja soketa – dobijamo rezultat
Nakon toga, sam preprocesor menedžer je postao usko grlo, pošto je to – jedan tok. Nailazio je na brzinu jezgra, dajući maksimalnu brzinu od otprilike 70 hiljada metrika u sekundi:
Zato smo ustvarili štiri, s štirimi kompleti socketov, delavcev:
In to je omogočilo povečanje hitrosti na približno 130 tisoč metrik:
Nelinearnost rasti je mogoče razložiti s tem, da je prišla konkurenca za predpomnilnik zgodovine. Za to so se borili štirje predprocesorji in sinhronizatorji zgodovine. Do tega trenutka smo na testnem stroju dobili približno 130 tisoč metrik na sekundo, pri čemer smo ga obremenjevali približno 95 % po procesorju:
Pred približno 2,5 meseca
Odziv od snmp-community je povečal NVP-je za 1,5-krat
MM: – Max, potrebujem nov testni stroj! Na trenutnem ne moremo več stisniti.
MČ: – Kaj imamo trenutno?
MM: – Trenutno imamo 130 k NVP-jev in procesor 'v polici'.
MČ: – Uau! Super! Poč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 do konca. Želim videti, koliko lahko iztisnemo iz tega sistema.
MČ: – Ampak…
MM: – Ampak zanj ni nobene koristi.
MČ: – Jasno. In drugo vprašanje: to, kar imamo zdaj, bomo lahko vzdrževali sami, brez pomoči razvijalca?
MM: – Ne mislim. Sprememba delovanja s konfiguracijskim predpomnilnikom – to je težava. Nanaša se na spremembe v večini tokov in je dovolj zapletena za vzdrževanje. Verjetno bo zelo težko to vzdrževati.
MČ: – Potem potrebujemo kakšno alternativo.
MM: – Obstaja taka možnost. Lahko preidemo na hitra jedra, pri tem pa se odpovedujemo novemu sistemu zaklepanja. Kljub temu bomo dosegli zmogljivost 60-80 tisoč metrik. Pri tem pa bomo lahko obdržali celotno drugo kodo. 'ClickHouse', asinhrono polnjenje bo delovalo. In to bo enostavno vzdrževati.
MČ: – Odlično! Predlagam, da tukaj zaključimo.
Po optimizaciji strežniškega dela smo končno uspeli zagnati novo kodo v produkcijo. Odpovedali smo se delu sprememb v korist prehoda na stroj s hitrimi jedri in minimalizacije števila sprememb v kodi. Prav tako smo poenostavili konfiguracijo in po možnosti opustili makre v podatkovnih elementih, saj so ti vir dodatnih zaklepanj.
Na primer, odpoved pogostemu makru snmp-community v naši dokumentaciji in primerih je v našem primeru omogočila dodatno pospešitev NVP-jev za približno 1,5-krat.
Po dveh dneh v produkciji
Odstranjujemo pojavna okna zgodovine incidentov
MČ: – Miša, uporabljava sistem že dva dni in vse deluje. Ampak samo, ko vse deluje! Imeli smo načrtovana dela z selitvijo precej velikega segmenta omrežja in spet smo s sodelavci preverjali, kaj je delovalo in kaj ne.
MM: – To ni mogoče! Vse smo preverili že 10-krat. Strežnik obdeluje celo popolno nedostopnost omrežja takoj.
MČ: – Vse razumem: strežnik, baza, top, austat, dnevniki – vse hitro… Ampak mi gledamo spletni vmesnik, tam pa – procesor je v slabem stanju na strežniku in tole:
MM: – Jasno. Poglejva spletno stran. Ugotovili smo, da v situacijah z veliko aktivnimi incidenti večina operativnih pripomočkov začne delovati zelo počasi:
Vzrok za to je bila generacija skočnih oken z zgodovino incidentov, ki se generirajo za vsak element na seznamu. Zato smo prenehali z generacijo teh oken (zakomentirali smo 5 vrstic v kodi) in to je rešilo naše težave.
Čas nalaganja pripomočkov se je celo ob popolni nedostopnosti skrajšal z več minut na za nas sprejemljivih 10-15 sekund, zgodovino pa je še vedno mogoče ogledati s klikom na čas:
Po delu. Pred 2 meseci
MČ: – Miša, odhajaš? Imava pogovor.
MM: – Nisem imel namena. Spet kaj s "Zabbixom"?
MČ: – Ne, sprosti se! Hotel sem samo reči: vse deluje, hvala! Jaz plačam pivo.
Zabbix je učinkovit
"Zabbix" je dovolj univerzalen in bogat sistem in funkcija. Lahko ga uporabljamo za manjše namestitve "iz škatle", toda s povečanjem potreb ga je treba optimizirati. Za shranjevanje velikega arhiva metrik uporabite ustrezno shrambo:
- lahko se poslužite vgrajenih sredstev, kot je integracija z "Elasticsearch" ali izvoženje zgodovine v besedilne datoteke (dostopno od četrte različice);
- lahko se poslužite naših izkušenj in integracije s "ClickHouse".
Za radikalno povečanje hitrosti zbiranja metrik jih zbirajte z asinkronimi metodami in jih prenašajte preko traper-interface v "Zabbix" strežnik; ali pa se lahko poslužite popravka za asinkronost polledov samega "Zabbixa".
Zabbix je napisan u C-u i dovoljno je učinkovit. Rješenje nekoliko uskih arhitektonskih mjesta dodatno povećava njegovu učinkovitost i, prema našem iskustvu, omogućava prikupljanje više od 100 tisuća metrika na jednoj procesorskoj mašini.
Ovaj tzv. Zabbix patch
MM: – Želim dodati nekoliko stvari. Sav trenutni izvještaj, svi testovi, brojke navedene su za onu konfiguraciju koja se koristi kod nas. Sa nje trenutno prikupljamo otprilike 20 tisuća metrika u sekundi. Ako pokušavate shvatiti hoće li to raditi kod vas – možete napraviti usporedbu. Ono o čemu smo danas govorili, dostupno je na GitHubu u obliku patcha:
Patch uključuje:
- potpunu integraciju s ClickHouse-om (uključujući Zabbix server i frontend);
- rješavanje problema s preprocesor menadžerom;
- asinkrono poliranje.
Patch je kompatibilan sa svim verzijama 4, uključujući LTS. Vjerovatno će raditi s minimalnim izmjenama na verziji 3.4.
Hvala na pažnji.
Vprašanja
Pitanje iz publike (dalje – P): – Dobar dan! Recite mi, molim vas, imate li planove za intenzivno surađivanje s timom Zabbix ili oni s vama, kako bi to bio normalan način rada Zabbixa, a ne samo patch?
MM: – Da, dio promjena obavezno ćemo uključiti. Neki detalji će ostati u patchu.
O: – Hvala vam puno na odličnom izlaganju! Recite mi, molim vas, nakon primjene patcha, hoće li podrška Zabbixa ostati i kako će se dalje nadograditi na više verzije? Hoće li biti mogućnosti nadogradnje Zabbixa nakon vašeg patcha na 4.2, 5.0?
MM: – O podršci ne mogu ništa reći. Da sam ja tehnička podrška Zabbixa, vjerojatno bih rekao ne, jer je to tuđi kod. Što se tiče kodne baze 4.2, naš stav je ovakav: "Krenut ćemo s vremenom i sami ćemo se nadograđivati na sljedeću verziju". Stoga ćemo neko vrijeme objavljivati patch za nove verzije. Već sam rekao u izlaganju: broj promjena između verzija za sada je dovoljno mali. Mislim da je prelazak s 3.4 na 4 kod nas trajao, činilo se, 15 minuta. Tamo se nešto promijenilo, ali nije tako bitno.
O: – Dakle, planirate podržavati svoj patch i može se sigurno uvesti u produkciju, a kasnije primati ažuriranja na neki način?
MM: – Mi to kategorički preporučujemo. To nam rješava mnogo problema.
MČ: – Še enkrat bi želel poudariti, da so spremembe, ki se ne nanašajo na arhitekturo in se ne dotikajo blokad, čakalnih vrst – modularne, te so v ločenih modulih. Tudi ob manjših spremembah jih je mogoče vzdrževati dovolj enostavno.
MM: – Če vas zanima, »Clickhouse« uporablja tako imenovano knjižnico zgodovine. Ta je ločena – gre za kopijo podpore »Elastiksa«, torej je konfiguracijsko prilagodljiva. Polling spremeni samo pollerje. Menimo, da bo to dolgo delovalo.
O: – Hvala lepa. Lahko poveste, ali obstaja kakšna dokumentacija o vnesenih spremembah?
MM: – Dokumentacija je patch. Očitno, z uvedbo »Clickhouse«, z uvedbo novih vrst pollerjev nastajajo nove konfiguracijske možnosti. Na povezavi iz zadnjega diapozitiva je kratka razlaga, kako to uporabljati.
O zamenjavi fping z nmap
O: – Kako ste to uresničili? Lahko podate konkretne primere: imate strapperje in zunanji skript? Kaj na koncu tako hitro preverja tako ogromno število gostiteljev? Kako pridobivate te gostitelje? Treba je nmapu nekako podati, pridobiti od nekod, shraniti, nekaj zagnati?..
MM: – Super. Zelo pravično vprašanje! Osnovna ideja je taka. Spremembili smo knjižnico (ICMP ping, del »Zabbix«) za ICMP preverjanja, kjer je število paketov – enota (1), koda pa poskuša uporabiti nmap. To pomeni notranje delovanje »Zabbix«, postalo je notranje delo pingerja. Tako ni potrebna nobena sinhronizacija ali uporaba trapperja. To je bilo narejeno namenoma, da obdržimo sistem celovit in se ne ukvarjamo s sinhronizacijo dveh sistemov baz: kaj preverjati, nalivati preko pollerja, ali se nam je nalivanje pokvarilo?.. To je veliko preprosteje.
O: – Ali to deluje tudi za proxy?
MM: – Da, a nismo tega preverjali. Koda pollinga je enotna v »Zabbix« in na strežniku. Mora delovati. Še enkrat poudarjam: zmogljivost sistema je taka, da proxy ni potreben.
MČ: – Pravi odgovor na vprašanje je: »Zakaj potrebujete proxy pri takšnem sistemu?« Le zaradi NAT-a ali za spremljanje preko počasne povezave...
O: – Ali vi uporabljate »Zabbix« kot alarm, če sem prav razumel. Ali so grafi (kjer je arhivska plast) odšli v drug sistem, kot je Grafana? Ali ne uporabljate te funkcionalnosti?
MM: – Ponovno naglašavam: napravili smo potpunu integraciju. Prebacujemo history u „ClickHouse“, ali smo promenili php frontend. Php frontend se povezuje s „ClickHouse“ i sve grafikone pravi odatle. Istovremeno, ako budem iskren, imamo deo koji gradi s istog „ClickHouse“, iz istih podataka „Zabbixa“ podatke u drugim sistemima za grafičko prikazivanje.
MČ: – U „Grafani“ takođe.
Kako je doneta odluka o dodeli resursa?
O: – Podelite malo unutrašnju kuhinju. Kako je doneta odluka da se izdvoje resursi za ozbiljnu preradu proizvoda? Ovo su, u suštini, određeni rizici. I recite, molim vas, u kontekstu toga da nameravate da podržavate nove verzije: kako se ova odluka opravdava sa stanovišta upravljanja?
MM: – Očigledno, dramu priče nismo dobro ispričali. Našli smo se u situaciji kada je nešto trebalo da se uradi, i krenuli smo suštinski sa dve paralelne ekipe:
- Jedna se bavila pokretanjem sistema praćenja na novim metodama: praćenje kao usluga, standardni set otvorenih rešenja, koje kombinujemo i zatim pokušavamo da promenimo poslovni proces kako bismo radili s novim sistemom praćenja.
- Paralelno je postojala entuzijasta-programer koji se time bavio (o sebi). Tako se dogodilo da je pobedio.
O: – Kolika je veličina tima?
MČ: – On je pred vama.
O: – Znači, kao uvek je potreban pasionar?
MM: – Ne znam šta je pasionar.
O: – U ovom slučaju, očigledno, vi. Hvala vam puno, vi ste sjajni.
MM: – Hvala.
O patčevima za Zabbix
O: – Za sistem koji koristi proksi (na primer, u nekim distribuiranim sistemima), da li je vaše rešenje moguće prilagoditi i patchovati, recimo, pollere, proksi i delimično preprocesor samog „Zabbixa“; i njihovu interakciju? Da li je moguće optimizovati postojeće radove za sistem sa više proksija?
MM: – Znam da se „Zabbix“ server sastavlja pomoću proksija (kompajlira se i dobija kod). Nismo to testirali u produkciji. Nisam siguran u to, ali mislim da se preprocesor-menadžer ne koristi u proksiju. Zadatak proksija je da uzme skup metrika iz „Zabbixa“, spoli ih (on takođe beleži konfiguraciju, lokalnu bazu) i vrati nazad „Zabbix“ serveru. Preprocesiranje će kasnije uraditi sam server kada ga dobije.
Zanimivost do proxijev je razumljiva. To bomo preverili. To je zanimiva tema.
O: – Ideja je bila taka: če je mogoče popravljati pollerje, jih je mogoče popravljati za proxije in prilagoditi interakcijo s strežnikom, predprocesor pa naj se za te namene prilagodi le na strežniku.
MM: – Mislim, da je vse še bolj preprosto. Vzamete kode, nanesete popravke, nato konfigurirate, kot vam ustreza – zgradite proxije (na primer z ODBC) in popravljen kodo razširite po sistemih. Kjer je potrebno, zgradite proxije, kjer je potrebno – strežnik.
O: – Dodatno verjetno ne bo potrebno popravljati prenosa proxijev na strežnik?
MČ: – Ne, ta je standardna.
MM: – V resnici ni bila izrečena ena izmed idej. Vedno smo ohranjali ravnotežje med množico idej in številom sprememb ter enostavno vzdrževanje.
Malo reklame 🙂
Hvala što ostajete s nama. Da li vam se sviđaju naši članci? Želite li videti više zanimljivih materijala? Podržite nas tako što ćete naručiti ili preporučiti prijateljima, , jedinstveni ekvivalent entry-level servera koji smo stvorili za vas: (options available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
Dell R730xd je dvostruko jeftiniji u Equinix Tier IV data centru u Amsterdamu? Only with us in the Netherlands! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — from $99! Read about how
Izvor: habr.com
