HighLoad++, Mihail Makurov, Maksim Černecov (Interzvaz): Zabbix, 100kNVPS na jednom serveru

Sljedeća konferencija HighLoad++ održat će se 6. i 7. travnja 2020. godine u Sankt Peterburgu. Više detalja i karte. na linku. HighLoad++ Moskva 2018. Dvorana „Moskva“. 9. studenog, 15:00. Teze i prezentacija.

* Praćenje — online i analitika.
* Glavna ograničenja platforme ZABBIX.
* Rješenje za skaliranje skladišta analitike.
* Optimizacija ZABBIX poslužitelja.
* Optimizacija UI.
* Iskustvo eksploatacije sustava pod opterećenjima većim od 40k NVPS.
* Ukratko zaključci.

Mikhail Makurov (dalje – MM): – Pozdrav svima!

Maxim Chernetcov (dalje – MC): – Dobar dan!

MM: – Dopustite mi da vam predstavim Maxima. Max je talentirani inženjer, najbolji mrežni stručnjak kojeg znam. Maxim se bavi mrežama i uslugama, njihovim razvojem i eksploatacijom.

MC: – A ja bih želio reći nešto o Mihailu. Mihail je programer na C-u. Napisao je nekoliko visoko opterećenih rješenja za obradu prometa za našu tvrtku. Živimo i radimo na Uralu, u gradu strogih muškaraca Čeljabinsku, u tvrtki „Intersvyaz“. Naša tvrtka je pružatelj internetskih usluga i kabelske televizije za milijun ljudi u 16 gradova.

MM: – I treba reći da je „Intersvyaz“ daleko više od samo pružatelja usluga, to je IT tvrtka. Većina naših rješenja napravljena je snagom našeg IT odjela.

A: s poslužitelja koji obrađuju promet, do call centra i mobilne aplikacije. U IT odjelu trenutno je oko 80 ljudi s vrlo različitim kompetencijama.

O Zabbixu i njegovoj arhitekturi

MC: – A sada ću pokušati postaviti osobni rekord i u jednoj minuti reći što je to Zabbix (dalje – „Zabbix“).

„Zabbix“ se pozicionira kao sustav praćenja „iz kutije“ na razini poduzeća. Ima mnogo funkcija koje olakšavaju život: razvijena pravila eskalacije, API za integraciju, grupiranje i automatsko otkrivanje hostova i metrika. U „Zabbixu“ postoje tzv. alati za skaliranje – proxy. „Zabbix“ je sustav s otvorenim kodom.

Kratko o arhitekturi. Može se reći da se sastoji od tri komponente:

• Poslužitelj. Napisan na C-u. S prilično složenom obradom i prijenosom informacija između niti. Sva obrada odvija se u njemu: od primanja do pohrane u bazu.
• Svi podaci pohranjeni su u bazi. „Zabbix“ podržava MySQL, PostgreSQL i Oracle.
• Web sučelje napisano je u PHP-u. U većini sustava dolazi s Apache serverom, no učinkovitije radi u kombinaciji nginx + php.

Danas bismo željeli podijeliti 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. Jednom prilikom nakon posla…

MC: – Miša, zdravo! Drago mi je da sam te uhvatio – imamo tema za razgovor. Ponovno smo imali problema s nadzorom. Tijekom velike nesreće sve je usporilo i nije bilo nikakvih informacija o stanju mreže. Nažalost, to se događa već ne prvi put. Treba mi tvoja pomoć. Napravimo da naš nadzor radi pod svaku cijenu!

MM: – Ali najprije da se uskladimo. Nisu gledao tamo već nekoliko godina. Koliko se sjećam, odustali smo od Nagiosa i prešli na „Zabbix“ prije 8 godina. I sada imamo, činilo se, 6 snažnih servera i oko desetak proxy-a. Nisam se zabunio?

MC: – Gotovo. 15 servera, od kojih su neki virtualne mašine. Najvažnije je da to ne pomaže u trenutku kada je to najpotrebnije. Kad dođe do kvara – serveri usporavaju i ništa se ne vidi. Pokušali smo optimizirati konfiguraciju, ali nismo dobili značajan porast performansi.

