La prossima conferenza HighLoad++ si terrà il 6 e 7 aprile 2020 a San Pietroburgo. Maggiori dettagli e biglietti . HighLoad++ Mosca 2018. Sala «Mosca». 9 novembre, 15:00. Riassunti e .
* Monitoraggio — online e analisi.
* Principali limitazioni della piattaforma ZABBIX.
* Soluzione per la scalabilità dello storage analitico.
* Ottimizzazione del server ZABBIX.
* Ottimizzazione dell'interfaccia utente.
* Esperienza nell'operare il sistema con carichi superiori a 40k NVPS.
* Brevi conclusioni.
Mikhail Makurov (d'ora in poi – MM): – Ciao a tutti!
Maxim Chernetsov (d'ora in poi – MC): – Buongiorno!
MM: – Permettetemi di presentarvi Maxim. Max è un ingegnere di talento, il miglior esperto di rete che conosca. Maxim si occupa di reti e servizi, del loro sviluppo e del loro funzionamento.
MC: – E io vorrei parlare di Mikhail. Mikhail è uno sviluppatore in C. Ha scritto diverse soluzioni ad alta richiesta per l'elaborazione del traffico per la nostra azienda. Viviamo e lavoriamo negli Urali, nella città di uomini duri, Chelyabinsk, nella compagnia «Intersvyaz». La nostra azienda è un fornitore di servizi internet e televisione via cavo per un milione di persone in 16 città.
MM: – E bisogna dire che «Intersvyaz» è molto più di un semplice provider, è una compagnia IT. La maggior parte delle nostre soluzioni è realizzata dal nostro reparto IT.
A: dai server che elaborano il traffico, al call center e all'app mobile. Nel reparto IT ci sono attualmente circa 80 persone con competenze molto diverse.
Su Zabbix e la sua architettura
MC: – E ora cercherò di stabilire un record personale e descrivere cos'è Zabbix (d'ora in poi – «Zabbix») in un minuto.
«Zabbix» si posiziona come un sistema di monitoraggio «pronto all'uso» a livello enterprise. Ha molte funzionalità che semplificano la vita: regole di escalation avanzate, API per integrazione, raggruppamento e auto-scoperta di host e metriche. In «Zabbix» ci sono i cosiddetti strumenti di scalabilità - proxy. «Zabbix» è un sistema open source.
Breve panoramica dell'architettura. Si può dire che è composta da tre componenti:
- Server. Scritto in C. Con una gestione piuttosto complessa e trasferimento di informazioni tra i thread. Tutta l'elaborazione avviene in esso: dalla ricezione alla conservazione nel database.
- Tutti i dati sono memorizzati nel database. «Zabbix» supporta MySQL, PostgreSQL e Oracle.
- L'interfaccia web è scritta in PHP. Nella maggior parte dei sistemi è fornita con il server Apache, ma funziona in modo più efficace in combinazione con nginx + php.
Oggi vorremmo raccontare una storia dalla vita della nostra azienda, legata a «Zabbix»…
Storia dalla vita dell'azienda «Intersvyaz». Cosa abbiamo e di cosa abbiamo bisogno?
5 o 6 mesi fa. Un giorno dopo il lavoro…
MC: – Misha, ciao! Sono contento di averti raggiunto – devo parlarti. Abbiamo di nuovo avuto problemi con il monitoraggio. Durante un grande guasto tutto si bloccava e non c'era alcuna informazione sullo stato della rete. Purtroppo, questo succede non è la prima volta. Ho bisogno del tuo aiuto. Facciamo in modo che il nostro monitoraggio funzioni in ogni situazione!
MM: – Ma iniziamo sincronicamente. Non ci sono andato da un paio d'anni. Se non ricordo male, abbiamo abbandonato Nagios e siamo passati a «Zabbix» circa 8 anni fa. E ora abbiamo, sembra, 6 server potenti e circa una dozzina di proxy. Non mi sbaglio?
MC: – Quasi. 15 server, alcuni dei quali sono macchine virtuali. La cosa più importante è che questo non ci salva nel momento in cui ne abbiamo più bisogno. Quando si verifica un guasto, i server si bloccano e non si vede nulla. Abbiamo provato a ottimizzare la configurazione, ma non ha dato un incremento di prestazioni ottimale.
MM: – Capito. Hai guardato qualcosa, hai già raccolto qualche dato dalla diagnostica?
MC: – La prima cosa con cui dobbiamo fare i conti è proprio il DB. MySQL è già costantemente carico, memorizzando nuove metriche, e quando «Zabbix» inizia a generare un sacco di eventi, il database va in crisi letteralmente per diverse ore. Ti ho già parlato dell’ottimizzazione della configurazione, ma quest'anno abbiamo aggiornato l'hardware: sui server ci sono più di cento giga di RAM e array di dischi su RAID SSD – continuare a farlo crescere in modo lineare non ha senso. Cosa facciamo?
MM: – Capito. In realtà, MySQL è una base LTP. A quanto pare non è più adatta per memorizzare l'archivio di metriche delle nostre dimensioni. Cominciamo a risolvere il problema.
MC: – Facciamo!
Integrazione di Zabbix e Clickhouse come risultato del hackathon
Dopo un po' di tempo, abbiamo ottenuto dati interessanti:
La maggior parte dello spazio nel nostro database era occupata dall'archivio delle metriche e meno dell'1% era utilizzato per la configurazione, i modelli e le impostazioni. A quel punto avevamo già utilizzato la soluzione Big Data basata su Clickhouse per oltre un anno. La direzione da prendere era chiara. Durante il nostro "Hackathon" primaverile, ho scritto un'integrazione tra Zabbix e Clickhouse per il server e il frontend. A quel tempo, Zabbix supportava già ElasticSearch, e abbiamo deciso di confrontarli.
Confronto tra Clickhouse ed Elasticsearch
MM: – Per il confronto generavamo un carico pari a quello fornito dal server Zabbix e osservavamo come si comportavano i sistemi. Scrivevamo dati in batch di 1000 righe, utilizzando CURL. Presupponevamo in anticipo che Clickhouse sarebbe stato più efficiente per quel profilo di carico generato da Zabbix. I risultati hanno sorpreso le nostre aspettative:
In condizioni identiche nei test, Clickhouse scriveva tre volte più dati. Entrambi i sistemi consumavano risorse in modo molto efficiente nella lettura dei dati. Tuttavia, per ElasticSearch la scrittura richiedeva un alto utilizzo della CPU:
In sintesi, Clickhouse superava significativamente ElasticSearch in termini di utilizzo della CPU e velocità. Grazie alla compressione dei dati, Clickhouse utilizza 11 volte meno spazio su disco e compie circa 30 volte meno operazioni su disco:
MC: – Sì, la gestione del sistema di archiviazione in Clickhouse è realizzata molto efficacemente. È possibile utilizzare enormi dischi SATA per i database e ottenere velocità di scrittura di centinaia di migliaia di righe al secondo. Il sistema supporta out-of-the-box sharding, replica ed è abbastanza semplice da configurare. Siamo molto soddisfatti del suo utilizzo durante l'anno.
Per ottimizzare le risorse, è possibile installare Clickhouse accanto al database principale esistente, risparmiando così una grande quantità di tempo di CPU e operazioni su disco. Abbiamo trasferito l'archivio delle metriche sui cluster Clickhouse esistenti:
Abbiamo alleggerito così tanto il database MySQL principale, da poterlo unire sulla stessa macchina con il server Zabbix e rinunciare a un server dedicato per MySQL.
Come funziona il polling in Zabbix?
4 mesi fa
MM: – Beh, possiamo dimenticare i problemi con il database?
MC: – Esatto! Un'altra questione che dobbiamo affrontare è la raccolta dati lenta. Ora tutti i nostri 15 proxy sono sovraccarichi con i processi SNMP e polling. E non ci sono alternative, se non installare nuovi server.
MM: – Ottimo. Ma prima dimmi come funziona il polling in Zabbix?
MC: – In breve, ci sono 20 tipi di metriche e dozzine di modi per ottenerle. Zabbix può raccogliere dati sia in modalità "richiesta - risposta", sia attendere nuovi dati tramite l'Interfaccia Trapper.
È importante notare che nel Zabbix originale questo metodo (Trapper) è il più veloce.
Esistono proxy per distribuire il carico:
I proxy possono eseguire le stesse funzioni di raccolta del server Zabbix, ricevendo compiti da esso e inviando le metriche raccolte tramite l'interfaccia Trapper. Questo è il metodo ufficialmente raccomandato per la distribuzione del carico. Inoltre, i proxy sono utili per il monitoraggio di infrastrutture remote che operano attraverso NAT o canali lenti:
MM: – Con l'architettura è tutto chiaro. Dobbiamo guardare il codice sorgente...
Qualche giorno dopo
La storia di come nmap ha sconfitto fping
MM: – Sembra che abbia trovato qualcosa.
MC: – Racconta!
MM: – Ho scoperto che durante i controlli di disponibilità Zabbix verifica al massimo 128 host contemporaneamente. Ho provato a aumentare questo numero fino a 500 e ho rimosso l'intervallo tra i pacchetti nel loro ping – questo ha raddoppiato le prestazioni. Ma vorrei numeri più grandi.
MC: – Nella mia pratica, a volte devo controllare la disponibilità di migliaia di host e non ho trovato niente di più veloce di nmap. Sono sicuro che sia il metodo più rapido. Proviamolo! Dobbiamo aumentare significativamente il numero di host per iterazione.
MM: – Controllare più di cinquecento? 600?
MC: – Almeno un paio di migliaia.
MM: – Ok. La cosa più importante che volevo dire: ho scoperto che la maggior parte del polling in Zabbix è fatto in modo sincrono. Dobbiamo assolutamente cambiarlo in modalità asincrona. Allora potremo aumentare drasticamente il numero di metriche raccolte dai poller, specialmente se aumentiamo il numero di metriche per iterazione.
MC: – Fantastico! E quando?
MM: – Come al solito, ieri.
MC: – Abbiamo confrontato entrambe le versioni di fping e nmap:
Su un gran numero di host, nmap è stato prevedibilmente fino a cinque volte più efficace. Poiché nmap verifica solo la disponibilità e il tempo di risposta, abbiamo trasferito il conteggio delle perdite nei trigger e notevolmente ridotto gli intervalli di verifica della disponibilità. Abbiamo identificato un numero ottimale di host per nmap intorno ai 4.000 per singola iterazione. Nmap ci ha permesso di ridurre di tre volte il carico della CPU per le verifiche di disponibilità e di accorciare l'intervallo da 120 secondi a 10.
Ottimizzazione del polling
MM: – Dopodiché ci siamo occupati dei poller. Eravamo principalmente interessati al prelievo SNMP e agli agenti. In «Zabbix», il polling è stato eseguito in modo sincrono e sono state adottate misure speciali per aumentare l'efficienza del sistema. In modalità sincrona, la non disponibilità degli host provoca una significativa degradazione del polling. Esiste un'intera rete di stati e processi speciali – i cosiddetti poller unreachable, che lavorano solo con host non disponibili:
Questo è un commento che dimostra la matrice degli stati, tutta la complessità del sistema di transizioni necessarie per mantenere il sistema efficace. Inoltre, il polling sincrono stesso è piuttosto lento:
È per questo che migliaia di thread di poller su una decina di proxy non sono riusciti a raccogliere la quantità di dati necessaria. L'implementazione asincrona ha risolto non solo i problemi con il numero di thread, ma ha anche semplificato notevolmente il sistema di stati degli host non disponibili, poiché con qualsiasi numero di elementi verificati in una singola iterazione di polling, il tempo massimo di attesa era di 1 timeout:
In aggiunta, abbiamo modificato e migliorato il sistema di polling per le richieste SNMP. Il fatto è che la maggior parte non può rispondere a più richieste SNMP simultaneamente. Pertanto, abbiamo creato una modalità ibrida, in cui il polling SNMP dello stesso host viene eseguito in modo asincrono:
Questo viene fatto per l'intero gruppo di host. Tale modalità non è più lenta di quella completamente asincrona, poiché il sondaggio di un centinaio e mezzo di valori SNMP è comunque molto più veloce di 1 timeout.
I nostri esperimenti hanno dimostrato che il numero ottimale di richieste in una singola iterazione è di circa 8.000 durante il polling SNMP. Complessivamente, il passaggio alla modalità asincrona ha permesso di accelerare le prestazioni del polling di 200 volte, e di alcune centinaia di volte.
MC: Le ottimizzazioni del polling hanno mostrato che non solo possiamo eliminare tutti i proxy, ma anche ridurre gli intervalli per molti controlli, e i proxy non saranno più necessari come metodo di bilanciamento del carico.
Circa tre mesi fa
Cambia l'architettura – aumenta il carico!
MM: – Allora, Max, è ora di passare alla produzione? Ho bisogno di un server potente e di un buon ingegnere.
MC: – Bene, pianifichiamo. È ora di muoverci da quel punto morto delle 5.000 metriche al secondo.
Mattina dopo l'aggiornamento
MC: – Misha, ci siamo aggiornati, ma per stamattina siamo tornati indietro... Indovina a quale velocità siamo riusciti ad arrivare?
MM: – Massimo 20.000.
MC: – Ah, 25! Sfortunatamente, siamo lì dove eravamo all'inizio.
MM: – Perché è successo? Abbiamo effettuato qualche diagnosi?
MC: – Certo! Ecco, ad esempio, un interessante top:
MM: – Vediamo. Vedo che abbiamo provato un'enorme quantità di thread di polling:
Ma non siamo riusciti nemmeno a utilizzare il sistema per metà:
E la produzione totale è abbastanza bassa, circa 4.000 metriche al secondo:
C'è qualcos'altro?
MC: – Sì, strace di uno dei poller:
MM: – Qui è chiaramente visibile che il processo di polling sta aspettando i "semafori". Queste sono le blocchi:
MC: – Non chiaro.
MM: – Guarda, sembra una situazione in cui molti thread stanno cercando di lavorare con una risorsa che può essere utilizzata solo da uno alla volta. Allora tutto ciò che possono fare è condividere questa risorsa nel tempo:
E la produttività totale con tale risorsa è limitata dalla velocità di un singolo core:
È possibile risolvere questo problema in due modi.
Potenziare l'hardware della macchina, optando per core più veloci:
Oppure cambiare architettura e, parallelamente, il carico:
MC: – A proposito, sulla macchina di test useremo un numero minore di core rispetto a quella di produzione, ma saranno 1,5 volte più veloci in termini di frequenza per core!
MM: – Chiaro? Dobbiamo controllare il codice del server.
Il percorso dei dati nel server Zabbix
MC: – Per capire, abbiamo iniziato ad analizzare come i dati vengono trasferiti all'interno del server "Zabbix":
Bella immagine, vero? Facciamo un passo alla volta per chiarire un po'. Ci sono thread e servizi responsabili della raccolta dei dati:
Le metriche raccolte vengono inviate tramite un socket al gestore del preprocessore, dove vengono salvate in coda:
Il "gestore del preprocessore" invia i dati ai suoi lavoratori, che eseguono le istruzioni di preelaborazione e li restituiscono tramite lo stesso socket:
Dopo di ciò, il gestore del preprocessore salva nella cache della cronologia:
Da lì, vengono recuperati dagli storici-sync, che svolgono molte funzioni: ad esempio, il calcolo dei trigger, il riempimento della cache dei valori e, soprattutto, la conservazione delle metriche nel database della cronologia. In generale, il processo è complesso e piuttosto confuso.
MM: – La prima cosa che abbiamo notato è che la maggior parte dei thread compete per quella che viene definita "cache di configurazione" (un'area di memoria in cui sono memorizzate tutte le configurazioni del server). Ci sono particolarmente molte lock generate dai thread responsabili dell'estrazione dei dati:
…poiché nella configurazione non sono memorizzate solo metriche con i loro parametri, ma anche le code da cui i poller ottengono informazioni su cosa fare successivamente. Quando ci sono molti poller e uno blocca la configurazione, gli altri aspettano le richieste:
I poller non devono entrare in conflitto
Quindi, la prima cosa che abbiamo fatto è stata dividere la coda in 4 parti e consentire ai poller di bloccare queste code in condizioni sicure, queste parti contemporaneamente:
Questo ha eliminato la competizione per la cache di configurazione e la velocità di lavoro dei poller è aumentata significativamente. Ma poi ci siamo trovati di fronte al fatto che il gestore del preprocessore ha iniziato ad accumulare una coda di compiti:
Il gestore del preprocessore deve essere in grado di dare priorità
Questo accadeva nei casi in cui mancava di prestazioni. Allora, tutto ciò che poteva fare era accumulare richieste dai processi di raccolta dei dati e accumularle nel buffer fino a quando non esauriva tutta la memoria e andava in crash:
Per risolvere questo problema, abbiamo aggiunto una seconda socket, dedicata esclusivamente ai lavoratori:
In questo modo, il gestore del preprocessore ha avuto la possibilità di dare priorità al proprio lavoro e, in caso di crescita del buffer, di rallentare l’estrazione, dando ai lavoratori la possibilità di recuperare quel buffer:
Poi abbiamo scoperto che una delle cause del rallentamento erano gli stessi lavoratori, poiché competevano per una risorsa che era completamente irrilevante per il loro lavoro. Abbiamo formalizzato questo problema con un bug-fix, ed è già stato risolto nelle nuove versioni di "Zabbix":
Aumentiamo il numero di socket – otteniamo il risultato
Successivamente, il gestore del preprocessore è diventato il collo di bottiglia, poiché è un solo thread. Raggiungeva un limite di velocità del kernel, offrendo una velocità massima di circa 70.000 metriche al secondo:
Per questo abbiamo creato quattro set di socket, lavoratori:
E questo ha permesso di aumentare la velocità fino a circa 130.000 metriche:
La non linearità della crescita è spiegata dal fatto che è emersa la concorrenza per la cache della storia. Quattro gestori di pre-processori e sincronizzatori di storia hanno gareggiato per essa. A questo punto, ricevevamo sulla macchina di test circa 130.000 metriche al secondo, utilizzando circa il 95% della CPU:
Circa 2,5 mesi fa
L'abbandono della snmp-community ha aumentato gli NVP di un netto 50%
MM: – Max, ho bisogno di una nuova macchina di test! Non possiamo più adattarci a quella attuale.
MC: – E cosa abbiamo adesso?
MM: – Attualmente – 130k NVP e la CPU è al limite.
MC: – Wow! Fantastico! Aspetta, ho due domande. Secondo i miei calcoli, abbiamo bisogno di circa 15-20.000 metriche al secondo. Perché abbiamo bisogno di di più?
MM: – Vogliamo completare il lavoro. Vogliamo vedere quanto possiamo spremere da questo sistema.
MC: – Ma…
MM: – Ma per il business non ha senso.
MC: – Chiaro. E la seconda domanda: possiamo mantenere quello che abbiamo attualmente da soli, senza aiuto degli sviluppatori?
MM: – Non penso. Modificare il modo in cui gestiamo la cache della configurazione è un problema. Riguarda cambiamenti nella maggior parte dei flussi ed è piuttosto complicato da mantenere. Probabilmente sarà molto difficile mantenerla.
MC: – Allora abbiamo bisogno di un'alternativa.
MM: – C'è una possibilità. Possiamo passare a core veloci, rinunciando al nuovo sistema di blocco. Otterremo comunque prestazioni di 60-80.000 metriche. Inoltre, potremo mantenere tutto il resto del codice. ClickHouse e il polling asincrono funzioneranno. E sarà facile da mantenere.
MC: – Meraviglioso! Propongo di fermarci qui.
Dopo l'ottimizzazione della parte server, siamo finalmente riusciti a lanciare il nuovo codice in produzione. Abbiamo rinunciato a parte delle modifiche a favore del passaggio a una macchina con core veloci e della minimizzazione delle modifiche nel codice. Abbiamo anche semplificato la configurazione e, per quanto possibile, abbiamo rinunciato ai macro negli elementi dei dati, poiché sono la fonte di ulteriori blocchi.
Ad esempio, l'abbandono del macro snmp-community, che si trova spesso nella documentazione e negli esempi, ha permesso di accelerare ulteriormente gli NVP di circa 1,5 volte.
Dopo due giorni in produzione
Rimuoviamo le finestre pop-up della storia degli incidenti
MC: – Misha, stiamo usando il sistema da due giorni e tutto funziona. Ma solo quando tutto funziona! Avevamo lavori programmati per trasferire un segmento abbastanza grande della rete e abbiamo di nuovo controllato manualmente cosa era attivo e cosa no.
MM: – Non è possibile! Abbiamo controllato tutto dieci volte. Il server gestisce anche la completa inattività della rete in modo immediato.
MC: – Capisco: server, database, top, austat, registri – tutto veloce... Ma stiamo guardando l'interfaccia web, e lì – la CPU è «in pausa» sul server e c'è questo:
MM: – Chiaro. Dai un'occhiata al web. Abbiamo scoperto che in situazioni con un gran numero di incidenti attivi, la maggior parte dei widget di sistema cominciava a funzionare molto lentamente:
La causa era la generazione di finestre pop-up con la cronologia degli incidenti, che vengono generate per ogni elemento nell'elenco. Quindi abbiamo rinunciato alla generazione di queste finestre (commentando 5 righe nel codice) e questo ha risolto i nostri problemi.
Il tempo di caricamento dei widget, anche in caso di completa inattività, è diminueto da diversi minuti a un accettabile 10-15 secondi, e la cronologia può comunque essere visualizzata con un clic sul tempo:
Dopo il lavoro. 2 mesi fa
MC: – Misha, stai per andare? Ho bisogno di parlare.
MM: – Non avevo intenzione. Di nuovo qualcosa con «Zabbix»?
MC: – No, rilassati! Volevo solo dire: tutto funziona, grazie! A me la birra.
Zabbix è efficace
«Zabbix» è un sistema e una funzione abbastanza universali e ricchi. Può essere utilizzato per piccole installazioni «out of the box», ma man mano che le esigenze crescono deve essere ottimizzato. Per conservare un grande archivio di metriche, usa un'archiviazione adeguata:
- puoi utilizzare gli strumenti integrati come l'integrazione con «Elasticsearch» o l'esportazione della cronologia in file di testo (disponibile dalla quarta versione);
- puoi sfruttare la nostra esperienza e l'integrazione con «ClickHouse».
Per un netto incremento della velocità di raccolta delle metriche, raccoglile in modo asincrono e trasmettile tramite interfaccia trapper al server «Zabbix»; oppure puoi utilizzare una patch per l'asincronicità dei poller di «Zabbix».
«Zabbix» è scritto in C ed è piuttosto efficiente. Alcuni limiti architettonici consentono di aumentare ulteriormente le sue prestazioni e, secondo la nostra esperienza, riesce a raccogliere oltre 100.000 metriche su una macchina monoprocessore.
Quella sono il patch Zabbix
MM: – Vorrei aggiungere un paio di punti. Tutto l'attuale rapporto, tutti i test, i numeri sono stati forniti per quella configurazione che utilizziamo. Da essa stiamo attualmente estrapolando circa 20.000 metriche al secondo. Se state cercando di capire se funzionerà anche per voi, potete confrontare. Le informazioni presentate oggi sono state caricate su GitHub come patch:
La patch include:
- integrazione completa con «ClickHouse» (sia per i server «Zabbix» che per il frontend);
- soluzione dei problemi con il preprocessore-gestore;
- polling asincrono.
La patch è compatibile con tutta la versione 4, inclusa la lts. Probabilmente, con modifiche minime funzionerà anche sulla versione 3.4.
Grazie per l'attenzione.
Domande
Domanda dal pubblico (di seguito – D): – Buongiorno! Vorrei sapere se avete piani per un'interazione intensa con il team di Zabbix o viceversa, in modo che non sia solo una patch, ma un comportamento normale di «Zabbix»?
MM: – Sì, parte delle modifiche verrà sicuramente committata. Alcuni aspetti resteranno nella patch.
A: – Grazie mille per l'ottima presentazione! Vorrei chiedere, dopo aver applicato la patch, se il supporto da parte di «Zabbix» continuerà e come sarà possibile aggiornarsi a versioni superiori? Sarà possibile aggiornare «Zabbix» dopo la vostra patch a 4.2, 5.0?
MM: – Sulla questione del supporto non posso dire. Se fossi il supporto tecnico di «Zabbix», probabilmente direi di no, perché questo è codice di terzi. Per quanto riguarda il codice base 4.2, la nostra posizione è: «Andremo avanti e ci aggiorneremo alla prossima versione». Pertanto, per un certo periodo pubblicheremo patch per le versioni aggiornate. Ho già detto nella relazione: il numero di cambiamenti tra le versioni è attualmente piuttosto ridotto. Penso che il passaggio da 3.4 a 4 ci abbia impegnato, sembra, circa 15 minuti. Ci sono state alcune modifiche, ma non di grande importanza.
A: – Quindi, intendete mantenere la vostra patch e si può tranquillamente installarla in produzione, ricevendo aggiornamenti in qualche modo in futuro?
MM: – Raccomandiamo categoricamente. Questo risolve molti problemi per noi.
MC: Vorrei sottolineare ancora una volta che le modifiche che non riguardano l'architettura e non riguardano blocchi o code sono modulari, si trovano in moduli separati. Anche da soli, per piccole modifiche, è possibile mantenere tutto abbastanza facilmente.
MM: Se ti interessano i dettagli, ClickHouse utilizza una cosiddetta libreria storica. È scollegata, una copia del supporto di Elasticsearch, il che significa che è configurabile. Il polling cambia solo i poller. Riteniamo che funzioni a lungo.
A: Grazie mille. Puoi dirmi se c'è qualche documentazione sui cambiamenti effettuati?
MM: La documentazione è un patch. Ovviamente, con l'introduzione di ClickHouse, con l'arrivo di nuovi tipi di poller, sorgono nuove opzioni di configurazione. C'è una breve descrizione su come utilizzarla nel link nell'ultima slide.
Sulla sostituzione di fping con nmap
A: Come l'avete realizzato? Puoi fare degli esempi concreti: avete strapper e uno script esterno? Cosa controlla così rapidamente un numero così elevato di host? Come li ottenete? Bisogna dare un input a nmap, ottenerli da qualche parte, metterli, eseguire qualcosa?
MM: Ottimo. È una domanda molto giusta! La questione è questa. Abbiamo modificato la libreria (ping ICMP, parte di Zabbix) per i controlli ICMP, dove è indicato il numero di pacchetti – uno (1), e il codice cerca di usare nmap. Quindi, è un lavoro interno di Zabbix, è diventato il lavoro interno del ping. Pertanto, non è necessaria alcuna sincronizzazione o utilizzo di trapper. Questo è stato fatto consapevolmente, per mantenere il sistema integro e non dover gestire la sincronizzazione di due basi di dati: cosa controllare, gestire tramite il poller, e verificare che il caricamento non si sia rotto... È molto più semplice.
A: Funziona anche per i proxy?
MM: Sì, ma non abbiamo controllato. Il codice di polling in Zabbix e sul server è unificato. Dovrebbe funzionare. Ripeto: le prestazioni del sistema sono tali che non abbiamo bisogno di proxy.
MC: La risposta giusta a questa domanda è: "Perché avete bisogno di un proxy con questo sistema?" Solo a causa del NAT o per monitorare tramite un canale lento, vero?
A: Utilizzate Zabbix come allerta, se ho capito bene. O i grafici (dove il layer di archiviazione) sono finiti in un altro sistema, come Grafana? O non utilizzate questa funzionalità?
MM: – Sottolineo ancora una volta: abbiamo effettuato una completa integrazione. Stiamo inviando la cronologia a «ClickHouse», ma abbiamo anche modificato il frontend PHP. Il frontend PHP interroga «ClickHouse» e tutte le cronologie vengono generate da lì. Inoltre, onestamente, abbiamo una parte che costruisce da «ClickHouse», utilizzando gli stessi dati di «Zabbix» per rappresentare informazioni in altri sistemi di visualizzazione grafica.
MC: – Inclusa «Grafana».
Come è stata presa la decisione riguardo l'assegnazione delle risorse?
A: – Condividete un po' la vostra esperienza interna. Come è stata presa la decisione di allocare risorse per un'importante revisione del prodotto? Si tratta, in sostanza, di rischi concreti. E vorrei sapere, nel contesto di chi sta pianificando di supportare nuove versioni: come viene giustificata questa decisione dal punto di vista della gestione?
MM: – Evidentemente, non abbiamo raccontato molto bene il dramma della nostra storia. Ci siamo trovati in una situazione in cui dovevamo fare qualcosa e siamo andati avanti, in sostanza, con due team paralleli:
- Uno si è occupato del lancio di un sistema di monitoraggio con nuovi metodi: monitoraggio come servizio, un insieme standard di soluzioni open source che combiniamo e cerchiamo di modificare il processo aziendale per lavorare con il nuovo sistema di monitoraggio.
- Parallelamente, avevamo un programmatore entusiasta che si occupava di questo (parlando di se stesso). È andata così che lui ha prevalso.
A: – Qual è la dimensione del team?
MC: – È qui davanti a voi.
A: – Quindi, come sempre, è necessario un passionario?
MM: – Non so cosa sia un passionario.
A: – In questo caso, evidentemente, siete voi. Grazie mille, siete fantastici.
MM: – Grazie.
Sui patch per Zabbix
A: – Per un sistema che utilizza proxy (ad esempio, in alcuni sistemi distribuiti), è possibile adattare la vostra soluzione e patchare, diciamo, i pollers, i proxy e parzialmente il pre-processore di «Zabbix»; e la loro interazione? È possibile ottimizzare le soluzioni esistenti per un sistema con più proxy?
MM: – So che il server «Zabbix» viene assemblato tramite proxy (compilato e si ottiene il codice). Non lo abbiamo testato in produzione. Non sono sicuro, ma credo che il gestore del pre-processore non venga utilizzato nei proxy. Il compito del proxy è raccogliere un insieme di metriche da «Zabbix», spedirle (registra anche la configurazione, il database locale) e restituirle al server «Zabbix». Il pre-processing avverrà poi direttamente sul server, quando lo riceve.
È comprensibile l'interesse per i proxy. Lo verificheremo. È un tema interessante.
A: – L'idea era questa: se si possono patchare i poller, si possono patchare per i proxy e modificare l'interazione con il server, mentre il preprocessore si adatta a questi scopi solamente sul server.
MM: – Penso sia anche più semplice. Prendete il codice, applicate la patch, poi configurate come desiderate – create proxy server (ad esempio, con ODBC) e distribuite il codice patchato nei sistemi. Dove serve, create proxy, dove serve, il server.
A: – Non sarà necessario patchare ulteriormente il trasferimento del proxy al server, giusto?
MC: – No, è standard.
MM: – In realtà, non è stata espressa una delle idee. Abbiamo sempre cercato di mantenere un equilibrio tra un'esplosione di idee e il numero di cambiamenti, e la facilità di supporto.
Un po' di pubblicità 🙂
Grazie per rimanere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci a qualcuno. , unica alternativa ai server entry-level, concepita da noi per te: (sono disponibili opzioni con RAID1 e RAID10, fino a 24 core e fino a 40GB DDR4).
Dell R730xd a metà prezzo nel data center Equinix Tier IV ad Amsterdam? Solo da noi nei Paesi Bassi! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partire da $99! Leggi di
Fonte: habr.com
