A prossima cunferenza HighLoad++ si terrà u 6 è 7 d'aprile 2020 in San Pietroburgo Dettagli è biglietti . HighLoad++ Moscow 2018. Sala "Mosca". 9 nuvembre, 15 ore. Tesi è .
* Monitoraghju - in linea è analitiche.
* Limitazioni basiche di a piattaforma ZABBIX.
* Soluzione per a scala di u almacenamentu analiticu.
* Ottimisazione di u servitore ZABBIX.
* Ottimisazione UI.
* Pruvate l'operazione di u sistema sottu carichi di più di 40k NVPS.
* Conclusioni brevi.
Mikhail Makurov (in seguitu - MM): - Salute à tutti !
Maxim Chernetsov (in seguitu - MCH): - Bonghjornu!
MM: - Lasciami presentà Maxim. Max hè un ingegnere talentu, u megliu networker chì cunnoscu. Maxim hè implicatu in rete è servizii, u so sviluppu è u funziunamentu.
MCH: – È vogliu parlà di Mikhail. Mikhail hè un sviluppatore C. Hà scrittu parechje suluzioni di trasfurmazioni di trafficu à alta carica per a nostra cumpagnia. Vivemu è travagliemu in l'Urali, in a cità di l'omi duri Chelyabinsk, in a cumpagnia Intersvyaz. A nostra cumpagnia hè un fornitore di servizii di Internet è di televisione per cable per un milione di persone in 16 cità.
MM: - È vale a pena dì chì Intersvyaz hè assai più cà solu un fornitore, hè una cumpagnia IT. A maiò parte di e nostre soluzioni sò fatte da u nostru dipartimentu IT.
A: da i servitori chì trattanu u trafficu à un call center è una applicazione mobile. U dipartimentu IT hà avà circa 80 persone cù cumpetenze assai, assai diverse.
Circa Zabbix è a so architettura
MCH: - È avà pruvà à stabilisce un registru persunale è dicu in un minutu ciò chì hè Zabbix (in seguitu chjamatu "Zabbix").
Zabbix si pone cum'è un sistema di surviglianza fora di scatula à livellu di l'impresa. Hà parechje funziunalità chì facenu a vita più faciule: regule avanzate di escalazione, API per integrazione, raggruppamentu è rilevazione automatica di ospiti è metriche. Zabbix hà cusì chjamati strumenti di scala - proxies. Zabbix hè un sistema open source.
In breve nantu à l'architettura. Pudemu dì chì hè custituitu di trè cumpunenti:
- Servitore. Scritta in C. Cù trasfurmazioni piuttostu cumplessu è trasferimentu di informazioni trà i fili. Tutti i prucessi sò fatti in questu: da a ricezione à a salvezza in a basa di dati.
- Tutti i dati sò guardati in a basa di dati. Zabbix supporta MySQL, PostreSQL è Oracle.
- L'interfaccia web hè scritta in PHP. In a maiò parte di i sistemi vene cun un servitore Apache, ma travaglia in modu più efficace in cumminazione cù nginx + php.
Oghje vulemu cuntà una storia da a vita di a nostra cumpagnia ligata à Zabbix...
Una storia da a vita di a cumpagnia Intersvyaz. Chì avemu è chì avemu bisognu ?
5 o 6 mesi fà. Un ghjornu dopu à u travagliu ...
MCH: - Misha, salutu ! Sò cuntentu chì aghju sappiutu catturà - ci hè una conversazione. Avemu dinò avutu prublemi cù u monitoraghju. Duranti un accidente maiò, tuttu era lentu è ùn ci era micca infurmazione nantu à u statu di a reta. Sfurtunatamente, ùn hè micca a prima volta chì questu hè accadutu. Aghju bisognu di u vostru aiutu. Facemu u nostru travagliu di monitoraghju in ogni circustanza!
MM: - Ma sincronizemu prima. Ùn aghju micca guardatu quì in un paru d'anni. Quantu mi ricordu, avemu abbandunatu Nagios è cambiatu à Zabbix circa 8 anni fà. È avà paremu avè 6 servitori putenti è circa una decina di proxy. Sò cunfusu qualcosa ?
MCH: - Quasi. 15 servitori, alcuni di i quali sò macchine virtuali. A più impurtante hè chì ùn ci salva micca in u mumentu quandu avemu bisognu di più. Cum'è un accidente - i servitori rallentanu è ùn pudete micca vede nunda. Avemu pruvatu à ottimisà a cunfigurazione, ma questu ùn hà micca furnitu l'aumentu di rendiment ottimali.
MM: - Hè chjaru. Avete guardatu qualcosa, avete digià scavatu qualcosa da i diagnostichi?
MCH: - A prima cosa chì avete da trattà hè a basa di dati. MySQL hè constantemente caricatu, almacenendu metriche novi, è quandu Zabbix cumencia à generà una mansa di avvenimenti, a basa di dati entra in overdrive per literalmente uni pochi d'ore. Aghju digià dettu di l'ottimisazione di a cunfigurazione, ma littiralmente quist'annu anu aghjurnatu u hardware: i servitori anu più di centu gigabyte di memoria è array di discu nantu à SSD RAID - ùn ci hè nunda di cultivà linearmente à longu andà. Chì facemu ?
MM: - Hè chjaru. In generale, MySQL hè una basa di dati LTP. Apparentemente, ùn hè più adattatu per almacenà un archiviu di metriche di a nostra dimensione. Scupritemu.
MCH: - Andemu !
Integrazione di Zabbix è Clickhouse cum'è u risultatu di l'hackathon
Dopu qualchì tempu avemu ricevutu dati interessanti:
A maiò parte di u spaziu in a nostra basa di dati hè stata occupata da l'archiviu di metrica è menu di 1% hè stata utilizata per a cunfigurazione, mudelli è paràmetri. À quellu tempu, avemu avutu operatu a suluzione Big data basatu in Clickhouse per più di un annu. A direzzione di u muvimentu era evidenti per noi. À a nostra primavera Hackathon, aghju scrittu l'integrazione di Zabbix cù Clickhouse per u servitore è u frontend. À quellu tempu, Zabbix avia digià supportu per ElasticSearch, è avemu decisu di paragunà.
Comparazione di Clickhouse è Elasticsearch
MM: - Per paragunà, avemu generatu a stessa carica chì u servitore Zabbix furnisce è hà guardatu cumu si cumportanu i sistemi. Avemu scrittu dati in lotti di 1000 linee, usendu CURL. Avemu presumitu in anticipu chì Clickhouse seria più efficace per u prufilu di carica chì Zabbix faci. I risultati anu superatu ancu e nostre aspettative:
In e stesse cundizioni di prova, Clickhouse hà scrittu trè volte più dati. À u listessu tempu, i dui sistemi cunsumu assai efficace (una piccula quantità di risorse) quandu leghje e dati. Ma l'Elastics necessitava una grande quantità di processore durante a registrazione:
In totale, Clickhouse era significativamente superiore à Elastix in quantu à u cunsumu di u processatore è a velocità. À u listessu tempu, per via di a compressione di dati, Clickhouse usa 11 volte menu in u discu duru è eseguisce circa 30 volte menu operazioni di discu:
MCH: - Iè, u travagliu di Clickhouse cù u sottosistema di discu hè implementatu assai efficace. Pudete utilizà enormi dischi SATA per basa di dati è uttene velocità di scrittura di centinaie di millaie di linee per seconda. U sistema out-of-the-box supporta sharding, replicazione, è hè assai faciule da cunfigurà. Semu più chè soddisfatti di u so usu in tuttu l'annu.
Per ottimisà e risorse, pudete installà Clickhouse accantu à a vostra basa di dati principale esistente è cusì risparmià assai tempu CPU è operazioni di discu. Avemu spustatu l'archiviu di metriche à i clusters Clickhouse esistenti:
Avemu allevatu a basa di dati principale MySQL tantu chì pudemu cumminà in una macchina cù u servitore Zabbix è abbandunà u servitore dedicatu per MySQL.
Cumu funziona u sondaghju in Zabbix?
4 mesi fa
MM: – Ebbè, pudemu scurdà di i prublemi cù a basa ?
MCH: - Hè sicuru ! Un altru prublema chì avemu bisognu di risolve hè a cullizzioni di dati lenta. Avà tutti i nostri 15 servitori proxy sò sovraccarichi cù SNMP è prucessi di polling. È ùn ci hè manera di stallà novi è novi servitori.
MM: - Perfettu. Ma prima, diteci cumu funziona u votu in Zabbix?
MCH: - In corta, ci sò 20 tipi di metriche è una decina di manere di ottene. Zabbix pò cullà dati sia in u modu "rimanda-risposta", o aspittà di novi dati attraversu l'"Interfaccia Trapper".
Hè nutate chì in u Zabbix originale stu metudu (Trapper) hè u più veloce.
Ci sò servitori proxy per a distribuzione di carica:
I proxy ponu eseguisce e stesse funzioni di cullizzioni cum'è u servitore Zabbix, ricevendu i compiti da ellu è mandendu e metriche raccolte attraversu l'interfaccia Trapper. Questu hè u modu ufficialmente cunsigliatu per distribuisce a carica. I proxy sò ancu utili per monitorà l'infrastruttura remota chì operanu attraversu NAT o un canale lento:
MM: - Tuttu hè chjaru cù l'architettura. Avemu bisognu di guardà e fonti ...
Un paru di ghjorni dopu
A storia di cumu nmap fping hà vintu
MM: "Pensu chì aghju scavatu qualcosa".
MCH: - Di mi!
MM: - Aghju scupertu chì quandu verificate a dispunibilità, Zabbix verifica un massimu di 128 ospiti à u mumentu. Aghju pruvatu à aumentà stu numeru à 500 è sguassate l'intervallu inter-packet in u so ping (ping) - questu duppiò u rendiment. Ma mi piacerebbe numeri più grande.
MCH: - In a mo pratica, qualchì volta aghju da verificà a dispunibilità di millaie d'ospiti, è ùn aghju mai vistu nunda più veloce di nmap per questu. Sò sicuru chì questu hè u modu più veloce. Pruvemu ! Avemu bisognu di aumentà significativamente u numeru di ospiti per iterazione.
MM: – Verificate più di cinque centu ? 600 ?
MCH: - Almenu un paru milla.
MM: - OK. A cosa più impurtante chì vulia dì hè chì aghju trovu chì a maiò parte di i sondaggi in Zabbix sò fatti in modu sincronu. Avemu bisognu di cambià in modu asincronu. Allora pudemu aumentà dramaticamente u numeru di metriche cullate da i pollers, soprattuttu s'ellu aumenta u numeru di metriche per iterazione.
MCH: - Perfettu! È quandu ?
MM: – Cum’è di solitu, eri.
MCH: - Avemu paragunatu e duie versioni di fping è nmap:
Nantu à un gran numaru d'ospiti, nmap era previstu per esse finu à cinque volte più efficace. Siccomu nmap verifica solu a dispunibilità è u tempu di risposta, avemu spustatu u calculu di perdite à i triggers è riduzzione significativamente l'intervalli di verificazione di dispunibilità. Avemu trovu u numeru ottimali di ospiti per nmap à circa 4 mila per iterazione. Nmap ci hà permessu di riduce u costu CPU di i cuntrolli di dispunibilità da trè volte è riduce l'intervallu da 120 seconde à 10.
Ottimisazione di polling
MM: "Allora avemu cuminciatu à fà pollers. Eramu principarmenti interessati à a deteczione è l'agenti SNMP. In Zabbix, u scrutiniu hè fattu in modu sincronu è misure speciali sò state pigliate per aumentà l'efficienza di u sistema. In u modu sincronu, a indisponibilità di l'ospite provoca una degradazione significativa di u votu. Ci hè un sistema sanu di stati, ci sò prucessi speciali - i chjamati pollers unreachable, chì travaglianu solu cù l'ospiti inaccessibili:
Questu hè un cummentariu chì mostra a matrice statale, tutta a cumplessità di u sistema di transizzioni chì sò necessarii per u sistema per esse efficace. Inoltre, u sondaghju sincronu stessu hè abbastanza lento:
Hè per quessa chì millaie di flussi di poller nantu à decine di proxy ùn puderanu micca recullà a quantità necessaria di dati per noi. L'implementazione asincrona risolve micca solu i prublemi cù u numeru di fili, ma hà ancu simplificatu significativamente u sistema statale di l'ospiti indisponibili, perchè per ogni numeru verificatu in una iterazione di polling, u tempu d'attesa massimu era 1 timeout:
Inoltre, avemu mudificatu è migliuratu u sistema di votazione per e dumande SNMP. U fattu hè chì a maiò parte di a ghjente ùn pò micca risponde à parechje richieste SNMP à u stessu tempu. Dunque, avemu fattu un modu hibridu, quandu u sondaghju SNMP di u stessu òspite hè fattu in modu asincronu:
Questu hè fattu per tuttu u pacchettu di ospiti. In ultimamente, stu modu ùn hè micca più lento ch'è un completamente asincronu, postu chì l'inchiesta di un centu è mezu di valori SNMP hè sempre assai più veloce di 1 timeout.
I nostri esperimenti anu dimustratu chì u nùmeru ottimale di richieste in una iterazione hè di circa 8 mila cù polling SNMP. In u tutale, a transizione à u modu asincronu ci hà permessu di accelerà u rendiment di votazione da 200 volte, parechji centu volte.
MCH: - L'ottimisazioni di polling resultanti anu dimustratu chì ùn pudemu micca solu sbarazzarsi di tutti i proxy, ma ancu riduce l'intervalli per parechji cuntrolli, è i proxy ùn saranu più necessarii per sparte a carica.
Circa trè mesi fà
Cambia l'architettura - aumenta a carica!
MM: - Ebbè, Max, hè ora d’esse pruduttivu ? Aghju bisognu di un servitore putente è un bon ingegnere.
MCH: - Va bè, prugemumu. Hè ora di passà da u puntu mortu di 5 mila metriche per seconda.
A matina dopu l'aghjurnamentu
MCH: - Misha, avemu aghjurnatu, ma à a matina ci vultemu in daretu... Indovina chì vitezza avemu riesciutu à ottene ?
MM: - 20 mila massimu.
MCH: - Iè, 25 ! Sfurtunatamente, simu ghjustu induve avemu principiatu.
MM: - Perchè? Avete fattu un diagnosticu?
MCH: - Iè, sicuru ! Eccu, per esempiu, una cima interessante:
MM: - Fighjemu. Vecu chì avemu pruvatu un gran numaru di fili di polling:
Ma à u listessu tempu ùn puderanu micca riciclà u sistema ancu à a mità:
È u rendiment generale hè abbastanza chjucu, circa 4 mila metriche per seconda:
Ci hè qualcosa d'altru ?
MCH: - Iè, strace di unu di l'elettori:
MM: - Quì pudete vede chjaramente chì u prucessu di votazione aspetta "semafori". Eccu i chjusi:
MCH: - Pocu chjaru.
MM: - Fighjate, questu hè simile à una situazione induve una mansa di fili cercanu di travaglià cù risorse chì solu unu pò travaglià à tempu. Allora tuttu ciò chì ponu fà hè di sparte sta risorsa cù u tempu:
È a prestazione tutale di travaglià cù una tale risorsa hè limitata da a velocità di un core:
Ci hè dui modi per risolve stu prublema.
Aghjurnate u hardware di a macchina, cambiate à core più veloci:
O cambia l'architettura è à u stessu tempu cambia a carica:
MCH: - A propositu, nantu à a macchina di prova useremu menu core chì in quella di cumbattimentu, ma sò 1,5 volte più veloci in frequenza per core!
MM: - Chjara ? Avete bisognu à vede u codice di u servitore.
Percorsu di dati in u servitore Zabbix
MCH: - Per capisce, avemu cuminciatu à analizà cumu e dati sò trasferiti in u servitore Zabbix:
Una bella foto, nò? Andemu à traversu passu à passu per fà più o menu chjaru. Ci sò fili è servizii rispunsevuli di cullà dati:
Trasmettenu e metriche raccolte via un socket à u manager di Preprocessor, induve sò salvate in una fila:
U "gestore di preprocessatore" trasmette dati à i so travagliadori, chì eseguenu struzzioni di preprocessing è li tornanu à traversu u stessu socket:
Dopu questu, u gestore di preprocessore li guarda in a cache di a storia:
Da quì sò pigliati da i sinkers di a storia, chì facenu assai funzioni: per esempiu, calculà i triggers, riempie u cache di valore è, più impurtante, salvà metriche in u almacenamiento di a storia. In generale, u prucessu hè cumplessu è assai cunfusu.
MM: - A prima cosa chì avemu vistu era chì a maiò parte di i fili cumpetenu per a chjamata "cache di cunfigurazione" (l'area di memoria induve tutte e cunfigurazioni di u servitore sò almacenate). I fili rispunsevuli di a cullizzioni di dati facenu in particulare assai blocchi:
...poi chì a cunfigurazione guarda micca solu metriche cù i so paràmetri, ma ancu fila da quale pollers piglianu infurmazioni nantu à ciò chì deve fà dopu. Quandu ci sò parechji pollers è unu blucca a cunfigurazione, l'altri aspettanu e dumande:
I pollers ùn deve micca cunflittu
Dunque, a prima cosa chì avemu fattu hè di divide a fila in 4 parte è permette à i pollers di bluccà queste file, sti parti à u stessu tempu, in cundizioni di sicurezza:
Questu hà eliminatu a cumpetizione per a cache di cunfigurazione, è a velocità di i pollers hà aumentatu significativamente. Ma dopu avemu scontru u fattu chì u manager di preprocessore hà cuminciatu à accumulà una fila di travaglii:
U gestore di preprocessore deve esse capace di priorità
Questu hè accadutu in i casi induve ùn mancava di prestazione. Allora tuttu ciò ch'ellu pudia fà era accumulà e dumande da i prucessi di cullizzioni di dati è aghjunghje u so buffer finu à cunsumà tutta a memoria è crash:
Per risolve stu prublema, avemu aghjustatu un secondu socket chì era dedicatu specificamente à i travagliadori:
Cusì, u manager di preprocessore hà avutu l'uppurtunità di prioritizà u so travagliu è, se u buffer cresce, u compitu hè di rallentà a rimozione, dendu à i travagliadori l'uppurtunità di piglià stu buffer:
Allora avemu scupertu chì unu di i mutivi di a rallentazione era i travagliadori stessi, postu chì eranu in competizione per una risorsa chì ùn era micca impurtante per u so travagliu. Avemu documentatu stu prublema cum'è un bug-fix, è hè digià statu risoltu in e novi versioni di Zabbix:
Aumentemu u numeru di sockets - avemu u risultatu
Inoltre, u gestore di preprocessore stessu hè diventatu un collu di buttiglia, postu chì hè un filu. Hè riposatu nantu à a velocità di core, dendu una velocità massima di circa 70 mila metriche per seconda:
Dunque, avemu fattu quattru, cù quattru setti di sockets, travagliadori:
È questu ci hà permessu di aumentà a vitezza à circa 130 mila metrica:
A non-linearità di a crescita hè spiegata da u fattu chì a cumpetizione per u cache di a storia hè apparsu. 4 gestori di preprocessori è sinkers di a storia anu cumpetitu per questu. À questu puntu, avemu ricevutu circa 130 mila metriche per seconda nantu à a macchina di prova, utilizendu da circa 95% di u processore:
Circa 2,5 mesi fà
U rifiutu da a snmp-community hà aumentatu i NVP da una volta è mezza
MM: - Max, aghju bisognu di una nova vittura di prova ! Ùn ci mette più in l'attuale.
MCH: - Chì avete avà ?
MM: - Avà - 130 NVP è un processore prontu per a scaffale.
MCH: - Wow ! Cool! Aspetta, aghju duie dumande. Sicondu i mo calculi, a nostra necessità hè di circa 15-20 mila metriche per seconda. Perchè avemu bisognu di più?
MM: "Vogliu finisce u travagliu". Mi piacerebbe vede quantu pudemu stringhje fora di stu sistema.
MCH: - Ma…
MM: "Ma hè inutile per l'affari".
MCH: - Hè chjaru. È a seconda quistione: pudemu sustene ciò chì avemu avà da noi, senza l'aiutu di un sviluppatore?
MM: - Ùn pensu micca. Cambia u funziunamentu di a cache di cunfigurazione hè un prublema. Affetta i cambiamenti in a maiò parte di i fili è hè abbastanza difficiule di mantene. Hè assai prubabile, serà assai difficiule di mantene.
MCH: "Allora avemu bisognu di qualchì alternativa".
MM: - Ci hè una tale opzione. Pudemu passà à core veloci, mentre abbandunendu u novu sistema di chjusi. Averemu sempre un rendimentu di 60-80 mila metri. À u listessu tempu, pudemu lascià tuttu u restu di u codice. Clickhouse è u sondaghju asincronu funzioneranu. È serà faciule di mantene.
MCH: - Stupente ! Suggeriu chì ci fermemu quì.
Dopu avè ottimisatu u latu di u servitore, avemu finalmente pussutu lancià u novu codice in pruduzzione. Avemu abbandunatu alcuni di i cambiamenti in favore di cambià à una macchina cù core veloci è minimizendu u numeru di cambiamenti di codice. Avemu ancu simplificatu a cunfigurazione è eliminatu macros in l'articuli di dati induve pussibule, postu chì introducenu un bloccu supplementu.
Per esempiu, abbandunà a macro snmp-community, chì si trova spessu in a documentazione è l'esempii, in u nostru casu hà permessu di accelerà più NVP per circa 1,5 volte.
Dopu dui ghjorni in pruduzzione
Eliminazione di i pop-up di storia di incidenti
MCH: - Misha, avemu usatu u sistema per dui ghjorni, è tuttu funziona. Ma solu quandu tuttu funziona! Avemu avutu u travagliu pianificatu cù u trasferimentu di un segmentu abbastanza grande di a reta, è avemu verificatu novu cù e nostre mani ciò chì hè andatu è ciò chì ùn hè micca.
MM: - Ùn pò esse ! Avemu verificatu tuttu 10 volte. U servitore gestisce ancu l'indisponibilità completa di a rete istantaneamente.
MCH: - Iè, aghju capitu tuttu: servitore, basa di dati, cima, austat, logs - tuttu hè veloce... Ma guardemu à l'interfaccia web, è ci hè un processatore "in a scaffale" in u servitore è questu:
MM: - Hè chjaru. Fighjemu u web. Avemu trovu chì in una situazione induve ci era un gran numaru di incidenti attivi, a maiò parte di i widgets live cuminciaru à travaglià assai lentamente:
U mutivu di questu era a generazione di pop-up di storia di incidenti chì sò generati per ogni articulu in a lista. Per quessa, avemu abbandunatu a generazione di sti finestri (cummentatu 5 linee in u codice), è questu risolve i nostri prublemi.
U tempu di carica per i widgets, ancu quandu ùn sò micca dispunibuli, hè statu riduttu da parechji minuti à l'accettabile 10-15 seconde per noi, è a storia pò ancu esse vista clicchendu nantu à u tempu:
Dopu à u travagliu. 2 mesi fà
MCH: - Misha, parti ? Avemu da parlà.
MM: - Ùn aghju micca intenzione. Qualcosa cù Zabbix di novu?
MCH: - Innò, rilassate ! Ci vulia à dì : tuttu funziona, grazie ! Aghju una birra.
Zabbix hè efficace
Zabbix hè un sistema è funzione abbastanza universale è riccu. Pò esse usatu per picculi installazioni fora di a scatula, ma cum'è i bisogni crescenu, deve esse ottimisatu. Per almacenà un grande archiviu di metriche, utilizate un almacenamentu adattatu:
- pudete aduprà strumenti integrati in forma di integrazione cù Elasticsearch o caricate a storia à i schedarii di testu (dispunibule da a versione XNUMX);
- Pudete prufittà di a nostra sperienza è integrazione cù Clickhouse.
Per aumentà dramaticamente a velocità di cullizzioni di metriche, cullighjate cù metudi asincroni è trasmettenu attraversu l'interfaccia di trapper à u servitore Zabbix; o pudete aduprà un patch per fà Zabbix pollers asynchronous.
Zabbix hè scrittu in C è hè abbastanza efficace. Risolviri parechji colli di bottiglia architettonica permette di aumentà ancu u so rendimentu è, in a nostra sperienza, uttene più di 100 mila metriche nantu à una macchina à un processatore.
U stessu patch Zabbix
MM: – Vogliu aghjunghje un paru di punti. Tuttu u rapportu attuale, tutte e teste, i numeri sò datu per a cunfigurazione chì usemu. Avà pigliamu circa 20 mila metriche per seconda da ellu. Sè vo circate di capisce s'ellu hà da travaglià per voi, pudete paragunà. Ciò chì hè statu discutitu oghje hè publicatu in GitHub in forma di patch:
U patch include:
- integrazione cumpleta cù Clickhouse (sia u servitore Zabbix sia u frontend);
- risolve i prublemi cù u manager di preprocessore;
- votazione asincrona.
U patch hè cumpatibile cù tutte e versioni 4, cumprese lts. Hè assai prubabile, cù cambiamenti minimi, travaglià nantu à a versione 3.4.
ti ringraziu per u vostru attinzioni.
I vostri dumanni
Quistione di l'audienza (in seguitu – A) : – Bona sera ! Per piacè ditemi, avete piani di interazzione intensiva cù a squadra di Zabbix o cun elli cun voi, perchè questu ùn hè micca un patch, ma un cumpurtamentu normale di Zabbix?
MM: - Iè, certamente cummettemu alcuni di i cambiamenti. Qualcosa accadrà, qualcosa fermarà in u patch.
A: - Grazie assai per l'eccellente rapportu! Per piacè dimmi, dopu avè applicà u patch, u supportu da Zabbix resterà è cumu cuntinuà l'aghjurnamentu à e versioni più altu? Serà pussibule aghjurnà Zabbix dopu u vostru patch à 4.2, 5.0?
MM: - Ùn possu micca dì nunda di sustegnu. Sè eru supportu tecnicu Zabbix, probabilmente diceraghju micca, perchè questu hè u codice di l'altru. In quantu à a basa di codice 4.2, a nostra pusizioni hè: "Ci muviamu cù u tempu, è aghjurneremu nantu à a prossima versione". Dunque, dapoi qualchì tempu pubblicheremu un patch per e versioni aghjurnate. Aghju digià dettu in u rapportu: u numeru di cambiamenti cù e versioni hè sempre abbastanza chjucu. Pensu chì a transizione da 3.4 à 4 ci hà pigliatu circa minuti 15. Qualcosa hà cambiatu quì, ma micca assai impurtante.
A: - Allora pensate di sustene u vostru patch è pudete installà in modu sicuru in a produzzione è riceve l'aghjurnamenti in qualchì modu in u futuru?
MM: - A ricumandemu fermamente. Questu risolve assai prublemi per noi.
MCH: - Una volta, vogliu attirà l'attenzione à u fattu chì i cambiamenti chì ùn cuncernanu micca l'architettura è ùn cuncernanu micca u bloccu o fila sò modulari, sò in moduli separati. Ancu cù cambiamenti minori, pudete mantene abbastanza facilmente.
MM: - Sè vo site interessatu à i ditagli, allora "Clickhouse" usa a chjamata biblioteca di storia. Hè unlied - hè una copia di u supportu Elastici, vale à dì, hè configurabile. A votazione cambia solu i pollers. Cridemu chì questu funzionerà per un bellu pezzu.
A: - Grazie tante. Dimmi, ci hè una documentazione di i cambiamenti fatti ?
MM: - A documentazione hè un patch. Ovviamente, cù l'intruduzioni di Clickhouse, cù l'intruduzioni di novi tipi di pollers, nascenu novi opzioni di cunfigurazione. U ligame da l'ultima diapositiva hà una breve descrizzione di cumu aduprà.
A propositu di rimpiazzà fping cù nmap
A: - Cumu avete infine implementatu questu? Pudete dà esempi specifichi: avete strappers è un script esternu? Chì finisce per verificà un numeru cusì grande di ospiti cusì rapidamente? Cumu minà questi ospiti? Avemu bisognu di alimentalli à nmap in qualchì modu, uttene da qualchì locu, metteli, eseguite qualcosa?...
MM: - Cool. Una quistione assai curretta! U puntu hè questu. Avemu mudificatu a biblioteca (ICMP ping, parte di Zabbix) per i cuntrolli ICMP, chì indicanu u numeru di pacchetti - unu (1), è u codice prova di utilizà nmap. Questu hè, questu hè u travagliu internu di Zabbix, chì hè diventatu u travagliu internu di u pinger. Per quessa, ùn hè micca necessariu sincronia o usu di un trapper. Questu hè statu fattu deliberatamente per abbandunà u sistema intactu è ùn avè micca affruntà cù a sincronizazione di dui sistemi di basa di dati: chì verificate, caricate attraversu u poller, è u nostru upload hè rottu? .. Questu hè assai più simplice.
A: – Funziona ancu per i proxy ?
MM: – Iè, ma ùn avemu micca verificatu. U codice di polling hè u listessu in Zabbix è u servitore. Deve travaglià. Lasciami enfatizà una volta: u rendiment di u sistema hè cusì chì ùn avemu micca bisognu di un proxy.
MCH: - A risposta curretta à a quistione hè: "Perchè avete bisognu di un proxy cù un tali sistema?" Solu per via di NAT o di monitorizazione attraversu un tipu di canale lento...
A: - È avete aduprà Zabbix cum'è allertor, se capiscu bè. O avete i vostri gràfici (induve a strata di l'archiviu hè) spustatu à un altru sistema, cum'è Grafana? O ùn avete micca aduprà sta funziunalità?
MM: – Sotturà una volta di più : avemu ottinutu una integrazione cumpleta. Avemu versà a storia in Clickhouse, ma à u stessu tempu avemu cambiatu u frontend php. U frontend Php va à Clickhouse è face tutte e grafiche da quì. À u listessu tempu, per esse onestu, avemu una parte chì custruisce dati in altri sistemi di visualizazione grafica da u stessu Clickhouse, da u listessu dati Zabbix.
MCH: - In "Grafan" ancu.
Cumu sò state decise nantu à l'assignazione di risorse?
A: - Sparte un pocu di a vostra cucina interna. Cumu hè statu fattu a decisione chì era necessariu di assignà risorse per u processu seriu di u pruduttu? Quessi sò, in generale, certi risichi. È per piacè ditemi, in u cuntestu di u fattu chì avete da sustene e versioni novi : cumu si ghjustificà sta decisione da un puntu di vista di gestione ?
MM: – Apparentemente, ùn avemu micca dettu assai bè u dramma di a storia. Ci truvamu in una situazione induve qualcosa avia da esse fattu, è andemu essenzialmente cù duie squadre parallele:
- Unu era lanciatu un sistema di surviglianza cù novi metudi: monitoring as a service, un inseme standard di suluzioni open source chì combinemu è poi pruvate à cambià u prucessu di cummerciale per travaglià cù u novu sistema di monitoraghju.
- À u listessu tempu, avemu avutu un programatore entusiasmu chì facia questu (circa ellu stessu). Hè accadutu chì hà vintu.
A: – E quale hè a dimensione di a squadra ?
MCH: - Ella hè davanti à tè.
A: – Allora, cum’è sempre, avete bisognu di un passioni ?
MM: – Ùn sò micca ciò chì hè un passione.
A: - In questu casu, apparentemente, voi. Grazie mille, sì fantastico.
MM: - Grazie.
À propositu di patch per Zabbix
A: - Per un sistema chì usa proxy (per esempiu, in certi sistemi distribuiti), hè pussibule adattà è patch, per dì, pollers, proxies è parzialmente u preprocessore di Zabbix stessu; è a so interazzione? Hè pussibule ottimisà i sviluppi esistenti per un sistema cù parechji proxy?
MM: - Sò chì u servitore Zabbix hè assemblatu cù un proxy (u codice hè compilatu è ottenutu). Ùn avemu micca pruvatu questu in produzzione. Ùn sò micca sicuru di questu, ma pensu chì u manager di preprocessore ùn hè micca usatu in u proxy. U compitu di u proxy hè di piglià un inseme di metriche da Zabbix, fusiona (ma registra a cunfigurazione, a basa di dati lucale) è rinvià à u servitore Zabbix. U servitore stessu farà tandu u preprocessing quandu u riceve.
L'interessu in i proxies hè comprensibile. Avemu da verificà. Questu hè un tema interessante.
A: - L'idea era questu: se pudete patch pollers, pudete patch elli nantu à u proxy è patch l'interazzione cù u servitore, è adattà u preprocessore per questi scopi solu in u servitore.
MM: - Pensu chì hè ancu più simplice. Pigliate u codice, applicà un patch, poi cunfigurà a manera chì avete bisognu - cullà i servitori proxy (per esempiu, cù ODBC) è distribuisce u codice patched in i sistemi. Quandu hè necessariu - cullate un proxy, induve necessariu - un servitore.
A: - Probabilmente, ùn avete micca bisognu di patch a trasmissione proxy à u servitore in più?
MCH: - Innò, hè standard.
MM: – In fatti, una di l'idee ùn sona micca. Avemu sempre mantinutu un equilibriu trà l'esplosione di idee è a quantità di cambiamenti è facilità di sustegnu.
Certi annunzii 🙂
Grazie per stà cun noi. Ti piace i nostri articuli ? Vulete vede più cuntenutu interessante? Supportaci facendu un ordine o ricumandendu à l'amichi, , un analogu unicu di servitori di livellu d'entrata, chì hè statu inventatu da noi per voi: (dispunibule cù RAID1 è RAID10, finu à 24 core è finu à 40GB DDR4).
Dell R730xd 2 volte più prezzu in u centru di dati Equinix Tier IV in Amsterdam? Solu quì in l'Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $ 99! Leghje circa
Source: www.habr.com