MM: – Razumijem. Jesi li pogledao što, što si već otkrio iz dijagnostike?

MC: – Prvo s čim se susrećemo jest upravo Baza podataka. MySQL je ionako stalno opterećen, spremajući nove metrike, a kada „Zabbix“ počne generirati hrpu događaja – baza doslovno odlazi sama u sebe na nekoliko sati. O optimizaciji konfiguracije sam ti već pričao, a nedavno smo obnovili hardver: na serverima imamo više od stotinu gigabajta memorije i diskovne nizove na SSD RAID-ima – linearno širiti dalje nema smisla. Što ćemo raditi?

MM: – Razumijem. U biti, MySQL je LTP baza. Čini se da više ne odgovara za pohranu arhiva metrika naše veličine. Idemo to riješiti.

MC: – Idemo!

Integracija Zabbixa i Clickhousea kao rezultat hackathona

Nakon nekog vremena dobili smo zanimljive podatke:

Većina prostora u našoj bazi bila je zauzeta arhivom metrika, dok je manje od 1% korišteno za konfiguraciju, predloške i postavke. U to vrijeme već smo više od godine koristili rješenje Big data temeljeno na Clickhouse. Smjer kretanja bio nam je očit. Na našem proljetnom „Hackathonu” napisao sam integraciju „Zabbixa” s „Clickhouseom” za poslužitelj i frontend. Tada je „Zabbix” već imao podršku za ElasticSearch, i odlučili smo ih usporediti.

Usporedba Clickhousea i Elasticsearcha

MM: – Za usporedbu generirali smo opterećenje jednako onome koje osigurava „Zabbix” poslužitelj i gledali kako će se sustavi ponašati. Podaci su se pisali u serijama od 1000 redaka, koristili smo CURL. Očekivali smo da će „Clickhouse” biti učinkovitiji za onaj profil opterećenja koji generira „Zabbix”. Rezultati su čak nadmašili naša očekivanja:

U istim uvjetima na testovima „Clickhouse” je pisao tri puta više podataka. Oba sustava su vrlo učinkovito trošila resurse pri čitanju podataka. Međutim, „Elasticsearchu” je pri pisanju bilo potrebno veliko količinu procesora:

Ukupno je „Clickhouse” značajno nadmašivao „Elasticsearch” u potrošnji procesora i brzini. Osim toga, zahvaljujući kompresiji podataka, „Clickhouse” koristi 11 puta manje prostora na tvrdom disku i čini otprilike 30 puta manje diskovnih operacija:

MC: – Da, rad s diskovnom subsistemom u „Clickhouseu” je vrlo učinkovit. Za baze se mogu koristiti ogromni SATA diskovi i ostvariti brzinu pisanja u stotinama tisuća redaka u sekundi. Sustav „iz kutije” podržava šarding, replikaciju, i vrlo je jednostavan za postavljanje. Više nego smo zadovoljni njegovim radom tijekom godine.

Za optimizaciju resursa može se instalirati „Clickhouse” uz postojeću glavnu bazu i na taj način uštedjeti značajno procesorsko vrijeme i diskovne operacije. Arhiv metrika prebacili smo na već postojeće „Clickhouse” klastere:

Toliko smo rasteretili glavnu MySQL bazu da smo je mogli spojiti na jednoj mašini s „Zabbix” poslužiteljem i odustati od zasebnog poslužitelja za MySQL.

Kako funkcionira polling u Zabbixu?

Prije 4 mjeseca

MM: – Pa, o problemima s bazom možemo zaboraviti?

MC: – Točno! Drugi zadatak koji moramo riješiti je spor prikupljanje podataka. Sada je svih naših 15 proxy poslužitelja preopterećeno SNMP i polling procesima. I nema druge opcije osim da dodajemo nove i nove poslužitelje.

MM: – Odlično. Ali prvo mi reci kako funkcionira polling u "Zabbixu"?

