Zabbix è un sistema di monitoraggio. Come qualsiasi altro sistema, affronta tre problemi principali di tutti i sistemi di monitoraggio: raccolta ed elaborazione dei dati, archiviazione della cronologia e pulizia degli stessi.
Le fasi di ricezione, elaborazione e registrazione dei dati richiedono tempo. Non molto, ma per un sistema di grandi dimensioni ciò può comportare notevoli ritardi. Il problema di archiviazione è un problema di accesso ai dati. Vengono utilizzati per report, controlli e trigger. Anche le latenze nell’accesso ai dati influiscono sulle prestazioni. Quando i database crescono, i dati irrilevanti devono essere eliminati. La rimozione è un’operazione difficile che divora anche alcune risorse.
I problemi di ritardi durante la raccolta e l'archiviazione in Zabbix vengono risolti mediante il caching: diversi tipi di cache, caching nel database. Per risolvere il terzo problema, la memorizzazione nella cache non è adatta, quindi Zabbix ha utilizzato TimescaleDB. Te lo racconterà Andrej Gušchin - ingegnere del supporto tecnico . Andrey supporta Zabbix da più di 6 anni e ha esperienza diretta con le performance.
Come funziona TimescaleDB, quali prestazioni può offrire rispetto al normale PostgreSQL? Che ruolo gioca Zabbix per il database TimescaleDB? Come iniziare da zero e come migrare da PostgreSQL e quale configurazione ha prestazioni migliori? Tutto questo sotto il taglio.
Sfide di produttività
Ogni sistema di monitoraggio deve affrontare sfide prestazionali specifiche. Ne parlerò tre: raccolta ed elaborazione dei dati, archiviazione e cancellazione della cronologia.
Raccolta ed elaborazione rapida dei dati. Un buon sistema di monitoraggio dovrebbe ricevere rapidamente tutti i dati ed elaborarli secondo le espressioni trigger, secondo i suoi criteri. Dopo l'elaborazione, il sistema deve anche salvare rapidamente questi dati nel database per un utilizzo successivo.
Archiviazione della cronologia. Un buon sistema di monitoraggio dovrebbe archiviare la cronologia in un database e fornire un facile accesso alle metriche. La cronologia è necessaria per essere utilizzata in report, grafici, trigger, soglie ed elementi di dati di avviso calcolati.
Cancellazione della cronologia. A volte arriva il giorno in cui non è più necessario archiviare le metriche. Perché hai bisogno di dati che sono stati raccolti 5 anni fa, un mese o due: alcuni nodi sono stati cancellati, alcuni host o metriche non sono più necessari perché obsoleti e non più raccolti. Un buon sistema di monitoraggio dovrebbe archiviare i dati storici ed eliminarli di tanto in tanto in modo che il database non cresca.
La pulizia dei dati obsoleti è un problema critico che incide notevolmente sulle prestazioni del database.
Memorizzazione nella cache di Zabbix
In Zabbix, la prima e la seconda chiamata vengono risolte utilizzando la memorizzazione nella cache. La RAM viene utilizzata per raccogliere ed elaborare i dati. Per l'archiviazione: cronologia in trigger, grafici ed elementi di dati calcolati. Sul lato del database è presente una certa memorizzazione nella cache per le selezioni di base, ad esempio i grafici.
La memorizzazione nella cache sul lato del server Zabbix stesso è:
- ConfigurazioneCache;
- ValueCache;
- Cache della cronologia;
- TrendsCache.
Consideriamoli in modo più dettagliato.
ConfigurazioneCache
Questa è la cache principale in cui memorizziamo metriche, host, elementi di dati, trigger: tutto ciò di cui abbiamo bisogno per la preelaborazione e la raccolta dei dati.
Tutto questo è archiviato in ConfigurationCache in modo da non creare query inutili nel database. Dopo l'avvio del server, aggiorniamo questa cache, creiamo e aggiorniamo periodicamente le configurazioni.
Raccolta dati
Il diagramma è piuttosto grande, ma la cosa principale lo è collezionisti. Questi sono vari "poller": processi di assemblaggio. Sono responsabili di diversi tipi di assemblaggio: raccolgono i dati tramite SNMP, IPMI e li trasferiscono tutti a PreProcessing.
I collezionisti sono delineati in arancione.
Zabbix ha calcolato gli elementi di aggregazione necessari per aggregare gli assegni. Se li abbiamo, recuperiamo i dati direttamente da ValueCache.
Cache della cronologia di preelaborazione
Tutti i raccoglitori utilizzano ConfigurationCache per ricevere lavori. Quindi li trasferiscono in PreProcessing.
PreProcessing usa ConfigurationCache per ricevere i passaggi di PreProcessing. Elabora questi dati in vari modi.
Dopo aver elaborato i dati utilizzando PreProcessing, li salviamo in HistoryCache per l'elaborazione. Questo termina la raccolta dei dati e passiamo al processo principale in Zabbix - sincronizzatore della storia, poiché si tratta di un'architettura monolitica.
Nota: la preelaborazione è un'operazione piuttosto difficile. Con la versione 4.2 è stato spostato su proxy. Se disponi di uno Zabbix molto grande con un gran numero di elementi di dati e frequenza di raccolta, questo rende il lavoro molto più semplice.
ValueCache, cache di cronologia e tendenze
Il sincronizzatore della cronologia è il processo principale che elabora atomicamente ciascun elemento di dati, ovvero ciascun valore.
Il sincronizzatore della cronologia prende i valori da HistoryCache e controlla nella configurazione la presenza di trigger per i calcoli. Se esistono, calcola.
La sincronizzazione della cronologia crea un evento, un'escalation per creare avvisi se richiesto dalla configurazione e record. Se sono presenti trigger per l'elaborazione successiva, memorizza questo valore in ValueCache in modo da non accedere alla tabella della cronologia. In questo modo ValueCache viene riempito con i dati necessari per calcolare i trigger e gli elementi calcolati.
Il sincronizzatore della cronologia scrive tutti i dati nel database e li scrive su disco. Il processo di elaborazione termina qui.
Memorizzazione nella cache del database
Lato database sono presenti varie cache dove si vogliono visualizzare grafici o report sugli eventi:
Innodb_buffer_pooldal lato MySQL;shared_buffersdal lato PostgreSQL;effective_cache_sizedalla parte dell'Oracolo;shared_poolsul lato DB2.
Esistono molte altre cache, ma queste sono le principali per tutti i database. Consentono di archiviare nella RAM i dati spesso necessari per le query. Hanno le proprie tecnologie per questo.
Le prestazioni del database sono fondamentali
Il server Zabbix raccoglie costantemente dati e li scrive. Al riavvio, legge anche dalla cronologia per riempire ValueCache. Utilizza script e report API Zabbix, che è basato su un'interfaccia Web. L'API Zabbix accede al database e recupera i dati necessari per grafici, report, elenchi di eventi e ultimi numeri.
Per la visualizzazione - graminacee. Questa è una soluzione popolare tra i nostri utenti. Può inviare richieste direttamente tramite l'API Zabbix e al database e crea una certa concorrenza per la ricezione dei dati. Pertanto, è necessaria una messa a punto più precisa e migliore del database per garantire una consegna rapida dei risultati e dei test.
Governante
La terza sfida prestazionale in Zabbix è la cancellazione della cronologia utilizzando Housekeeper. Segue tutte le impostazioni: gli elementi di dati indicano per quanto tempo memorizzare la dinamica dei cambiamenti (tendenze) in giorni.
Calcoliamo TrendsCache al volo. Quando arrivano i dati, li aggreghiamo per un'ora e li registriamo in tabelle per la dinamica dei cambiamenti di tendenza.
Housekeeper avvia e cancella le informazioni dal database utilizzando le solite “seleziona”. Ciò non è sempre efficace, come si può vedere dai grafici delle prestazioni dei processi interni.
Il grafico rosso mostra che il sincronizzatore della cronologia è costantemente occupato. Il grafico arancione in alto rappresenta Housekeeper, che è costantemente in funzione. Attende che il database elimini tutte le righe specificate.
Quando dovresti disabilitare Housekeeper? Ad esempio, c'è un "ID articolo" ed è necessario eliminare le ultime 5mila righe entro un certo tempo. Naturalmente, questo avviene per indice. Ma di solito il set di dati è molto grande e il database continua a leggere dal disco e a inserirlo nella cache. Questa è sempre un'operazione molto costosa per il database e, a seconda delle dimensioni del database, può portare a problemi di prestazioni.
La governante è facile da disabilitare. Nell'interfaccia Web è presente un'impostazione in “Amministrazione generale” per Housekeeper. Disabilitiamo la pulizia interna per la cronologia delle tendenze interne e non la gestisce più.
La governante è stata spenta, i grafici si sono livellati: quali problemi potrebbero esserci in questo caso e cosa potrebbe aiutare a risolvere la terza sfida prestazionale?
Partizionamento: partizionamento o partizionamento
In genere, il partizionamento è configurato in modo diverso su ciascun database relazionale che ho elencato. Ognuno ha la propria tecnologia, ma in generale sono simili. La creazione di una nuova partizione porta spesso a determinati problemi.
In genere, le partizioni vengono configurate in base alla "configurazione": la quantità di dati creata in un giorno. Di norma, il partizionamento viene emesso in un giorno, questo è il minimo. Per le tendenze di un nuovo lotto - 1 mese.
I valori potrebbero cambiare se il “setup” è molto ampio. Se un “setup” piccolo arriva fino a 5 nvps (nuovi valori al secondo), uno medio va da 000 a 5, quindi uno grande supera i 000 nvps. Si tratta di installazioni grandi e molto grandi che richiedono un'attenta configurazione del database.
Nelle installazioni molto grandi, un periodo di un giorno potrebbe non essere ottimale. Ho visto partizioni MySQL da 40 GB o più al giorno. Si tratta di una quantità molto grande di dati che può causare problemi e deve essere ridotta.
Cosa offre il partizionamento?
Tabelle di partizione. Spesso si tratta di file separati su disco. Il piano di query seleziona una partizione in modo più ottimale. Di solito il partizionamento viene utilizzato per intervallo: questo vale anche per Zabbix. Usiamo "timestamp" lì - tempo dall'inizio dell'era. Questi sono numeri ordinari per noi. Imposta l'inizio e la fine della giornata: questa è una partizione.
Rimozione rapida - DELETE. Viene selezionato un file/sottotabella anziché una selezione di righe da eliminare.
Accelera significativamente il recupero dei dati SELECT - utilizza una o più partizioni, anziché l'intera tabella. Se si accede a dati vecchi di due giorni, questi verranno recuperati dal database più velocemente perché è necessario caricare solo un file nella cache e restituirlo, non una tabella di grandi dimensioni.
Spesso anche molti database vengono accelerati INSERT — inserimenti nella tabella figlio.
Scala cronologica DB
Per la versione 4.2, abbiamo rivolto la nostra attenzione a TimescaleDB. Questa è un'estensione per PostgreSQL con un'interfaccia nativa. L'estensione funziona in modo efficace con i dati delle serie temporali, senza perdere i vantaggi dei database relazionali. TimescaleDB inoltre partiziona automaticamente.
TimescaleDB ha un concetto ipertabella (hypertable) che crei. Contiene pezzi - partizioni. I blocchi sono frammenti di ipertabella gestiti automaticamente che non influiscono su altri frammenti. Ogni pezzo ha il proprio intervallo di tempo.
TimescaleDB contro PostgreSQL
TimescaleDB funziona in modo davvero efficiente. I produttori dell'estensione affermano di utilizzare un algoritmo di elaborazione delle query più corretto, in particolare inserts . Man mano che la dimensione dell'inserimento del set di dati aumenta, l'algoritmo mantiene prestazioni costanti.
Dopo 200 milioni di righe, PostgreSQL di solito inizia a cedere in modo significativo e perde le prestazioni fino a 0. TimescaleDB consente di inserire in modo efficiente "inserimenti" per qualsiasi quantità di dati.
Installazione
L'installazione di TimescaleDB è abbastanza semplice per qualsiasi pacchetto. IN tutto è descritto in dettaglio: dipende dai pacchetti PostgreSQL ufficiali. TimescaleDB può anche essere creato e compilato manualmente.
Per il database Zabbix attiviamo semplicemente l'estensione:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Ti attivi extension e crearlo per il database Zabbix. L'ultimo passaggio è creare un'ipertabella.
Migrazione delle tabelle della cronologia a TimescaleDB
C'è una funzione speciale per questo create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
La funzione ha tre parametri. Primo - tabella nel database, per il quale è necessario creare una hypertable. Secondo - campo, in base al quale è necessario creare chunk_time_interval — intervallo dei blocchi di partizione da utilizzare. Nel mio caso, l'intervallo è di un giorno: 86.
Terzo parametro - migrate_data. Se imposti true, quindi tutti i dati correnti vengono trasferiti in blocchi precreati. L'ho usato io stesso migrate_data. Avevo circa 1 TB, che ha richiesto più di un'ora. Anche in alcuni casi, durante i test, ho cancellato i dati storici dei tipi di carattere che non erano necessari per l'archiviazione, in modo da non trasferirli.
Ultimo passo - UPDATE: in db_extension Mettere timescaledbin modo che il database comprenda che questa estensione esiste. Zabbix lo attiva e utilizza correttamente la sintassi e le query al database, quelle funzionalità necessarie per TimescaleDB.
Configurazione hardware
Ho usato due server. Primo - Macchina VMware. È piuttosto piccolo: 20 processori Intel® Xeon® CPU E5-2630 v 4 a 2.20 GHz, 16 GB di RAM e un SSD da 200 GB.
Ho installato PostgreSQL 10.8 su di esso con il sistema operativo Debian 10.8-1.pgdg90+1 e il file system xfs. Ho configurato tutto minimamente per utilizzare questo particolare database, meno ciò che utilizzerà Zabbix stesso.
Sulla stessa macchina c'erano un server Zabbix, PostgreSQL e agenti di carico. Avevo 50 agenti attivi che stavano utilizzando LoadableModuleper generare molto rapidamente risultati diversi: numeri, stringhe. Ho riempito il database con molti dati.
Inizialmente la configurazione conteneva 5 articoli dati per host. Quasi ogni elemento conteneva un trigger per renderlo simile alle installazioni reali. In alcuni casi si è verificato più di un fattore scatenante. Per un nodo di rete c'erano 3-000 trigger.
Intervallo di aggiornamento degli elementi dati − secondi 4-7. Ho regolato il carico stesso utilizzando non solo 50 agenti, ma aggiungendone altri. Inoltre, utilizzando gli elementi dati, ho regolato dinamicamente il carico e ridotto l'intervallo di aggiornamento a 4 s.
PostgreSQL. 35 nvp
La mia prima esecuzione su questo hardware è stata su PostgreSQL puro: 35mila valori al secondo. Come puoi vedere, l'inserimento dei dati richiede frazioni di secondo: tutto va bene e velocemente. L'unica cosa è che un disco SSD da 200 GB si riempie velocemente.
Questa è una dashboard standard delle prestazioni del server Zabbix.
Il primo grafico blu è il numero di valori al secondo. Il secondo grafico a destra è il caricamento dei processi di compilazione. Il terzo sta caricando i processi di build interni: sincronizzatori della cronologia e Housekeeper, che è in esecuzione qui da un po' di tempo.
Il quarto grafico mostra l'utilizzo di HistoryCache. Questa è una sorta di buffer prima dell'inserimento nel database. Il quinto grafico verde mostra l'utilizzo di ValueCache, ovvero il numero di accessi ValueCache per i trigger: si tratta di diverse migliaia di valori al secondo.
PostgreSQL. 50 nvp
Poi ho aumentato il carico fino a 50mila valori al secondo sullo stesso hardware.
Durante il caricamento da Housekeeper, l'inserimento di 10mila valori ha richiesto 2-3 secondi.
La governante sta già iniziando a interferire con il lavoro.
Il terzo grafico mostra che, in generale, il carico su trapper e sincronizzatori di cronologia è ancora al 60%. Nel quarto grafico, HistoryCache sta già iniziando a riempirsi piuttosto attivamente durante l'operazione Housekeeper. È pieno al 20%, ovvero circa 0,5 GB.
PostgreSQL. 80 nvp
Poi ho aumentato il carico fino a 80mila valori al secondo. Si tratta di circa 400mila elementi di dati e 280mila trigger.
Il costo di caricamento di trenta sincronizzatori di cronologia è già piuttosto elevato.
Ho anche aumentato vari parametri: sincronizzatori della cronologia, cache.
Sul mio hardware, il caricamento dei sincronizzatori della cronologia è aumentato al massimo. HistoryCache si è riempita rapidamente di dati: i dati per l'elaborazione si erano accumulati nel buffer.
Per tutto questo tempo ho osservato come venivano utilizzati il processore, la RAM e altri parametri di sistema e ho scoperto che l'utilizzo del disco era al massimo.
Ho raggiunto l'uso capacità massime del disco su questo hardware e su questa macchina virtuale. Con tale intensità, PostgreSQL ha iniziato a scaricare i dati in modo abbastanza attivo e il disco non ha più avuto il tempo di scrivere e leggere.
Secondo servitore
Ho preso un altro server, che aveva già 48 processori e 128 GB di RAM. L'ho ottimizzato, impostato su 60 sincronizzatori della cronologia e ho ottenuto prestazioni accettabili.
In realtà, questo è già il limite della produttività in cui è necessario fare qualcosa.
TimescaleDB. 80 nvp
Il mio compito principale è testare le capacità di TimescaleDB rispetto al carico di Zabbix. 80mila valori al secondo sono tanti, la frequenza di raccolta delle metriche (ad eccezione di Yandex, ovviamente) e una “configurazione” abbastanza ampia.
C'è un calo in ogni grafico: si tratta precisamente della migrazione dei dati. Dopo i guasti nel server Zabbix, il profilo di caricamento del sincronizzatore della cronologia è cambiato molto: è diminuito tre volte.
TimescaleDB ti consente di inserire i dati quasi 3 volte più velocemente e di utilizzare meno HistoryCache.
Di conseguenza, riceverai i dati in modo tempestivo.
TimescaleDB. 120 nvp
Quindi ho aumentato il numero di elementi di dati a 500mila. Il compito principale era testare le capacità di TimescaleDB: ho ricevuto un valore calcolato di 125mila valori al secondo.
Questa è una “configurazione” funzionante che può funzionare a lungo. Ma poiché il mio disco misurava solo 1,5 TB, l'ho riempito in un paio di giorni.
La cosa più importante è che allo stesso tempo siano state create nuove partizioni TimescaleDB.
Questo è completamente impercettibile per le prestazioni. Quando vengono create le partizioni in MySQL, ad esempio, tutto è diverso. Questo di solito accade di notte perché blocca l'inserimento generale, il funzionamento con le tabelle e può creare un degrado del servizio. Questo non è il caso di TimescaleDB.
Ad esempio, mostrerò un grafico tra molti nella comunità. Nell'immagine è abilitato TimescaleDB, grazie al quale il carico relativo all'utilizzo di io.weight sul processore è diminuito. È diminuito anche l'utilizzo di elementi di processo interni. Inoltre, questa è una normale macchina virtuale su normali dischi pancake, non un SSD.
risultati
TimescaleDB è una buona soluzione per piccole "configurazioni", che influiscono sulle prestazioni del disco. Ti consentirà di continuare a lavorare bene finché il database non verrà migrato sull'hardware il più rapidamente possibile.
TimescaleDB è facile da configurare, offre miglioramenti delle prestazioni, funziona bene con Zabbix e presenta vantaggi rispetto a PostgreSQL.
Se usi PostgreSQL e non prevedi di cambiarlo, lo consiglio utilizzare PostgreSQL con l'estensione TimescaleDB insieme a Zabbix. Questa soluzione funziona efficacemente fino ad un “setup” medio.
Quando diciamo “alte prestazioni” intendiamo . Non dovrai aspettare molto per conoscere le tecnologie e le pratiche che consentono ai servizi di servire milioni di utenti. Elenco per il 7 e 8 novembre abbiamo già compilato, ma qui si può suggerire di più.
Iscriviti al nostro и , in cui sveliamo le caratteristiche del prossimo convegno, e scopriamo come sfruttarlo al meglio.
Fonte: habr.com