Esamineremo il funzionamento di Zabbix con il database TimescaleDB come backend. Mostreremo come avviare il servizio da zero e come migrare da PostgreSQL. Inoltre, presenteremo test comparativi delle prestazioni delle due configurazioni.
HighLoad++ Siberia 2019. Sala «Tomsk». 24 giugno, 16:00. Abstract e . La prossima conferenza HighLoad++ si terrà il 6 e 7 aprile 2020 a San Pietroburgo. Maggiori dettagli e biglietti .
Andrey Gushchin (di seguito – AG): – Sono ingegnere del supporto tecnico ZABBIX (di seguito – «Zabbix»), formatore. Lavoro nel supporto tecnico da oltre 6 anni e mi sono occupato direttamente delle performance. Oggi parlerò delle prestazioni che può offrire TimescaleDB in confronto con il tradizionale PostgreSQL 10. Includerò anche una parte introduttiva su come funziona tutto questo.
Le principali sfide delle prestazioni: dalla raccolta alla pulizia dei dati
Cominciamo col dire che ci sono determinate sfide di performance con cui ogni sistema di monitoraggio deve confrontarsi. La prima di queste è la raccolta e l'elaborazione rapida dei dati.
Un buon sistema di monitoraggio deve ricevere tempestivamente tutti i dati, elaborarli in base alle espressioni di trigger, ovvero secondo determinati criteri (che variano a seconda dei sistemi), e conservarli nel database affinché possano essere utilizzati successivamente.
La seconda sfida delle prestazioni riguarda la conservazione della storia. È fondamentale mantenere i dati nel database e avere accesso rapido e comodo alle metriche raccolte per un determinato periodo. È importante che questi dati possano essere facilmente ottenuti e utilizzati in report, grafici, trigger, soglie di valori per notifiche, ecc.
La terza sfida di prestazioni è la pulizia della storia, ossia quando arriva il momento di eliminare dettagli metrici raccolti in un periodo lungo, come 5 anni (anche solo mesi o due mesi). Alcuni nodi di rete possono essere stati rimossi o alcuni host possono non essere più necessari perché obsoleti e non raccolti. Tutto ciò deve essere pulito affinché il database non si espanda eccessivamente. Inoltre, la pulizia della storia è spesso una seria prova per il sistema di archiviazione e influisce notevolmente sulle prestazioni.
Come risolvere i problemi di caching?
Ora parlerò specificamente di «Zabbix». In «Zabbix», le prime due sfide sono state affrontate attraverso il caching.
Raccolta e trattamento dei dati – utilizziamo la memoria RAM per memorizzare tutti questi dati. Sarà fornito maggiori dettagli su questi dati.
Inoltre, sul lato del database esiste un caching per le selezioni principali – per i grafici e altre cose.
Caching sul server Zabbix stesso: abbiamo ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Cosa sono?
ConfigurationCache – è il principale cache in cui memorizziamo metriche, host, elementi di dati, trigger; tutto ciò che serve per il pre-processing, la raccolta dei dati e le relative frequenze. Tutto questo è conservato in ConfigurationCache per evitare richieste superflue al database. Dopo l'avvio del server, aggiorniamo (creiamo) questo cache e lo aggiorniamo periodicamente (in base alle impostazioni di configurazione).
Caching in Zabbix. Raccolta di dati
Qui lo schema è piuttosto ampio:
I principali elementi nello schema sono questi raccoglitori:
Questi sono i processi di raccolta effettivi, diversi «poller» che rispondono a ogni tipo di raccolta. Raccolgono dati tramite icmp, ipmi, vari protocolli e li inviano per il pre-processing.
PreProcessing HistoryCache
Inoltre, se abbiamo elementi di dati calcolati (chi è a conoscenza di «Zabbix» lo sa), ossia elementi di dati calcolati e aggregati, li preleviamo direttamente da ValueCache. Di come viene popolato parlerò più avanti. Tutti questi raccoglitori utilizzano ConfigurationCache per ottenere i loro compiti e successivamente trasmettono al pre-processing.
Il pre-processing utilizza anche ConfigurationCache per ottenere i passaggi di pre-processing, elaborando questi dati in vari modi. A partire dalla versione 4.2, è stato spostato sui proxy. Questo è molto comodo, poiché il pre-processing è un'operazione piuttosto pesante. E se hai un grande sistema Zabbix, con molti elementi di dati e alta frequenza di raccolta, ciò facilita notevolmente il lavoro.
Di conseguenza, dopo aver elaborato questi dati in un certo modo tramite il pre-processing, li salviamo in HistoryCache per ulteriori elaborazioni. Qui termina la raccolta di dati. Passiamo al processo principale.
Funzionamento di History syncer
Il processo principale in «Zabbix» (essendo un'architettura monolitica) è il syncer della storia. Questo è il processo principale che si occupa dell'elaborazione atomica di ogni elemento di dati, ovvero di ogni valore:
- riceve un valore (lo preleva dalla HistoryCache);
- verifica nel syncer della configurazione: ci sono trigger da calcolare? Se sì, li calcola;
se ci sono, crea eventi e genera un'escalation per inviare notifiche, se necessario secondo la configurazione; - registra i trigger per un'elaborazione e aggregazione future; se aggreghi per l'ultima ora e così via, questo valore viene memorizzato in ValueCache, in modo da non dover accedere alla tabella della storia; in questo modo, ValueCache si riempie con i dati necessari per il calcolo dei trigger e degli elementi calcolati, ecc.;
- successivamente, il syncer della storia scrive tutti i dati nel database;
- il database li registra su disco: a questo punto il processo di elaborazione termina.
Database. Cache
Dalla parte del database, quando desideri visualizzare grafici o report sugli eventi, ci sono varie cache. Ma in questo intervento non parlerò di esse.
Per MySQL, c'è Innodb_buffer_pool, e ci sono molte altre cache che possono essere configurate.
Ma questi sono i principali:
- shared_buffers;
- effective_cache_size;
- shared_pool.
Per tutti i database, ho indicato che ci sono determinate cache che consentono di mantenere in memoria operativa i dati spesso necessari per le query. Hanno le proprie tecnologie per farlo.
Sulle prestazioni del database
Pertanto, esiste un ambiente competitivo, cioè il server «Zabbix» raccoglie e registra i dati. Al riavvio, legge anche dalla storia per riempire ValueCache, e così via. Allo stesso tempo, potresti avere script e report che utilizzano l'API di «Zabbix», che è basata su un'interfaccia web. L'API di «Zabbix» accede al database e recupera i dati necessari per i grafici, i report o per un elenco di eventi o problemi recenti.
Una soluzione molto popolare per la visualizzazione è Grafana, che i nostri utenti utilizzano. Essa può accedere direttamente sia tramite l'API di «Zabbix» che tramite il database. Crea anche una certa concorrenza per il recupero dei dati: è necessaria una configurazione più fine e adeguata del database per garantire un rapido rilascio dei risultati e i test.
Pulizia della storia. In Zabbix c'è Housekeeper
Il terzo chiamato utilizzato in «Zabbix» è la pulizia della storia tramite Housekeeper. L'«Housekeeper» rispetta tutte le impostazioni, quindi abbiamo indicato negli elementi di dati quanti giorni conservare e quanti trend mantenere, la dinamica delle variazioni.
Non ho parlato di TrendCache, che calcoliamo in tempo reale: i dati arrivano, li aggregiamo per un'ora (principalmente numeri dell'ultima ora), calcoliamo il valore medio/minimo e li registriamo ogni ora nella tabella della dinamica delle variazioni (i «Trend»). L'«Housekeeper» viene avviato e rimuove i dati dal database con delle select, il che non è sempre efficiente.
Come capire che non è efficiente? Puoi vedere sui grafici delle prestazioni dei processi interni un'immagine del genere:
Hai il syncer della storia costantemente occupato (grafico rosso). E il grafico 'arancione' che si muove sopra. Questo è l'«Housekeeper», che si avvia e aspetta che il database rimuova tutte le righe che ha impostato.
Prendiamo un qualche ID di elemento: bisogna rimuovere le ultime 5.000 righe; naturalmente, secondo gli indici. Ma di solito il dataset è piuttosto grande - il database legge comunque da disco e solleva in cache, e questa è un'operazione molto costosa per il database. A seconda delle dimensioni del database, ciò può portare a certi problemi di prestazioni.
Disattivare l'«Housekeeper» è semplice: abbiamo l'interfaccia web, ben nota a tutti. Nelle impostazioni di Administration general (impostazioni per l'«Housekeeper») disattiviamo la gestione interna della storia e dei trend. Pertanto, l'«Housekeeper» non gestirà più questo:
Cosa si può fare ulteriormente? Hai disattivato, i tuoi grafici si sono stabilizzati... Quali potrebbero essere i problemi successivi? Cosa può aiutare?
Partizionamento
Di solito viene configurato in ogni database relazionale che ho menzionato, in modi diversi. MySQL ha la sua tecnologia. Ma in generale sono molto simili, se parliamo di PostgreSQL 10 e MySQL. Certamente, ci sono molte differenze interne su come tutto è implementato e su come influisce sulle prestazioni. Ma in generale, la creazione di una nuova partizione porta spesso a certi problemi.
A seconda della tua configurazione (quanto dati vengono generati in un giorno), di solito si imposta il minimo – cioè 1 giorno/partizione, e per i "trend", la dinamica delle modifiche – 1 mese / nuova partizione. Questo può variare se hai una configurazione molto grande.
Iniziamo con le dimensioni della configurazione: fino a 5.000 nuovi valori al secondo (note come nvps) sono considerate una piccola "configurazione". Una configurazione media è tra 5 e 25.000 valori al secondo. Tutto ciò che supera è già classificato come grandi e molto grandi installazioni, che richiedono una configurazione molto attenta del database stesso.
In installazioni molto grandi, 1 giorno può non essere ottimale. Ho visto personalmente partizioni di 40 gigabyte al giorno su MySQL (e possono essere anche più grandi). Si tratta di un enorme volume di dati, che può portare a diversi problemi. È necessario ridurlo.
Perché è necessario il partizionamento?
Cosa offre il partizionamento, penso che tutti lo sappiano – si tratta della suddivisione delle tabelle. Spesso si tratta di file separati su disco e query span. Seleziona in modo più ottimale una partizione se rientra nel normale partizionamento.
Per "Zabbix", in particolare, si utilizza per range, cioè usiamo un timestamp (un numero normale, tempo dall'inizio dell'epoca). Imposti l'inizio del giorno / la fine del giorno, e questo diventa una partizione. Pertanto, se richiedi dati risalenti a due giorni fa, tutto ciò verrà prelevato più rapidamente dal database, perché deve semplicemente caricare un file in cache e fornirlo (e non una grande tabella).
Molti database accelerano anche l'inserimento (nella child-table). Finora ho parlato in modo astratto, ma è possibile anche questo. Spesso il partizionamento aiuta.
Elasticsearch per NoSQL
Recentemente, nella versione 3.4, abbiamo implementato una soluzione per NoSQL. Abbiamo aggiunto la possibilità di scrivere in Elasticsearch. Puoi scrivere tipi di dati diversi: scegli – scrivi numeri oppure segni; abbiamo stringhe di testo, log che puoi scrivere in Elasticsearch… Di conseguenza, anche l'interfaccia web accederà a Elasticsearch. Questo funziona molto bene in alcuni casi, ma al momento può essere utilizzato.
TimescaleDB. Hyper-tables
Per la versione 4.4.2 abbiamo notato una cosa riguardo a TimescaleDB. Che cos'è? È un'estensione per "Postgres", quindi ha un'interfaccia nativa PostgreSQL. Inoltre, questa estensione permette di lavorare in modo molto più efficiente con i dati time-series e dispone di partizionamento automatico. Ecco come appare:
Questa è un'hypertable – esiste un concetto in Timescale. È un'hypertable che crei, e contiene chunk (chunk). I chunk sono partizioni, sono child-tables, se non erro. Questo è davvero efficiente.
TimescaleDB e PostgreSQL
Come affermano i produttori di TimescaleDB, utilizzano un algoritmo di elaborazione delle query più efficace, in particolare per gli insert, che consente di avere prestazioni pressoché costanti all'aumentare della dimensione del dataset di inserimento. Cioè, dopo 200 milioni di righe, "Postgres" normale inizia a scendere drasticamente e perde letteralmente fino a zero prestazioni, mentre "Timescale" consente di inserire dati in modo molto efficace indipendentemente dalla quantità.
Come installare TimescaleDB? È molto semplice!
È descritto nella documentazione – puoi installarlo dai pacchetti per qualsiasi… Dipende dai pacchetti ufficiali di "Postgres". Puoi compilarlo manualmente. Così è successo che ho dovuto compilarlo per il database.
Su "Zabbix", attiviamo semplicemente l'estensione. Penso che chiunque abbia usato l'estensione in "Postgres"… Attivi semplicemente l'estensione, crei quella per il database "Zabbix" che stai utilizzando.
E l'ultimo passo…
TimescaleDB. Migrazione delle tabelle storiche
Devi creare un'hypertable. Per questo c'è una funzione speciale – Create hypertable. In questo caso, come primo parametro, indichi la tabella che deve essere presente nel database (per la quale deve essere creata l'hypertable).
Il campo su cui deve essere creato e chunk_time_interval (questo è l'intervallo dei chunk (partizioni) da utilizzare). 86.400 – è un giorno.
Il parametro migrate_data: se imposti su true, trasferisce tutti i dati correnti nei chunk già creati.
Ho utilizzato migrate_data – richiede un tempo considerevole, a seconda delle dimensioni del tuo database. Avevo più di un terabyte – la creazione ha richiesto più di un'ora. In alcuni casi, durante il test, ho eliminato i dati storici per il testo (history_text) e la stringa (history_str), per evitare di trasferire – in realtà non mi interessavano.
L'ultimo aggiornamento che facciamo nel nostro db_extension: stiamo installando timescaledb, affinché il database e, in particolare, il nostro «Zabbix», comprendano l'esistenza di db_extension. Attiva e utilizza correttamente la sintassi e le query per il database, sfruttando già le «funzionalità» necessarie per TimescaleDB.
Configurazione del server
Ho utilizzato due server. Il primo server è una macchina virtuale piuttosto piccola, con 20 processori e 16 gigabyte di RAM. Ho installato PostgreSQL 10.8 su di essa:
Il sistema operativo era Debian, il file system – xfs. Ho effettuato impostazioni minime per utilizzare specificamente questo database, a parte ciò che utilizzerà il «Zabbix». Sulla stessa macchina c'erano il server «Zabbix», PostgreSQL e agenti di carico.
Ho impiegato 50 agenti attivi, che utilizzano LoadableModule per generare rapidamente risultati diversi. Sono stati generati stringhe, numeri e così via. Ho riempito il database con una grande quantità di dati. Inizialmente la configurazione conteneva 5.000 elementi di dati per ogni host, e circa ogni elemento di dati includeva un trigger, affinché fosse una configurazione reale. A volte, per l'utilizzo è necessario anche più di un trigger.
L'intervallo di aggiornamento e il carico stesso lo regolavo non solo utilizzando 50 agenti (aggiungevo anche altri), ma grazie a elementi di dati dinamici e riducendo l'intervallo di aggiornamento a 4 secondi.
Test di prestazioni. PostgreSQL: 36.000 NVPs
La prima esecuzione, il primo setup era su un PostgreSQL 10 pulito su questa macchina (35.000 valori al secondo). In generale, come si può vedere sullo schermo, l'inserimento dei dati richiede frazioni di secondo – va tutto bene e veloce, con dischi SSD (200 gigabyte). L'unico problema è che 20 GB si riempiono piuttosto rapidamente.
Ci saranno molti di questi grafici in seguito. Questo è il dashboard di prestazioni standard del server «Zabbix».
Il primo grafico mostra il numero di valori al secondo (blu, in alto a sinistra), 35.000 valori in questo caso. Questo (in alto al centro) è il carico dei processi di raccolta, e questo (in alto a destra) è il carico dei processi interni: history syncers e housekeeper, che qui (in basso al centro) ha operato per un tempo considerevole.
Questo grafico (in basso al centro) mostra l'uso di ValueCache – quanti hit di ValueCache per i trigger (alcuni migliaia di valori al secondo). Un grafico importante è il quarto (in basso a sinistra), che mostra l'uso di HistoryCache, di cui ho parlato, che è un buffer prima dell'inserimento nel database.
Test di prestazioni. PostgreSQL: 50.000 NVPs
Successivamente ho aumentato il carico a 50.000 valori al secondo su questa stessa macchina. Con il caricamento da parte di «Housekeeper», 10.000 valori venivano già registrati in 2-3 secondi con calcolo. Questo è evidenziato nello screenshot seguente:
«Housekeeper» inizia a interferire con il lavoro, ma in generale il carico dei trapper history-syncers è ancora al livello del 60% (terzo grafico, in alto a destra). HistoryCache inizia a riempirsi attivamente durante il funzionamento di «Housekeeper» (in basso a sinistra). Era circa mezzo gigabyte, riempito al 20%.
Test di prestazioni. PostgreSQL: 80.000 NVPs
Ho poi aumentato fino a 80.000 valori al secondo:
Erano circa 400.000 elementi di dati, 280.000 trigger. Come potete vedere, l'inserimento, in base al carico degli history-syncers (ce n'erano 30), era già piuttosto alto. Ho continuato ad aumentare diversi parametri: history-syncers, cache… Su questa macchina il carico degli history-syncers ha iniziato ad aumentare al massimo, praticamente «in punteggio», portando a un carico di HistoryCache molto elevato:
Durante tutto questo tempo ho monitorato tutti i parametri di sistema (come l'uso della CPU, della RAM) e ho scoperto che l'utilizzo dei dischi era massimo – ho raggiunto la massima capacità di questo disco su questa macchina virtuale. PostgreSQL ha iniziato a scaricare dati con abbastanza intensità e il disco non era più in grado di scrivere e leggere...
Ho preso un altro server, che aveva già 48 processori e 128 gigabyte di RAM:
Ho anche ottimizzato questo server – ho installato 60 history syncers e ho raggiunto prestazioni accettabili. Non siamo esattamente «in punteggio», ma è probabilmente il limite delle prestazioni, dove è necessario intervenire.
Test di prestazioni. TimescaleDB: 80.000 NVPs
Avevo come obiettivo principale – utilizzare TimescaleDB. In ogni grafico si vede un calo:
Questi fallimenti sono proprio la migrazione dei dati. Dopo di che, nel server Zabbix, il profilo di caricamento degli storici dei sincronizzatori, come potete vedere, è cambiato notevolmente. Ora consente di inserire dati quasi tre volte più velocemente e utilizza meno HistoryCache – quindi i dati vi arriveranno puntualmente. Ancora una volta, 80 mila valori al secondo è un tasso piuttosto elevato (ovviamente, non per Yandex). In generale, si tratta di un setup piuttosto grande, con un server.
Test di prestazioni PostgreSQL: 120 mila NVP.
Dopo ho aumentato il numero di elementi dati a mezzo milione e ho ottenuto un valore stimato di 125 mila al secondo:
E ho ottenuto questi grafici:
In linea di massima si tratta di un setup funzionante, può lavorare per lungo tempo. Ma poiché avevo un disco di solo 1,5 terabyte, l'ho esaurito in pochi giorni. La cosa più importante è che allo stesso tempo venivano create nuove partizioni su TimescaleDB, e questo per le prestazioni avveniva in modo totalmente invisibile, a differenza di MySQL.
Di solito le partizioni vengono create di notte, perché questo blocca del tutto l'inserimento e il lavoro con le tabelle, e può portare a una degradazione del servizio. In questo caso non c'è nulla di tutto ciò! L'obiettivo principale era verificare le capacità di TimescaleDB. Ho ottenuto questo numero: 120 mila valori al secondo.
Ci sono anche esempi nella comunità:
Una persona ha attivato TimescaleDB e il caricamento per utilizzo di io.weight è diminuito sulla CPU; e l'utilizzo degli elementi dei processi interni è sceso anche grazie all'attivazione di TimescaleDB. Inoltre, si trattava di dischi normali, ovvero una normale virtual machine su dischi comuni (non SSD)!
Per piccoli setup che si scontrano con le prestazioni del disco, TimescaleDB è, a mio avviso, una soluzione molto valida. Permetterà di continuare a lavorare fino a quando non si migrerà su hardware più veloce per il database.
Invito tutti voi ai nostri eventi: Conferenza – a Mosca, Summit – a Riga. Utilizzate i nostri canali – Telegram, forum, IRC. Se avete domande, veniteci a trovare allo stand, possiamo parlare di tutto.
Domande dal pubblico
Domanda dal pubblico (di seguito – A): – Se TimescaleDB è così facile da configurare e fornisce un aumento delle prestazioni, potrebbe valere la pena utilizzarlo come best practice per configurare Zabbix con PostgreSQL? E ci sono insidie o svantaggi in questa soluzione, o se decido di utilizzare Zabbix, posso tranquillamente prendere PostgreSQL, installare Timescale immediatamente, utilizzarlo e non preoccuparmi di alcun problema?
AG: – Sì, direi che è un'ottima raccomandazione: utilizzare PostgreSQL subito con l'estensione TimescaleDB. Come ho già detto, ci sono molte recensioni positive, nonostante questa funzione sia sperimentale. Ma in realtà i test mostrano che è una soluzione eccellente (con TimescaleDB), e credo che continuerà a svilupparsi! Seguiamo come si evolve questa estensione e gestiremo ciò che è necessario.
Durante lo sviluppo ci siamo basati su una loro nota funzione: là si poteva lavorare con i chunk in modo un po' diverso. Ma poi l'hanno rimosso nella versione successiva, e abbiamo dovuto smettere di basarci su quel codice. Consiglierei di utilizzare questa soluzione su molti setup. Se usate MySQL… Per setup di dimensioni medie qualsiasi soluzione funziona bene.
A: – Negli ultimi grafici, che provengono dalla comunità, c'era un grafico con Housekeeper:
Ha continuato a funzionare. Cosa fa Housekeeper nel caso di TimescaleDB?
AG: – Al momento non posso dirlo con certezza – esaminerò il codice e fornirò informazioni più dettagliate. Usa query specifiche di TimescaleDB non per eliminare i chunk, ma per aggregare in qualche modo. Non sono pronto a rispondere a questa domanda tecnica. Lo chiariremo oggi o domani allo stand.
A: – Ho una domanda simile – riguardo alle prestazioni dell'operazione di eliminazione in Timescale.
A (risposta dal pubblico): – Quando si eliminano dati da una tabella, se si utilizza il delete, è necessario scorrere la tabella – eliminare, pulire, segnare tutto per la futura vacuum. In Timescale, poiché si hanno chunk, si può semplicemente droppare. In sostanza, si dice semplicemente al file che si trova nei big data: «Elimina!»
Timescale capisce semplicemente che quel chunk non esiste più. E poiché si integra nel pianificatore delle query, cattura le vostre condizioni nel select o in altre operazioni e comprende immediatamente che quel chunk non esiste più – «Non andrò lì!» (i dati sono assenti). Ecco tutto! Quindi la scansione della tabella viene sostituita dall'eliminazione di un file binario, perciò è veloce.
A: – Abbiamo già toccato l'argomento non SQL. Da quanto ho capito, a «Zabbix» non serve molto modificare i dati, e tutto ciò è simile a un log. È possibile utilizzare database specializzati che non possono modificare i loro dati, ma che al contempo sono molto più veloci nel salvare, accumulare e restituire – Clickhouse, per esempio, qualcosa di tipo Kafka?.. Kafka è anch'esso un log! Possono essere integrati in qualche modo?
AG: – È possibile effettuare l'export. Abbiamo una certa «feature» dalla versione 3.4: puoi scrivere in file tutti i file storici, eventi e tutto il resto; e poi inviare a qualsiasi altro DB con un certo elaboratore. In effetti, molte persone modificano e scrivono direttamente nel DB. Gli history-sinkers li scrivono in file al volo, ruotano questi file e così via, e puoi trasferirli in «Clickhouse». Non posso dire quali siano i piani, ma è possibile che il supporto per le soluzioni NoSQL (come «Clickhouse») continuerà.
A: – Quindi, è possibile liberarsi completamente da postgres?
AG: – Certamente, la parte più complessa in «Zabbix» sono le tabelle storiche, che creano più problemi, e gli eventi. In questo caso, se non si conservano a lungo gli eventi e si mantiene la storia con le tendenze in un altro storage veloce, in generale non ci dovrebbero essere problemi.
A: – Puoi valutare quanto sarebbe più veloce tutto se ci si trasferisse a «Clickhouse», per esempio?
AG: – Non ho testato. Penso che si possano raggiungere almeno le stesse cifre piuttosto facilmente, considerando che «Clickhouse» ha la sua interfaccia, ma non posso dirlo con certezza. È meglio testare. Tutto dipende dalla configurazione: quante macchine hai e così via. L'inserimento è una cosa, ma bisogna anche recuperare i dati – con Grafana o altro.
A: – Quindi si tratta di una battaglia equa, e non di un grande vantaggio di questi DB veloci?
AG: – Penso che quando integriamo, avremo test più accurati.
A: – E dove è finito il vecchio buon RRD? Cosa ha spinto a passare ai database SQL? Inizialmente tutte le metriche venivano raccolte su RRD.
AG: – In «Zabbix» RRD potrebbe essere stato presente in una versione molto antica. Sono sempre esistiti database SQL – l'approccio classico. L'approccio classico è MySQL, PostgreSQL (esistono da molto tempo). Abbiamo un'interfaccia comune per i database SQL e praticamente non abbiamo mai utilizzato RRD.
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