MC: – Ukratko, postoji 20 vrsta metrike i desetak načina za njihovo prikupljanje. "Zabbix" može prikupljati podatke ili u načinu "upit – odgovor", ili čekati nove podatke putem "Trapper sučelja".

Važno je napomenuti da je u originalnom "Zabbixu" ovaj način (Trapper) najbrži.

Postoje proxy poslužitelji za raspodjelu opterećenja:

Proxy mogu obavljati iste funkcije prikupljanja kao i "Zabbix"-poslužitelj, primajući zadatke s njega i šaljući prikupljene metrike upravo putem Trapper sučelja. Ovo je službeno preporučeni način raspodjele opterećenja. Također, proxy su korisni za praćenje udaljene infrastrukture koja radi putem NAT-a ili sporog kanala:

MM: – Sa arhitekturom je sve jasno. Treba pogledati izvorne kodove…

Nekoliko dana kasnije

Priča o tome kako je nmap fping pobijedio

MM: – Čini se da sam nešto otkrio.

MC: – Pričaj!

MM: – Otkrio sam da pri provjerama dostupnosti "Zabbix" provodi provjeru maksimalno do 128 hostova istovremeno. Pokušao sam povećati tu brojku na 500 i uklonio međupaketno kašnjenje u njihovom pingu (ping) – to je povećalo performanse do dvostruko. Ali volio bih veće brojke.

MC: – U svojoj praksi ponekad moram provjeravati dostupnost tisuća hostova, i ništa brže od nmap-a nisam pronašao za to. Siguran sam da je to najbrži način. Pokušajmo s tim! Trebamo značajno povećati broj hostova po iteraciji.

MM: – Provjeravati više od petsto? 600?

MC: – Minimalno nekoliko tisuća.

MM: – Okej. Najvažnije što želim reći: otkrio sam da se većina polling-a u "Zabbixu" radi sinkrono. Definitivno ga moramo preurediti za asinkroni način. Tada ćemo moći dramatično povećati broj metrika koje prikupljaju polleri, posebno ako povećamo broj metrika po iteraciji.

MC: – Super! I kada?

MM: – Kao obično, jučer.

MC: – Usporedili smo obje verzije fping i nmap:

Na velikom broju hostinga nmap je bio očekivano do pet puta učinkovitiji. Budući da nmap provjerava samo dostupnost i vrijeme odgovora, broj gubitaka smo prebacili u triggere i značajno smanjili intervale provjere dostupnosti. Optimalan broj hostova za nmap koji smo pronašli bio je oko 4 tisuće po jednoj iteraciji. Nmap nam je omogućio da smanjimo troškove CPU-a za provjeru dostupnosti tri puta i skratimo interval s 120 sekundi na 10.

Optimizacija polling-a

MM: – Zatim smo se posvetili pollerima. Uglavnom nas je zanimala SNMP i agenti. U „Zabbixu“ je polling napravljen sinkrono i poduzete su posebne mjere kako bi se povećala učinkovitost sustava. U sinkronom načinu nedostupnost hostova uzrokuje značajnu degradaciju pollinga. Postoji cijeli sustav stanja, postoje posebni procesi – tzv. unreachable polleri, koji rade samo s nedostupnim hostovima:

Ovo je komentar koji prikazuje matricu stanja, svu složenost sustava prijelaza potrebnih za održavanje učinkovitosti sustava. Osim toga, sam sinkroni polling je prilično spor:

Zbog toga tisuće niti pollera na desetak proxyja nisu mogle prikupiti potrebnu količinu podataka. Asinkrona realizacija riješila je ne samo probleme s brojem niti, već je i značajno pojednostavila sustav stanja nedostupnih hostova, jer je pri bilo kojem broju provjerenih u jednoj iteraciji pollinga maksimalno vrijeme čekanja iznosilo 1 timeout:

Osim toga, modificirali smo i doradili sustav pollinga za SNMP upite. Naime, većina ne može odgovoriti na nekoliko SNMP upita istovremeno. Stoga smo uveli hibridni režim, kada SNMP polling jednog te istog hosta radi asinkrono:

