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. Sintesi 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 operativa del sistema con carichi superiori a 40k NVPS.
* Brevi conclusioni.
Mikhail Makurov (di seguito – MM): – Ciao a tutti!
Maksim Chernecov (di seguito – MC): – Buongiorno!
MM: – Permettetemi di presentarvi Maksim. Max è un ingegnere talentuoso, il miglior specialista di rete che conosca. Maksim si occupa di reti e servizi, del loro sviluppo e della loro gestione.
MC: – Vorrei raccontarvi di Mikhail. Mikhail è uno sviluppatore C. Ha scritto diverse soluzioni ad alto carico per l'elaborazione del traffico per la nostra azienda. Viviamo e lavoriamo negli Urali, a Čeljabinsk, in un'azienda chiamata «Intersvyaz». La nostra azienda fornisce servizi internet e televisione via cavo a un milione di persone in 16 città.
MM: – È importante sottolineare che "Intersvyaz" è molto più di un semplice provider, è un'azienda IT. La maggior parte delle nostre soluzioni è realizzata dal nostro dipartimento IT.
A: dai server che gestiscono il traffico, fino al call center e all'app mobile. Attualmente nel dipartimento IT ci sono circa 80 persone con competenze molto variegate.
Su Zabbix e la sua architettura
MC: – Adesso cercherò di impostare un record personale e dire in un minuto che cos'è Zabbix (di seguito – "Zabbix").
"Zabbix" si presenta come un sistema di monitoraggio 'pronto all'uso' di livello enterprise. Ha molte funzionalità che semplificano la vita: regole di escalation avanzate, API per integrazioni, raggruppamento e auto-scoperta di host e metriche. In "Zabbix" ci sono così detti strumenti di scaling – proxy. "Zabbix" è un sistema open-source.
In breve sull'architettura. Si può dire che è composta da tre componenti:
- Server. Scritto in C. Con un'elaborazione e un trasferimento delle informazioni piuttosto complessi tra i thread. Tutta l'elaborazione avviene in esso: dalla ricezione fino al salvataggio 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 viene fornita con il server Apache, ma funziona in modo più efficiente in combinazione con nginx + php.
Oggi vorremmo raccontare una storia dalla vita della nostra azienda riguardo a 'Zabbix'...
Una storia dalla vita dell'azienda 'Intersvyaz'. Cosa abbiamo e cosa ci serve?
5 o 6 mesi fa. Un giorno dopo il lavoro...
MC: – Misha, ciao! Felice di averti incontrato – dobbiamo parlare. 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 è un problema che si ripete non per la prima volta. Ho bisogno del tuo aiuto. Facciamo in modo che il nostro monitoraggio funzioni in qualsiasi circostanza!
MM: – Ma prima facciamo un sincronizzazione. Non ci guardo da un paio d'anni. Per quanto ricordo, abbiamo abbandonato Nagios e siamo passati a 'Zabbix' circa 8 anni fa. E adesso abbiamo, sembra, 6 potenti server e circa una decina di proxy. Non mi confondo?
MC: – Quasi. 15 server, alcuni dei quali sono macchine virtuali. La cosa più importante è che questo non ci protegge nel momento del bisogno. Come in caso di emergenza – i server rallentano e non si vede nulla. Abbiamo provato a ottimizzare la configurazione, ma non abbiamo ottenuto alcun incremento significativo delle prestazioni.
MM: – Capisco. Avete esaminato qualcosa, avete già raccolto informazioni sulla diagnostica?
MC: – La prima cosa con cui ci si deve confrontare è proprio il database. MySQL è continuamente sovraccarico, conservando nuove metriche, e quando Zabbix inizia a generare un sacco di eventi, il database va sostanzialmente in stallo per alcune ore. Ti ho già parlato dell'ottimizzazione della configurazione, mentre quest'anno abbiamo aggiornato l'hardware: i server hanno più di cento gigabyte di memoria e array di dischi su RAID SSD – non ha senso continuare a farlo crescere linearmente. Cosa facciamo?
MM: – Chiaro. In effetti, MySQL è una base LTP. Sembrerebbe che non sia più adatta per archiviare le metriche della nostra dimensione. Iniziamo a indagare.
MC: – Facciamo!
Integrazione tra 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 di metriche e meno dell'1% utilizzato per configurazioni, modelli e impostazioni. A quel punto, avevamo già sfruttato per oltre un anno la soluzione Big Data basata su Clickhouse. La direzione per noi era chiara. Durante il nostro «Hackathon» primaverile, ho sviluppato 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 i dati in batch di 1000 righe, utilizzando CURL. Presumavamo in anticipo che Clickhouse sarebbe stato più efficiente per quel carico di lavoro generato da Zabbix. I risultati hanno persino superato le nostre aspettative:
In condizioni identiche nei test, Clickhouse ha scritto tre volte più dati. Entrambi i sistemi consumavano molto efficientemente (poche risorse) durante la lettura dei dati. Ma ElasticSearch richiedeva una grande quantità di CPU durante la scrittura:
In sintesi, ClickHouse supera 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 sottosistema di archiviazione in ClickHouse è molto efficiente. Puoi utilizzare enormi dischi SATA per le basi dati e ottenere velocità di scrittura nell'ordine di centinaia di migliaia di righe al secondo. Il sistema supporta out-of-the-box sharding, replica ed è molto semplice da configurare. Siamo più che soddisfatti della sua operatività dopo un anno.
Per ottimizzare le risorse, è possibile installare ClickHouse accanto all'attuale base dati principale, risparmiando così notevolmente sul tempo di CPU e sulle operazioni di disco. Abbiamo spostato l'archivio delle metriche sui cluster ClickHouse già esistenti:
Abbiamo alleggerito così tanto la base dati principale MySQL che abbiamo potuto unificarla su una sola macchina con il server Zabbix e rinunciare a un server dedicato per MySQL.
Come funziona il polling in Zabbix?
4 mesi fa
MM: – Allora, possiamo dimenticarci dei problemi con la base dati?
MC: – È proprio così! Un altro problema che dobbiamo risolvere è la raccolta lenta dei dati. Ora tutti i nostri 15 server proxy sono sovraccarichi a causa dei processi SNMP e del polling. E non ci sono altre opzioni se non aggiungere nuovi server.
MM: – Ottimo. Ma raccontami prima come funziona il polling in Zabbix?
MC: – In breve, ci sono 20 tipi di metriche e una decina di modi per ottenerle. Zabbix può raccogliere dati sia in modalità 'richiesta - risposta', sia attendere nuovi dati attraverso l'Interfaccia Trapper.
Va notato che nel Zabbix originale questo metodo (Trapper) è il più veloce.
Ci sono server proxy per bilanciare il carico:
I proxy possono svolgere le stesse funzioni di raccolta che il server Zabbix, ricevendo incarichi da esso e inviando le metriche raccolte proprio attraverso l'interfaccia Trapper. Questo è il modo ufficialmente raccomandato per bilanciare il carico. Inoltre, i proxy sono utili per monitorare infrastrutture remote che operano tramite NAT o canali lenti:
MM: – L'architettura è chiara. Dobbiamo esaminare i sorgenti…
Un paio di giorni dopo
La storia di come nmap e fping hanno trionfato
MM: – Sembra che io abbia trovato qualcosa.
MC: – Racconta!
MM: – Ho scoperto che durante i controlli di disponibilità, Zabbix verifica al massimo 128 host contemporaneamente. Ho provato ad aumentare questo numero 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 esperienza, a volte devo controllare la disponibilità di migliaia di host, e non ho trovato niente di più veloce di nmap per farlo. Sono sicuro che sia il modo più veloce. Proviamolo! Dobbiamo aumentare significativamente il numero di host per iterazione.
MM: – Controllare più di cinquecento? 600?
MC: – Almeno un paio di mila.
MM: – Ok. La cosa principale che volevo dire: ho scoperto che la maggior parte del polling in Zabbix è fatto in modo sincrono. Dobbiamo assolutamente modificarlo per lavorare in modalità asincrona. In questo modo potremo aumentare drasticamente il numero di metriche raccolte dai poller, soprattutto 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'ampia gamma di host, nmap si è dimostrato fino a cinque volte più efficace del previsto. Poiché nmap verifica solo la disponibilità e il tempo di risposta, abbiamo spostato il conteggio delle perdite nei trigger e ridotto significativamente gli intervalli di verifica della disponibilità. Abbiamo trovato che il numero ottimale di host per nmap è intorno ai 4.000 per iterazione. Nmap ci ha permesso di ridurre il carico della CPU per le verifiche di disponibilità di tre volte e di accorciare l'intervallo da 120 secondi a 10.
Ottimizzazione del polling
MM: – Dopodiché, ci siamo concentrati sui poller. Eravamo principalmente interessati alla raccolta SNMP e agli agenti. In «Zabbix», il polling è realizzato in modo sincrono e sono state adottate misure speciali per aumentare l'efficienza del sistema. In modalità sincrona, l'inaccessibilità degli host causa una significativa degradazione del polling. Esiste un'intera rete di stati, vi sono 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 affinché il sistema rimanga efficiente. Inoltre, il polling sincrono stesso è piuttosto lento:
Ecco perché migliaia di thread di poller su molteplici proxy non sono riusciti a raccogliere il numero necessario di dati. L'implementazione asincrona ha risolto non solo i problemi con il numero di thread, ma ha anche semplificato notevolmente il sistema di stato degli host non disponibili, poiché, indipendentemente dal numero di controlli effettuati in un'unica iterazione di polling, il tempo massimo di attesa era di 1 timeout:
Inoltre, abbiamo modificato e migliorato il sistema di polling per le richieste SNMP. Infatti, la maggior parte non può rispondere a più richieste SNMP contemporaneamente. Pertanto, abbiamo creato una modalità ibrida, in cui il polling SNMP dello stesso host avviene in modo asincrono:
Questo viene fatto per l'intero batch di host. Questa modalità non risulta più lenta rispetto a quella completamente asincrona, poiché interrogare 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 un'unica iterazione è di circa 8.000 durante il polling SNMP. Complessivamente, la transizione alla modalità asincrona ha consentito di aumentare le prestazioni del polling di 200 volte, fino a diverse centinaia di volte.
MC: Le ottimizzazioni del polling hanno dimostrato che possiamo non solo eliminare tutti i proxy, ma anche ridurre gli intervalli per molte verifiche, rendendo i proxy non necessari come metodo di bilanciamento del carico.
Circa tre mesi fa
Cambia l'architettura – aumenta il carico!
MM: – Bene, Max, è ora di entrare in produzione? Ho bisogno di un server potente e di un buon ingegnere.
MC: – Va bene, pianifichiamo. È tempo di muoversi da questo stallo di 5 mila metriche al secondo.
Mattina dopo l'upgrade
MC: – Misha, ci siamo aggiornati, ma per questa mattina siamo tornati indietro… Indovina quale velocità siamo riusciti a raggiungere?
MM: – Al massimo 20 mila.
MC: – Ah, 25! Purtroppo, siamo dove eravamo, da dove abbiamo iniziato.
MM: – Perché è così? Abbiamo fatto qualche diagnosi?
MC: – Sì, certo! Ecco, ad esempio, un interessante top:
MM: – Diamo un'occhiata. Vedo che abbiamo provato un numero enorme di thread di polling:
Ma non siamo riusciti a utilizzare il sistema nemmeno a metà:
E la performance totale è piuttosto bassa, circa 4 mila metriche al secondo:
C'è qualcos'altro?
MC: – Sì, strace di uno dei poller:
MM: – Qui si vede chiaramente che il processo di polling aspetta i 'semafori'. Queste sono delle blocchi:
MC: – Non è chiaro.
MM: – Guarda, questo sembra una situazione in cui molti thread stanno cercando di lavorare con una risorsa accessibile solo a uno alla volta. Così, l'unica cosa che possono fare è suddividere l'accesso a questa risorsa nel tempo:
E la produttività complessiva nell'utilizzo di questa risorsa è limitata dalla velocità di un solo core:
Ci sono due modi per risolvere questo problema.
Aggiornare l'hardware della macchina, passando a core più veloci:
Oppure cambiare l'architettura e parallelamente il carico:
MC: – Tra l'altro, sulla macchina di test utilizziamo un numero minore di core rispetto a quella di produzione, ma sono circa 1,5 volte più veloci per frequenza per core!
MM: – Chiaro? Dobbiamo esaminare il codice del server.
Il percorso dei dati nel server Zabbix
MC: – Per capire meglio, abbiamo iniziato ad analizzare come i dati vengono trasmessi all'interno del server Zabbix:
Un'immagine fantastica, vero? Facciamo un passo alla volta per chiarire. Ci sono thread e servizi responsabili della raccolta dei dati:
Le metriche raccolte vengono inviate tramite socket al Preprocessor manager, dove vengono memorizzate in coda:
Il gestore del preprocessore invia i dati ai suoi worker, i quali eseguono le istruzioni di preprocessing e li restituiscono attraverso lo stesso socket:
Successivamente, il gestore del preprocessore li memorizza nella cache della storia:
Da lì, vengono prelevati dai sincronizzatori di storia, che svolgono diverse funzioni: ad esempio, il calcolo dei trigger, il riempimento della cache dei valori e, cosa più importante, la registrazione delle metriche nel repository della storia. 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 chiamata 'cache di configurazione' (un'area di memoria dove sono archiviate tutte le configurazioni del server). Soprattutto molti lock vengono generati dai thread responsabili del recupero dei dati:
…poiché nella configurazione sono memorizzate non solo le 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 confliggere
Perciò, la prima cosa che abbiamo fatto è stata dividere la coda in 4 parti e consentire ai poller di bloccare queste code in condizioni sicure, simultaneamente:
Questo ha eliminato la concorrenza per la cache di configurazione, e la velocità di lavoro dei poller è aumentata significativamente. Ma poi ci siamo trovati di fronte al problema che il gestore del preprocessore ha iniziato ad accumulare la coda di lavoro:
Il gestore del preprocessore deve essere in grado di stabilire delle priorità.
Questo accadeva nei casi in cui mancava di prestazioni. Allora, tutto ciò che poteva fare era accumulare le richieste dai processi di raccolta dati e inserirle nel buffer fino a esaurire la memoria e bloccarsi:
Per risolvere questo problema, abbiamo aggiunto un secondo socket, dedicato esclusivamente ai worker:
In questo modo, il gestore del preprocessore ha potuto dare priorità al proprio lavoro e, in caso di crescita del buffer, interrompere il caricamento, consentendo ai worker di prelevare quel buffer:
Poi abbiamo scoperto che una delle cause del rallentamento erano gli stessi worker, poiché competevano per una risorsa che non era affatto importante per il loro lavoro. Abbiamo risolto questo problema con un bug-fix, e nelle nuove versioni di «Zabbix» è già stato risolto:
Aumentiamo il numero di socket – otteniamo risultati
In seguito, il gestore del preprocessore è diventato il collo di bottiglia, poiché opera in un solo thread. Ha raggiunto la massima velocità di circa 70 mila metriche al secondo:
Pertanto, abbiamo creato quattro, con quattro set di socket e worker:
E questo ha permesso di aumentare la velocità a circa 130 mila metriche:
La non linearità della crescita è spiegata dal fatto che c'era competizione per la cache della cronologia. Quattro gestori del preprocessore e gli history-sinkers competevano per essa. A questo punto, sulla macchina di test ottenevamo circa 130 mila metriche al secondo, utilizzando circa il 95 % della CPU:
Circa 2,5 mesi fa
L'abbandono della snmp-community ha aumentato gli NVPs di un fattore e mezzo
MM: – Max, ho bisogno di una nuova macchina di test! Nella attuale non riusciamo più a entrare.
MC: – E cosa abbiamo attualmente?
MM: – Attualmente – 130k NVPs e processore "in riserva".
MC: – Wow! Cool! Wait, I have two questions. Based on my calculations, our need is around 15-20 thousand metrics per second. Why do we need more?
MM: – I want to see it through to the end. I want to find out how much we can get out of this system.
MC: – But...
MM: – But it's useless for the business.
MC: – Got it. And the second question: can we maintain what we have now by ourselves, without a developer's help?
MM: – I don't think so. Changing the configuration cache management is an issue. It impacts most streams and is quite complex to maintain. It will likely be very difficult to support.
MC: – Then we need some kind of alternative.
MM: – There is an option. We can switch to fast cores while abandoning the new locking system. We'll still achieve performance of 60-80 thousand metrics. Plus, we can keep all the other code. ClickHouse and asynchronous polling will work. And it will be easy to maintain.
MC: – Wonderful! I suggest we stop here.
Dopo l'ottimizzazione della parte server, siamo finalmente riusciti a lanciare il nuovo codice in produzione. Abbiamo rinunciato a alcune modifiche a favore del passaggio a una macchina con processori veloci e per minimizzare il numero di cambiamenti nel codice. Abbiamo anche semplificato la configurazione e, dove possibile, eliminato i macro negli elementi dei dati, poiché sono una fonte di ulteriore blocco.
Ad esempio, l'eliminazione del macro snmp-community, comunemente presente nella documentazione e negli esempi, ha permesso di velocizzare ulteriormente gli NVPs di circa 1,5 volte.
Dopo due giorni in produzione
Rimuoviamo le finestre pop-up della cronologia degli incidenti
MC: – Misha, utilizziamo il sistema da due giorni e tutto funziona. Ma solo quando tutto funziona! Abbiamo avuto lavori programmati per il trasferimento di un segmento abbastanza grande della rete e abbiamo controllato manualmente cosa era attivo e cosa no.
MM: – Non può essere! Abbiamo controllato tutto dieci volte. Il server gestisce anche una completa inattività della rete istantaneamente.
MC: – Sì, capisco: server, database, top, austat, log – tutto veloce… Ma guardiamo l'interfaccia web e lì il processore "in stand-by" sul server e questo:
MM: – Chiaro. Andiamo a vedere il web. Abbiamo scoperto che in situazioni con un gran numero di incidenti attivi, la maggior parte dei widget operativi iniziava a funzionare molto lentamente:
La causa di ciò era la generazione di finestre popup con la cronologia degli incidenti, che venivano create per ogni elemento nell'elenco. Pertanto, abbiamo rinunciato alla generazione di queste finestre (commentando 5 righe di codice), e questo ha risolto i nostri problemi.
Il tempo di caricamento dei widget, anche in caso di completa indisponibilità, è stato ridotto da diversi minuti a un accettabile 10-15 secondi, e la cronologia può ancora essere visualizzata semplicemente cliccando sul timestamp:
Dopo il lavoro. 2 mesi fa
MC: – Misha, te ne vai? Ho qualcosa da dirti.
MM: – Non avevo intenzione. Di nuovo qualcosa con Zabbix?
MC: – No, rilassati! Volevo solo dire: tutto funziona, grazie! A spese mie una birra.
Zabbix è efficiente
Zabbix è un sistema e una funzionalità piuttosto versatili e completi. Può essere utilizzato senza problemi per piccole installazioni 'out of the box', ma con l'aumento delle esigenze, è necessario ottimizzarlo. Per la memorizzazione di un ampio archivio di metriche, utilizzare un sistema di archiviazione adeguato:
- si possono utilizzare gli strumenti integrati come l'integrazione con «Elasticsearch» o l'export della cronologia in file di testo (disponibile dalla quarta versione);
- si può sfruttare la nostra esperienza e l'integrazione con «ClickHouse».
Per un incremento significativo della velocità di raccolta delle metriche, raccoglieteli utilizzando metodi asincroni e trasmetteteli attraverso l'interfaccia trapper al server «Zabbix»; in alternativa, è possibile utilizzare una patch per l'asincronismo dei poller di «Zabbix».
«Zabbix» è scritto in C ed è abbastanza efficiente. Alcuni miglioramenti architettonici consentono di aumentare ulteriormente le sue prestazioni e, secondo la nostra esperienza, di ottenere oltre 100.000 metriche su una macchina a singolo processore.
Quella famosa patch Zabbix
MM: – Vorrei aggiungere un paio di dettagli. Tutto il rapporto attuale, tutti i test e i dati forniti si riferiscono alla configurazione che utilizziamo noi. Attualmente stiamo raccogliendo circa 20.000 metriche al secondo. Se vi state chiedendo se funzionerà per voi, potete confrontare. Ciò di cui abbiamo parlato oggi è disponibile su GitHub come patch:
La patch include:
- integrazione completa con «ClickHouse» (sia per il server «Zabbix» che per il front-end);
- risoluzione dei problemi con il gestore dei pre-processori;
- polling asincrono.
La patch è compatibile con tutta la versione 4, incluso l'lts. Probabilmente funzionerà con modifiche minime sulla versione 3.4.
Grazie per l'attenzione.
Domande
Domanda dal pubblico (di seguito – A): – Buongiorno! Vorrei sapere, avete in programma un'interazione intensa con il team di Zabbix o loro con voi, in modo che non si tratti di una patch ma di un comportamento normale di «Zabbix»?
MM: – Sì, alcune modifiche sicuramente le committeremo. Alcune cose saranno in patch, altre no.
A: – Grazie mille per la presentazione eccellente! Mi può dire, per favore, dopo l'applicazione della patch, il supporto da parte di «Zabbix» rimarrà e come si aggiornerà a versioni più alte? Ci sarà la possibilità di aggiornare «Zabbix» dopo la vostra patch alla 4.2, 5.0?
MM: – Sulla questione del supporto non posso dire molto. Se fossi il supporto tecnico di «Zabbix», probabilmente direi di no, perché si tratta di codice esterno. Per quanto riguarda il codice sorgente 4.2, la nostra posizione è la seguente: «Ci aggiorneremo con il tempo e passeremo alla prossima versione». Pertanto, per un certo periodo rilasceremo patch per le versioni aggiornate. L'ho già detto nella relazione: il numero di modifiche tra le versioni è attualmente abbastanza ridotto. Penso che la transizione da 3.4 a 4 ci abbia preso, mi sembra, circa 15 minuti. Qualcosa è cambiato, ma non è fondamentale.
A: – Quindi, pianificate di mantenere la vostra patch e si può tranquillamente installarla in produzione, ricevendo successivamente aggiornamenti in qualche modo?
MM: – Sì, lo raccomandiamo vivamente. Questo risolve molti problemi per noi.
MC: – Vorrei sottolineare ancora una volta che le modifiche che non riguardano l'architettura e non riguardano i blocchi, le code – sono modulari, si trovano in moduli separati. Anche con modifiche minime, possono essere gestite piuttosto facilmente.
MM: – Se ti interessano i dettagli, «ClickHouse» utilizza quella che viene chiamata la libreria della cronologia. È disaccoppiata: è una copia del supporto per «Elastik», ovvero è configurabile. Il polling modifica solo i poller. Riteniamo che questo funzionerà a lungo.
A: – Grazie mille. Puoi dirmi se c'è qualche documentazione delle modifiche apportate?
MM: – La documentazione è una patch. È evidente che con l'introduzione del «ClickHouse» e dei nuovi tipi di poller nascono nuove opzioni di configurazione. Nel link dell'ultima diapositiva c'è una breve descrizione su come utilizzarlo.
Sostituzione di fping con nmap
A: – Come lo avete realizzato alla fine? Puoi fare esempi specifici: avete strapper e uno script esterno? Cosa controlla alla fine così rapidamente un numero così elevato di host? Come raccogliete questi host? Bisogna in qualche modo fornirli a nmap, ottenerli da qualche parte, metterli da parte, e poi eseguire qualcosa?..
MM: – Ottimo. È una domanda molto pertinente! Ecco il punto. Abbiamo modificato la libreria (ping ICMP, parte di «Zabbix») per le verifiche ICMP, in cui è specificato il numero di pacchetti – uno (1) – e il codice cerca di utilizzare nmap. Questo significa che è un'operazione interna di «Zabbix», diventata un'operazione interna del ping. Di conseguenza, non è necessaria alcuna sincronizzazione o utilizzo di trapper. Questo è stato fatto intenzionalmente per mantenere il sistema integro e non occuparsi della sincronizzazione di due sistemi di base: cosa controllare, caricare tramite il poller, e non ci sono problemi nel caricamento?... È molto più semplice.
A: – Funziona anche per il proxy?
MM: – Sì, ma non abbiamo fatto test. Il codice di polling sia in «Zabbix» che nel server è unificato. Dovrebbe funzionare. Ripeto: le prestazioni del sistema sono tali che non abbiamo bisogno di un proxy.
MC: – La risposta giusta alla domanda è: «Perché avete bisogno di un proxy con un sistema del genere?» Solo a causa del NAT o per monitorare attraverso un canale lento…
A: – State usando «Zabbix» come allerta, se ho capito bene. O i grafici (dove il layer archivio) sono andati in un altro sistema, tipo Grafana? O non utilizzate questa funzionalità?
MM: – Ribadisco: abbiamo effettuato un'integrazione completa. Stiamo trasferendo la storia in «Clickhouse», ma abbiamo anche modificato il frontend PHP. Il frontend PHP consulta «Clickhouse» e genera tutti i grafici da lì. Tuttavia, onestamente, abbiamo una parte che crea dati da «Clickhouse» e da quelli di «Zabbix» per altri sistemi di visualizzazione grafica.
MC: – Anche in «Grafana».
Come è stata presa la decisione e la raccolta delle risorse?
A: – Condividete un po' la cucina interna. Come è stata presa la decisione di allocare risorse per un importante rinnovamento del prodotto? Ci sono, in effetti, certi rischi. E per favore, nel contesto di ciò che intendete supportare con nuove versioni: come si giustifica questa decisione dal punto di vista della gestione?
MM: – Evidentemente, non abbiamo raccontato molto bene il dramma della storia. Ci siamo trovati in una situazione in cui dovevamo fare qualcosa, e abbiamo proceduto con sostanzialmente due team paralleli:
- Una persona si è occupata del lancio di un sistema di monitoraggio basato su nuove metodologie: monitoraggio come servizio, una serie standard di soluzioni open source che combiniamo e poi tentiamo di adattare i processi aziendali per lavorare con il nuovo sistema di monitoraggio.
- Parallelamente, avevamo un programmatore appassionato che si occupava di questo (parlando di sé). Alla fine, ha vinto.
A: – E qual è la dimensione del team?
MC: – È proprio di fronte a voi.
A: – Quindi, come sempre, è necessario avere un passionale?
MM: – Non so cosa sia un passionale.
A: – In questo caso, evidentemente, sei tu. Grazie mille, siete fantastici.
MM: – Grazie.
Riguardo ai patch per Zabbix
A: – Per un sistema che utilizza proxy (ad esempio, in alcuni sistemi distribuiti), è possibile adattare e patchare la vostra soluzione, diciamo, i poller, i proxy e parzialmente il preprocessore di "Zabbix"; e la loro interazione? È possibile ottimizzare i lavori esistenti per un sistema con più proxy?
MM: – So che il server «Zabbix» viene costruito tramite un proxy (viene compilato e si ottiene il codice). Non lo abbiamo testato in produzione. Non ne sono sicuro, ma penso che il gestore del preprocessore non venga utilizzato nel proxy. Il compito del proxy è prendere un insieme di metriche da «Zabbix», scansionarle (scrive anche la configurazione, il database locale) e restituirle al server «Zabbix». Il preprocessamento avverrà poi direttamente sul server quando riceve i dati.
L'interesse per il proxy è comprensibile. Lo verificheremo. È un argomento interessante.
A: – L'idea era questa: se è possibile applicare patch ai poller, allora si possono applicare patch al proxy e modificare l'interazione con il server, adattando il preprocessore a questi scopi solo sul server.
MM: – Penso sia anche più semplice. Prendete il codice, applicate la patch, poi configurate come necessario – costruite i server proxy (ad esempio con ODBC) e distribuite il codice patchato nei vari sistemi. Dove serve, costruite i proxy, dove serve, il server.
A: – Non sarà necessario applicare ulteriori patch per la trasmissione del proxy al server, giusto?
MC: – No, è standard.
MM: In realtà, una delle idee non è mai stata sentita. Abbiamo sempre mantenuto un equilibrio tra l'esplosione di idee e il numero di cambiamenti, mantenendo la facilità di supporto.
Un po' di pubblicità 🙂
Grazie per essere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci ai tuoi conoscenti, , un'alternativa unica ai server entry-level, che abbiamo creato per te: (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! Scopri di più su
Fonte: habr.com
