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 primire, procesare și înregistrare a datelor necesită timp. Nu mult, dar pentru un sistem mare, acest lucru poate duce la întârzieri mari. Problema de stocare este o problemă de acces la date. Sunt folosite pentru rapoarte, verificări și declanșatoare. Latența accesului la date afectează și performanța. Când bazele de date cresc, datele irelevante trebuie șterse. Îndepărtarea este o operațiune dificilă care consumă și unele resurse.
Problemele de întârziere în timpul colectării și stocării în Zabbix sunt rezolvate prin cache: mai multe tipuri de cache, cache în baza de date. Pentru a rezolva a treia problemă, memorarea în cache nu este potrivită, așa că Zabbix a folosit TimescaleDB. Îți va spune despre asta Andrei Gușcin - inginer suport tehnic . Andrey îl susține pe Zabbix de mai bine de 6 ani și are experiență directă în performanță.
Cum funcționează TimescaleDB, ce performanță poate oferi în comparație cu PostgreSQL obișnuit? Ce rol joacă Zabbix pentru baza de date TimescaleDB? Cum să pornești de la zero și cum să migrezi de la PostgreSQL și care configurație are performanțe mai bune? Despre toate acestea sub tăietură.
Provocări ale productivității
Fiecare sistem de monitorizare se confruntă cu provocări specifice de performanță. Voi vorbi despre trei dintre ele: colectarea și prelucrarea datelor, stocarea și ștergerea istoricului.
Colectarea și prelucrarea rapidă a datelor. Un sistem de monitorizare bun ar trebui să primească rapid toate datele și să le proceseze conform expresiilor de declanșare - conform criteriilor sale. După procesare, sistemul trebuie să salveze rapid aceste date în baza de date pentru o utilizare ulterioară.
Stocarea istoricului. Un sistem de monitorizare bun ar trebui să stocheze istoricul într-o bază de date și să ofere acces ușor la valori. Istoricul este necesar pentru a fi utilizat în rapoarte, grafice, declanșatoare, praguri și elemente de date de alertă calculate.
Ștergerea istoricului. Uneori vine o zi în care nu trebuie să stocați valori. De ce aveți nevoie de date care au fost colectate acum 5 ani, o lună sau două: unele noduri au fost șterse, unele gazde sau metrici nu mai sunt necesare pentru că sunt depășite și nu mai sunt colectate. Un sistem de monitorizare bun ar trebui să stocheze date istorice și să le ștergă din când în când, astfel încât baza de date să nu crească.
Curățarea datelor învechite este o problemă critică care are un impact semnificativ asupra performanței bazei de date.
Memorarea în cache în Zabbix
În Zabbix, primul și al doilea apel sunt rezolvate folosind cache. RAM este folosită pentru a colecta și procesa date. Pentru stocare - istoric în declanșatoare, grafice și elemente de date calculate. Pe partea bazei de date există unele memorări în cache pentru selecțiile de bază, de exemplu, grafice.
Memorarea în cache pe partea serverului Zabbix în sine este:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Luați în considerare în detaliu.
ConfigurationCache
Acesta este memoria cache principală în care stocăm valorile, gazdele, elementele de date, declanșatoarele - tot ce avem nevoie pentru preprocesare și pentru colectarea datelor.
Toate acestea sunt stocate în ConfigurationCache pentru a nu crea interogări inutile în baza de date. După ce pornește serverul, actualizăm acest cache, creăm și actualizăm periodic configurațiile.
Colectare de date
Diagrama este destul de mare, dar principalul lucru în ea este colecționari. Acestea sunt diverse „pollers” - procese de asamblare. Ei sunt responsabili pentru diferite tipuri de asamblare: colectează date prin SNMP, IPMI și le transferă pe toate la Preprocessing.
Colectorii sunt conturați în portocaliu.
Zabbix a calculat elementele de agregare care sunt necesare pentru agregarea controalelor. Dacă le avem, preluăm datele pentru ele direct din ValueCache.
Cache istoric de preprocesare
Toți colectorii folosesc ConfigurationCache pentru a primi joburi. Apoi le transferă la PreProcessing.
Preprocesarea folosește ConfigurationCache pentru a primi pașii de preprocesare. Prelucrează aceste date în diferite moduri.
După procesarea datelor folosind PreProcessing, le salvăm în HistoryCache pentru procesare. Acest lucru încheie colectarea datelor și trecem la procesul principal din Zabbix - sincronizator istoric, întrucât este o arhitectură monolitică.
Notă: Preprocesarea este o operație destul de dificilă. Cu v 4.2 a fost mutat în proxy. Dacă aveți un Zabbix foarte mare, cu un număr mare de elemente de date și frecvență de colectare, atunci acest lucru ușurează mult munca.
ValueCache, istoric și tendințe cache
History Syncer este procesul principal care prelucrează atomic fiecare element de date, adică fiecare valoare.
Sincronizarea istoricului preia valori din HistoryCache și verifică Configurația pentru prezența declanșatorilor pentru calcule. Dacă există, se calculează.
Sincronizarea istoricului creează un eveniment, escaladare pentru a crea alerte dacă este necesar de configurare și înregistrări. Dacă există declanșatori pentru procesarea ulterioară, atunci acesta stochează această valoare în ValueCache pentru a nu accesa tabelul istoric. Acesta este modul în care ValueCache este umplut cu date necesare pentru a calcula declanșatorii și elementele calculate.
History Syncer scrie toate datele în baza de date și scrie pe disc. Procesul de procesare se termină aici.
Memorarea în cache în baza de date
Pe partea bazei de date există diverse cache atunci când doriți să vizualizați grafice sau rapoarte despre evenimente:
Innodb_buffer_poolpe partea MySQL;shared_bufferspe partea PostgreSQL;effective_cache_sizepe partea Oracle;shared_poolpe partea DB2.
Există multe alte cache-uri, dar acestea sunt principalele pentru toate bazele de date. Acestea vă permit să stocați date în RAM, care sunt adesea necesare pentru interogări. Ei au propriile lor tehnologii pentru asta.
Performanța bazei de date este critică
Serverul Zabbix colectează în mod constant date și le scrie. Când este repornit, citește și din istoric pentru a umple ValueCache. Utilizează scripturi și rapoarte Zabbix API, care este construit pe o interfață Web. Zabbix API accesează baza de date și preia datele necesare pentru grafice, rapoarte, liste de evenimente și ultimele probleme.
Pentru vizualizare - grafana. Aceasta este o soluție populară printre utilizatorii noștri. Poate trimite direct cereri prin API-ul Zabbix și către baza de date și creează o anumită competiție pentru primirea datelor. Prin urmare, este nevoie de o reglare mai fină și mai bună a bazei de date pentru a se potrivi cu livrarea rapidă a rezultatelor și testării.
gospodină
A treia provocare de performanță în Zabbix este curățarea istoriei folosind Menajera. Urmărește toate setările - elementele de date indică cât timp trebuie stocată dinamica schimbărilor (tendințelor) în zile.
Calculăm TrendsCache din mers. Când sosesc datele, le cumulăm timp de o oră și le înregistrăm în tabele pentru dinamica schimbărilor de tendințe.
Menajera pornește și șterge informații din baza de date folosind „selectările” obișnuite. Acest lucru nu este întotdeauna eficient, așa cum se poate vedea din graficele de performanță ale proceselor interne.
Graficul roșu arată că sincronizatorul Istoric este ocupat în mod constant. Graficul portocaliu din partea de sus este Menajeră, care rulează constant. El așteaptă ca baza de date să șteargă toate rândurile pe care le-a specificat.
Când ar trebui să dezactivați menajera? De exemplu, există un „ID articol” și trebuie să ștergeți ultimele 5 mii de rânduri într-un anumit timp. Desigur, acest lucru se întâmplă prin index. Dar, de obicei, setul de date este foarte mare, iar baza de date încă citește de pe disc și o pune în cache. Aceasta este întotdeauna o operațiune foarte costisitoare pentru baza de date și, în funcție de dimensiunea bazei de date, poate duce la probleme de performanță.
Menajera este ușor de dezactivat. În interfața Web există o setare în „Administrare generală” pentru Menajeră. Dezactivăm menajul intern pentru istoricul intern al tendințelor și nu îl mai gestionează.
Menajera a fost oprită, graficele s-au nivelat - ce probleme ar putea exista în acest caz și ce ar putea ajuta la rezolvarea celei de-a treia provocări de performanță?
Partitioning - partitionare sau partitionare
De obicei, partiționarea este configurată într-un mod diferit pentru fiecare bază de date relațională pe care am enumerat-o. Fiecare are propria sa tehnologie, dar sunt similare în general. Crearea unei noi partiții duce adesea la anumite probleme.
De obicei, partițiile sunt configurate în funcție de „configurare” - cantitatea de date care este creată într-o zi. De regulă, partiționarea este emisă într-o zi, acesta este minimul. Pentru tendințele unui nou lot - 1 lună.
Valorile se pot schimba dacă „configurarea” este foarte mare. Dacă o „configurare” mică este de până la 5 nvps (noi valori pe secundă), una medie este de la 000 la 5, atunci una mare este peste 000 nvps. Acestea sunt instalații mari și foarte mari care necesită o configurare atentă a bazei de date.
La instalațiile foarte mari, o perioadă de o zi poate să nu fie optimă. Am văzut partiții MySQL de 40 GB sau mai mult pe zi. Aceasta este o cantitate foarte mare de date care poate cauza probleme și trebuie redusă.
Ce oferă partiționarea?
Tabele de partiționare. Adesea, acestea sunt fișiere separate pe disc. Planul de interogare selectează o partiție mai optim. De obicei, partiționarea este utilizată în funcție de interval - acest lucru este valabil și pentru Zabbix. Folosim „timpul de timp” acolo - timp de la începutul erei. Acestea sunt numere obișnuite pentru noi. Setați începutul și sfârșitul zilei - aceasta este o partiție.
Îndepărtare rapidă - DELETE. Este selectat un fișier/subtabel, mai degrabă decât o selecție de rânduri pentru ștergere.
Accelerează semnificativ recuperarea datelor SELECT - folosește una sau mai multe partiții, mai degrabă decât întreaga tabelă. Dacă accesați date vechi de două zile, acestea sunt preluate din baza de date mai rapid, deoarece trebuie doar să încărcați un fișier în cache și să îl returnați, nu un tabel mare.
Adesea, multe baze de date sunt, de asemenea, accelerate INSERT — inserții în masa copil.
TimecaleDB
Pentru versiunea 4.2, ne-am îndreptat atenția către TimescaleDB. Aceasta este o extensie pentru PostgreSQL cu o interfață nativă. Extensia funcționează eficient cu datele serii de timp, fără a pierde beneficiile bazelor de date relaționale. De asemenea, TimescaleDB partiţionează automat.
TimescaleDB are un concept hipertable (hipertabil) pe care îl creați. Contine bucăți - compartimentari. Bucățile sunt fragmente hipertable gestionate automat care nu afectează alte fragmente. Fiecare bucată are propriul interval de timp.
TimescaleDB vs PostgreSQL
TimescaleDB funcționează foarte eficient. Producătorii extensiei susțin că folosesc un algoritm de procesare a interogărilor mai corect, în special inserts . Pe măsură ce dimensiunea inserției setului de date crește, algoritmul menține performanța constantă.
După 200 de milioane de rânduri, PostgreSQL începe de obicei să scadă semnificativ și pierde performanța la 0. TimescaleDB vă permite să inserați eficient „inserții” pentru orice cantitate de date.
Instalare
Instalarea TimescaleDB este destul de ușoară pentru orice pachet. ÎN totul este descris în detaliu - depinde de pachetele oficiale PostgreSQL. TimescaleDB poate fi, de asemenea, construit și compilat 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
Tu activezi extension și creați-l pentru baza de date Zabbix. Ultimul pas este crearea unui hypertable.
Migrarea tabelelor istorice la TimescaleDB
Există o funcție specială pentru aceasta 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. În primul rând - tabel din baza de date, pentru care trebuie să creați un hypertable. Al doilea - câmp, conform căruia trebuie să creați chunk_time_interval — intervalul bucăților de partiții care urmează să fie utilizate. În cazul meu, intervalul este de o zi - 86.
Al treilea parametru - migrate_data. Dacă setați true, apoi toate datele curente sunt transferate în bucăți pre-create. L-am folosit chiar eu migrate_data. Am avut cam 1 TB, ceea ce a durat peste o oră. Chiar și în unele cazuri, în timpul testării, am șters datele istorice ale tipurilor de caractere care nu erau necesare pentru stocare, pentru a nu le transfera.
Ultimul pas - UPDATE: în db_extension a pune timescaledbastfel încât baza de date să înțeleagă că această extensie există. Zabbix îl activează și utilizează corect sintaxa și interogările la baza de date - acele caracteristici care sunt necesare pentru TimescaleDB.
Configurare hardware
Am folosit două servere. În primul rând - mașină VMware. Este destul de mic: 20 de procesoare Intel® Xeon® E5-2630 v 4 @ 2.20GHz, 16 GB RAM și un SSD de 200 GB.
Am instalat PostgreSQL 10.8 pe el cu Debian 10.8-1.pgdg90+1 OS și sistemul de fișiere xfs. Am configurat totul minim pentru a utiliza această bază de date, minus ceea ce va folosi Zabbix.
Pe aceeași mașină exista un server Zabbix, PostgreSQL și agenţi de încărcare. Am avut 50 de agenți activi care foloseau LoadableModulepentru a genera foarte rapid rezultate diferite: numere, șiruri. Am umplut baza de date cu multe date.
Inițial configurația conținută 5 de elemente date per gazdă. Aproape fiecare element conținea un declanșator pentru a-l face similar cu instalațiile reale. În unele cazuri, a existat mai mult de un declanșator. Pentru un nod de rețea au existat 3-000 de declanșatori.
Interval de actualizare a elementului de date − 4-7 secunde. Am reglat încărcarea în sine folosind nu numai 50 de agenți, ci adăugând mai mulți. De asemenea, folosind elemente de date, am ajustat dinamic sarcina și am redus intervalul de actualizare la 4 s.
PostgreSQL. 35 nvps
Prima mea rulare pe acest hardware a fost pe PostgreSQL pur - 35 de mii de valori pe secundă. După cum puteți vedea, inserarea datelor durează fracțiuni de secundă - totul este bun și rapid. Singurul lucru este că un disc SSD de 200 GB se umple rapid.
Acesta este un tablou de bord standard pentru performanța serverului Zabbix.
Primul grafic albastru este numărul de valori pe secundă. Al doilea grafic din dreapta este încărcarea proceselor de construcție. Al treilea este încărcarea proceselor interne de construcție: sincronizare istorică și menajer, care rulează aici de ceva timp.
Al patrulea grafic arată utilizarea HistoryCache. Acesta este un fel de buffer înainte de a fi introdus în baza de date. Al cincilea grafic verde arată utilizarea ValueCache, adică câte accesări ValueCache pentru declanșatoare - aceasta este câteva mii de valori pe secundă.
PostgreSQL. 50 nvps
Apoi am crescut încărcarea la 50 de mii de valori pe secundă pe același hardware.
La încărcarea de la Housekeeper, inserarea a 10 mii de valori a durat 2-3 secunde.
Menajera începe deja să interfereze cu munca.
Cel de-al treilea grafic arată că, în general, sarcina asupra trapperilor și a sincronizatoarelor istorice este încă la 60%. În al patrulea grafic, HistoryCache începe deja să se umple destul de activ în timpul funcționării menajere. Este plin cu 20%, adică aproximativ 0,5 GB.
PostgreSQL. 80 nvps
Apoi am crescut încărcarea la 80 de mii de valori pe secundă. Este vorba de aproximativ 400 de mii de elemente de date și 280 de mii de declanșatori.
Costul de încărcare a treizeci de sincronizatoare de istorie este deja destul de mare.
De asemenea, am crescut diverși parametri: sincronizare istoric, cache.
Pe hardware-ul meu, încărcarea sincronizatoarelor istorice a crescut la maximum. HistoryCache s-a umplut rapid cu date - datele pentru procesare s-au acumulat în buffer.
În tot acest timp am observat cum au fost utilizați procesorul, memoria RAM și alți parametri de sistem și am constatat că utilizarea discului a fost la maxim.
Am realizat utilizarea capabilități maxime de disc pe acest hardware și pe această mașină virtuală. Cu o asemenea intensitate, PostgreSQL a început să șteargă datele destul de activ, iar discul nu a mai avut timp să scrie și să citească.
Al doilea server
Am luat un alt server, care avea deja 48 de procesoare și 128 GB RAM. L-am reglat - l-am setat la 60 de sincronizare istoric și am obținut o performanță acceptabilă.
De fapt, aceasta este deja limita productivității acolo unde trebuie făcut ceva.
TimecaleDB. 80 nvps
Sarcina mea principală este să testez capabilitățile TimescaleDB împotriva încărcării Zabbix. 80 de mii de valori pe secundă este mult, frecvența de colectare a valorilor (cu excepția Yandex, desigur) și o „configurare” destul de mare.
Există o scădere în fiecare grafic - aceasta este tocmai migrarea datelor. După eșecuri în serverul Zabbix, profilul de încărcare al sincronizatorului istoric s-a schimbat mult - a scăzut de trei ori.
TimescaleDB vă permite să inserați date de aproape 3 ori mai rapid și să utilizați mai puțin HistoryCache.
În consecință, veți primi datele în timp util.
TimecaleDB. 120 nvps
Apoi am crescut numărul de elemente de date la 500 de mii. Sarcina principală a fost să testez capabilitățile TimescaleDB - am primit o valoare calculată de 125 de mii de valori pe secundă.
Aceasta este o „configurare” funcțională care poate funcționa mult timp. Dar, deoarece discul meu avea doar 1,5 TB, l-am umplut în câteva zile.
Cel mai important lucru este că în același timp au fost create noi partiții TimescaleDB.
Acest lucru este complet de neobservat pentru performanță. Când partițiile sunt create în MySQL, de exemplu, totul este diferit. Acest lucru se întâmplă de obicei noaptea, deoarece blochează inserarea generală, lucrul cu tabele și poate crea degradarea serviciului. Acesta nu este cazul cu TimescaleDB.
Ca exemplu, voi arăta un grafic din mai multe din comunitate. În imagine, TimescaleDB este activat, datorită căruia sarcina de utilizare a io.weight pe procesor a scăzut. A scăzut și utilizarea elementelor interne ale procesului. Mai mult, aceasta este o mașină virtuală obișnuită pe discuri clătite obișnuite, nu un SSD.
Constatări
TimescaleDB este o soluție bună pentru „configurarea” mică, care afectează performanța discului. Vă va permite să continuați să lucrați bine până când baza de date este migrată la hardware cât mai repede posibil.
TimescaleDB este ușor de configurat, oferă câștiguri de performanță, funcționează bine cu Zabbix și are avantaje față de PostgreSQL.
Dacă utilizați PostgreSQL și nu intenționați să îl schimbați, vă recomand utilizați PostgreSQL cu extensia TimescaleDB împreună cu Zabbix. Această soluție funcționează eficient până la o „configurare” medie.
Când spunem „performanță înaltă” ne referim . Nu va avea mult de așteptat pentru a afla despre tehnologiile și practicile care permit serviciilor să deservească milioane de utilizatori. Listă pentru 7 și 8 noiembrie am compilat deja, dar aici mai multe se pot sugera.
Abonează-te la nostru и , în care dezvăluim caracteristicile conferinței viitoare și aflăm cum să profităm la maximum de ea.
Sursa: www.habr.com