To se radi za čitavu grupu hostova. Ovaj način na kraju nije sporiji od potpuno asinkronog, jer ispitivanje preko 150 SNMP vrijednosti i dalje je znatno brže od 1 timeouta.

Naši eksperimenti su pokazali da je optimalan broj upita u jednoj iteraciji otprilike 8 tisuća prilikom SNMP pollinga. Ukupno prelazak na asinkroni režim omogućio je ubrzanje performansi pollinga 200 puta, u nekoliko stotina puta.

MC: Optimizacije pollinga pokazale su da ne samo da možemo eliminirati sve proksije, već i skratiti intervale za mnoge provjere, dok proksiji više neće biti potrebni kao način opterećenja.

Prije otprilike tri mjeseca

Promijeni arhitekturu – povećaj opterećenje!

MM: Pa, Max, je li vrijeme za proizvodnju? Trebam snažan server i dobrog inženjera.

MC: Dobro, planirajmo. Već je prošlo vrijeme da se pokrenemo s mrtve točke na 5000 metrika u sekundi.

Jutro nakon nadogradnje

MC: Misha, nadogradili smo se, ali do jutra smo se vratili natrag… Pogodi kojoj brzini smo uspjeli doći?

MM: Maksimalno 20 tisuća.

MC: Aha, 25! Nažalost, tu smo gdje smo počeli.

MM: Zašto je to tako? Jesmo li proveli neku dijagnostiku?

MC: Da, naravno! Evo, na primjer, zanimljiv top:

MM: Hajde da pogledamo. Vidim da smo probali ogroman broj pollinga:

Ali pritom nismo uspjeli iskoristiti sustav ni napola:

A ukupna učinkovitost je prilično mala, oko 4000 metrika u sekundi:

Ima li još nešto?

MC: Da, strace jednog od pollersa:

MM: Ovde se jasno vidi da proces pollinga čeka 'semafore'. To su blokade:

MC: Nije jasno.

MM: Pogledaj, ovo liči na situaciju kada hrpa niti pokušava raditi s resursom, s kojim istovremeno može raditi samo jedan. Tada sve što mogu raditi je dijeliti taj resurs kroz vrijeme:

I ukupna produktivnost rada s takvim resursom ograničena je brzinom jednog jezgra:

Ovaj problem se može riješiti na dva načina.

Nadograditi hardver mašine, prijeći na brža jezgra:

Ili promijeniti arhitekturu i paralelno – opterećenje:

MC: Usput, na testnom stroju ćemo koristiti manje jezgri nego na produkcijskom, ali će one biti 1,5 puta brže po jezgri!

MM: Jasno? Trebamo pogledati kod servera.

Put podataka u Zabbix serveru

MC: Da bismo razumjeli, počeli smo analizirati kako se podaci prenose unutar 'Zabbix' servera:

Super slika, zar ne? Idemo korak po korak da malo razjasnimo. Tu su niti i servisi odgovorni za prikupljanje podataka:

Sakupljene metrike šalju kroz soket u Preprocessor manager, gdje se pohranjuju u red:

Menadžer preprocesora' šalje podatke svojim radnicima, koji izvršavaju upute predobrade i vraćaju ih nazad kroz isti soket:

Nakon toga, menadžer preprocesora ih čuva u kešu istorije:

Odande ih uzimaju sinhronizatori istorije, koji obavljaju niz funkcija: na primer, izračunavanje okidača, popunjavanje keša vrednosti i, što je najvažnije, čuvanje metrika u skladištu istorije. Ukratko, proces je složen i veoma zbunjujući.

MM: – Prvo što smo primetili jeste da se većina tokova takmiči za takozvani "konfiguracijski keš" (odeljak memorije u kojem se čuvaju sve konfiguracije servera). Posebno su mnogo blokada pravili tokovi odgovorni za preuzimanje podataka:

…budući da u konfiguraciji nisu samo metrike s njihovim parametrima, već i redovi iz kojih preuzimalici uzimaju informacije o tome šta dalje da rade. Kada je preuzimalica mnogo, a jedan blokira konfiguraciju, ostali čekaju na zahteve:

Preuzimalice ne bi trebale da se sukobljavaju

