Zabbix hè un sistema di monitoraghju. Cum'è ogni altru sistema, face trè prublemi principali di tutti i sistemi di surviglianza: cullizzioni è trasfurmazioni di dati, almacenà a storia, è sguassà.
E tappe di riceve, trasfurmà è arregistramentu di dati piglianu tempu. Micca assai, ma per un grande sistema, questu pò esse risultatu in grandi ritardi. U prublema di almacenamiento hè una questione di accessu à e dati. Sò usati per rapporti, cuntrolli è triggers. I ritardi di l'accessu à i dati afectanu ancu u rendiment. Quandu a basa di dati cresce, i dati irrilevanti anu da esse eliminati. L'eliminazione hè una operazione pesante chì manghja ancu alcune risorse.
I prublemi di ritardu di cullizzioni è di almacenamiento in Zabbix sò risolti da caching: parechji tipi di cache, caching in a basa di dati. Per risolve u terzu prublema, u caching ùn hè micca adattatu, cusì TimescaleDB hè stata utilizata in Zabbix. Ne dirà Andrey Gushchin - ingegnere di supportu tecnicu . Andrey supporta Zabbix da più di 6 anni è hè direttamente implicatu in a performance.
Cumu funziona TimescaleDB, chì prestazioni pò dà paragunatu à PostgreSQL regulare? Chì rolu ghjucà Zabbix in TimescaleDB? Cumu principià da zero è cumu migrate da PostgreSQL è quale prestazione di cunfigurazione hè megliu? Tuttu chistu sottu u cut.
Sfide di rendiment
Ogni sistema di surviglianza face certe sfide di rendiment. Parlaraghju di trè di elli: cullizzioni di dati è trasfurmazioni, almacenamiento, pulizia di a storia.
Raccolta rapida di dati è trasfurmazioni. Un bon sistema di surviglianza deve riceve rapidamente tutte e dati è processà secondu l'espressioni trigger - secondu i so criteri. Dopu a trasfurmazioni, u sistema deve ancu almacenà rapidamente sta dati in a basa di dati per usà dopu.
Stoccaggio di storia. Un bon sistema di surviglianza deve guardà a storia in una basa di dati è furnisce un accessu faciule à e metriche. A storia hè necessaria per esse aduprata in rapporti, grafici, triggers, thresholds è articuli d'alerta calculati.
Storia di sguassà. Calchì volta vene un ghjornu chì ùn avete micca bisognu di almacenà metriche. Perchè avete bisognu di dati chì sò stati raccolti 5 anni fà, un mesi o dui: alcuni nodi sò stati eliminati, alcuni ospiti o metrichi ùn sò più necessarii, perchè sò obsoleti è ùn sò più raccolti. Un bon sistema di surviglianza deve almacenà e dati storichi è sguassate da u tempu à u tempu per chì a basa di dati ùn cresce.
A pulizia di e dati stanchi hè un prublema spinosa chì hà un grande impattu nantu à u rendiment di a basa di dati.
Caching in Zabbix
In Zabbix, a prima è a seconda chjama sò risolte cù u caching. A RAM hè aduprata per cullà è processà e dati. Per u almacenamentu - storia in triggers, grafici è articuli calculati. Da u latu DB, ci hè qualchì caching per selezzione basi, cum'è i grafici.
A caching in u latu di u servitore Zabbix stessu hè:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
E cunsiderenu in più detail.
ConfigurationCache
Questa hè a cache principale in quale guardemu metriche, hosts, data items, triggers - tuttu ciò chì hè necessariu per PreProcessing è per a cullizzioni di dati.
Tuttu chistu hè guardatu in u ConfigurationCache per ùn creà dumande innecessarii in a basa di dati. Dopu chì u servitore principia, aghjurnà sta cache, creanu è aghjurnà periodicamente e cunfigurazioni.
Raccolta di dati
U schema hè abbastanza grande, ma u principale hè cullezzione. Quessi sò diversi "pollers" - prucessi di assemblea. Sò rispunsevuli di diversi tipi di assemblea: cullighjanu dati via SNMP, IPMI, è trasfirìanu tuttu à PreProcessing.
I pickers sò circundati in aranciu.
Zabbix hà calculatu l'articuli di aggregazione chì sò necessarii per aggregate i cuntrolli. Se l'avemu, pigliamu i dati per elli direttamente da u ValueCache.
Preprocessing HistoryCache
Tutti i cullezzione utilizanu u ConfigurationCache per riceve impieghi. Allora li passanu à PreProcessing.
Preprocessing usa ConfigurationCache per uttene i passi di PreProcessing. Tratta sta dati in diversi modi.
Dopu avè trasfurmatu i dati cù PreProcessing, l'avemu guardatu in HistoryCache per processà. Questu compie a cullizzioni di dati è andemu à u prucessu principale in Zabbix - sincronizatore di storia, cum'è hè una architettura monolitica.
Nota: Preprocessing hè una operazione abbastanza pesante. Da a v 4.2 hè stata spustata in un proxy. Sì avete un Zabbix assai grande cù un gran numaru d'articuli è a freccia di cullizzioni, allora questu rende e cose assai più faciuli.
ValueCache, cache di storia è tendenze
History syncer hè u prucessu principale chì processa atomicamente ogni elementu di dati, vale à dì, ogni valore.
Storia Syncer piglia valori da HistoryCache è verifica a Configurazione per i triggers per i calculi. S'elli sò - calcula.
Storia Syncer crea un avvenimentu, scala per creà alerti se necessariu da a cunfigurazione, è registra. Se ci sò attivatori per più processu, allora ricorda stu valore in ValueCache per ùn riferite micca à a tabella di storia. Questu hè cumu u ValueCache hè pienu di e dati chì hè necessariu per calculà triggers, calculate items.
History syncer scrive tutte e dati à a basa di dati, è scrive à u discu. U prucessu di trasfurmazioni finisci quì.
cache DB
Ci hè parechje cache nantu à u latu DB quandu vulete guardà grafici o rapporti di avvenimenti:
Innodb_buffer_poolda u latu MySQL;shared_buffersda u latu PostgreSQL;effective_cache_sizenant'à u latu Oracle;shared_poolda u latu DB2.
Ci sò parechje altre cache, ma queste sò i principali per tutte e basa di dati. Permettenu di mantene e dati in RAM chì hè spessu necessariu per e dumande. Hanu a so propria tecnulugia per questu.
A prestazione di a basa di dati hè critica
U servitore Zabbix raccoglie constantemente dati è scrive. Quandu si riavvia, leghje ancu da a storia per riempie u ValueCache. Scripts è rapporti usi API Zabbix, chì hè custruitu nantu à a basa di l'interfaccia Web. L'API Zabbix accede à a basa di dati è ricuperà i dati necessarii per i grafici, i rapporti, i listi di l'avvenimenti è i prublemi recenti.
Per a visualizazione - Grafana. Questa hè una suluzione populari trà i nostri utilizatori. Puderà mandà direttamente richieste attraversu l'API Zabbix è à a basa di dati, è crea una certa cuncurrenza per ottene dati. Dunque, una sintonizazione di basa di dati più fina è megliu hè necessaria per currisponde à a consegna rapida di risultati è teste.
Associazione
A terza sfida di rendiment in Zabbix hè a storia di pulizia cù Housekeeper. Rispetta tutti i paràmetri - l'elementi di dati indicanu quantu tempu per almacenà a dinamica di cambiamenti (tendenzi) in ghjorni.
TrendsCache avemu calculatu nantu à a mosca. Quandu i dati venenu, l'avemu aggregate in una ora è mette in tavule per a dinamica di i cambiamenti di tendenza.
Housekeeper principia è sguassate l'infurmazioni da a basa di dati cù i soliti "selezzioni". Questu ùn hè micca sempre efficace, chì pò esse capitu da i grafici di rendiment di i prucessi internu.
U graficu rossu mostra chì u Syncer Storia hè constantemente occupatu. U graficu aranciu in cima hè Housekeeper, chì hè in constantemente. Aspitta chì a basa di dati per sguassà tutte e fila chì hà specificatu.
Quandu duvete disattivà Housekeeper? Per esempiu, ci hè un "Item ID" è avete bisognu di sguassà l'ultimi 5 mila linee in un certu tempu. Di sicuru, questu succede da l'indici. Ma di solitu u dataset hè assai grande, è a basa di dati sempre leghje da u discu è u mette in a cache. Questa hè sempre una operazione assai caru per a basa di dati è, secondu a dimensione di a basa di dati, pò purtà à prublemi di rendiment.
Housekeeper hè simplice per disattivà. In l'interfaccia Web, ci hè un paràmetru in "Amministrazione generale" per Housekeeper. Disattivate a pulizia interna per a storia di tendenza interna è ùn cuntrolla più questu.
A domestica hè stata disattivata, i grafici sò stati livellati - chì puderanu esse i prublemi in questu casu è chì pò aiutà à risolve a terza sfida di rendiment?
Partitioning - partitioning o partitioning
A partizione hè generalmente cunfigurata in una manera diversa nantu à ogni basa di dati relazionale chì aghju listatu. Ognunu hà a so propria tecnulugia, ma sò simili, in generale. Crià una nova particione spessu porta à certi prublemi.
Di genere, i partizioni sò cunfigurati secondu a "setup" - a quantità di dati chì hè creatu in un ghjornu. Comu regula, u Partitioning hè stallatu in un ghjornu, questu hè u minimu. Per novi tendenzi di partizioni - 1 mese.
I valori pò cambià in u casu di una "setup" assai grande. Se una piccula "configurazione" hè finu à 5 nvps (nuvelli valori per seconda), una media hè da 000 à 5, allora una grande hè sopra 000 nvps. Quessi sò installazioni grande è assai grande chì necessitanu una cunfigurazione curretta di a basa di dati stessu.
In installazioni assai grande, un ghjornu pò esse micca ottimali. Aghju vistu partizioni MySQL di 40 GB o più per ghjornu. Questa hè una quantità assai grande di dati chì ponu purtà à prublemi è deve esse ridutta.
Chì dà u Partitioning?
Tavule di partizione. Spessu questi sò schedarii separati nantu à u discu. U pianu di a dumanda selezziunate una partizione più ottimali. Di solitu u particionamentu hè utilizatu da u range - questu hè ancu veru per Zabbix. Avemu aduprà quì "timestamp" - u tempu da u principiu di l'epica. Avemu numeri regularmente. Avete stabilitu u principiu è a fine di u ghjornu - questu hè una partizione.
Rimozione rapida - DELETE. Un schedariu / sottotavola hè sceltu, micca una selezzione di fila per sguassà.
Accelera significativamente u campionamentu di dati SELECT - usa una o più partizioni, micca tutta a tavola. Sè vo avete accessu à dati di dui ghjorni, l'avete da a basa di dati più veloce perchè avete solu carricà in a cache è rinvià solu un schedariu, micca una grande tavola.
Spessu assai basa di dati acceleranu ancu INSERT - inserisce in a tavola di u zitellu.
TimecaleDB
Per v 4.2 avemu vultatu a nostra attenzione à TimescaleDB. Questa hè una estensione PostgreSQL cù una interfaccia nativa. L'estensione travaglia in modu efficiente cù dati di serie temporale senza perde i vantaghji di e basa di dati relazionale. TimescaleDB hè ancu partizionatu automaticamente.
TimescaleDB hà un cuncettu ipertable (ipertable) chì create. In questu sò pezzi - partizioni. I chunks sò automaticamente gestiti frammenti di una ipertavule chì ùn affettanu micca altri frammenti. Ogni pezzu hà u so propiu intervallu di tempu.
TimescaleDB vs PostgreSQL
TimescaleDB hè veramente efficace. I pruduttori di l'estensione pretendenu chì utilizanu un algoritmu di trasfurmazione di query più currettu, in particulare, inserts . Quandu a dimensione di l'inseritu di dataset cresce, l'algoritmu mantene a prestazione constante.
Dopu à 200 milioni di fila, PostgreSQL di solitu principia à sag assai è perde u rendiment à 0. TimescaleDB permette di inserisce in modu efficace "inserti" cù qualsiasi quantità di dati.
rimarchevuli
L'installazione di TimescaleDB hè abbastanza faciule per qualsiasi pacchetti. IN tuttu hè detallatu - dipende da i pacchetti ufficiali PostgreSQL. TimescaleDB pò ancu esse custruitu è cumpilatu da a manu.
Per a basa di dati Zabbix, avemu solu attivà l'estensione:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
vi attivate extension è creanu per a basa di dati Zabbix. L'ultimu passu hè di creà un hypertable.
Migrazione di e tabelle di storia à TimescaleDB
Ci hè una funzione speciale per questu. 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
A funzione hà trè paràmetri. Primu - tabella in a basa di datiU per quale vulete creà un hypertable. Sicondu - campu, secondu a quale hè necessariu di creà chunk_time_interval - intervallu di partizioni di partizioni per esse usatu. In u mo casu, l'intervallu hè un ghjornu - 86 400.
U terzu paràmetru hè migrate_data. Se stabilitu true, allura tutti i dati currenti sò trasferiti à chunks pre-creati. Eiu stessu aghju utilizatu migrate_data. Aghju avutu circa 1TB chì hà pigliatu più di una ora. Ancu in certi casi, durante a prova, aghju sguassatu i dati storichi di i tipi di caratteri, chì sò opzionali per u almacenamentu, per ùn trasfiriri.
Ultimu passu - UPDATE: à db_extension mette timescaledbcusì chì a basa di dati capisce chì ci hè sta estensione. Zabbix l'attiva è usa currettamente a sintassi è e dumande digià à a basa di dati - quelli funziunalità chì sò necessarii per TimescaleDB.
Cunfigurazione hardware
Aghju utilizatu dui servitori. Primu - macchina VMware. Hè abbastanza chjucu: 20 CPU Intel® Xeon® E5-2630 v 4 @ 2.20GHz, 16 GB di RAM è un drive SSD 200 GB.
Aghju installatu PostgreSQL 10.8 nantu à questu cù Debian OS 10.8-1.pgdg90 + 1 è u sistema di schedariu xfs. Aghju cunfiguratu tuttu minimamente per utilizà sta basa di dati particulari, minus chì Zabbix stessu aduprà.
Nant'à a stessa macchina ci era un servitore Zabbix, PostgreSQL è agenti di carica. Aghju avutu 50 agenti attivi chì anu utilizatu LoadableModuleper generà parechji risultati assai rapidamente: numeri, strings. Aghju pienu a basa di dati cù assai dati.
In principiu, a cunfigurazione cuntene 5 articuli dati per host. Quasi tutti l'elementu cuntenenu un trigger per fà vede cum'è installazioni veri. In certi casi, ci era più di un trigger. Un node di rete avia 3-000 triggers.
Intervallu di aghjurnamentu di l'articulu - 4-7 seconde. Aghju regulatu a carica stessu usendu micca solu agenti 50, ma aghjunghjendu più. Inoltre, cù l'aiutu di elementi di dati, aghju regulatu dinamicamente a carica è reduciu l'intervallu di l'aghjurnamentu à 4 s.
PostgreSQL. 35 nvps
A mo prima corsa nantu à questu hardware hè stata nantu à PostgreSQL pura - 35 mila valori per seconda. Comu pudete vede, l'inserimentu di dati piglia frazioni di un secondu - tuttu hè bonu è veloce. L'unica cosa hè chì l'unità SSD 200 GB si riempie rapidamente.
Questu hè un dashboard standard di prestazione di u servitore Zabbix.
U primu graficu blu hè u numeru di valori per seconda. U secondu graficu à a diritta hè caricate i prucessi di creazione. U terzu hè a carica di i prucessi internu di custruzzione: i sincronizatori di a storia è u Housekeeper, chì hè in esecuzione per un bellu pezzu quì.
U quartu graficu mostra l'usu di HistoryCache. Questu hè un tipu di buffer prima di inserisce in a basa di dati. U quintu graficu verde mostra l'usu di ValueCache, vale à dì, quanti hits ValueCache per triggers sò parechji millai di valori per seconda.
PostgreSQL. 50 nvps
Allora aghju aumentatu a carica à 50 mila valori per seconda nantu à u stessu hardware.
Quandu si carica da Housekeeper, inserisce 10 mila valori hà pigliatu 2-3 seconde.
A domestica hè digià cuminciata à mette in u modu.
U terzu gràficu mostra chì, in generale, a carica di i trappers è i syncers di a storia hè sempre à u livellu di 60%. In u quartu graficu, u HistoryCache durante l'operazione di Housekeeper hè digià cuminciatu à riempie abbastanza attivamente. Hè 20% pienu - circa 0,5 GB.
PostgreSQL. 80 nvps
Allora aghju aumentatu a carica à 80 mila valori per seconda. Questu hè circa 400 mila elementi di dati è 280 mila triggers.
L'inseritu di carica di trenta syncers di storia hè digià abbastanza altu.
Aghju ancu aumentatu parechji paràmetri: syncers di storia, cache.
Nantu à u mo hardware, a carica di i sincronizatori di a storia hà aumentatu à u massimu. HistoryCache si riempia rapidamente di dati - u buffer hà accumulatu dati per u processu.
Tuttu stu tempu, aghju vistu cumu u processatore, a RAM è altri paràmetri di u sistema sò stati utilizati, è truvaru chì l'utilizazione di u discu era massimu.
Aghju fattu usu di capacità massima di discu nantu à questu hardware è in questa macchina virtuale. Cù una tale intensità, PostgreSQL hà cuminciatu à dump data assai attivamente, è u discu ùn hà più tempu di scrive è leghje.
Second server
Aghju pigliatu un altru servitore chì avia digià 48 processori è 128 GB di RAM. L'aghju sintonizatu - stabilitu 60 sincronizatori di storia, è ottenutu un rendimentu accettabile.
In fatti, questu hè digià un limitu di rendiment induve qualcosa deve esse fattu.
timescaled b. 80 nvps
U mo compitu principale hè di pruvà e capacità di TimescaleDB contru una carica Zabbix. 80 mila valori per seconda hè assai, a freccia di cullizzioni di metrica (eccettu Yandex, sicuru) è una "setup" abbastanza grande.
Ci hè un dip in ogni graficu - questu hè solu una migrazione di dati. Dopu à i fallimenti in u servitore Zabbix, u prufilu di carica di u syncer di a storia hà cambiatu assai - hè cascatu trè volte.
TimescaleDB permette di inserisce dati quasi 3 volte più veloce è aduprà menu HistoryCache.
In cunsiquenza, riceverete dati in una manera puntuale.
timescaled b. 120 nvps
Allora aghju aumentatu u numeru di elementi di dati à 500 mila. U compitu principalu era di verificà e capacità di TimescaleDB - aghju avutu un valore calculatu di 125 mila valori per seconda.
Questu hè un "setup" di travagliu chì pò piglià assai tempu per travaglià. Ma postu chì u mo discu era solu 1,5 TB, l'aghju pienu in un paru di ghjorni.
U più impurtante, novi partizioni TimescaleDB sò stati creati à u stessu tempu.
Per u funziunamentu, questu hè cumplettamente imperceptible. Quandu i partizioni sò creati in MySQL, per esempiu, e cose sò diffirenti. Stu solitu succèri a notte, perchè bluccà inserzione generale, manipulation table è pò creà degradazione di u serviziu. Questu ùn hè micca u casu cù TimescaleDB.
Per esempiu, vi mustrarà un graficu da u settore in a cumunità. In a stampa, TimescaleDB hè attivatu, grazie à quale a carica nantu à l'usu di io.weight in u processatore hè cascatu. L'usu di elementi di prucessi internu hè ancu diminuitu. Inoltre, questa hè una macchina virtuale ordinaria nantu à i dischi pancake ordinali, è micca un SSD.
scuperti
TimescaleDB hè una bona suluzione per i picculi "setups", chì si basanu nantu à u rendiment di u discu. Vi permetterà di cuntinuà à travaglià bè finu à chì a basa di dati hè migrata à u hardware più veloce.
TimescaleDB hè faciule da stallà, dà un impulso di rendiment, funziona bè cù Zabbix è hà vantaghji nantu à PostgreSQL.
Se aduprate PostgreSQL è ùn pensate micca di cambià, allora vi cunsigliu aduprà PostgreSQL cù l'estensione TimescaleDB in cunjunzione cù Zabbix. Sta suluzione travaglia effittivamenti sin'à mediu "setup".
Dicemu "altu rendiment" - vulemu dì . Ùn passerà assai prima di cunnosce e tecnulugia è e pratiche chì permettenu à i servizii di serve milioni di utilizatori. Lista per u 7 è l'8 di nuvembre, avemu digià elaboratu, ma più pò esse suggeritu.
Abbonate à u nostru и , In quale avemu revelatu e caratteristiche di a cunferenza chì vene, è scopre cumu ottene u più.
Source: www.habr.com