Vedremo come funziona Zabbix con il database TimescaleDB come backend. Ti mostreremo come iniziare da zero e come migrare da PostgreSQL. Forniremo anche test comparativi delle prestazioni delle due configurazioni.
HighLoad++ Siberia 2019. Sala Tomsk. 24 giugno, 16:00. Tesi e . La prossima conferenza HighLoad++ si terrà il 6 e 7 aprile 2020 a San Pietroburgo. Dettagli e biglietti .
Andrey Gushchin (di seguito – AG): – Sono un tecnico del supporto tecnico ZABBIX (di seguito denominato “Zabbix”), un formatore. Lavoro nel supporto tecnico da più di 6 anni e ho avuto esperienza diretta con le prestazioni. Oggi parlerò delle prestazioni che TimescaleDB può fornire rispetto al normale PostgreSQL 10. Inoltre, alcune parti introduttive su come funziona in generale.
Le principali sfide per la produttività: dalla raccolta dei dati alla pulizia dei dati
Per cominciare, ci sono alcune sfide prestazionali che ogni sistema di monitoraggio deve affrontare. La prima sfida per la produttività è raccogliere ed elaborare rapidamente i dati.
Un buon sistema di monitoraggio dovrebbe ricevere rapidamente e tempestivamente tutti i dati, elaborarli secondo le espressioni trigger, cioè elaborarli secondo alcuni criteri (questo è diverso nei diversi sistemi) e salvarli in un database per utilizzare questi dati nel futuro.
La seconda sfida in termini di prestazioni è l'archiviazione della cronologia. Archivia spesso in un database e ottieni un accesso rapido e conveniente a queste metriche raccolte in un periodo di tempo. La cosa più importante è che questi dati siano convenienti da ottenere, utilizzarli in report, grafici, trigger, in alcuni valori di soglia, per avvisi, ecc.
La terza sfida in termini di prestazioni è la cancellazione della cronologia, ovvero quando si arriva al punto in cui non è più necessario archiviare metriche dettagliate raccolte in 5 anni (anche mesi o due mesi). Alcuni nodi della rete sono stati cancellati, oppure alcuni host, le metriche non sono più necessarie perché sono già obsolete e non più raccolte. Tutto questo deve essere ripulito in modo che il database non diventi troppo grande. In generale, la cancellazione della cronologia è spesso un test serio per l'archiviazione: spesso ha un impatto molto forte sulle prestazioni.
Come risolvere i problemi di memorizzazione nella cache?
Parlerò ora nello specifico di Zabbix. In Zabbix, la prima e la seconda chiamata vengono risolte utilizzando la memorizzazione nella cache.
Raccolta ed elaborazione dei dati: utilizziamo la RAM per archiviare tutti questi dati. Questi dati verranno ora discussi più nel dettaglio.
Anche dal lato del database c'è un po' di memorizzazione nella cache per le selezioni principali, per i grafici e altre cose.
Caching sul lato del server Zabbix stesso: abbiamo ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Cos'è?
ConfigurationCache è la cache principale in cui memorizziamo metriche, host, elementi di dati, trigger; tutto ciò di cui hai bisogno per elaborare la preelaborazione, raccogliere dati, da quali host raccogliere, con quale frequenza. Tutto questo è archiviato in ConfigurationCache in modo da non andare nel database e creare query non necessarie. Dopo l'avvio del server, aggiorniamo questa cache (la creiamo) e la aggiorniamo periodicamente (a seconda delle impostazioni di configurazione).
Memorizzazione nella cache di Zabbix. Raccolta dati
Qui il diagramma è piuttosto grande:
I principali nello schema sono questi collettori:
Questi sono i processi di assemblaggio stessi, vari “poller” responsabili di diversi tipi di assemblaggi. Raccolgono dati tramite icmp, ipmi e vari protocolli e li trasferiscono tutti alla preelaborazione.
Cache della cronologia di preelaborazione
Inoltre, se abbiamo elementi di dati calcolati (chi ha familiarità con Zabbix lo sa), ovvero elementi di dati calcolati e di aggregazione, li prendiamo direttamente da ValueCache. Più tardi ti dirò come viene riempito. Tutti questi raccoglitori utilizzano ConfigurationCache per ricevere i propri lavori e quindi trasmetterli alla preelaborazione.
La preelaborazione utilizza anche ConfigurationCache per ottenere passaggi di preelaborazione ed elabora questi dati in vari modi. A partire dalla versione 4.2, lo abbiamo spostato su un proxy. Questo è molto conveniente, perché la preelaborazione stessa è un'operazione piuttosto difficile. E se hai uno Zabbix molto grande, con un gran numero di elementi di dati e un'alta frequenza di raccolta, allora questo semplifica notevolmente il lavoro.
Di conseguenza, dopo aver elaborato questi dati in qualche modo utilizzando la preelaborazione, li salviamo in HistoryCache per elaborarli ulteriormente. Questo conclude la raccolta dei dati. Passiamo al processo principale.
Il lavoro del sincronizzatore della storia
Il processo principale in Zabbix (poiché è un'architettura monolitica) è History Syncer. Questo è il processo principale che si occupa specificamente dell'elaborazione atomica di ciascun elemento di dati, ovvero ciascun valore:
- il valore arriva (lo prende da HistoryCache);
- controlla in Configurazione sincronizzatore: se ci sono trigger per il calcolo - li calcola;
se c'è - crea eventi, crea escalation per creare un alert, se necessario secondo la configurazione; - registra i trigger per la successiva elaborazione, aggregazione; se si aggrega nell'ultima ora e così via, questo valore viene ricordato da ValueCache per non andare nella tabella della cronologia; Pertanto, ValueCache viene riempita con i dati necessari per calcolare trigger, elementi calcolati, ecc.;
- quindi il sincronizzatore della cronologia scrive tutti i dati nel database;
- il database li scrive su disco: è qui che termina il processo di elaborazione.
Banca dati. Memorizzazione nella cache
Lato database, quando si vogliono visualizzare grafici o qualche resoconto sugli eventi, sono presenti varie cache. Ma in questo rapporto non ne parlerò.
Per MySQL c'è Innodb_buffer_pool e un sacco di cache diverse che possono anche essere configurate.
Ma questi sono i principali:
- buffer_condivisi;
- dimensione_cache_effettiva;
- pool_condiviso.
Per tutti i database ho detto che esistono alcune cache che permettono di archiviare nella RAM i dati che spesso servono per le interrogazioni. Hanno le proprie tecnologie per questo.
Informazioni sulle prestazioni del database
Di conseguenza, esiste un ambiente competitivo, ovvero il server Zabbix raccoglie dati e li registra. Al riavvio, legge anche dalla cronologia per riempire ValueCache e così via. Qui puoi avere script e report che utilizzano l'API Zabbix, che è costruita su un'interfaccia web. L'API Zabbix entra nel database e riceve i dati necessari per ottenere grafici, report o qualche tipo di elenco di eventi, problemi recenti.
Anche una soluzione di visualizzazione molto popolare è Grafana, utilizzata dai nostri utenti. In grado di accedere direttamente sia tramite l'API Zabbix che tramite il database. Crea inoltre una certa competizione per l’ottenimento dei dati: è necessaria una messa a punto più precisa e migliore del database per rispettare la rapida consegna dei risultati e dei test.
Cancellazione della cronologia. Zabbix ha la governante
La terza chiamata utilizzata in Zabbix è la cancellazione della cronologia utilizzando Housekeeper. Housekeeper segue tutte le impostazioni, ovvero i nostri elementi di dati indicano per quanto tempo archiviare (in giorni), per quanto tempo archiviare le tendenze e la dinamica dei cambiamenti.
Non ho parlato di TrendCache, che calcoliamo al volo: i dati arrivano, li aggreghiamo per un'ora (per lo più sono numeri dell'ultima ora), la quantità è media/minima e la registriamo una volta ogni ora nella tabella della dinamica dei cambiamenti (“Tendenze”). "Housekeeper" avvia ed elimina i dati dal database utilizzando selezioni regolari, il che non è sempre efficace.
Come capire che è inefficace? Puoi vedere la seguente immagine sui grafici delle prestazioni dei processi interni:
Il sincronizzatore della cronologia è costantemente occupato (grafico rosso). E il grafico “rosso” che va in alto. Questa è una "Housekeeper" che si avvia e attende che il database elimini tutte le righe che ha specificato.
Prendiamo qualche ID articolo: devi eliminare gli ultimi 5mila; ovviamente tramite indici. Ma di solito il set di dati è piuttosto grande: il database lo legge comunque dal disco e lo inserisce nella cache, e questa è un'operazione molto costosa per il database. A seconda delle sue dimensioni, ciò può portare a determinati problemi di prestazioni.
Puoi disabilitare Housekeeper in modo semplice: abbiamo un'interfaccia web familiare. Nelle impostazioni in Amministrazione generale (impostazioni per "Governante") disabilitiamo la pulizia interna per la cronologia e le tendenze interne. Di conseguenza, la Governante non controlla più ciò:
Cosa puoi fare dopo? L'hai spento, i tuoi grafici si sono livellati... Quali ulteriori problemi potrebbero sorgere in questo caso? Cosa può aiutare?
Partizionamento (sezionamento)
In genere questo è configurato in modo diverso su ciascun database relazionale che ho elencato. MySQL ha la propria tecnologia. Ma nel complesso sono molto simili quando si tratta di PostgreSQL 10 e MySQL. Naturalmente, ci sono molte differenze interne nel modo in cui il tutto viene implementato e nel modo in cui influisce sulle prestazioni. Ma in generale, la creazione di una nuova partizione porta spesso anche ad alcuni problemi.
A seconda della tua configurazione (quanti dati crei in un giorno), di solito impostano il minimo - 1 giorno / batch, e per "tendenze", dinamica dei cambiamenti - 1 mese / nuovo batch. Questo potrebbe cambiare se hai una configurazione molto grande.
Diciamo subito la dimensione della configurazione: fino a 5mila nuovi valori al secondo (i cosiddetti nvps) - questa sarà considerata una piccola "configurazione". Media – da 5 a 25 mila valori al secondo. Tutto quanto sopra sono già installazioni grandi e molto grandi che richiedono una configurazione molto attenta del database.
Nelle installazioni molto grandi, 1 giorno potrebbe non essere ottimale. Personalmente ho visto partizioni su MySQL da 40 gigabyte al giorno (e potrebbero essercene di più). Si tratta di una quantità di dati molto grande, che può portare ad alcuni problemi. È necessario ridurlo.
Perché hai bisogno del partizionamento?
Ciò che fornisce Partitioning, penso che tutti lo sappiano, è il partizionamento delle tabelle. Spesso si tratta di file separati su disco e richieste di estensione. Seleziona una partizione in modo più ottimale se fa parte del partizionamento normale.
Per Zabbix, in particolare, viene utilizzato by range, by range, ovvero utilizziamo un timestamp (un numero regolare, tempo trascorso dall'inizio dell'epoca). Si specifica l'inizio/fine giornata e questa è la partizione. Di conseguenza, se si richiedono dati vecchi di due giorni, tutto verrà recuperato dal database più velocemente, poiché è necessario caricare solo un file nella cache e restituirlo (anziché una tabella di grandi dimensioni).
Molti database velocizzano anche l'inserimento (inserimento in una tabella figlia). Per ora parlo in astratto, ma anche questo è possibile. Il partitoning spesso aiuta.
Ricerca elastica per NoSQL
Recentemente, nella versione 3.4, abbiamo implementato una soluzione NoSQL. Aggiunta la possibilità di scrivere in Elasticsearch. Puoi scrivere determinati tipi: scegli tu: scrivi numeri o alcuni segni; abbiamo una stringa di testo, puoi scrivere log su Elasticsearch... Di conseguenza, anche l'interfaccia web accederà a Elasticsearch. Funziona benissimo in alcuni casi, ma al momento può essere utilizzato.
TimescaleDB. Ipertabelle
Per la versione 4.4.2 abbiamo prestato attenzione a qualcosa come TimescaleDB. Cos'è? Questa è un'estensione per PostgreSQL, ovvero ha un'interfaccia PostgreSQL nativa. Inoltre, questa estensione ti consente di lavorare in modo molto più efficiente con i dati delle serie temporali e di avere un partizionamento automatico. Cosa sembra:
Questo è ipertabella: esiste un tale concetto in Timescale. Questa è una hypertable creata da te e contiene blocchi. I blocchi sono partizioni, queste sono tabelle figlie, se non sbaglio. È davvero efficace.
TimescaleDB e PostgreSQL
Come assicurano i produttori di TimescaleDB, utilizzano un algoritmo più corretto per l'elaborazione delle query, in particolare degli inserimenti, che consente loro di avere prestazioni approssimativamente costanti all'aumentare della dimensione dell'inserimento del set di dati. Cioè, dopo 200 milioni di righe di Postgres, il solito inizia a abbassarsi molto e perde le prestazioni letteralmente a zero, mentre Timescale consente di inserire inserti nel modo più efficiente possibile con qualsiasi quantità di dati.
Come installare TimescaleDB? È semplice!
È nella documentazione, è descritto: può essere installato da pacchetti per qualsiasi... Dipende dai pacchetti Postgres ufficiali. Può essere compilato manualmente. È successo così che ho dovuto compilare per il database.
Su Zabbix attiviamo semplicemente Extention. Penso che coloro che hanno utilizzato Extention in Postgres... Devi semplicemente attivare Extention, crearlo per il database Zabbix che stai utilizzando.
E l'ultimo passo...
TimescaleDB. Migrazione delle tabelle della cronologia
È necessario creare un'ipertabella. Esiste una funzione speciale per questo: Crea ipertabella. In esso, il primo parametro è la tabella necessaria in questo database (per la quale è necessario creare un'ipertabella).
Il campo in base al quale creare e Chunk_Time_Interval (questo è l'intervallo dei blocchi (partizioni che devono essere utilizzate). 86 è un giorno.
Parametro Migrate_data: se inserisci su true, migrerà tutti i dati correnti in blocchi precreati.
Io stesso ho usato migrate_data: ci vuole una discreta quantità di tempo, a seconda di quanto è grande il tuo database. Avevo più di un terabyte: ci è voluta più di un'ora per crearlo. In alcuni casi, durante i test, ho cancellato i dati storici per testo (history_text) e stringa (history_str) per non trasferirli: non mi interessavano molto.
E facciamo l'ultimo aggiornamento nel nostro db_extention: installiamo timescaledb in modo che il database e, in particolare, il nostro Zabbix capiscano che esiste db_extention. Lo attiva e utilizza la sintassi e le query corrette al database, utilizzando quelle "funzionalità" necessarie per TimescaleDB.
Configurazione del server
Ho usato due server. Il primo server è una macchina virtuale abbastanza piccola, 20 processori, 16 gigabyte di RAM. Ho configurato Postgres 10.8 su di esso:
Il sistema operativo era Debian, il file system era xfs. Ho effettuato impostazioni minime per utilizzare questo particolare database, meno ciò che utilizzerà Zabbix stesso. Sulla stessa macchina c'erano un server Zabbix, PostgreSQL e agenti di caricamento.
Ho utilizzato 50 agenti attivi che utilizzano LoadableModule per generare rapidamente risultati diversi. Sono loro che hanno generato stringhe, numeri e così via. Ho riempito il database con molti dati. Inizialmente, la configurazione conteneva 5mila elementi di dati per host e circa ciascun elemento di dati conteneva un trigger, affinché questa fosse una vera configurazione. A volte è necessario utilizzare più di un trigger.
Ho regolato l'intervallo di aggiornamento e il carico stesso non solo utilizzando 50 agenti (aggiungendone altri), ma anche utilizzando elementi di dati dinamici e riducendo l'intervallo di aggiornamento a 4 secondi.
Test della prestazione. PostgreSQL: 36mila NVP
Il primo avvio, il primo setup che ho avuto è stato su PostreSQL 10 puro su questo hardware (35mila valori al secondo). In generale, come puoi vedere sullo schermo, l'inserimento dei dati richiede frazioni di secondo: tutto va bene e velocemente, unità SSD (200 gigabyte). L'unica cosa è che 20 GB si riempiono abbastanza velocemente.
Ci saranno molti di questi grafici in futuro. Questa è una dashboard standard delle prestazioni del server Zabbix.
Il primo grafico è il numero di valori al secondo (blu, in alto a sinistra), 35mila valori in questo caso. Questo (in alto al centro) è il caricamento dei processi di compilazione, e questo (in alto a destra) è il caricamento dei processi interni: sincronizzatori della cronologia e governante, che qui (in basso al centro) è in esecuzione da un bel po' di tempo.
Questo grafico (in basso al centro) mostra l'utilizzo di ValueCache: quanti accessi ValueCache per i trigger (diverse migliaia di valori al secondo). Un altro grafico importante è il quarto (in basso a sinistra), che mostra l'utilizzo di HistoryCache, di cui ho parlato, che è un buffer prima dell'inserimento nel database.
Test della prestazione. PostgreSQL: 50mila NVP
Successivamente ho aumentato il carico a 50mila valori al secondo sullo stesso hardware. Quando caricato da Housekeeper, sono stati registrati 10mila valori in 2-3 secondi con calcolo. Ciò che, in effetti, è mostrato nello screenshot seguente:
La “governante” comincia già a interferire con il lavoro, ma in generale il carico sui cacciatori di storia è ancora al livello del 60% (terzo grafico, in alto a destra). HistoryCache inizia già a riempirsi attivamente mentre Housekeeper è in esecuzione (in basso a sinistra). Era circa mezzo gigabyte, pieno al 20%.
Test della prestazione. PostgreSQL: 80mila NVP
Poi l'ho aumentato a 80mila valori al secondo:
Si trattava di circa 400mila elementi di dati, 280mila trigger. L'inserto, come potete vedere, in termini di carico di piombini storici (erano 30) era già piuttosto elevato. Quindi ho aumentato vari parametri: platine della cronologia, cache... Su questo hardware, il carico delle platine della cronologia ha iniziato ad aumentare al massimo, quasi "sullo scaffale" - di conseguenza, HistoryCache ha subito un carico molto elevato:
Per tutto questo tempo ho monitorato tutti i parametri di sistema (come viene utilizzato il processore, RAM) e ho scoperto che l'utilizzo del disco era massimo: ho raggiunto la capacità massima di questo disco su questo hardware, su questa macchina virtuale. "Postgres" ha iniziato a scaricare i dati in modo piuttosto attivo e con tale intensità, e il disco non ha più avuto il tempo di scrivere, leggere...
Ho preso un altro server che aveva già 48 processori e 128 gigabyte di RAM:
L'ho anche "ottimizzato": ho installato il sincronizzatore della cronologia (60 pezzi) e ho ottenuto prestazioni accettabili. In effetti, non siamo “sullo scaffale”, ma questo è probabilmente il limite della produttività, dove è già necessario fare qualcosa al riguardo.
Test della prestazione. TempisticaDB: 80mila NVP
Il mio compito principale era utilizzare TimescaleDB. Ogni grafico mostra un calo:
Questi fallimenti sono proprio la migrazione dei dati. Successivamente, nel server Zabbix, il profilo di caricamento dei piombini della storia, come puoi vedere, è cambiato molto. Ti consente di inserire i dati quasi 3 volte più velocemente e di utilizzare meno HistoryCache: di conseguenza, i dati verranno consegnati in tempo. Ancora una volta, 80mila valori al secondo sono un tasso abbastanza alto (ovviamente, non per Yandex). Nel complesso si tratta di una configurazione abbastanza grande, con un server.
Test delle prestazioni PostgreSQL: 120mila NVP
Successivamente, ho aumentato il valore del numero di elementi di dati a mezzo milione e ho ricevuto un valore calcolato di 125mila al secondo:
E ho ottenuto questi grafici:
In linea di principio, questa è una configurazione funzionante, può funzionare per un periodo piuttosto lungo. Ma poiché avevo solo un disco da 1,5 terabyte, l'ho esaurito in un paio di giorni. La cosa più importante è che allo stesso tempo sono state create nuove partizioni su TimescaleDB, e questo è passato completamente inosservato per le prestazioni, cosa che non si può dire di MySQL.
In genere, le partizioni vengono create di notte, poiché ciò generalmente blocca l'inserimento e il lavoro con le tabelle e può portare al degrado del servizio. In questo caso non è così! Il compito principale era testare le capacità di TimescaleDB. Il risultato è stato il seguente dato: 120mila valori al secondo.
Ci sono anche esempi nella comunità:
La persona ha anche attivato TimescaleDB e il carico relativo all'utilizzo di io.weight è diminuito sul processore; e anche l'uso degli elementi di processo interni è diminuito grazie all'inclusione di TimescaleDB. Inoltre, questi sono normali dischi pancake, ovvero una normale macchina virtuale su normali dischi (non SSD)!
Per alcune piccole configurazioni limitate dalle prestazioni del disco, TimescaleDB, a mio avviso, è un'ottima soluzione. Ti consentirà di continuare a lavorare prima di migrare verso un hardware più veloce per il database.
Vi invito tutti ai nostri eventi: Conferenza a Mosca, Summit a Riga. Utilizza i nostri canali: Telegram, forum, IRC. Se hai domande vieni alla nostra scrivania, possiamo parlare di tutto.
Domande del pubblico
Domanda dal pubblico (di seguito - A): - Se TimescaleDB è così facile da configurare e offre un tale incremento delle prestazioni, allora forse dovrebbe essere usato come best practice per configurare Zabbix con Postgres? E ci sono insidie e svantaggi di questa soluzione, o dopo tutto, se decidessi di creare Zabbix per me, potrei facilmente prendere Postgres, installare subito Timescale, usarlo e non pensare ad alcun problema?
AG: – Sì, direi che questa è una buona raccomandazione: usa subito Postgres con l’estensione TimescaleDB. Come ho già detto, molte recensioni positive, nonostante questa “funzionalità” sia sperimentale. Ma in realtà i test dimostrano che questa è un'ottima soluzione (con TimescaleDB) e penso che si evolverà! Stiamo monitorando lo sviluppo di questa estensione e apporteremo le modifiche necessarie.
Anche durante lo sviluppo ci siamo basati su una delle loro “caratteristiche” ben note: era possibile lavorare con i blocchi in modo leggermente diverso. Ma poi lo hanno eliminato nella versione successiva e abbiamo dovuto smettere di fare affidamento su questo codice. Consiglierei di utilizzare questa soluzione su molte configurazioni. Se usi MySQL... Per configurazioni medie, qualsiasi soluzione funziona bene.
E: – Negli ultimi grafici della community, c'era un grafico con "Housekeeper":
Ha continuato a lavorare. Cosa fa Housekeeper con TimescaleDB?
AG: – Ora non posso dirlo con certezza – guarderò il codice e te lo dirò in modo più dettagliato. Utilizza le query TimescaleDB non per eliminare blocchi, ma per aggregarli in qualche modo. Non sono ancora pronto a rispondere a questa domanda tecnica. Ne scopriremo di più allo stand oggi o domani.
E: – Ho una domanda simile – sulle prestazioni dell'operazione di eliminazione in Timescale.
A (risposta del pubblico): – Quando elimini i dati da una tabella, se lo fai tramite Elimina, devi passare attraverso la tabella: eliminare, pulire, contrassegnare tutto per il vuoto futuro. In Timescale, poiché hai blocchi, puoi rilasciarli. In parole povere, dici semplicemente al file che si trova nei big data: "Elimina!"
Timescale capisce semplicemente che un pezzo del genere non esiste più. E poiché è integrato nel query planner, utilizza gli hook per catturare le tue condizioni nelle operazioni di selezione o di altro tipo e capisce immediatamente che questo pezzo non esiste più: "Non ci andrò più!" (dati non disponibili). È tutto! Cioè, la scansione di una tabella viene sostituita dall'eliminazione di un file binario, quindi è veloce.
E: – Abbiamo già toccato il tema del non-SQL. Per quanto ho capito, Zabbix non ha realmente bisogno di modificare i dati, e tutto questo è qualcosa come un registro. È possibile utilizzare database specializzati che non possono modificare i propri dati, ma allo stesso tempo salvarli, accumularli e distribuirli molto più velocemente - Clickhouse, per esempio, qualcosa di simile a Kafka?... Kafka è anche un registro! È possibile integrarli in qualche modo?
AG: - È possibile effettuare lo scarico. Abbiamo una certa "funzionalità" dalla versione 3.4: puoi scrivere tutti i file storici, gli eventi, tutto il resto sui file; e quindi inviarlo a qualsiasi altro database utilizzando un gestore. In effetti, molte persone rielaborano e scrivono direttamente nel database. Al volo, gli esperti di storia scrivono tutto questo in file, ruotano questi file e così via, e puoi trasferirlo su Clickhouse. Non posso dire nulla sui piani, ma forse continuerà l’ulteriore supporto per le soluzioni NoSQL (come Clickhouse).
E: – In generale, risulta che puoi eliminare completamente Postgres?
AG: – Naturalmente la parte più difficile in Zabbix sono le tavole storiche, che creano più problemi, ed eventi. In questo caso, se non memorizzi gli eventi per un lungo periodo e memorizzi la cronologia con le tendenze in qualche altro archivio veloce, in generale, penso, non ci saranno problemi.
E: – Puoi stimare quanto più velocemente funzionerà il tutto se, ad esempio, passassi a Clickhouse?
AG: – Non l’ho testato. Penso che almeno gli stessi numeri possano essere raggiunti in modo abbastanza semplice, dato che Clickhouse ha una propria interfaccia, ma non posso dirlo con certezza. È meglio provare. Tutto dipende dalla configurazione: quanti host hai e così via. L'inserimento è una cosa, ma devi anche recuperare questi dati: Grafana o qualcos'altro.
E: – Quindi stiamo parlando di una lotta alla pari e non del grande vantaggio di questi database veloci?
AG: – Penso che quando ci integreremo, ci saranno test più accurati.
E: – Dov’è finito il buon vecchio RRD? Cosa ti ha spinto a passare ai database SQL? Inizialmente, tutti i parametri sono stati raccolti su RRD.
AG: – Zabbix aveva RRD, forse in una versione molto antica. Ci sono sempre stati database SQL: un approccio classico. L'approccio classico è MySQL, PostgreSQL (esistono da molto tempo). Non abbiamo quasi mai utilizzato un'interfaccia comune per i database SQL e RRD.
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