Zato smo prvo što smo uradili – podelili red na 4 dela i dozvolili preuzimalicama da u sigurnim uslovima istovremeno blokiraju te redove, te delove:

To je uklonilo konkurenciju za konfiguracijski keš, i brzina rada preuzimalica znacajno je porasla. No, zatim smo se susreli sa problemom da je menadžer preprocesora počeo da skuplja red zadataka:

Menadžer preprocesora treba da zna kako da postavi prioritete

To se dešavalo u situacijama kada mu je nedostajala performansa. Tada je sve što je mogao da radi – skupljati zahteve od procesa prikupljanja podataka i slagati ih u bafer do trenutka kada ne bi pojeo svu memoriju i pao:

Da bismo rešili ovaj problem, dodali smo drugi soket, koji je bio posebno dodeljen radnicima:

Tako je menadžer preprocesora dobio mogućnost da prioritetizuje svoj rad i u slučaju rasta bafera zadao je da uspori preuzimanje, pružajući radnicima priliku da preuzmu taj bafer:

Zatim smo otkrili da je jedan od uzroka usporavanja sam radnik, jer su se takmičili za resurs koji nije bio važan za njihov rad. Ovaj problem smo rešili sa bug-fixom, i u novim verzijama "Zabbiksa" je već rešen:

Povećavamo broj soketa – dobijamo rezultat

Nakon toga, sam menadžer preprocesora postao je usko grlo, jer je to jedan tok. Oslonio se na brzinu jezgra, dajući maksimalnu brzinu od otprilike 70 hiljada metrika u sekundi:

Zato smo napravili četiri, sa četiri skupa utičnica, radnika:

I to je omogućilo povećanje brzine na otprilike 130 tisuća metrika:

Nelinearnost rasta objašnjena je time što je došla konkurencija za keš povijesti. Za njega su se natjecala četiri menadžera predprocesora i sinkronizatori povijesti. U tom trenutku dobijali smo na probnoj mašini otprilike 130 tisuća metrika u sekundi, koristeći je otprilike 95 % po procesoru:

Prije otprilike 2,5 mjeseca

Odustajanje od snmp-community povećalo je NVPs jedan i pol puta

MM: – Max, trebam novu probnu mašinu! U ovu više ne možemo stati.

MC: – A što imamo sada?

MM: – Sada imamo 130k NVPs i procesor 'u skladištu'.

MC: – Wow! Super! Čekaj, imam dva pitanja. Prema mojim izračunima, naša potreba je oko 15-20 tisuća metrika u sekundi. Zašto nam više?

MM: – Želim završiti posao do kraja. Želim vidjeti koliko možemo izvući iz ovog sistema.

MC: – Ali...

MM: – Ali za biznis je beskorisno.

MC: – Razumijem. I drugo pitanje: to što imamo sada, možemo li održavati sami, bez pomoći developera?

MM: – Ne mislim. Promjena u radu s konfiguracijskim kešom je problem. To se odnosi na promjene u većini tokova i dovoljno je složeno za podršku. Vjerojatno će biti vrlo teško održavati.

MC: – Onda nam treba neka alternativa.

MM: – Ima takva opcija. Možemo preći na brza jezgra, uz odustajanje od novog sistema zaključavanja. U svakom slučaju, dobit ćemo performanse od 60-80 tisuća metrika. Osim toga, možemo zadržati sav ostatak koda. 'ClickHouse', asinhrono polling će raditi. I to će biti lako održavati.

MC: – Sjajno! Predlažem da stanemo ovdje.

Nakon optimizacije serverskog dijela konačno smo uspjeli pokrenuti novi kod u produkciji. Odustali smo od dijela promjena u korist prelaska na mašinu s brzim jezgrama i minimiziranju broja promjena u kodu. Također smo pojednostavili konfiguraciju i, gdje god je moguće, odustali od makroa u podacima, jer oni predstavljaju izvor dodatnih zaključavanja.

Na primjer, odustajanje od često viđenog makroa snmp-community u našoj dokumentaciji i primjerima omogućilo je dodatno ubrzanje NVPs za otprilike 1,5 puta.

