La prossima conferenza HighLoad++ si terrà il 6 e 7 aprile 2020 a San Pietroburgo Dettagli e biglietti . HighLoad++ Mosca 2018. Padiglione “Mosca”. 9 novembre, 15:00. Tesi e .
* Monitoraggio: online e analisi.
*Limitazioni di base della piattaforma ZABBIX.
* Решение для масштабирования хранилища аналитики.
* Ottimizzazione del server ZABBIX.
* Ottimizzazione dell'interfaccia utente.
* Esperienza nell'utilizzo del sistema con carichi superiori a 40k NVPS.
* Brevi conclusioni.
Mikhail Makurov (di seguito – MM): – Всем привет!
Maxim Chernetsov (di seguito – MCH): – Добрый день!
MM: – Lascia che ti presenti Maxim. Max è un ingegnere di talento, il miglior networker che conosco. Maxim si occupa di reti e servizi, del loro sviluppo e funzionamento.
МЧ: – E vorrei parlarvi di Mikhail. Mikhail è uno sviluppatore C. Ha scritto diverse soluzioni di elaborazione del traffico ad alto carico per la nostra azienda. Viviamo e lavoriamo negli Urali, nella città dei duri Chelyabinsk, nella compagnia Intersvyaz. La nostra azienda fornisce servizi Internet e televisione via cavo a un milione di persone in 16 città.
MM: – И стоит сказать, что «Интерсвязь» – гораздо больше, чем просто провайдер, это IT-компания. Большинство наших решений сделано силами нашего IT-отдела.
E: от серверов, обрабатывающих трафик, до колл-центра и мобильного приложения. В IT-отделе сейчас около 80 человек с очень и очень разнообразными компетенциями.
A proposito di Zabbix e della sua architettura
МЧ: – E ora proverò a stabilire un record personale e a dire in un minuto cos’è Zabbix (di seguito denominato “Zabbix”).
«Заббикс» позиционирует себя как систему мониторинга «из коробки» уровня предприятия. В нём есть много упрощающих жизнь функций: развитые правила эскалации, API для интеграции, группировка и автообнаружение хостов и метрик. В «Заббиксе» есть так называемые средства масштабирования – прокси. «Заббикс» – это система с открытым исходным кодом.
Brevemente sull'architettura. Possiamo dire che è composto da tre componenti:
- Server. Scritto in C. Con elaborazione e trasferimento di informazioni piuttosto complessi tra thread. In esso avviene tutta l'elaborazione: dalla ricezione al salvataggio nel database.
- Tutti i dati sono memorizzati nel database. Zabbix supporta MySQL, PostreSQL e Oracle.
- L'interfaccia web è scritta in PHP. Sulla maggior parte dei sistemi viene fornito con un server Apache, ma funziona in modo più efficiente in combinazione con nginx + php.
Oggi vorremmo raccontare una storia della vita della nostra azienda legata a Zabbix...
История из жизни компании «Интерсвязь». Что имеем и что нужно?
5 o 6 mesi fa. Un giorno dopo il lavoro...
МЧ: - Misha, ciao! Sono felice di essere riuscito a catturarti: c'è una conversazione. Abbiamo avuto ancora una volta problemi con il monitoraggio. Durante un grave incidente tutto procedeva lentamente e non c'erano informazioni sullo stato della rete. Sfortunatamente, questa non è la prima volta che ciò accade. Ho bisogno del vostro aiuto. Facciamo in modo che il nostro monitoraggio funzioni in qualsiasi circostanza!
MM: - Ma prima sincronizziamo. Non ci guardo da un paio d'anni. Per quanto ricordo, abbiamo abbandonato Nagios e siamo passati a Zabbix circa 8 anni fa. E ora sembra che abbiamo 6 server potenti e circa una dozzina di proxy. Sto confondendo qualcosa?
МЧ: - Quasi. 15 server, alcuni dei quali sono macchine virtuali. La cosa più importante è che non ci salvi nel momento in cui ne abbiamo più bisogno. Come un incidente: i server rallentano e non puoi vedere nulla. Abbiamo provato a ottimizzare la configurazione, ma questo non ha fornito l'aumento ottimale delle prestazioni.
MM: - È chiaro. Hai guardato qualcosa, hai già scoperto qualcosa dalla diagnostica?
МЧ: – La prima cosa di cui devi occuparti è il database. MySQL viene costantemente caricato, memorizza nuove metriche e quando Zabbix inizia a generare una serie di eventi, il database va in overdrive letteralmente per alcune ore. Ti ho già parlato dell'ottimizzazione della configurazione, ma quest'anno hanno letteralmente aggiornato l'hardware: i server hanno più di cento gigabyte di memoria e array di dischi su RAID SSD - non ha senso farli crescere linearmente a lungo termine. Cosa facciamo?
MM: - È chiaro. In generale, MySQL è un database LTP. Apparentemente non è più adatto a conservare un archivio di metriche delle nostre dimensioni. Scopriamolo.
МЧ: - Andiamo!
Интеграция Zabbix и Clickhouse как итог хакатона
Dopo qualche tempo abbiamo ricevuto dati interessanti:
La maggior parte dello spazio nel nostro database era occupato dall'archivio delle metriche e meno dell'1% era utilizzato per configurazione, modelli e impostazioni. A quel punto gestivamo già da più di un anno la soluzione Big Data basata su Clickhouse. La direzione del movimento era ovvia per noi. Al nostro Hackathon primaverile, ho scritto l'integrazione di Zabbix con 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 confronto, abbiamo generato lo stesso carico fornito dal server Zabbix e abbiamo osservato come si sarebbero comportati i sistemi. Abbiamo scritto i dati in batch di 1000 righe, utilizzando CURL. Abbiamo ipotizzato in anticipo che Clickhouse sarebbe stato più efficiente per il profilo di carico di Zabbix. I risultati hanno addirittura superato le nostre aspettative:
Nelle stesse condizioni di test, Clickhouse ha scritto tre volte più dati. Allo stesso tempo, entrambi i sistemi hanno consumato in modo molto efficiente (una piccola quantità di risorse) durante la lettura dei dati. Ma Elastics richiedeva una grande quantità di processore durante la registrazione:
Nel complesso, Clickhouse si è rivelato significativamente superiore a Elastix in termini di consumo e velocità del processore. Allo stesso tempo, grazie alla compressione dei dati, Clickhouse utilizza 11 volte meno il disco rigido ed esegue circa 30 volte meno operazioni sul disco:
МЧ: – Sì, il lavoro di Clickhouse con il sottosistema del disco è implementato in modo molto efficiente. Puoi utilizzare enormi dischi SATA per database e ottenere velocità di scrittura di centinaia di migliaia di righe al secondo. Il sistema pronto all'uso supporta lo sharding, la replica ed è molto facile da configurare. Siamo più che soddisfatti del suo utilizzo durante tutto l'anno.
Per ottimizzare le risorse, puoi installare Clickhouse accanto al tuo database principale esistente e quindi risparmiare molto tempo della CPU e operazioni sul disco. Abbiamo spostato l'archivio delle metriche nei cluster Clickhouse esistenti:
Abbiamo alleggerito così tanto il database MySQL principale che abbiamo potuto combinarlo su un'unica macchina con il server Zabbix e abbandonare il server dedicato per MySQL.
Come funzionano i sondaggi in Zabbix?
mesi fa 4
MM: – Ну что, о проблемах с базой можно забыть?
МЧ: - Certamente! Un altro problema che dobbiamo risolvere è la lentezza nella raccolta dei dati. Ora tutti i nostri 15 server proxy sono sovraccarichi di processi SNMP e polling. E non c'è altro modo se non installare nuovi e nuovi server.
MM: – Отлично. Но расскажи сперва, как устроен поллинг в «Заббикс»?
МЧ: – Если коротко, то существует 20 типов метрик и десяток способов их получения. «Заббикс» может собирать данные либо в режиме «запрос – ответ», либо ожидать новые данные через «Интерфейс Траппера».
Vale la pena notare che nello Zabbix originale questo metodo (Trapper) è il più veloce.
Esistono server proxy per la distribuzione del carico:
I proxy possono eseguire le stesse funzioni di raccolta del server Zabbix, ricevendo attività da esso e inviando le metriche raccolte tramite l'interfaccia Trapper. Questo è il modo ufficialmente raccomandato per distribuire il carico. I proxy sono utili anche per monitorare l'infrastruttura remota che opera tramite NAT o un canale lento:
MM: – Con l’architettura tutto è chiaro. Dobbiamo cercare le fonti...
Пару дней спустя
La storia di come ha vinto nmap fping
MM: "Penso di aver scoperto qualcosa."
МЧ: - Dimmi!
MM: – Ho scoperto che durante la verifica della disponibilità, Zabbix controlla un massimo di 128 host alla volta. Ho provato ad aumentare questo numero a 500 e a rimuovere l'intervallo tra pacchetti nel loro ping (ping): questo ha raddoppiato le prestazioni. Ma vorrei numeri più grandi.
МЧ: – Nella mia pratica, a volte devo verificare la disponibilità di migliaia di host e non ho mai visto nulla di più veloce di nmap per questo. Sono sicuro che questo sia il modo più veloce. Proviamolo! Dobbiamo aumentare in modo significativo il numero di host per iterazione.
MM: – Controlla più di cinquecento? 600?
МЧ: - Almeno un paio di migliaia.
MM: - OK. La cosa più importante che volevo dire è che ho scoperto che la maggior parte dei sondaggi in Zabbix vengono eseguiti in modo sincrono. Dobbiamo assolutamente cambiarlo in modalità asincrona. Quindi possiamo aumentare notevolmente il numero di parametri raccolti dai sondaggi, soprattutto se aumentiamo il numero di parametri per iterazione.
МЧ: - Grande! E quando?
MM: – Come al solito, ieri.
МЧ: – Abbiamo confrontato entrambe le versioni di fping e nmap:
Su un gran numero di host, si prevedeva che nmap fosse fino a cinque volte più efficace. Poiché nmap controlla solo la disponibilità e i tempi di risposta, abbiamo spostato il calcolo delle perdite sui trigger e ridotto significativamente gli intervalli di controllo della disponibilità. Abbiamo riscontrato che il numero ottimale di host per nmap è di circa 4mila per iterazione. Nmap ci ha permesso di ridurre di tre volte il costo della CPU per i controlli di disponibilità e di ridurre l'intervallo da 120 secondi a 10.
Ottimizzazione del sondaggio
MM: “Poi abbiamo iniziato a fare sondaggi. Eravamo interessati principalmente al rilevamento e agli agenti SNMP. In Zabbix, il polling viene effettuato in modo sincrono e sono state adottate misure speciali per aumentare l’efficienza del sistema. In modalità sincrona, l'indisponibilità dell'host provoca un significativo peggioramento del polling. Esiste un intero sistema di stati, esistono processi speciali: i cosiddetti poller irraggiungibili, che funzionano solo con host irraggiungibili:
Questo è un commento che dimostra la matrice dello stato, tutta la complessità del sistema di transizioni necessarie affinché il sistema rimanga efficace. Inoltre, il polling sincrono stesso è piuttosto lento:
Именно поэтому тысячи потоков поллеров на десятке прокси не могли собрать для нас нужного количества данных. Асинхронная реализация решила не только проблемы с количеством потоков, но и значительно упростила систему состояний недоступных хостов, потому что при любом количестве, проверяемых в одной итерации поллинга, максимальное время ожидания составляло 1 тайм-аут:
Inoltre, abbiamo modificato e migliorato il sistema di polling per le richieste SNMP. Il fatto è che la maggior parte delle persone non è in grado di rispondere a più richieste SNMP contemporaneamente. Pertanto, abbiamo creato una modalità ibrida, quando il polling SNMP dello stesso host viene eseguito in modo asincrono:
Questo viene fatto per l'intero pacchetto di host. Questa modalità in definitiva non è più lenta di quella completamente asincrona, poiché il polling di un centinaio e mezzo di valori SNMP è ancora molto più veloce di 1 timeout.
I nostri esperimenti hanno dimostrato che il numero ottimale di richieste in un'iterazione è di circa 8mila con il polling SNMP. In totale, il passaggio alla modalità asincrona ci ha permesso di accelerare le prestazioni del polling di 200, diverse centinaia di volte.
МЧ: – Le ottimizzazioni del polling risultanti hanno dimostrato che non solo possiamo eliminare tutti i proxy, ma anche ridurre gli intervalli per molti controlli e che i proxy non saranno più necessari per condividere il carico.
Circa tre mesi fa
Cambia l'architettura: aumenta il carico!
MM: - Bene, Max, è ora di diventare produttivi? Ho bisogno di un server potente e di un buon ingegnere.
МЧ: - Ok, pianifichiamolo. È giunto il momento di superare il punto morto dei 5mila parametri al secondo.
Mattina dopo l'aggiornamento
МЧ: – Миша, мы обновились, но к утру откатились обратно… Отгадай, какой скорости удалось достичь?
MM: – 20mila massimo.
МЧ: - Sì, 25! Purtroppo siamo esattamente al punto di partenza.
MM: - Perché? Hai eseguito qualche diagnostica?
МЧ: - Si certo! Ecco, ad esempio, un top interessante:
MM: - Guardiamo. Vedo che abbiamo provato un numero enorme di thread di sondaggi:
Ma allo stesso tempo non sono riusciti a riciclare il sistema nemmeno della metà:
E la prestazione complessiva è piuttosto ridotta, circa 4mila parametri al secondo:
C'è niente altro?
МЧ: – Sì, strace di uno dei sondaggi:
MM: – Qui puoi vedere chiaramente che il processo di votazione è in attesa di “semafori”. Queste sono le serrature:
МЧ: – Непонятно.
MM: – Guarda, questo è simile a una situazione in cui un gruppo di thread sta cercando di lavorare con risorse con cui solo uno può lavorare alla volta. Quindi tutto ciò che possono fare è condividere questa risorsa nel tempo:
E le prestazioni totali di lavoro con tale risorsa sono limitate dalla velocità di un core:
Esistono due modi per risolvere questo problema.
Aggiorna l'hardware della macchina, passa a core più veloci:
Oppure cambiare l'architettura e allo stesso tempo cambiare il carico:
МЧ: – A proposito, sulla macchina di prova utilizzeremo meno core rispetto a quella da combattimento, ma sono 1,5 volte più veloci in frequenza per core!
MM: – Ясно? Надо смотреть код сервера.
Percorso dei dati nel server Zabbix
МЧ: – Per capirlo, abbiamo iniziato ad analizzare come vengono trasferiti i dati all’interno del server Zabbix:
Bella foto, vero? Vediamolo passo dopo passo per renderlo più o meno chiaro. Esistono thread e servizi responsabili della raccolta dei dati:
Trasmettono le metriche raccolte tramite un socket al gestore del preprocessore, dove vengono salvate in una coda:
Il “responsabile del preprocessore” trasmette i dati ai suoi lavoratori, che eseguono istruzioni di preelaborazione e li restituiscono attraverso lo stesso socket:
После этого препроцессор-менеджер сохраняет их в кэше истории:
Da lì vengono presi dagli storici che svolgono molte funzioni: ad esempio, calcolare i trigger, riempire la cache dei valori e, soprattutto, salvare le metriche nell'archivio della cronologia. In generale, il processo è complesso e molto confuso.
MM: – La prima cosa che abbiamo visto è che la maggior parte dei thread compete per la cosiddetta “cache di configurazione” (l’area di memoria in cui sono archiviate tutte le configurazioni del server). I thread responsabili della raccolta dei dati effettuano soprattutto molti blocchi:
…так как в конфигурации хранятся не только метрики с их параметрами, но и очереди, из которых поллеры берут информацию о том, что им делать дальше. Когда поллеров много, и один блокирует конфигурацию, остальные ждут запросов:
I sondaggi non dovrebbero entrare in conflitto
Pertanto, la prima cosa che abbiamo fatto è stata dividere la coda in 4 parti e permettere ai poller di bloccare queste code, queste parti contemporaneamente, in condizioni di sicurezza:
Ciò ha eliminato la concorrenza per la cache di configurazione e la velocità dei poller è aumentata in modo significativo. Ma poi abbiamo riscontrato il fatto che il gestore del preprocessore ha iniziato ad accumulare una coda di lavori:
Il responsabile del preprocessore deve essere in grado di stabilire le priorità
Ciò è accaduto nei casi in cui gli mancavano le prestazioni. Quindi tutto ciò che poteva fare era accumulare richieste dai processi di raccolta dati e sommare il loro buffer finché non consumava tutta la memoria e si bloccava:
Per risolvere questo problema abbiamo aggiunto una seconda presa dedicata specificatamente ai lavoratori:
Pertanto, il responsabile del preprocessore è stato in grado di dare priorità al proprio lavoro e, se il buffer cresce, il compito è rallentare la rimozione, dando ai lavoratori l'opportunità di occupare questo buffer:
Poi abbiamo scoperto che uno dei motivi del rallentamento erano proprio i lavoratori, poiché gareggiavano per una risorsa del tutto irrilevante per il loro lavoro. Abbiamo documentato questo problema come correzione di bug ed è già stato risolto nelle nuove versioni di Zabbix:
Aumentiamo il numero di socket: otteniamo il risultato
Inoltre, lo stesso gestore del preprocessore è diventato un collo di bottiglia, poiché è un thread. Si basava sulla velocità del core, fornendo una velocità massima di circa 70mila metri al secondo:
Pertanto ne abbiamo realizzati quattro, con quattro serie di prese, operai:
E questo ci ha permesso di aumentare la velocità fino a circa 130mila metriche:
Нелинейность роста объясняется тем, что появилась конкуренция за кэш истории. За него конкурировали 4 препроцессор-менеджера и хистори-синкеры. К этому моменту мы получали на тестовой машине примерно 130 тысяч метрик в секунду, утилизируя её примерно на 95 % по процессору:
Circa 2,5 mesi fa
Il rifiuto della comunità snmp ha aumentato gli NVP di una volta e mezza
MM: – Max, mi serve una nuova macchina di prova! Non ci adattiamo più a quello attuale.
МЧ: - Cos'hai adesso?
MM: – Ora – 130 NVP e un processore pronto per l'uso.
МЧ: - Oh! Freddo! Aspetta, ho due domande. Secondo i miei calcoli il nostro fabbisogno è di circa 15-20mila metriche al secondo. Perché ne abbiamo bisogno di più?
MM: "Voglio finire il lavoro." Vorrei vedere quanto possiamo spremere da questo sistema.
МЧ: - Ma ...
MM: "Ma è inutile per gli affari."
МЧ: - È chiaro. E la seconda domanda: possiamo supportare ciò che abbiamo adesso da soli, senza l'aiuto di uno sviluppatore?
MM: - Non credo. Cambiare il funzionamento della cache di configurazione è un problema. Influisce sui cambiamenti nella maggior parte dei thread ed è piuttosto difficile da mantenere. Molto probabilmente, sarà molto difficile mantenerlo.
МЧ: “Allora abbiamo bisogno di una sorta di alternativa.”
MM: - Esiste una tale opzione. Possiamo passare ai core veloci, abbandonando il nuovo sistema di bloccaggio. Otterremo comunque una performance di 60-80mila metriche. Allo stesso tempo, possiamo lasciare tutto il resto del codice. La clickhouse e il polling asincrono funzioneranno. E sarà facile mantenerlo.
МЧ: - Sorprendente! Suggerisco di fermarci qui.
Dopo aver ottimizzato il lato server, siamo finalmente riusciti a lanciare il nuovo codice in produzione. Abbiamo abbandonato alcune modifiche in favore del passaggio a una macchina con core veloci e della riduzione al minimo del numero di modifiche al codice. Abbiamo anche semplificato la configurazione ed eliminato, ove possibile, le macro negli elementi dati, poiché introducono un blocco aggiuntivo.
Например, отказ от часто встречающегося в документации и примерах макроса snmp-community в нашем случае позволил дополнительно ускорить NVPs примерно в 1,5 раза.
Dopo due giorni di produzione
Rimozione dei popup della cronologia degli incidenti
МЧ: – Миша, мы два дня пользуемся системой, и всё работает. Но только тогда, когда всё работает! У нас были плановые работы с переносом достаточно большого сегмента сети, и мы снова руками проверяли, что поднялось, что – нет.
MM: - Non può essere! Abbiamo controllato tutto 10 volte. Il server gestisce istantaneamente anche l'indisponibilità completa della rete.
МЧ: - Sì, capisco tutto: server, database, top, austat, logs - tutto è veloce... Ma guardiamo l'interfaccia web, e c'è un processore “nello scaffale” sul server e questo:
MM: - È chiaro. Guardiamo il web. Abbiamo scoperto che in una situazione in cui si verificava un gran numero di incidenti attivi, la maggior parte dei widget live iniziava a funzionare molto lentamente:
Il motivo di ciò è stata la generazione di popup della cronologia degli incidenti generati per ciascun elemento nell'elenco. Pertanto, abbiamo abbandonato la generazione di queste finestre (5 righe di codice commentate) e questo ha risolto i nostri problemi.
Il tempo di caricamento dei widget, anche quando completamente non disponibili, è stato ridotto da diversi minuti ai 10-15 secondi per noi accettabili, e la cronologia può ancora essere visualizzata cliccando sull'ora:
Dopo il lavoro. 2 mesi fa
МЧ: - Misha, te ne vai? Dobbiamo parlare.
MM: – Не собирался. Опять что-то с «Заббиксом»?
МЧ: - No, rilassati! Volevo solo dirvi: funziona tutto, grazie! Ho una birra.
Zabbix è efficiente
Zabbix è un sistema e una funzione abbastanza universali e ricchi. Può essere utilizzato per piccole installazioni pronte all'uso, ma man mano che le esigenze crescono, deve essere ottimizzato. Per archiviare un archivio di metriche di grandi dimensioni, utilizzare uno spazio di archiviazione adatto:
- puoi utilizzare strumenti integrati sotto forma di integrazione con Elasticsearch o caricamento della cronologia su file di testo (disponibile dalla versione XNUMX);
- Puoi sfruttare la nostra esperienza e l'integrazione con Clickhouse.
Per aumentare notevolmente la velocità di raccolta delle metriche, raccoglile utilizzando metodi asincroni e trasmettili attraverso l'interfaccia trapper al server Zabbix; oppure puoi usare una patch per rendere asincroni i poller Zabbix.
Zabbix è scritto in C ed è abbastanza efficiente. Risolvere diversi colli di bottiglia architetturali consente di aumentarne ulteriormente le prestazioni e, nella nostra esperienza, ottenere più di 100mila metriche su una macchina a processore singolo.
La stessa toppa Zabbix
MM: – Voglio aggiungere un paio di punti. L'intero rapporto attuale, tutti i test, i numeri sono forniti per la configurazione che utilizziamo. Ora ne stiamo ricavando circa 20mila parametri al secondo. Se stai cercando di capire se funzionerà per te, puoi confrontare. Quanto discusso oggi è pubblicato su GitHub sotto forma di patch:
La toppa include:
- piena integrazione con Clickhouse (sia server Zabbix che frontend);
- risolvere problemi con il gestore del preprocessore;
- polling asincrono.
La patch è compatibile con tutta la versione 4, inclusa lts. Molto probabilmente, con modifiche minime funzionerà sulla versione 3.4.
Grazie per la vostra attenzione.
domande
Domanda del pubblico (di seguito – A): – Buon pomeriggio! Per favore dimmi, hai piani per un'interazione intensa con il team Zabbix o con loro con te, in modo che questa non sia una patch, ma un comportamento normale di Zabbix?
MM: – Sì, applicheremo sicuramente alcuni cambiamenti. Qualcosa accadrà, qualcosa rimarrà nella toppa.
E: – Grazie mille per l’eccellente rapporto! Per favore dimmi, dopo aver applicato la patch, il supporto di Zabbix rimarrà e come continuare l'aggiornamento alle versioni successive? Sarà possibile aggiornare Zabbix dopo la patch 4.2, 5.0?
MM: – О поддержке я не могу сказать. Если б я был техподдержкой «Заббикса», то, видимо, сказал бы нет, потому что это чужой код. Что касается кодовой базы 4.2, то наша позиция такая: «Мы будем идти со временем, и сами будем обновляться на следующей версии». Поэтому какое-то время мы будем выкладывать патч на обновлённые версии. Я уже сказал в докладе: количество изменений с версиями пока достаточно небольшое. Думаю, переход с 3.4 на 4 у нас заняло, кажется, минут 15. Там что-то поменялось, но не сильно важное.
E: – Quindi prevedi di supportare la tua patch e di poterla installare in sicurezza in produzione e ricevere aggiornamenti in qualche modo in futuro?
MM: – Lo consigliamo vivamente. Questo ci risolve molti problemi.
МЧ: – Ancora una volta vorrei attirare l’attenzione sul fatto che le modifiche che non riguardano l’architettura e non riguardano il blocco o le code sono modulari, si trovano in moduli separati. Anche con piccole modifiche puoi mantenerli abbastanza facilmente.
MM: – Se sei interessato ai dettagli, “Clickhouse” utilizza la cosiddetta libreria della cronologia. È slegato: è una copia del supporto Elastics, ovvero è configurabile. Il sondaggio cambia solo i sondaggi. Crediamo che funzionerà per molto tempo.
E: - Molte grazie. Dimmi, c'è qualche documentazione delle modifiche apportate?
MM: – La documentazione è una patch. Ovviamente con l'introduzione di Clickhouse, con l'introduzione di nuove tipologie di poller, nascono nuove opzioni di configurazione. Il collegamento dell'ultima diapositiva contiene una breve descrizione di come utilizzarlo.
Informazioni sulla sostituzione di fping con nmap
E: – Come hai finalmente implementato tutto questo? Puoi fornire esempi specifici: hai strapper e uno script esterno? Cosa finisce per controllare un numero così elevato di host così rapidamente? Come estrai questi host? Dobbiamo darli in pasto a nmap in qualche modo, prenderli da qualche parte, inserirli, eseguire qualcosa?...
MM: – Круто. Очень правильный вопрос! Суть такая. Мы модифицировали библиотеку (ICMP-пинг, составная часть «Заббикса») для ICMP-проверок, в которых указано количество пакетов – единица (1), а код пытается использовать nmap. То есть это внутренняя работа «Заббикса», стало внутренней работой пингера. Соответственно, никакой синхронизации или использования траппера не требуется. Это было сделано сознательно, чтобы оставить систему целостной и не заниматься синхронизацией двух систем баз: что проверять, заливать через поллер, а не сломалась ли у нас заливка?.. Это гораздо проще.
E: – Funziona anche con i proxy?
MM: – Sì, ma non abbiamo controllato. Il codice di polling è lo stesso sia in Zabbix che nel server. Dovrebbe funzionare. Vorrei sottolinearlo ancora una volta: le prestazioni del sistema sono tali che non abbiamo bisogno di un proxy.
МЧ: – La risposta corretta alla domanda è: “Perché hai bisogno di un proxy con un sistema del genere?” Solo a causa del NAT o del monitoraggio attraverso una sorta di canale lento...
E: – E tu usi Zabbix come allertore, se ho capito bene. Oppure la tua grafica (dove si trova il livello di archivio) è stata spostata su un altro sistema, come Grafana? Oppure non stai utilizzando questa funzionalità?
MM: – Lo sottolineo ancora una volta: abbiamo raggiunto la completa integrazione. Stiamo riversando la storia in Clickhouse, ma allo stesso tempo abbiamo cambiato il frontend php. Il frontend Php va su Clickhouse e da lì esegue tutta la grafica. Allo stesso tempo, a dire il vero, abbiamo una parte che costruisce dati in altri sistemi di visualizzazione grafica dalla stessa Clickhouse, dagli stessi dati Zabbix.
МЧ: – Anche in “Grafan”.
Come sono state prese le decisioni sull’allocazione delle risorse?
E: – Condividi un po’ della tua cucina interiore. Come è stata presa la decisione che fosse necessario stanziare risorse per una lavorazione seria del prodotto? Questi sono, in generale, alcuni rischi. E per favore dimmi, nel contesto del fatto che supporterai le nuove versioni: come si giustifica questa decisione da un punto di vista gestionale?
MM: – Видимо, драму истории мы не очень хорошо рассказали. Мы оказались в ситуации, когда что-то надо было делать, и пошли по сути двумя параллельными командами:
- Uno stava lanciando un sistema di monitoraggio utilizzando nuovi metodi: monitoraggio come servizio, un insieme standard di soluzioni open source che combiniamo e quindi proviamo a modificare il processo aziendale per lavorare con il nuovo sistema di monitoraggio.
- Allo stesso tempo, avevamo un programmatore entusiasta che lo faceva (su se stesso). È successo così che ha vinto.
E: – E qual è la dimensione della squadra?
МЧ: - Lei è di fronte a te.
E: – То есть как всегда нужен пассионарий?
MM: – Non so cosa sia un passionale.
E: - In questo caso, a quanto pare, tu. Grazie mille, sei fantastico.
MM: - Grazie.
Informazioni sulle patch per Zabbix
E: – Per un sistema che utilizza proxy (ad esempio, in alcuni sistemi distribuiti), è possibile adattare e applicare patch, ad esempio, poller, proxy e parzialmente il preprocessore di Zabbix stesso; e la loro interazione? È possibile ottimizzare gli sviluppi esistenti per un sistema con più deleghe?
MM: – So che il server Zabbix è assemblato utilizzando un proxy (il codice viene compilato e ottenuto). Non l'abbiamo testato in produzione. Non ne sono sicuro, ma penso che il gestore del preprocessore non sia utilizzato nel proxy. Il compito del proxy è prendere un insieme di metriche da Zabbix, unirle (registra anche la configurazione, il database locale) e restituirle al server Zabbix. Il server stesso eseguirà quindi la preelaborazione quando lo riceve.
L'interesse per i proxy è comprensibile. Lo controlleremo. Questo è un argomento interessante.
E: – Идея такая была: если можно патчить поллеры, их можно патчить на прокси и патчить взаимодействие с сервером, а препроцессор под эти цели адаптировать только на сервере.
MM: – Penso che sia ancora più semplice. Prendi il codice, applichi una patch, quindi la configuri nel modo che ti serve: raccogli i server proxy (ad esempio con ODBC) e distribuisci il codice patchato sui sistemi. Se necessario, raccogli un proxy, se necessario, un server.
E: – Дополнительно патчить передачу прокси к серверу не придётся, скорее всего?
МЧ: - No, è standard.
MM: – In effetti, una delle idee non suonava. Abbiamo sempre mantenuto un equilibrio tra l'esplosione di idee e la quantità di cambiamenti e facilità di supporto.
Alcuni annunci 🙂
Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, , un analogo unico dei server entry-level, che è stato inventato da noi per te: (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).
Dell R730xd 2 volte più economico nel data center Equinix Tier IV ad Amsterdam? Solo qui In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi
Fonte: habr.com