Sljedeća HighLoad++ konferencija održat će se 6. i 7. aprila 2020. u Sankt Peterburgu Detalji i ulaznice . HighLoad++ Moskva 2018. Moskovska dvorana. 9. novembar, 15:00. Sažeci i .
* Monitoring - online i analitika.
* Glavna ograničenja ZABBIX platforme.
* Rješenje za skaliranje pohrane analitike.
* Optimizacija ZABBIX servera.
* Optimizacija korisničkog sučelja.
* Iskustvo u radu sa sistemom pod opterećenjem većim od 40k NVPS.
* Kratki zaključci.
Mihail Makurov (u daljem tekstu - MM): - Zdravo svima!
Maxim Chernetsov (u daljem tekstu - MCH): - Dobar dan!
MM: Dozvolite mi da vam predstavim Maxima. Max je talentirani inženjer, najbolji networker kojeg poznajem. Maxim se bavi mrežama i uslugama, njihovim razvojem i radom.
MCH: – I želeo bih da vam pričam o Majklu. Michael je C programer. Napisao je nekoliko rješenja za obradu saobraćaja visokog opterećenja za našu kompaniju. Živimo i radimo na Uralu, u gradu čvrstih ljudi Čeljabinsku, u kompaniji Intersvyaz. Naša kompanija pruža usluge Interneta i kablovske televizije za milion ljudi u 16 gradova.
MM: - I vredi reći da je Intersvyaz mnogo više od samog provajdera, to je IT kompanija. Većinu naših rješenja izrađuje naš IT odjel.
O: od servera koji obrađuju promet do call centra i mobilne aplikacije. IT odjel sada ima oko 80 ljudi sa vrlo, vrlo raznolikim kompetencijama.
O Zabbixu i njegovoj arhitekturi
MCH: - A sada ću pokušati da postavim lični rekord i za jedan minut kažem šta je Zabbix (u daljem tekstu - "Zabbiks").
Zabbix se pozicionira kao sistem za praćenje na nivou preduzeća. Ima mnogo funkcija koje olakšavaju život: napredna pravila eskalacije, API za integraciju, grupisanje i automatsko otkrivanje hostova i metrike. Zabbix ima takozvane alate za skaliranje - proksije. Zabbix je sistem otvorenog koda.
Ukratko o arhitekturi. Možemo reći da se sastoji od tri komponente:
- Server. Napisano u C. Uz prilično složenu obradu i prijenos informacija između niti. U njemu se odvija sva obrada: od prijema do pohranjivanja u bazu podataka.
- Svi podaci se pohranjuju u bazi podataka. Zabbix podržava MySQL, PostreSQL i Oracle.
- Web interfejs je napisan u PHP-u. U većini sistema dolazi sa Apache serverom, ali radi efikasnije u kombinaciji sa nginx + php.
Danas želimo ispričati jednu priču vezanu za Zabbix iz života naše kompanije…
Priča iz života kompanije Intersvyaz. Šta imamo i šta nam treba?
prije 5 ili 6 mjeseci. Jedan dan posle posla...
MCH: - Miša, zdravo! Drago mi je da sam te uspio uhvatiti - postoji razgovor. Opet smo imali problema sa praćenjem. Tokom veće nesreće sve je usporilo, a informacija o stanju mreže nije bilo. Nažalost, ovo nije prvi put da se to dešava. Trebam tvoju pomoć. Učinimo da naš monitoring funkcionira pod bilo kojim okolnostima!
MM: Ali hajde da se prvo sinhronizujemo. Nisam tamo gledao 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 servera i desetak proksija. Da li nešto zbunjujem?
MCH: - Skoro. 15 servera, od kojih su neki virtuelne mašine. Ono što je najvažnije, ne spašava nas u trenutku kada nam je najpotrebnije. Kao nesreća - serveri usporavaju i ništa se ne vidi. Pokušali smo optimizirati konfiguraciju, ali to ne daje optimalno povećanje performansi.
MM: - To je jasno. Jesi li nešto pogledao, jesi li već nešto iskopao sa dijagnostike?
MCH: - Prva stvar sa kojom se morate pozabaviti je samo baza podataka. MySQL se već konstantno učitava, čuva nove metrike, a kada Zabbix počne generirati gomilu događaja, baza podataka ulazi sama u sebe na bukvalno nekoliko sati. Već sam vam pričao o optimizaciji konfiguracije, ali doslovno ove godine su ažurirali hardver: serveri imaju više od sto gigabajta memorije i diskovnih nizova na SSD RAID-ovima - nema smisla to linearno povećavati. Šta da radimo?
MM: - To je jasno. Generalno, MySQL je LTP baza podataka. Očigledno više nije prikladan za pohranjivanje arhive metrike naše veličine. Hajde da to shvatimo.
MCH: - Hajdemo!
Zabbix i Clickhouse integracija kao rezultat hakatona
Nakon nekog vremena dobili smo zanimljive podatke:
Najviše prostora u našoj bazi podataka zauzima arhiva metrike, a manje od 1% je iskorišteno za konfiguraciju, šablone i postavke. Do tada smo već više od godinu dana koristili Big data rješenje bazirano na Clickhouseu. Smjer kretanja za nas je bio očigledan. Na našem proljetnom Hackathonu napisao sam integraciju Zabbixa sa Clickhouse za server i frontend. U to vrijeme Zabbix je već imao podršku za ElasticSearch, a mi smo odlučili da ih uporedimo.
Poređenje Clickhouse i Elasticsearch
MM: - Poređenja radi, generisali smo opterećenje isto kao i Zabbix server i gledali kako će se sistemi ponašati. Pisali smo podatke u serijama od 1000 linija koristeći CURL. Pretpostavili smo unaprijed da će Clickhouse biti efikasniji za profil opterećenja koji Zabbix radi. Rezultati su čak i premašili naša očekivanja:
Pod istim uslovima testiranja, Clickhouse je napisao tri puta više podataka. Istovremeno, oba sistema su trošila veoma efikasno (mala količina resursa) prilikom čitanja podataka. Ali Elastics je zahtijevao veliku količinu procesora prilikom snimanja:
Ukupno, Clickhouse je značajno nadmašio Elastic u pogledu potrošnje procesora i brzine. U isto vrijeme, zbog kompresije podataka, Clickhouse koristi 11 puta manje na tvrdom disku i radi oko 30 puta manje operacija na disku:
MCH: - Da, Clickhouse-ov rad sa diskovnim podsistemom je implementiran veoma efikasno. Možete koristiti ogromne SATA diskove za baze podataka i dobiti brzinu pisanja od stotina hiljada redova u sekundi. Sistem iz kutije podržava dijeljenje, replikaciju i vrlo je jednostavan za postavljanje. Više smo nego zadovoljni njegovim radom tokom godine.
Da biste optimizirali resurse, možete instalirati Clickhouse pored postojeće glavne baze i na taj način uštedjeti mnogo CPU vremena i operacija na disku. Premjestili smo arhivu metrike u postojeće Clickhouse klastere:
Toliko smo rasteretili glavnu MySQL bazu podataka da smo je mogli kombinovati na istoj mašini sa Zabbix serverom i napustiti namenski server za MySQL.
Kako funkcionira glasanje u Zabbixu?
Prije 4 mjeseci
MM: - Pa, možeš zaboraviti na probleme sa bazom?
MCH: - To je sigurno! Još jedan izazov koji moramo riješiti je sporo prikupljanje podataka. Sada je svih naših 15 proxy servera preopterećeno SNMP-om i procesima anketiranja. I ne postoji drugi način osim instaliranja novih i novih servera.
MM: - Super. Ali prvo, kako funkcionira glasanje u Zabbixu?
MCH: – Ukratko, postoji 20 vrsta metrika i desetak načina da ih dobijete. Zabbix može prikupljati podatke ili u načinu "zahtjev-odgovor" ili čekati nove podatke preko "Trapper Interface".
Vrijedi napomenuti da je u originalnom Zabbixu ova metoda (Trapper) najbrža.
Postoje proxy serveri za balansiranje opterećenja:
Proksiji mogu obavljati iste funkcije prikupljanja kao i Zabbix server, primajući zadatke od njega i šaljući prikupljene metrike samo kroz Trapper interfejs. Ovo je službeno preporučeni način raspodjele opterećenja. Proksiji su također korisni za praćenje udaljene infrastrukture koja radi kroz NAT ili sporu vezu:
MM: Sa arhitekturom je sve jasno. Moram pogledati izvor...
Par dana kasnije
Priča o tome kako je nmap fping pobijedio
MM: “Izgleda da sam nešto iskopao.
MCH: - Reci mi!
MM: - Otkrio sam da prilikom provjere dostupnosti Zabbix provjerava do maksimalno 128 hostova u isto vrijeme. Pokušao sam povećati ovu cifru na 500 i uklonio interval između paketa u njihovom pingu (ping) - ovo je udvostručilo performanse. Ali ja bih volio velike brojeve.
MCH: - U svojoj praksi ponekad moram provjeriti dostupnost hiljada hostova, a nisam vidio ništa brže od nmapa za ovo. Siguran sam da je ovo najbrži način. Hajde da probamo! Morate značajno povećati broj hostova u jednoj iteraciji.
MM: – Provjeriti više od pet stotina? 600?
MCH: „Najmanje nekoliko hiljada.
MM: - UREDU. Najvažnija stvar koju sam htio reći je da sam otkrio da se većina anketa u Zabbixu radi sinhrono. Moramo ga promijeniti u asinhroni način rada. Tada možemo drastično povećati broj metrika koje prikupljaju anketari, posebno ako povećamo broj metrika po iteraciji.
MCH: - Super! I kada?
MM: - Kao i obično, juče.
MCH: – Uporedili smo obe verzije fpinga i nmapa:
Na velikom broju hostova, očekivalo se da će nmap biti do pet puta efikasniji. Budući da nmap samo provjerava dostupnost i vrijeme odgovora, pomjerili smo proračun gubitaka na okidače i značajno smanjili intervale provjere dostupnosti. Otkrili smo da je optimalan broj hostova za nmap oko 4 hiljade po iteraciji. Nmap nam je omogućio da smanjimo CPU troškove provjere dostupnosti za faktor tri i smanjimo interval sa 120 sekundi na 10.
Optimizacija anketiranja
MM: “Onda smo ušli u birače. Uglavnom smo bili zainteresovani za SNMP snimanje i agente. U Zabbixu se anketiranje vrši sinhrono i poduzimaju se posebne mjere za povećanje efikasnosti sistema. U sinhronom načinu rada, nedostupnost hostova uzrokuje značajnu degradaciju anketiranja. Postoji čitav sistem stanja, postoje posebni procesi - takozvani nedostupni polleri, koji rade samo sa nedostižnim domaćinima:
Ovo je komentar koji pokazuje matricu stanja, složenost tranzicionog sistema koji je potreban da bi sistem ostao efikasan. Osim toga, samo sinhrono ispitivanje je prilično sporo:
Zbog toga hiljade anketnih niti na desetak proksija nisu mogle prikupiti potrebnu količinu podataka za nas. Asinhrona implementacija je riješila ne samo probleme s brojem niti, već je i uvelike pojednostavila sistem stanja nedostupnih hostova, jer je za bilo koji broj provjeren u jednoj iteraciji anketiranja, maksimalno vrijeme čekanja bilo 1 timeout:
Dodatno, modificirali smo i poboljšali sistem glasanja za SNMP zahtjeve. Činjenica je da većina 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 asinhrono:
Ovo se radi za cijeli skup hostova. Ovaj način na kraju nije sporiji od potpuno asinhronog, budući da je prozivanje sto i pol SNMP vrijednosti i dalje mnogo brže od 1 timeouta.
Naši eksperimenti su pokazali da je optimalan broj zahtjeva u jednoj iteraciji oko 8 hiljada sa SNMP pollingom. Ukupno, prelazak na asinhroni način rada omogućio nam je da ubrzamo performanse anketiranja za 200 puta, nekoliko stotina puta.
MCH: – Rezultirajuće optimizacije anketiranja su pokazale da ne samo da se možemo riješiti svih proksija, već i smanjiti intervale za mnoge provjere, a proksiji više neće biti potrebni kao način za dijeljenje opterećenja.
Prije otprilike tri mjeseca
Promijenite arhitekturu - povećajte opterećenje!
MM: - Pa, Max, vrijeme je da budeš produktivan? Treba mi moćan server i dobar inženjer.
MCH: - Ok, hajde da planiramo. Krajnje je vrijeme da se sa mrtve tačke pomaknemo za 5 hiljada metrika u sekundi.
Jutro nakon nadogradnje
MCH: – Miša, nadogradili smo, ali smo se ujutru vratili... Pogodite koju brzinu ste uspeli da postignete?
MM: - 20 hiljada maksimalno.
MCH: - Da, 25! Nažalost, mi smo upravo tamo gdje smo počeli.
MM: - Zašto? Da li ste radili neku dijagnostiku?
MCH: - Da naravno! Evo, na primjer, zanimljivog vrha:
MM: - Hajde da gledamo. Vidim da smo isprobali ogroman broj anketnih niti:
Ali u isto vrijeme, sistem nisu mogli iskoristiti ni do pola:
A ukupna izvedba je prilično mala, oko 4 hiljade metrika u sekundi:
Ima li još nešto?
MCH: – Da, trag jednog od birača:
MM: - Ovde se jasno vidi da proces glasanja čeka "semafore". Ovo su brave:
MCH: - Nejasno.
MM: – Gledajte, to je kao situacija u kojoj gomila niti pokušava da radi sa resursima sa kojima samo jedan može da radi u isto vreme. Tada sve što mogu učiniti je podijeliti ovaj resurs po vremenu:
A ukupne performanse rada s takvim resursom ograničene su brzinom jedne jezgre:
Postoje dva načina za rješavanje ovog problema.
Nadogradite hardver mašine, pređite na brže jezgre:
Ili promijenite arhitekturu i paralelno - opterećenje:
MCH: - Inače, na testnoj mašini koristićemo manji broj jezgara nego na borbenoj, ali su one 1,5 puta brže u smislu frekvencije po jezgru!
MM: - Jasno? Potrebno je pogledati kod servera.
Putanja podataka u Zabbix serveru
MCH: - Da bismo razumjeli, počeli smo analizirati kako se podaci prenose unutar Zabbix servera:
Cool slika, zar ne? Idemo kroz to korak po korak da bismo manje-više razjasnili. Postoje niti i servisi odgovorni za prikupljanje podataka:
Oni prosleđuju prikupljene metrike kroz soket do upravitelja pretprocesora, gdje se pohranjuju u redu čekanja:
Upravitelj pretprocesora" prosljeđuje podatke svojim radnicima, koji izvršavaju instrukcije za pretprocesiranje i vraćaju ih nazad kroz isti socket:
Upravitelj predprocesora ih zatim pohranjuje u keš historije:
Odatle ih preuzimaju sinkeri istorije koji obavljaju dosta funkcija: na primjer, izračunavanje okidača, popunjavanje predmemorije vrijednosti i, što je najvažnije, čuvanje metrike u spremištu historije. Općenito, proces je složen i vrlo zbunjujući.
MM: - Prvo što smo vidjeli je da se većina niti takmiči za takozvani "konfiguracijski keš" (memorija u kojoj su pohranjene sve konfiguracije servera). Posebno puno zaključavanja čine niti odgovorne za dohvaćanje podataka:
…s obzirom da konfiguracija ne pohranjuje samo metrike sa njihovim parametrima, već i redove iz kojih anketari uzimaju informacije o tome što dalje treba učiniti. Kada ima mnogo pollera, a jedan blokira konfiguraciju, ostali čekaju na zahtjeve:
Anketari se ne bi trebali sukobljavati
Stoga, prva stvar koju smo uradili je da podijelimo red na 4 dijela i omogućimo anketarima da sigurno blokiraju ove redove, ove dijelove u isto vrijeme:
Ovo je uklonilo konkurenciju za keš konfiguracije, a brzina pollera je značajno porasla. Ali tada smo se suočili s činjenicom da je upravitelj predprocesora počeo gomilati red poslova:
Menadžer predprocesora bi trebao biti u stanju da odredi prioritete
To se dešavalo u slučajevima kada je nedostajala performansa. Tada je sve što je mogao učiniti je akumulirati zahtjeve iz procesa prikupljanja podataka i dodati njihov međuspremnik dok ne pojede svu memoriju i sruši se:
Da bismo riješili ovaj problem, dodali smo drugu utičnicu koja je namijenjena posebno za radnike:
Tako je menadžer predprocesora dobio priliku da odredi prioritete svog rada, a u slučaju rasta bafera, zadatak je da uspori uklanjanje, dajući radnicima mogućnost da pokupe ovaj bafer:
Tada smo otkrili da su jedan od razloga usporavanja bili i sami radnici, jer su se takmičili za resurs koji je bio potpuno nevažan za njihov rad. Izdali smo ispravak grešaka za ovaj problem, a on je već riješen u novim verzijama Zabbixa:
Povećavamo broj utičnica - dobijamo rezultat
Nadalje, sam predprocesor-menadžer je postao usko grlo, budući da je jedna nit. Počivao je na brzini jezgre, dajući maksimalnu brzinu od oko 70 hiljada metrika u sekundi:
Tako smo napravili četiri, sa četiri seta utičnica, radnika:
A to nam je omogućilo da povećamo brzinu na oko 130 hiljada metrika:
Nelinearnost rasta objašnjava se činjenicom da postoji konkurencija za keš historije. Za njega su se takmičila 4 menadžera predprocesora i potapača istorije. Do ovog trenutka, dobijali smo oko 130 hiljada metrika u sekundi na test mašini, koristeći je za oko 95% procesora:
Prije otprilike 2,5 mjeseca
Odbijanje snmp-zajednice povećalo je NVP za jedan i po puta
MM: Max, treba mi novi probni auto! Više se ne uklapamo u sadašnju.
MCH: – Šta sad imaš?
MM: - Sada - 130 NVP-a i procesor na policama.
MCH: - Vau! Cool! Čekaj, imam dva pitanja. Prema mojim proračunima, naša potreba je u području od 15-20 hiljada metrika u sekundi. Zašto nam treba više?
MM: - Želim da završim posao. Želim da vidim koliko možemo da izvučemo iz ovog sistema.
MCH: - Ali…
MM: Ali to je beskorisno za posao.
MCH: - To je jasno. I drugo pitanje: hoćemo li moći sami podržati ono što sada imamo, bez pomoći programera?
MM: - Ne mislim. Promjena načina na koji radi konfiguracijski keš je problem. Bavi se promjenama u većini tokova i prilično ga je teško održavati. Najvjerovatnije će ga biti vrlo teško održavati.
MCH: “Onda nam treba neka alternativa.”
MM: - Postoji takva opcija. Možemo se prebaciti na brza jezgra, dok napuštamo novi sistem blokiranja. I dalje ćemo dobiti performanse od 60-80 hiljada metrika. U ovom slučaju možemo ostaviti ostatak koda. Clickhouse, asinkrono ispitivanje će raditi. I biće lako održavati.
MCH: - Neverovatno! Predlažem da stanemo tamo.
Nakon optimizacije serverske strane, konačno smo uspjeli pokrenuti novi kod u produkciji. Odustali smo od nekih promena u korist prelaska na mašinu sa brzim jezgrom i minimiziranja broja promena u kodu. Također smo pojednostavili konfiguraciju i izbjegli makroe u stavkama gdje je to moguće, jer su izvor dodatnih zaključavanja.
Na primjer, odbacivanje makroa snmp-community, koje se često nalazi u dokumentaciji i primjerima, u našem slučaju nam je omogućilo da dodatno ubrzamo NVP-ove za oko 1,5 puta.
Nakon dva dana u proizvodnji
Uklonite iskačuće prozore za historiju incidenata
MCH: – Miša, koristimo sistem dva dana i sve radi. Ali samo kada sve funkcioniše! Planirali smo rad na prijenosu prilično velikog segmenta mreže i ponovo smo rukama provjerili šta je poraslo, a šta nije.
MM: - Ne može biti! Sve smo provjerili 10 puta. Server trenutno rješava čak i potpunu nedostupnost mreže.
MCH: - Da, razumijem sve: server, baza podataka, top, austat, logovi - sve je brzo... Ali pogledamo web interfejs, a na serveru je procesor "na polici" i ovo:
MM: - To je jasno. Pogledajmo web. Utvrdili smo da je u situaciji kada je bilo velikog broja aktivnih incidenata većina operativnih widgeta počela raditi vrlo sporo:
Razlog za to je generisanje iskačućih prozora istorije incidenata koji se generišu za svaku stavku na listi. Stoga smo odbili da generišemo ove prozore (komentarisao 5 redova u kodu), i to je rešilo naše probleme.
Vrijeme učitavanja widgeta, čak i kada je potpuno nedostupan, smanjeno je sa nekoliko minuta na 10-15 sekundi, što je za nas prihvatljivo, a povijest i dalje možete pogledati klikom na vrijeme:
Nakon posla. prije 2 mjeseca
MCH: Miša, odlaziš? Moramo razgovarati.
MM: - Nisam htela. Opet nešto sa Zabbixom?
MCH: - Ne, opusti se! Hteo sam samo da kažem: sve radi, hvala! Pivo od mene.
Zabbix je efikasan
Zabbix je prilično svestran i bogat sistem i funkcija. Može se koristiti za male instalacije izvan kutije, ali kako potrebe rastu, mora se optimizirati. Da biste pohranili veliku arhivu metrike, koristite odgovarajuću pohranu:
- možete koristiti ugrađene alate u obliku integracije sa Elasticsearch-om ili učitavanja istorije u tekstualne datoteke (dostupno od četvrte verzije);
- možete koristiti naše iskustvo i integraciju sa Clickhouse-om.
Da biste drastično povećali brzinu prikupljanja metrike, prikupite ih pomoću asinhronih metoda i prenesite ih kroz trapper interfejs na Zabbix server; ili možete koristiti zakrpu za asinhrone pollere samog Zabbixa.
Zabbix je napisan u C i prilično je efikasan. Rešenje nekoliko arhitektonskih uskih grla omogućava dalje povećanje njegovih performansi i, prema našem iskustvu, dobijanje više od 100 metrika na mašini sa jednim procesorom.
Isti Zabbix patch
MM: – Želim da dodam par stvari. Cijeli tekući izvještaj, svi testovi, brojke su date za konfiguraciju koju koristimo. Sada od njega uzimamo oko 20 hiljada metrika u sekundi. Ako pokušavate da shvatite da li će to raditi za vas - možete da uporedite. Ono o čemu smo danas razgovarali objavljeno je na GitHub-u kao zakrpa:
Zakrpa uključuje:
- puna integracija sa Clickhouse (i Zabbix server i frontend);
- rješavanje problema s upraviteljem pretprocesora;
- asinhrono ispitivanje.
Zakrpa je kompatibilna sa svim verzijama 4, uključujući lts. Najvjerovatnije će, uz minimalne izmjene, raditi na verziji 3.4.
Hvala na pažnji.
Vaša pitanja
Pitanje iz publike (u daljem tekstu - A): - Dobar dan! Molim vas recite mi da li imate planove za intenzivnu interakciju sa Zabbix timom ili oni imaju sa vama, tako da ovo nije zakrpa, već normalno ponašanje Zabbixa?
MM: – Da, neke promjene ćemo svakako izvršiti. Nešto će biti, nešto će ostati u zakrpi.
O: – Hvala vam puno na odličnom izvještaju! Recite mi, molim vas, nakon primjene zakrpe, podrška sa Zabbixa će ostati i kako nadograditi na više verzije? Hoće li biti moguće ažurirati Zabbix nakon vaše zakrpe na 4.2, 5.0?
MM: Ne mogu govoriti za podršku. Da sam ja Zabbix tehnička podrška, onda bih, očigledno, rekao ne, jer je ovo tuđi kod. Što se tiče baze koda 4.2, naš stav je: "Ići ćemo s vremenom, a mi ćemo se ažurirati na sljedećoj verziji." Stoga ćemo neko vrijeme postavljati zakrpu za ažurirane verzije. Već sam rekao u izvještaju: broj izmjena sa verzijama je još uvijek prilično mali. Mislim da nam je za prelaz sa 3.4 na 4 trebalo, čini se, nekih 15 minuta.Nešto se tu promenilo, ali ne mnogo bitno.
O: - Dakle, planirate podržati svoju zakrpu i možete je bezbedno staviti u proizvodnju, u budućnosti primajući ažuriranja na neki način?
MM: - Toplo preporučujemo. To nam rješava mnoge probleme.
MCH: - Još jednom želim da istaknem da su promjene koje se ne tiču arhitekture i ne tiču se brava, redova čekanja - modularne su, nalaze se u zasebnim modulima. Čak i sami uz manje izmjene, mogu se vrlo lako održavati.
MM: - Ako vas zanimaju detalji, onda Clickhouse koristi takozvanu historijsku biblioteku. Nevezan je - ovo je kopija Elastics podrške, odnosno podesiv je. Anketiranje mijenja samo anketare. Vjerujemo da će ovo funkcionirati još dugo.
O: - Hvala puno. A recite mi da li postoji neka dokumentacija o izvršenim promjenama?
MM: – Dokumentacija je zakrpa. Očigledno, sa uvođenjem Clickhousea, sa uvođenjem novih tipova pollera, pojavljuju se nove opcije konfiguracije. Link sa poslednjeg slajda ima kratak opis kako ga koristiti.
O zamjeni fpinga sa nmap
O: - Kako si to na kraju uradio? Možete li navesti konkretne primjere: imate li trake i eksternu skriptu? Šta na kraju tako brzo provjerava toliko domaćina? Kako rudarite ove hostove? Treba li ih nmap nekako hraniti, odnekud uzeti, staviti, pokrenuti nešto?..
MM: - Cool. Veoma valjano pitanje! Poenta je u ovome. Modificirali smo biblioteku (ICMP ping, sastavni dio Zabbixa) za ICMP provjere, koje označavaju broj paketa - jedan (1), a kod pokušava da koristi nmap. To jest, ovo je interni rad Zabbixa, postao je interni rad pingera. Shodno tome, nije potrebna nikakva sinhronizacija ili upotreba trapera. To je urađeno namjerno da bi sistem ostao netaknut i da se ne sinhronizuju dva osnovna sistema: šta provjeriti, uploadati preko pollera i da li je naš upload pokvaren?.. Mnogo je lakše.
O: – Radi li i za proksije?
MM: Da, ali nismo provjerili. Polling code je isti i u Zabbixu i na serveru. Trebalo bi da radi. Još jednom naglašavam: performanse sistema su takve da nam proxy ne treba.
MCH: - Tačan odgovor na pitanje je: "Zašto vam treba proxy sa takvim sistemom?" Samo zbog NAT-a ili da se sporim kanalom prati neki...
O: - A ti koristiš Zabbix kao alertor, ako sam dobro razumio. Ili je grafika (gdje je arhivski sloj) otišla na drugi sistem, kao što je Grafana? Ili ne koristite ovu funkciju?
MM: – Još jednom ću naglasiti: napravili smo punu integraciju. Ubacili smo istoriju u Clickhouse, ali smo u isto vreme promenili php frontend. Php-frontend ide u Clickhouse i odatle radi svu grafiku. U isto vrijeme, da budemo iskreni, imamo dio koji gradi podatke u drugim sistemima grafičkog prikaza iz istog Clickhousea, iz istih Zabbix podataka.
MCH: - U "Grafani" uključujući.
Kako je donesena odluka o raspodjeli sredstava?
O: – Podijelite dio unutrašnje kuhinje. Kako je donesena odluka da je potrebno izdvojiti sredstva za ozbiljnu preradu proizvoda? To su, generalno, određeni rizici. I molim vas recite mi, u kontekstu činjenice da ćete podržati nove verzije: kako se ova odluka opravdava sa stanovišta menadžmenta?
MM: – Očigledno nismo dobro ispričali dramu istorije. Našli smo se u situaciji da je nešto trebalo da se uradi, i krenuli smo u stvari sa dve paralelne komande:
- Jedna je bila uključena u pokretanje sistema za praćenje baziranog na novim metodama: monitoring kao servis, standardni set open source rješenja koje kombinujemo, a zatim pokušavamo promijeniti poslovni proces kako bismo mogli raditi sa novim sistemom za praćenje.
- Paralelno, imali smo entuzijastičnog programera koji je ovo radio (o sebi). Desilo se da je pobedio.
O: – A kolika je veličina tima?
MCH: Ona je ispred tebe.
O: - Odnosno, kao i uvek, potreban je pasionar?
MM: – Ne znam šta je pasionar.
O: U ovom slučaju, izgleda da ste to vi. Hvala vam puno, super ste.
MM: - Hvala.
O zakrpama za Zabbix
O: - Za sistem koji koristi proxy (na primjer, u nekim distribuiranim sistemima), da li je moguće prilagoditi i zakrpiti, recimo, pollers, proxy i djelimično preprocesor samog Zabbixa; i njihova interakcija? Da li je moguće optimizirati postojeće razvoje za sistem sa više proksija?
MM: - Znam da se "Zabbix" server sastavlja pomoću proxyja (prevodi se i dobija se kod). Ovo nismo testirali u proizvodnji. Nisam siguran u ovo, ali mislim da se upravitelj predprocesora ne koristi u proxyju. Zadatak proxyja je da uzme skup metrika od Zabbixa, da ih iznese (također snima konfiguraciju, lokalnu bazu podataka) i vrati ga Zabbix serveru. Sam server će tada obaviti prethodnu obradu kada je primi.
Interesovanje za punomoćnike je razumljivo. Mi ćemo to provjeriti. Ovo je zanimljiva tema.
O: – Ideja je bila sljedeća: ako možete zakrpiti pollere, možete ih zakrpiti na proxyju i zakrpiti interakciju sa serverom, a preprocesor prilagoditi za ove svrhe samo na serveru.
MM: - Mislim da je još lakše. Uzimate kod, primenjujete zakrpu, a zatim ga konfigurišete onako kako vam je potrebno - skupljate proxy servere (na primer, sa ODBC) i distribuirate zakrpljeni kod među sistemima. Gdje je potrebno - prikupite proxy, gdje je potrebno - server.
O: - Osim toga, najvjerovatnije nećete morati da krpite proxy transfer na server?
MCH: Ne, to je standardno.
MM: - Zapravo, jedna od ideja nije zvučala. Uvijek smo održavali ravnotežu između eksplozije ideja i broja promjena, lakoće podrške.
Neke reklame 🙂
Hvala vam što ste ostali s nama. Da li vam se sviđaju naši članci? Želite li vidjeti još zanimljivih sadržaja? Podržite nas naručivanjem ili preporukom prijateljima, , jedinstveni analog servera početnog nivoa, koji smo mi izmislili za vas: (dostupno sa RAID1 i RAID10, do 24 jezgra i do 40GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV data centru u Amsterdamu? Samo ovdje u Holandiji! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - od 99 USD! Pročitajte o
izvor: www.habr.com