Nakon dva dana u produkciji

Uklanjamo iskačuće prozore povijesti incidenata

MC: – Miša, koristimo sustav već dva dana i sve radi. Ali samo kada sve funkcionira! Imali smo planirane radove s premještanjem prilično velikog segmenta mreže i ponovno smo provjeravali rukama što je podignuto, a što nije.

MM: – Ne može biti! Sve smo provjerili 10 puta. Poslužitelj obrađuje čak i potpunu nedostupnost mreže trenutno.

MC: – Razumijem sve: poslužitelj, baza, top, austat, logovi – sve brzo… Ali gledamo web sučelje, a tamo – procesor „u praznom hodu” na poslužitelju i ovo:

MM: – Jasno. Pogledajmo web. Otkrili smo da u situacijama s velikim brojem aktivnih incidenata većina operativnih widgeta počinju raditi vrlo sporo:

Uzrok tome je bila generacija iskačućih prozora s poviješću incidenata, koji se generiraju za svaki element na popisu. Stoga smo odustali od generacije tih prozora (zakomentirali smo 5 redaka u kodu), i to je riješilo naše probleme.

Vrijeme učitavanja widgeta, čak i pri potpunoj nedostupnosti, smanjeno je s nekoliko minuta na prihvatljivih naših 10-15 sekundi, a povijest se i dalje može pogledati jednim klikom na vrijeme:

Nakon posla. Prije 2 mjeseca

MC: – Miša, odlaziš? Trebam razgovarati.

MM: – Nisam planirao. Opet nešto s „Zabbixom”?

MC: – Ma ne, opusti se! Samo sam htio reći: sve radi, hvala! Ja ću platiti pivo.

Zabbix je učinkovit

„Zabbix” je prilično univerzalan i bogat sustav i funkcija. Može se koristiti za male instalacije „iz kutije”, ali s rastom potreba mora se optimizirati. Za pohranu velikog arhiva metrika koristite odgovarajuće skladište:

• možete iskoristiti ugrađena sredstva u obliku integracije s „Elastisearchom” ili izvoza povijesti u tekstualne datoteke (dostupno od četvrte verzije);
• možete iskoristiti naše iskustvo i integraciju s „Clickhouseom”.

Za radikalno povećanje brzine prikupljanja metrika, prikupljajte ih asinkronim metodama i prenosite putem trapper sučelja na „Zabbix” poslužitelj; ili možete iskoristiti zakrpu za asinkronost pollera samog „Zabbixa”.

"Zabbix" je napisan u C-u i vrlo je učinkovit. Rješenja za nekoliko uskih arhitektonskih mjesta dodatno povećavaju njegovu učinkovitost, a prema našem iskustvu, omogućuju dobivanje više od 100.000 metrika na jednoj procesorskoj mašini.

Taj poznati patch Zabbix

MM: – Želim dodati nekoliko točaka. Sav trenutni izlaganje, svi testovi, podaci navedeni su za konfiguraciju koju koristimo. S nje trenutno uzimamo otprilike 20.000 metrika u sekundi. Ako pokušavate razumjeti hoće li to raditi kod vas – možete usporediti. Ono o čemu smo danas govorili je dostupno na GitHubu u obliku patcha: github.com/miklert/zabbix

Patch uključuje:

• potpunu integraciju s "ClickHouse" (tako za Zabbix server, kao i za frontend);
• rješavanje problema s preprocesor menadžerom;
• asinhroni polling.

Patch je kompatibilan sa svim verzijama 4, uključujući lts. Vjerojatno će uz minimalne izmjene raditi i na verziji 3.4.

Hvala na pažnji.

Pitanja

Pitanje iz publike (dalje – P): – Dobar dan! Možete li molim vas reći imate li planove za intenzivnu suradnju s timom Zabbix ili oni s vama, kako bi to bio normalan rad Zabbixa, a ne samo patch?

MM: – Da, dio promjena ćemo definitivno commitirati. Nešto će ostati u patchu.

