Zabbix este un sistem de monitorizare. Ca orice alt sistem, se confruntă cu trei probleme principale ale tuturor sistemelor de monitorizare: colectarea și procesarea datelor, stocarea istoricului și curățarea acestuia.
Etapele de obținere, procesare și scriere a datelor necesită timp. Puțin, dar pentru un sistem de mari dimensiuni, acest lucru poate duce la întârzieri semnificative. Problema stocării este o chestiune de acces la date. Acestea sunt utilizate pentru rapoarte, verificări și declanșatoare. Întârzierile în accesarea datelor afectează de asemenea performanța. Pe măsură ce baza de date crește, datele învechite trebuie șterse. Ștergerea este o operațiune costisitoare, care consumă și ea o parte din resurse.
Problemele întârzierilor în colectare și stocare în Zabbix sunt rezolvate prin caching: mai multe tipuri de cache, cache în baza de date. Pentru a rezolva a treia problemă, cachingul nu este suficient, așa că în Zabbix a fost implementat TimescaleDB. Despre acest lucru va vorbi Andrei Gușțin — inginer de suport tehnic . Andrei are peste 6 ani în suportul Zabbix și se confruntă direct cu problemele de performanță.
Cum funcționează TimescaleDB, ce performanță poate oferi în comparație cu un PostgreSQL obișnuit? Ce rol joacă Zabbix pentru baza de date TimescaleDB? Cum se lansează de la zero și cum se migrează de la PostgreSQL și ce configurație oferă cele mai bune performanțe? Toate acestea sunt detaliate mai jos.
Provocările performanței
Fiecare sistem de monitorizare se confruntă cu anumite provocări legate de performanță. Voi vorbi despre trei dintre ele: colectarea și procesarea datelor, stocarea, curățarea istoricului.
Colectarea și procesarea rapidă a datelor. Un sistem de monitorizare bun trebuie să obțină rapid toate datele și să le proceseze conform expresiilor de declanșare — după propriile criterii. După procesare, sistemul trebuie să salveze rapid aceste date în baza de date pentru a fi utilizate ulterior.
Stocarea istoricului. Un sistem de monitorizare bun trebuie să stocheze istoricul în baza de date și să ofere acces ușor la metrici. Istoricul este necesar pentru a fi utilizat în rapoarte, grafice, declanșatoare, valori prag și elemente de date calculate pentru alerte.
Curățarea istoricului. Uneori vine o zi când nu mai ai nevoie de metrici. De ce ai nevoie de date acumulate acum 5 ani, o lună sau două: unele noduri au fost șterse, unele gazde sau metrici nu mai sunt necesare deoarece sunt depășite și nu mai sunt colectate. Un sistem bun de monitorizare ar trebui să stocheze datele istorice și din când în când să le ștergă pentru a preveni creșterea bazei de date.
Curățarea datelor depășite este o problemă urgentă, care afectează semnificativ performanța bazei de date.
Cache-ul în Zabbix
În Zabbix, prima și a doua apelare sunt rezolvate prin cache. Pentru colectarea și procesarea datelor se utilizează memoria RAM. Pentru stocare — istoricul din declanșatori, grafice și elemente de date calculate. Pe partea bazei de date există un anumit caching pentru interogările principale, de exemplu, graficele.
Caching pe partea serverului Zabbix este:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Să le discutăm în detaliu.
ConfigurationCache
Acesta este cache-ul principal, în care stocăm metricile, gazdele, elementele de date, declanșatoarele — tot ceea ce este necesar pentru PreProcessing și pentru colectarea datelor.
Toate acestea sunt stocate în ConfigurationCache, pentru a evita interogările inutile în baza de date. După pornirea serverului, actualizăm acest cache, creăm și actualizăm periodic configurațiile.
Colectarea datelor
Schema este destul de mare, dar esențialul ei este colectorii. Acestea sunt diferite "pollers" — procese de colectare. Ele răspund la diferite tipuri de colectare: colectează date prin SNMP, IPMI și transmit totul la PreProcessing.
Colectorii sunt evidențiați cu o linie portocalie.
În Zabbix există elemente de date agregate calculate, care sunt necesare pentru a agrega verificările. Dacă le avem, preluăm datele pentru ele direct din ValueCache.
PreProcessing HistoryCache
Toți colectorii utilizează ConfigurationCache pentru a primi sarcinile. Apoi, le transmit la PreProcessing.
PreProcessing folosește ConfigurationCache pentru a obține pașii PreProcessing. Acesta procesează aceste date în diverse moduri.
După procesarea datelor prin PreProcessing, le salvăm în HistoryCache pentru a fi procesate. Aici se încheie colectarea datelor și trecem la procesul principal în Zabbix — history syncer, deoarece este o arhitectură monolitică.
Notă: PreProcessing este o operațiune destul de greoaie. Începând cu versiunea 4.2, a fost mutat pe proxy. Dacă aveți un Zabbix foarte mare, cu un număr mare de elemente de date și o frecvență mare de colectare, aceasta ușurează mult munca.
ValueCache, istoric & tendințe cache
History syncer — este procesul principal care procesează atomic fiecare element de date, adică fiecare valoare.
History syncer ia valorile din HistoryCache și verifică în Configuration dacă există triggere pentru calcule. Dacă există, le calculează.
History syncer creează un eveniment, o escaladare, pentru a genera alerte, dacă este necesar conform configurației, și înregistrează. Dacă există triggere pentru procesare ulterioară, atunci această valoare o reține în ValueCache, pentru a nu apela la tabelul de istoric. Astfel, ValueCache se umple cu datele necesare pentru a calcula triggerele și elementele calculate.
History syncer înregistrează toate datele în baza de date, iar aceasta — pe disc. Procesul de procesare se încheie aici.
Cache-ul în baza de date
Pe partea de bază de date există diferite cache-uri, atunci când doriți să vizualizați grafice sau rapoarte de evenimente:
Innodb_buffer_poolpe partea de MySQL;shared_bufferspe partea de PostgreSQL;effective_cache_sizepe partea de Oracle;shared_poolpe partea de DB2.
Există și multe alte cache-uri, dar acestea sunt principalele pentru toate bazele de date. Ele permit menținerea în memorie a datelor care sunt frecvent necesare pentru interogări. Au propriile tehnologii pentru aceasta.
Performanța bazei de date este critică
Serverul Zabbix colectează constant date și le înregistrează. La repornire, de asemenea, citește din istoric pentru a umple ValueCache. Scripturile și rapoartele folosesc Zabbix API, care este construit pe baza interfeței web. Zabbix API interoghează baza de date și obține datele necesare pentru grafice, rapoarte, liste de evenimente și ultimele probleme.
Pentru vizualizare — Grafana. Printre utilizatorii noștri, aceasta este o soluție populară. Ea poate trimite direct cereri prin Zabbix API atât către baza de date, cât și creează o anumită concurență pentru obținerea datelor. De aceea este nevoie de o configurare mai fină și bună a bazei de date pentru a se potrivi cu livrarea rapidă a rezultatelor și testarea.
Housekeeper
A treia provocare de performanță în Zabbix este curățarea istoriei prin Housekeeper. Acesta respectă toate setările — în elementele de date este specificat cât timp să se păstreze dinamica schimbărilor (tendințelor) în zile.
TrendsCache îl calculăm pe loc. Când primim date, le agregăm pe o oră și le înregistrăm în tabele pentru dinamica schimbărilor tendințelor.
Housekeeper se lansează și șterge informațiile din baza de date cu ajutorul unor „selecturi” obișnuite. Acest lucru nu este întotdeauna eficient, ceea ce se poate observa din graficele de performanță ale proceselor interne.
Graficul roșu arată că History syncer este constant ocupat. Graficul portocalie de sus reprezintă Housekeeper, care se lansează constant. Acesta așteaptă de la baza de date să șteargă toate rândurile pe care le-a specificat.
Când ar trebui să dezactivați Housekeeper? De exemplu, dacă există un „Item ID” și trebuie să ștergeți ultimele 5.000 de rânduri într-o anumită perioadă. Desigur, acest lucru se realizează prin indecși. Dar, de obicei, setul de date este foarte mare și baza de date citește totuși de pe disc și îl aduce în cache. Aceasta este întotdeauna o operațiune foarte costisitoare pentru baza de date și, în funcție de dimensiunile bazei, poate duce la probleme de performanță.
Housekeeper poate fi pur și simplu dezactivat. În interfața web, există o setare în „Administration general” pentru Housekeeper. Dezactivăm Housekeeping-ul intern pentru istoricul tendințelor interne și acesta nu mai gestionează acest lucru.
Housekeeper a fost dezactivat, graficele s-au aliniat — ce probleme ar putea apărea în acest caz și ce ar putea ajuta la soluționarea celui de-al treilea apel de performanță?
Partitioning — secționare sau partajare
De obicei, partajarea este configurată în diferite moduri pe fiecare bază de date relațională pe care am enumerat-o. Fiecare are propria tehnologie, dar sunt asemănătoare, în general. Crearea unei noi partiții duce adesea la anumite probleme.
De obicei, partițiile se configurează în funcție de „setup” — cantitatea de date create pe parcursul unei zile. În general, partitioning-ul este stabilit pe o zi, acesta fiind minimul. Pentru tendințe, o nouă partiție se face pentru 1 lună.
Valorile pot varia în cazul unui „setup” foarte mare. Dacă un „setup” mic este de până la 5.000 nvps (noi valori pe secundă), unul mediu este între 5.000 și 25.000, iar unul mare este peste 25.000 nvps. Acestea sunt instalări mari și foarte mari, care necesită o configurare atentă a bazei de date.
În instalații foarte mari, o porțiune de o zi poate să nu fie optimă. Am văzut pe MySQL partiții de 40 GB sau mai mult pe zi. Aceasta este o cantitate foarte mare de date, ceea ce poate duce la probleme, și trebuie redusă.
Ce beneficii oferă Partitioning?
Secționarea tabelelor. De obicei, acestea sunt fișiere separate pe disc. Planul de interogări selectează mai optim o partiție. De obicei, partiționarea este utilizată pe intervale — acest lucru este, de asemenea, adevărat pentru Zabbix. Utilizăm acolo „timestamp” — timpul de la începutul epocii. La noi este vorba de numere obișnuite. Definești începutul și sfârșitul zilei — aceasta este o partiție.
Ștergere rapidă — DELETE. Se selectează un fișier/subtabel, nu un set de rânduri pentru ștergere.
Accelerarea semnificativă a accesării datelor SELECT — utilizează o sau mai multe partiții, nu întreaga tabelă. Dacă soliciți date de acum două zile, acestea sunt selectate din baza de date mai repede, pentru că este nevoie să încarci în memorie și să furnizezi doar un singur fișier, nu o tabelă mare.
Adesea, multe baze de date accelerează de asemenea INSERT — inserțiile în tabelul copil.
TimescaleDB
Pentru versiunea 4.2, am observat TimescaleDB. Această extensie pentru PostgreSQL are o interfață nativă. Extensia lucrează eficient cu datele de tip serie temporală, fără a pierde avantajele bazelor de date relaționale. TimescaleDB își partitionează automat datele.
În TimescaleDB există conceptul de hipertabel (hypertable), pe care îl creezi. Aici se află chunk-uri — partiții. Chunk-urile sunt fragmente gestionate automat ale hipertabelei, care nu influențează alte fragmente. Fiecare chunk are propria interval de timp.
TimescaleDB vs PostgreSQL
TimescaleDB funcționează cu adevărat eficient. Producătorii extensiei susțin că folosesc un algoritm de procesare a interogărilor mai corect, în special pentru <code>inserts</code>. Pe măsură ce dimensiunile seturilor de date pentru inserare cresc, algoritmul menține o performanță constantă.
După 200 de milioane de rânduri, PostgreSQL de obicei începe să decaleze semnificativ și își pierde performanța până la 0. TimescaleDB permite inserții eficiente de „inserts” indiferent de volumul de date.
Instalare
Instalarea TimescaleDB este destul de simplă pentru orice pachet. În este descris detaliat — depinde de pachetele oficiale PostgreSQL. De asemenea, TimescaleDB poate fi compilat și construit manual.
Pentru baza de date Zabbix, pur și simplu activăm extensia:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix Activezi extensia și o creezi pentru baza de date Zabbix. Ultimul pas este crearea hipertabelei.
Migrarea tabelilor de istoric în TimescaleDB
Pentru aceasta există o funcție specială 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 Funcția are trei parametri. Primul — tabelul din baza de date, pentru care trebuie creată o hipertabelă. Al doilea — câmpul, pe baza căruia trebuie să fie creat chunk_time_interval — intervalul de chunk-uri pentru partiții, care trebuie utilizat. În cazul meu, intervalul este de o zi — 86 400.
Al treilea parametru — migrați_date. Dacă este setat true, toate datele curente sunt mutate în chunk-urile create anterior. Eu am folosit migrați_date. Am avut aproximativ 1 TB, ceea ce a durat mai mult de o oră. Chiar și în unele cazuri, în timpul testării, am șters date istorice inutile de tip simbolic pentru a nu le muta.
Ultimul pas — UPDATE: în db_extension setăm timescaledb, pentru ca baza de date să înțeleagă că există această extensie. Zabbix o activează și folosește corect sintaxa și interogările pentru baza de date — acele funcții necesare pentru TimescaleDB.
Configurarea hardware-ului
Am folosit două servere. Primul — mașină VMware. Este destul de mică: 20 procesoare Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 GB de RAM și un SSD de 200 GB.
Am instalat pe ea PostgreSQL 10.8 cu OS Debian 10.8-1.pgdg90+1 și sistem de fișiere xfs. Am configurat totul minimal pentru a utiliza exact această bază de date, cu excepția celor pe care le va folosi Zabbix.
Pe aceeași mașină rula serverul Zabbix, PostgreSQL și agenții de încărcare. Am avut 50 de agenți activi care foloseau LoadableModule, pentru a genera foarte rapid diverse rezultate: numere, șiruri. Am umplut baza de date cu un volum mare de date.
Inițial, configurația conținea 5 000 de elemente de date pentru fiecare host. Aproape fiecare element conținea un trigger, pentru a fi asemănător cu instalațiile reale. În unele cazuri, erau mai multe de un trigger. Pentru un nod de rețea, erau 3 000-7 000 de triggers.
Intervalul de actualizare a elementelor de date — 4-7 secunde. Am reglat sarcina folosind nu doar 50 de agenți, ci am adăugat și altele. De asemenea, cu ajutorul elementelor de date am reglat dinamic sarcina și am redus intervalul de actualizare la 4 secunde.
PostgreSQL. 35 000 nvps
Prima rulare pe acest hardware a fost cu PostgreSQL curat — 35 de mii de valori pe secundă. Așa cum se vede, inserția de date durează fracțiuni de secundă — totul este bine și rapid. Singurul inconvenient este că discul SSD de 200 GB se umple rapid.
Acesta este dashboard-ul standard de performanță Zabbix — servere.
Primul grafic albastru - numărul de valori pe secundă. Al doilea grafic din dreapta - încărcarea proceselor de colectare. Al treilea - încărcarea proceselor interne de colectare: history syncers și Housekeeper, care a fost activ o perioadă suficient de lungă.
Al patrulea grafic arată utilizarea HistoryCache. Aceasta este un fel de buffer înainte de inserția în baza de date. Al cincilea grafic verde arată utilizarea ValueCache, adică câte hituri pentru ValueCache pentru declanșatoare - sunt câteva mii de valori pe secundă.
PostgreSQL. 50 000 nvps
Apoi am crescut sarcina la 50 de mii de valori pe secundă pe același hardware.
La încărcarea cu Housekeeper, inserția a 10 mii de valori s-a realizat în 2-3 secunde.
Housekeeper începe deja să interfereze cu activitatea.
Pe al treilea grafic se vede că, în general, încărcarea trapper-ilor și history syncers-urilor este încă la nivelul de 60%. Pe al patrulea grafic, HistoryCache începe să se umple destul de activ în timpul funcționării Housekeeper-ului. S-a umplut la 20% — aceasta înseamnă aproximativ 0,5 GB.
PostgreSQL. 80 000 nvps
Apoi am crescut sarcina la 80 de mii de valori pe secundă. Acesta este aproximativ 400 de mii de elemente de date și 280 de mii de declanșatoare.
Inserția cu treizeci de history syncers este deja destul de ridicată.
De asemenea, am crescut diferite parametrii: history syncers, cache-uri.
Pe hardware-ul meu, încărcarea history syncers a crescut la maxim. HistoryCache s-a umplut rapid cu date — în buffer s-au acumulat date pentru procesare.
Toată această perioadă, am observat utilizarea procesorului, memoriei RAM și altor parametri ai sistemului, și am descoperit că utilizarea discurilor a fost maximă.
Am reușit să folosesc capacitățile maxime ale discului pe acest hardware și pe această mașină virtuală. Cu o astfel de intensitate, PostgreSQL a început să reseteze datele destul de activ, iar discul nu mai reușea să lucreze eficient atât la scriere, cât și la citire.
Al doilea server
Am ales un alt server, care avea deja 48 de procesoare și 128 GB de memorie RAM. L-am optimizat – am instalat 60 history syncer și am obținut o viteză de operare acceptabilă.
De fapt, aceasta este deja limita performanței, unde este necesar să se ia măsuri.
TimescaleDB. 80.000 nvps
Principala mea sarcină a fost să verific capacitățile TimescaleDB sub încărcarea Zabbix. 80.000 de valori pe secundă – este mult, frecvența de colectare a metricalor (cu excepția Yandex, desigur) și un „setup” destul de mare.
Pe fiecare grafic există o scădere – aceasta este în special migrarea datelor. După scăderile de pe serverul Zabbix, profilul de încărcare al history syncer s-a schimbat semnificativ – a scăzut de trei ori.
TimescaleDB permite inserarea datelor aproape de 3 ori mai rapid și utilizează mai puțin HistoryCache.
Prin urmare, datele vor fi livrate la timp.
TimescaleDB. 120.000 nvps
Apoi, am crescut numărul de elemente de date la 500.000. Principala sarcină a fost să verific capacitățile TimescaleDB – am obținut o valoare estimată de 125.000 de valori pe secundă.
Acesta este un „setup” funcțional, care poate rula mult timp. Dar, deoarece discul meu era de doar 1,5 TB, l-am umplut în câteva zile.
Cel mai important lucru este că, în același timp, erau create noi partiții TimescaleDB.
Pentru performanță, acest aspect este complet imperceptibil. Atunci când se creează partiții în MySQL, de exemplu, totul este diferit. De obicei, acest lucru se întâmplă noaptea, deoarece blochează inserția generală, lucrarea cu tabelele și poate provoca degradarea serviciului. În cazul TimescaleDB, acest lucru nu se întâmplă.
Pentru un exemplu, voi arăta un grafic dintre cele multe în comunitate. În imagine, TimescaleDB este activat, datorită căruia încărcătura de utilizare io.weight pe procesor a scăzut. Utilizarea elementelor proceselor interne a scăzut, de asemenea. Și aceasta este o mașină virtuală obișnuită pe discuri HDD, nu SSD.
Conclusions
TimescaleDB este o soluție bună pentru „setup”-uri mici, care se confruntă cu limitele performanței discului. Aceasta va permite să continuați să lucrați bine până la migrarea Bazei de Date pe hardware mai rapid.
TimescaleDB este ușor de configurat, oferă un adevărat câștig de performanță, funcționează bine cu Zabbix și are avantajele față de PostgreSQL.
Dacă folosiți PostgreSQL și nu plănuiți să îl schimbați, vă recomand să folosiți PostgreSQL cu extensia TimescaleDB împreună cu Zabbix. Această soluție funcționează eficient pentru „setup”-uri medii.
Când spunem „performanță ridicată” – ne referim la . Așteptați să descoperiți tehnologiile și practicile care permit serviciilor să deservescă milioane de utilizatori nu va dura mult. Lista pentru 7 și 8 noiembrie este deja realizată, iar încă pot fi propuse.
Abonează-te la și , în care dezvăluim lucrurile interesante ale conferinței viitoare și aflați cum să obțineți maximum de beneficii.
Sursa: habr.com
