Sljedeća HighLoad++ konferencija održat će se 6. i 7. travnja 2020. u St. Petersburgu Detalji i ulaznice . HighLoad++ Moskva 2018. Dvorana “Moskva”. 9. studenog, 15:00. Teze i .
* Praćenje - online i analitika.
* Osnovna ograničenja ZABBIX platforme.
* Rješenje za skaliranje analitičke pohrane.
* Optimizacija ZABBIX poslužitelja.
* Optimizacija korisničkog sučelja.
* Iskustvo rada sa sustavom pod opterećenjem od više od 40k NVPS.
* Kratki zaključci.
Mikhail Makurov (u daljnjem tekstu – MM): - Bok svima!
Maxim Chernetsov (u daljnjem tekstu – MCH): - Dobar dan!
MM: – Da vam predstavim Maxima. Max je talentirani inženjer, najbolji umrežavač kojeg poznajem. Maxim se bavi mrežama i uslugama, njihovim razvojem i radom.
MCH: – I htio bih vam reći o Mikhailu. Mikhail je C programer. Napisao je nekoliko rješenja za obradu prometa s velikim opterećenjem za našu tvrtku. Živimo i radimo na Uralu, u gradu čvrstih ljudi Čeljabinsku, u tvrtki Intersvyaz. Naša tvrtka pruža usluge interneta i kabelske televizije za milijun ljudi u 16 gradova.
MM: – Vrijedno je reći da je Intersvyaz mnogo više od samog pružatelja usluga, to je IT tvrtka. Većinu naših rješenja izradio je naš IT odjel.
a: od poslužitelja koji obrađuju promet do pozivnog centra i mobilne aplikacije. IT odjel sada ima oko 80 ljudi s vrlo, vrlo različitim kompetencijama.
O Zabbixu i njegovoj arhitekturi
MCH: – A sada ću pokušati postaviti osobni rekord i u jednoj minuti reći što je Zabbix (u daljnjem tekstu „Zabbix”).
Zabbix se pozicionira kao sustav za nadzor izvan kutije na razini poduzeća. Ima mnogo značajki koje olakšavaju život: napredna pravila eskalacije, API za integraciju, grupiranje i automatsko otkrivanje hostova i metrike. Zabbix ima takozvane alate za skaliranje - proxy. Zabbix je sustav otvorenog koda.
Ukratko o arhitekturi. Možemo reći da se sastoji od tri komponente:
- poslužitelj. Napisano u C. S prilično složenom obradom i prijenosom informacija između niti. U njemu se odvijaju sve obrade: od primanja do spremanja u bazu podataka.
- Svi podaci pohranjuju se u bazu podataka. Zabbix podržava MySQL, PostreSQL i Oracle.
- Web sučelje je napisano u PHP-u. Na većini sustava dolazi s Apache poslužiteljem, ali radi učinkovitije u kombinaciji s nginx + php.
Danas bismo htjeli ispričati jednu priču iz života naše tvrtke vezanu uz Zabbix...
Priča iz života tvrtke Intersvyaz. Što imamo i što nam treba?
prije 5 ili 6 mjeseci. Jedan dan nakon posla...
MCH: - Miša, zdravo! Drago mi je da sam te uspio uhvatiti - vodi se razgovor. Opet smo imali problema s praćenjem. Tijekom veće havarije sve je bilo usporeno i nije bilo informacija o stanju mreže. Nažalost, ovo nije prvi put da se to događa. Trebam tvoju pomoć. Učinimo da naš nadzor radi u svim okolnostima!
MM: - Ali idemo prvo sinkronizirati. Nisam tamo pogledao par godina. Koliko se sjećam, napustili smo Nagios i prešli na Zabbix prije otprilike 8 godina. A sada se čini da imamo 6 moćnih poslužitelja i oko desetak proxyja. Da li nešto brkam?
MCH: - Skoro. 15 poslužitelja, od kojih su neki virtualni strojevi. Najvažnije je da nas ne spašava u trenutku kada nam je najpotrebniji. Kao nesreća - poslužitelji usporavaju i ne možete ništa vidjeti. Pokušali smo optimizirati konfiguraciju, ali to nije omogućilo optimalno povećanje performansi.
MM: - To je jasno. Jeste li nešto pogledali, jeste li već nešto iskopali od dijagnostike?
MCH: – Prvo s čime se morate pozabaviti je baza podataka. MySQL se konstantno učitava, pohranjuje nove metrike, a kada Zabbix počne generirati hrpu događaja, baza podataka pretjerano radi doslovno na nekoliko sati. Već sam vam rekao o optimizaciji konfiguracije, ali doslovno ove godine ažurirali su hardver: poslužitelji imaju više od stotinu gigabajta memorije i diskovnih polja na SSD RAID-ovima - nema smisla dugoročno ga linearno povećavati. Što nam je činiti?
MM: - To je jasno. Općenito, MySQL je LTP baza podataka. Očigledno više nije prikladan za pohranjivanje arhive metrike naše veličine. Hajdemo shvatiti.
MCH: - Hajdemo!
Integracija Zabbixa i Clickhousea kao rezultat hackathona
Nakon nekog vremena dobili smo zanimljive podatke:
Većinu prostora u našoj bazi podataka zauzimala je arhiva metrika, a manje od 1% iskorišteno je za konfiguraciju, predloške i postavke. Do tada smo već više od godinu dana upravljali Big data rješenjem temeljenim na Clickhouseu. Smjer kretanja bio nam je očit. Na našem proljetnom Hackathonu napisao sam integraciju Zabbixa s Clickhouseom za poslužitelj i sučelje. U to vrijeme Zabbix je već imao podršku za ElasticSearch i odlučili smo ih usporediti.
Usporedba Clickhousea i Elasticsearcha
MM: – Za usporedbu, generirali smo isto opterećenje koje pruža Zabbix poslužitelj i gledali kako bi se sustavi ponašali. Zapisali smo podatke u serijama od 1000 redaka, koristeći CURL. Unaprijed smo pretpostavili da će Clickhouse biti učinkovitiji za profil opterećenja od Zabbixa. Rezultati su čak nadmašili naša očekivanja:
Pod istim uvjetima testiranja, Clickhouse je napisao tri puta više podataka. Pritom su oba sustava vrlo učinkovito trošila (malu količinu resursa) prilikom čitanja podataka. Ali Elastics je zahtijevao veliku količinu procesora prilikom snimanja:
Sveukupno, Clickhouse je bio znatno bolji od Elastixa što se tiče potrošnje procesora i brzine. Istodobno, zbog kompresije podataka, Clickhouse koristi 11 puta manje na tvrdom disku i izvodi približno 30 puta manje diskovnih operacija:
MCH: – Da, Clickhouseov rad s diskovnim podsustavom implementiran je vrlo učinkovito. Možete koristiti ogromne SATA diskove za baze podataka i dobiti brzine pisanja od stotina tisuća redaka u sekundi. Sustav izvan kutije podržava dijeljenje, replikaciju i vrlo ga je lako konfigurirati. Više smo nego zadovoljni njegovim korištenjem tijekom cijele godine.
Kako biste optimizirali resurse, možete instalirati Clickhouse uz svoju postojeću glavnu bazu podataka i time uštedjeti puno CPU vremena i diskovnih operacija. Premjestili smo arhivu metrike u postojeće Clickhouse klastere:
Toliko smo rasteretili glavnu MySQL bazu podataka da smo je mogli kombinirati na jednom stroju sa Zabbix poslužiteljem i napustiti namjenski poslužitelj za MySQL.
Kako anketiranje funkcionira u Zabbixu?
4 mjeseci prije
MM: – Pa, možemo li zaboraviti na probleme s bazom?
MCH: - To je sigurno! Drugi problem koji moramo riješiti je sporo prikupljanje podataka. Sada je svih naših 15 proxy poslužitelja preopterećeno SNMP-om i procesima anketiranja. I nema načina osim instalirati nove i nove servere.
MM: - Sjajno. Ali prvo, recite nam kako anketiranje funkcionira u Zabbixu?
MCH: – Ukratko, postoji 20 vrsta metrika i desetak načina kako ih dobiti. Zabbix može prikupljati podatke u načinu rada "zahtjev-odgovor" ili čekati nove podatke putem "Trapper sučelja".
Vrijedno je napomenuti da je u originalnom Zabbixu ova metoda (Trapper) najbrža.
Postoje proxy poslužitelji za raspodjelu opterećenja:
Proxiji mogu obavljati iste funkcije prikupljanja kao Zabbix poslužitelj, primati zadatke od njega i slati prikupljene metrike kroz Trapper sučelje. Ovo je službeno preporučeni način raspodjele tereta. Proxiji su također korisni za praćenje udaljene infrastrukture koja radi putem NAT-a ili sporog kanala:
MM: – S arhitekturom je sve jasno. Moramo pogledati izvore...
Par dana kasnije
Priča o tome kako je nmap fping pobijedio
MM: “Mislim da sam nešto iskopao.”
MCH: - Reci mi!
MM: – Otkrio sam da prilikom provjere dostupnosti Zabbix provjerava najviše 128 hostova odjednom. Pokušao sam povećati ovaj broj na 500 i ukloniti međupaketni interval u njihovom pingu (ping) - ovo je udvostručilo performanse. Ali volio bih veće brojke.
MCH: – U svojoj praksi ponekad moram provjeriti dostupnost tisuća hostova, a nikad nisam vidio ništa brže od nmapa za to. Siguran sam da je ovo najbrži način. Pokušajmo! Moramo značajno povećati broj hostova po iteraciji.
MM: – Provjerite više od pet stotina? 600?
MCH: - Najmanje nekoliko tisuća.
MM: - U REDU. Najvažnija stvar koju sam htio reći je da sam otkrio da se većina anketiranja u Zabbixu radi sinkrono. Definitivno ga moramo promijeniti u asinkroni način rada. Tada možemo dramatično povećati broj metrika koje prikupljaju anketari, posebno ako povećamo broj metrika po iteraciji.
MCH: - Sjajno! I kada?
MM: – Kao i obično, jučer.
MCH: – Usporedili smo obje verzije fpinga i nmapa:
Na velikom broju hostova se očekivalo da će nmap biti do pet puta učinkovitiji. Budući da nmap provjerava samo dostupnost i vrijeme odziva, prebacili smo izračun gubitaka na okidače i značajno smanjili intervale provjere dostupnosti. Otkrili smo da je optimalan broj hostova za nmap oko 4 tisuće po iteraciji. Nmap nam je omogućio smanjenje troškova CPU-a za provjere dostupnosti za tri puta i smanjenje intervala sa 120 sekundi na 10.
Optimizacija glasanja
MM: “Onda smo počeli raditi ankete. Uglavnom smo bili zainteresirani za SNMP detekciju i agente. U Zabbixu se anketiranje vrši sinkrono i poduzete su posebne mjere za povećanje učinkovitosti sustava. U sinkronom načinu rada, nedostupnost hosta uzrokuje značajnu degradaciju anketiranja. Postoji cijeli sustav stanja, postoje posebni procesi - takozvani nedostupni anketari, koji rade samo s nedostupnim hostovima:
Ovo je komentar koji pokazuje matricu stanja, svu kompleksnost sustava prijelaza koji su potrebni da bi sustav ostao učinkovit. Osim toga, samo sinkrono prozivanje je prilično sporo:
Zbog toga tisuće anketnih tokova na desecima proxy poslužitelja nisu mogli prikupiti potrebnu količinu podataka za nas. Asinkrona implementacija riješila je ne samo probleme s brojem niti, već je i značajno pojednostavila sustav stanja nedostupnih hostova, jer je za bilo koji broj provjeren u jednoj iteraciji prozivanja maksimalno vrijeme čekanja bilo 1 timeout:
Osim toga, modificirali smo i poboljšali sustav anketiranja za SNMP zahtjeve. Činjenica je da većina ljudi ne može odgovoriti na više SNMP zahtjeva u isto vrijeme. Stoga smo napravili hibridni način rada, kada se SNMP prozivanje istog hosta vrši asinkrono:
To se radi za cijeli paket domaćina. Ovaj način rada u konačnici nije sporiji od potpuno asinkronog, budući da je ispitivanje jedne i pol stotine SNMP vrijednosti još uvijek mnogo brže od 1 vremenskog ograničenja.
Naši eksperimenti su pokazali da je optimalan broj zahtjeva u jednoj iteraciji približno 8 tisuća sa SNMP prozivanjem. Sveukupno, prijelaz na asinkroni način rada omogućio nam je da ubrzamo performanse anketiranja za 200 puta, nekoliko stotina puta.
MCH: – Rezultirajuće optimizacije anketiranja pokazale su da ne samo da se možemo riješiti svih proxyja, već i smanjiti intervale za mnoge provjere, a proxyji više neće biti potrebni kao način dijeljenja opterećenja.
Prije otprilike tri mjeseca
Promijenite arhitekturu - povećajte opterećenje!
MM: - Pa, Max, je li vrijeme da postaneš produktivan? Trebam moćan server i dobrog inženjera.
MCH: - U redu, isplanirajmo to. Krajnje je vrijeme da se pomaknete s mrtve točke od 5 tisuća metrika u sekundi.
Jutro nakon nadogradnje
MCH: - Misha, ažurirali smo se, ali do jutra smo se vratili... Pogodite koju smo brzinu uspjeli postići?
MM: – 20 tisuća maksimalno.
MCH: - Da, 25! Nažalost, tu smo gdje smo krenuli.
MM: - Zašto? Jeste li radili kakvu dijagnostiku?
MCH: - Da naravno! Evo, na primjer, zanimljivog vrha:
MM: - Gledajmo. Vidim da smo isprobali veliki broj anketnih niti:
Ali u isto vrijeme nisu mogli reciklirati sustav ni napola:
A ukupna izvedba je prilično mala, oko 4 tisuće metrika u sekundi:
Ima li još nešto?
MCH: – Da, trag jednog od anketara:
MM: – Ovdje se jasno vidi da proces glasanja čeka “semafore”. Ovo su brave:
MCH: - Nejasno.
MM: – Gledajte, ovo je slično situaciji u kojoj hrpa niti pokušava raditi s resursima s kojima samo jedna može raditi u isto vrijeme. Tada sve što mogu učiniti je dijeliti ovaj resurs tijekom vremena:
A ukupna izvedba rada s takvim resursom ograničena je brzinom jedne jezgre:
Postoje dva načina za rješavanje ovog problema.
Nadogradite hardver stroja, prebacite se na brže jezgre:
Ili promijenite arhitekturu i u isto vrijeme promijenite opterećenje:
MCH: – Usput, na testnom stroju koristit ćemo manje jezgri nego na borbenom, ali one su 1,5 puta brže po frekvenciji po jezgri!
MM: - Čisto? Morate pogledati kod poslužitelja.
Putanja podataka u Zabbix poslužitelju
MCH: – Da bismo to shvatili, počeli smo analizirati kako se podaci prenose unutar Zabbix poslužitelja:
Cool slika, zar ne? Prođimo kroz to korak po korak da bude više-manje jasno. Postoje niti i usluge odgovorne za prikupljanje podataka:
Oni prenose prikupljene metrike putem utičnice upravitelju pretprocesora, gdje se spremaju u red čekanja:
"Upravitelj pretprocesora" prenosi podatke svojim radnicima, koji izvršavaju instrukcije pretprocesiranja i vraćaju ih natrag kroz isti socket:
Nakon toga, upravitelj pretprocesora ih sprema u predmemoriju povijesti:
Odatle ih preuzimaju potopnici povijesti, koji obavljaju dosta funkcija: na primjer, izračunavaju okidače, popunjavaju predmemoriju vrijednosti i, što je najvažnije, spremaju metrike u pohranu povijesti. Općenito, proces je složen i vrlo zbunjujući.
MM: – Prvo što smo vidjeli je da se većina niti natječe za takozvanu “konfiguracijsku predmemoriju” (memorijsko područje gdje su pohranjene sve konfiguracije poslužitelja). Niti odgovorne za prikupljanje podataka posebno često blokiraju:
...budući da konfiguracija ne pohranjuje samo metrike s njihovim parametrima, već i redove iz kojih anketari uzimaju informacije o tome što učiniti sljedeće. Kada postoji mnogo anketara i jedan blokira konfiguraciju, drugi čekaju zahtjeve:
Anketari se ne bi trebali sukobljavati
Stoga smo prvo što smo učinili podijelili red čekanja na 4 dijela i omogućili ispitivačima da blokiraju te redove čekanja, te dijelove u isto vrijeme, pod sigurnim uvjetima:
Ovo je uklonilo konkurenciju za konfiguracijsku predmemoriju, a brzina anketara značajno se povećala. Ali onda smo naišli na činjenicu da je upravitelj pretprocesora počeo gomilati niz poslova:
Upravitelj pretprocesora mora moći odrediti prioritete
To se događalo u slučajevima kada mu je nedostajalo učinka. Tada je sve što je mogao učiniti bilo akumulirati zahtjeve iz procesa prikupljanja podataka i zbrajati njihov međuspremnik sve dok nije potrošio svu memoriju i srušio se:
Kako bismo riješili ovaj problem, dodali smo drugu utičnicu koja je bila posebno namijenjena radnicima:
Stoga je upravitelj pretprocesora mogao odrediti prioritete svog rada i, ako međuspremnik raste, zadatak je usporiti uklanjanje, dajući radnicima priliku da preuzmu ovaj međuspremnik:
Tada smo otkrili da su jedan od razloga usporavanja i sami radnici, jer su se natjecali za resurs koji im je bio potpuno nebitan za rad. Dokumentirali smo ovaj problem kao ispravak greške i već je riješen u novim verzijama Zabbixa:
Povećavamo broj utičnica - dobivamo rezultat
Nadalje, sam upravitelj pretprocesora postao je usko grlo, jer je to jedna nit. Počivao je na brzini jezgre, dajući maksimalnu brzinu od oko 70 tisuća metrika u sekundi:
Stoga smo napravili četiri, s četiri seta utičnica, radnika:
I to nam je omogućilo da povećamo brzinu na otprilike 130 tisuća metrika:
Nelinearnost rasta objašnjava se činjenicom da se pojavila konkurencija za predmemoriju povijesti. Za njega su se natjecala 4 upravitelja pretprocesora i potapača povijesti. U ovom smo trenutku primali otprilike 130 tisuća metrika u sekundi na testnom stroju, koristeći ga otprilike 95% procesora:
Prije otprilike 2,5 mjeseca
Odbijanje snmp-zajednice povećalo je NVP-ove jedan i pol puta
MM: – Max, trebam novi testni auto! Više se ne uklapamo u sadašnju.
MCH: - Što sad imaš?
MM: – Sada – 130k NVP-ova i procesor spreman za police.
MCH: - Vau! cool! Čekaj, imam dva pitanja. Prema mojim izračunima, naša potreba je oko 15-20 tisuća metrika u sekundi. Zašto nam treba više?
MM: "Želim završiti posao." Volio bih vidjeti koliko možemo iscijediti iz ovog sustava.
MCH: - Ali…
MM: "Ali to je beskorisno za posao."
MCH: - To je jasno. I drugo pitanje: možemo li sami podržati ovo što sada imamo, bez pomoći programera?
MM: - Ne mislim. Promjena načina rada konfiguracijske predmemorije je problem. Utječe na promjene u većini niti i prilično ga je teško održavati. Najvjerojatnije će ga biti vrlo teško održavati.
MCH: "Onda nam treba neka alternativa."
MM: - Postoji takva opcija. Možemo prijeći na brze jezgre, a napustiti novi sustav zaključavanja. I dalje ćemo dobiti izvedbu od 60-80 tisuća metrika. U isto vrijeme, možemo ostaviti sav ostatak koda. Clickhouse i asinkrono prozivanje će raditi. I bit će lako održavati.
MCH: - Nevjerojatno! Predlažem da ovdje stanemo.
Nakon optimizacije poslužiteljske strane, konačno smo mogli pokrenuti novi kod u produkciju. Odustali smo od nekih promjena u korist prelaska na stroj s brzim jezgrama i minimiziranja broja promjena koda. Također smo pojednostavili konfiguraciju i eliminirali makronaredbe u podatkovnim stavkama gdje je to moguće, jer uvode dodatno zaključavanje.
Na primjer, napuštanje makronaredbe snmp-community, koja se često nalazi u dokumentaciji i primjerima, u našem je slučaju omogućila dodatno ubrzanje NVP-a za oko 1,5 puta.
Nakon dva dana u proizvodnji
Uklanjanje skočnih prozora povijesti incidenata
MCH: – Misha, koristimo sustav dva dana i sve radi. Ali samo kad sve radi! Imali smo planirani rad s prijenosom prilično velikog segmenta mreže i ponovno smo rukama provjerili što ide gore, a što ne.
MM: - Ne može biti! Sve smo provjerili 10 puta. Poslužitelj trenutno rješava čak i potpunu nedostupnost mreže.
MCH: - Da, sve razumijem: server, baza podataka, top, austat, dnevnici - sve je brzo... Ali gledamo web sučelje, a na serveru je procesor “u polici” i ovo:
MM: - To je jasno. Gledajmo web. Otkrili smo da je u situaciji u kojoj je postojao velik broj aktivnih incidenata većina live widgeta počela raditi vrlo sporo:
Razlog za to bilo je generiranje skočnih prozora povijesti incidenata koji se generiraju za svaku stavku na popisu. Stoga smo odustali od generiranja ovih prozora (komentirali smo 5 redaka u kodu) i to je riješilo naše probleme.
Vrijeme učitavanja widgeta, čak i kada su potpuno nedostupni, smanjeno je s nekoliko minuta na nama prihvatljivih 10-15 sekundi, a povijest se i dalje može pogledati klikom na vrijeme:
Nakon posla. prije 2 mjeseca
MCH: - Misha, odlaziš li? Moramo razgovarati.
MM: - Nisam namjeravao. Opet nešto sa Zabbixom?
MCH: - Ne, opusti se! Samo sam htio reći: sve radi, hvala! Imam pivo.
Zabbix je učinkovit
Zabbix je prilično univerzalan i bogat sustav i funkcije. Može se koristiti za male instalacije izvan kutije, ali kako potrebe rastu, mora se optimizirati. Za pohranjivanje velike arhive metričkih podataka upotrijebite odgovarajuću pohranu:
- možete koristiti ugrađene alate u obliku integracije s Elasticsearchom ili prijenos povijesti u tekstualne datoteke (dostupno od verzije XNUMX);
- Možete iskoristiti naše iskustvo i integraciju s Clickhouseom.
Kako biste dramatično povećali brzinu prikupljanja metrike, prikupite ih pomoću asinkronih metoda i prenesite ih kroz trapper sučelje na Zabbix poslužitelj; ili možete koristiti zakrpu da Zabbix anketare učinite asinkronima.
Zabbix je napisan u C-u i prilično je učinkovit. Rješavanje nekoliko arhitektonskih uskih grla omogućuje vam daljnje povećanje performansi i, prema našem iskustvu, dobivanje više od 100 tisuća metrika na jednoprocesorskom stroju.
Isti Zabbix patch
MM: – Želim dodati nekoliko točaka. Cjelokupno trenutno izvješće, svi testovi, brojke dane su za konfiguraciju koju koristimo. Sada iz njega uzimamo otprilike 20 tisuća metrika u sekundi. Ako pokušavate shvatiti hoće li vam ovo uspjeti, možete usporediti. Ono o čemu se danas raspravljalo objavljeno je na GitHubu u obliku zakrpe:
Zakrpa uključuje:
- puna integracija s Clickhouseom (i Zabbix poslužitelj i frontend);
- rješavanje problema s upraviteljem pretprocesora;
- asinkrono prozivanje.
Zakrpa je kompatibilna sa svim verzijama 4, uključujući lts. Najvjerojatnije će uz minimalne izmjene raditi na verziji 3.4.
Hvala na pozornosti.
pitanja
Pitanje iz publike (u daljnjem tekstu – A): – Dobar dan! Recite mi, molim vas, imate li planove za intenzivnu interakciju sa Zabbix timom ili oni s vama, tako da ovo nije zakrpa, već normalno ponašanje Zabbixa?
MM: – Da, sigurno ćemo izvršiti neke od promjena. Nešto će se dogoditi, nešto će ostati u zakrpi.
a: – Hvala vam puno na izvrsnoj reportaži! Recite mi, molim vas, nakon primjene zakrpe, podrška Zabbixa će ostati i kako nastaviti s ažuriranjem na novije verzije? Hoće li biti moguće ažurirati Zabbix nakon vaše zakrpe na 4.2, 5.0?
MM: – O podršci ne mogu ništa reći. Da sam ja Zabbix tehnička podrška, vjerojatno bih rekao ne, jer je ovo tuđi kod. Što se tiče kodne baze 4.2, naš stav je: "Mi ćemo se kretati s vremenom i ažurirat ćemo se na sljedećoj verziji." Stoga ćemo neko vrijeme objavljivati zakrpu za ažurirane verzije. Već sam rekao u izvješću: broj izmjena s verzijama je još uvijek prilično mali. Mislim da nam je za prijelaz s 3.4 na 4 trebalo nekih 15 minuta, tu se nešto promijenilo, ali ne previše bitno.
a: – Dakle, planirate podržati svoju zakrpu i možete je sigurno instalirati u produkciji i primati ažuriranja na neki način u budućnosti?
MM: – Toplo preporučujemo. To nam rješava mnoge probleme.
MCH: – Još jednom želim skrenuti pozornost da su promjene koje se ne tiču arhitekture i ne tiču se blokade ili redova čekanja modularne, one su u zasebnim modulima. Čak i s manjim promjenama možete ih vrlo lako održavati.
MM: – Ako vas zanimaju detalji, onda “Clickhouse” koristi takozvanu biblioteku povijesti. Nevezan je - kopija je Elastics podrške, odnosno konfigurabilan je. Anketiranje mijenja samo anketare. Vjerujemo da će ovo još dugo raditi.
a: - Hvala puno. Recite mi, postoji li dokumentacija o izvršenim promjenama?
MM: – Dokumentacija je zakrpa. Očito, s uvođenjem Clickhousea, s uvođenjem novih vrsta anketara, pojavljuju se nove mogućnosti konfiguracije. Poveznica s posljednjeg slajda ima kratak opis kako ga koristiti.
O zamjeni fpinga s nmapom
a: – Kako ste to na kraju uspjeli provesti? Možete li dati konkretne primjere: imate li strappere i vanjsku skriptu? Što na kraju tako brzo provjerava tako velik broj hostova? Kako rudarite ove hostove? Trebamo li ih nekako ubaciti u nmap, nabaviti odnekud, staviti, pokrenuti nešto?..
MM: - Kul. Vrlo korektno pitanje! Poanta je ovo. Modificirali smo biblioteku (ICMP ping, dio Zabbixa) za ICMP provjere, koje označavaju broj paketa - jedan (1), a kod pokušava koristiti nmap. Odnosno, ovo je interni rad Zabbixa, koji je postao interni rad pingera. Sukladno tome, nije potrebna nikakva sinkronizacija niti korištenje trappera. To je učinjeno namjerno kako bi sustav ostao netaknut i kako se ne bismo morali baviti sinkronizacijom dvaju sustava baza podataka: što provjeriti, uploadati kroz poller i je li naš upload pokvaren?.. Ovo je mnogo jednostavnije.
a: – Radi li i za proxyje?
MM: – Da, ali nismo provjeravali. Prozivni kod je isti iu Zabbixu i na poslužitelju. Trebalo bi raditi. Još jednom želim naglasiti: performanse sustava su takve da nam ne treba proxy.
MCH: – Točan odgovor na pitanje je: “Zašto vam treba proxy s takvim sustavom?” Samo zbog NAT-a ili praćenja preko nekakvog sporog kanala...
a: – I koristite Zabbix kao alertor, ako sam dobro shvatio. Ili ste svoju grafiku (gdje je arhivski sloj) premjestili na drugi sustav, npr. Grafana? Ili ne koristite ovu funkciju?
MM: – Još jednom ću naglasiti: postigli smo potpunu integraciju. Ubacujemo povijest u Clickhouse, ali smo u isto vrijeme promijenili php sučelje. Php sučelje ide u Clickhouse i tamo radi svu grafiku. U isto vrijeme, da budemo iskreni, imamo dio koji gradi podatke u drugim sustavima grafičkog prikaza iz istog Clickhousea, iz istih Zabbix podataka.
MCH: – I u “Grafanu”.
Kako su se donosile odluke o raspodjeli sredstava?
a: – Podijelite malo svoje unutarnje kuhinje. Kako je donesena odluka da je potrebno izdvojiti sredstva za ozbiljnu preradu proizvoda? To su općenito određeni rizici. I molim vas recite mi, u kontekstu činjenice da ćete podržati nove verzije: kako je ova odluka opravdana sa stajališta upravljanja?
MM: – Očigledno nismo dobro ispričali dramu povijesti. Našli smo se u situaciji da se nešto mora poduzeti, a u biti smo išli s dvije paralelne ekipe:
- Jedan je bio pokretanje sustava nadzora s novim metodama: monitoring kao usluga, standardni set open source rješenja koje kombiniramo i zatim pokušavamo promijeniti poslovni proces kako bismo radili s novim sustavom nadzora.
- U isto vrijeme, imali smo entuzijastičnog programera koji je to radio (o sebi). Dogodilo se da je pobijedio.
a: – A kolika je veličina momčadi?
MCH: - Ona je ispred tebe.
a: – Dakle, kao i uvijek, treba vam pasionar?
MM: – Ne znam što je pasionar.
a: - U ovom slučaju, izgleda, ti. Hvala vam puno, super ste.
MM: - Hvala.
O zakrpama za Zabbix
a: – Za sustav koji koristi proxy (npr. u nekim distribuiranim sustavima), je li moguće prilagoditi i zakrpati, recimo, pollere, proxije i djelomično predprocesor samog Zabbixa; i njihovu interakciju? Je li moguće optimizirati postojeće razvoje za sustav s više proxy poslužitelja?
MM: – Znam da je Zabbix poslužitelj sastavljen pomoću proxyja (kod se kompilira i dobiva). Ovo nismo testirali u proizvodnji. Nisam siguran u ovo, ali mislim da se upravitelj pretprocesora ne koristi u proxyju. Zadatak proxyja je uzeti skup metrika od Zabbixa, spojiti ih (također bilježi konfiguraciju, lokalnu bazu podataka) i vratiti ih Zabbix poslužitelju. Poslužitelj će sam izvršiti pretprocesiranje kada ga primi.
Interes za opunomoćenike je razumljiv. Provjerit ćemo. Ovo je zanimljiva tema.
a: – Ideja je bila sljedeća: ako možete zakrpati anketare, možete ih zakrpati na proxyju i zakrpati interakciju s poslužiteljem, a pretprocesor prilagoditi za te svrhe samo na poslužitelju.
MM: – Mislim da je još jednostavnije. Uzmete kod, primijenite zakrpu, zatim ga konfigurirate onako kako vam je potrebno - prikupite proxy poslužitelje (na primjer, s ODBC-om) i distribuirajte zakrpani kod po sustavima. Gdje je potrebno - prikupite proxy, gdje je potrebno - poslužitelj.
a: – Najvjerojatnije nećete morati dodatno krpati proxy prijenos na poslužitelj?
MCH: – Ne, to je standardno.
MM: – Zapravo, jedna od ideja nije zvučala. Uvijek smo održavali ravnotežu između eksplozije ideja i količine promjena te lakoće podrške.
Neki oglasi 🙂
Hvala što ste ostali s nama. Sviđaju li vam se naši članci? Želite li vidjeti više zanimljivog sadržaja? Podržite nas narudžbom ili preporukom prijateljima, , jedinstveni analog poslužitelja početne razine, koji smo izmislili za vas: (dostupno s RAID1 i RAID10, do 24 jezgre i do 40 GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV podatkovnom centru u Amsterdamu? Samo ovdje u Nizozemskoj! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 USD! Pročitaj o
Izvor: www.habr.com