A: – Hvala vam puno na odličnom izlaganju! Možete li molim vas reći, nakon primjene patcha, hoće li podrška od strane Zabbixa ostati i kako se dalje nadograditi na više verzije? Hoće li biti mogućnosti nadograditi Zabbix nakon vašeg patcha na 4.2, 5.0?

MM: – O podršci ne mogu ništa reći. Da sam bio 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: "Idemo s vremenom i sami ćemo se nadograditi na sljedeću verziju". Tako da ćemo neko vrijeme objavljivati patch za ažurirane verzije. Već sam rekao u izlaganju: broj promjena s verzijama za sada je dovoljno malen. Mislim da je prijelaz s 3.4 na 4 trajao otprilike 15 minuta. Tamo se nešto promijenilo, ali ne toliko bitno.

A: – Dakle, planirate podržavati svoj patch i može se sigurno instalirati u produkciji, primajući daljnje nadogradnje na neki način?

MM: – Mi to kategorički preporučujemo. To nam rješava jako mnogo problema.

MC: Želim još jednom naglasiti da su promjene koje se ne tiču arhitekture i ne odnose se na blokade, redove – modularne su i nalaze se u odvojenim modulima. Čak i sami, pri neznatnim promjenama, mogu se relativno lako održavati.

MM: Ako vas zanimaju detalji, „ClickHouse“ koristi takozvanu biblioteku povijesti. Ona je nezavisna – to je kopija podrške za „Elastics“, tj. može se konfigurirati. Polling mijenja samo pollere. Smatramo da će ovo dugo raditi.

A: Hvala puno. Možete li reći postoji li neka dokumentacija o unesenim promjenama?

MM: Dokumentacija je patch. Očigledno, s uvođenjem „ClickHousea“, s novim vrstama pollera javljaju se nove konfiguracijske opcije. Na linku iz posljednjeg slajda postoji kratki opis kako koristiti ovo.

O zamjeni fping-a s nmap-om

A: Kako ste to konačno realizirali? Možete li dati konkretne primjere: imate li strapere i vanjski skript? Što na kraju provjerava tako brzo ogromnu količinu hostova? Kako dolazite do tih hostova? Treba ih nekako dati nmap-u, dobiti negdje, pohraniti, nešto pokrenuti?

MM: Super. Vrlo pravo pitanje! Suština je u tome. Modificirali smo biblioteku (ICMP ping, sastavni dio „Zabbixa“) za ICMP provjere, gdje je broj paketa postavljen na jedan (1), a kod pokušava koristiti nmap. To jest, to je unutarnji rad „Zabbixa“ i postalo je unutarnji rad pingera. Prema tome, nikakva sinhronizacija ili korištenje trappera nije potrebna. Ovo je učinjeno svjesno kako bi sustav ostao cjelovit i da se ne bavi sinhronizacijom dvaju sustava baza: što provjeravati, puniti putem pollera, a da li nam punjenje nije puklo? Ovo je znatno jednostavnije.

A: Da li to također radi za proxy?

MM: Da, ali nismo provjeravali. Kod polling-a i u „Zabbixu“ i na serveru je jedinstven. Trebalo bi raditi. Još jednom naglašavam: performanse sustava su takve da nam proxy nije potreban.

MC: Pravi odgovor na pitanje je: „Zašto vam treba proxy u ovakvom sustavu?“ Samo zbog NAT-a ili da biste nadgledali preko sporog kanala?

A: Koristite li „Zabbix“ kao alertor, ako sam dobro shvatio? Ili su grafovi (gdje je arhivski sloj) otišli u neki drugi sustav, poput Grafane? Ili ne koristite ovu funkcionalnost?

MM: – Ponovo naglašavam: napravili smo potpunu integraciju. Ispunjavamo historiju u „ClickHouse“, ali smo pritom promijenili php frontend. Php frontend se povezuje s „ClickHouse“ i sve grafike izrađuje odatle. Uz to, moram biti iskren, imamo dio koji gradi podatke iz istog „ClickHouse“, iz istih podataka „Zabbixa“ u drugim sustavima grafičkog prikazivanja.

MC: – U „Grafani“ uključujući.

Kako je donesena odluka o izdavanju resursa?

A: – Podijelite malo unutarnju kuhinju. Kako je donesena odluka da se treba izdvojiti resurse za ozbiljno preuređenje proizvoda? To, u osnovi, nosi određene rizike. I molim vas, recite u kontekstu toga što namjeravate podržavati nove verzije: kako se ta odluka opravdava s točke gledišta upravljanja?

MM: – Čini se da nismo baš dobro ispričali dramu povijesti. Našli smo se u situaciji kada je bilo potrebno nešto učiniti, i krenuli smo suštinski s dvije paralelne ekipe:

• Jedna se bavila pokretanjem sustava praćenja novim metodama: praćenje kao usluga, standardni set open-source rješenja koja kombiniramo i zatim pokušavamo mijenjati poslovne procese kako bismo radili s novim sustavom praćenja.
• Paralelno, imali smo entuzijasta-programera koji se time bavio (o sebi). Ispalo je da je on pobijedio.

A: – Kolika je veličina tima?

MC: – On je pred vama.

A: – Dakle, kao i uvijek treba strastveni čovjek?

MM: – Ne znam što je strastveni čovjek.

A: – U ovom slučaju, očito ste vi. Hvala puno, vi ste sjajni.

MM: – Hvala.

O zakrpama za Zabbix

A: – Za sustav koji koristi proksi (na primjer, u nekim distribuiranim sustavima), je li moguće prilagoditi i zakrpati vaše rješenje, recimo, puller-e, proksi i djelomično preprocesor samog „Zabbixa“; i njihovu interakciju? Je li moguće optimizirati postojeće radove za sustav s više proksi?

MM: – Znam da se „Zabbix“ server gradi s pomoću proksi (kompajlira se i dobija kod). Nismo to provjeravali u produkciji. Nisam siguran u to, ali mislim da se preprocesor-menadžer ne koristi u proksi. Zadatak proksi je uzeti set metrika iz „Zabbixa“, ispuniti ih (također zapisuje konfiguraciju, lokalnu bazu) i vratiti „Zabbix“ serveru. Preprocesiranje će kasnije raditi sam server, kada ga primi.

Interes za proxy je razumljiv. Provjerit ćemo to. To je zanimljiva tema.

A: – Ideja je bila: ako se mogu patchirati polleri, mogu se patchirati i na proxy i prilagoditi interakciju sa serverom, dok se preprocesor za te svrhe prilagođava samo na serveru.

MM: – Mislim da je to još jednostavnije. Uzimate kod, nanosete patch, zatim ga konfigurirate prema vlastitim potrebama – konfigurirate proxy servere (na primjer, s ODBC) i distribuirate patchirani kod po sustavima. Gdje je potrebno – postavljate proxy, gdje je potrebno – server.

A: – Dodatno, patchiranje prijenosa proxy na server vjerojatno neće biti potrebno?

MC: – Ne, to je standardno.

MM: – U stvari, jedna od ideja nije zvučala. Uvijek smo nastojali održati ravnotežu između inflacije ideja i broja promjena, te lakoće održavanja.

Malo reklame 🙂

Hvala što ostajete s nama. Sviđa li vam se naše članke? Želite li vidjeti više zanimljivih materijala? Podržite nas narudžbom ili preporučite prijateljima, oblačni VPS za developere od 4,99 $, jedinstveni analog entry-level servera koji smo razvili za vas: Sva istina o VPS-u (KVM) E5-2697 v3 (6 jezgri) 10GB DDR4 480GB SSD 1Gbps od 19 $ ili kako pravilno dijeliti server? (dostupne opcije s RAID1 i RAID10, do 24 jezgre i do 40GB DDR4).

Dell R730xd je 2 puta jeftiniji u data centaru Equinix Tier IV u Amsterdamu? Samo kod nas 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB od 199 $ u Nizozemskoj! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Pročitajte o tome Kako izgraditi infrastrukturu korporacijske klase koristeći Dell R730xd E5-2650 v4 servere po cijeni od 9000 eura za sitniš?

Izvor: habr.com