Zabbix je sustav za praćenje. Kao i svaki drugi sustav, suočava se s tri osnovna problema svih sustava za praćenje: prikupljanje i obrada podataka, pohrana povijesti i njezino čišćenje.
Faze prikupljanja, obrade i zapisivanja podataka oduzimaju vrijeme. Malo, ali za velike sustave to može rezultirati velikim kašnjenjima. Problem pohrane je pitanje pristupa podacima. Oni se koriste za izvještavanje, provjere i okidače. Kašnjenja u pristupu podacima također utječu na performanse. Kada se baze podataka proširuju, zastarjeli podaci moraju se brisati. Brisanje je teška operacija koja također troši dio resursa.
Problemi s kašnjenjem u prikupljanju i pohrani u Zabbixu rješavaju se keširanjem: nekoliko vrsta keša, keširanje u bazi podataka. Za rješavanje trećeg problema, keširanje nije prikladno, stoga je u Zabbixu primijenjen TimescaleDB. O tome će govoriti Andrej Guščin — inženjer tehničke podrške . U podršci Zabbixu Andrej je više od 6 godina i izravno se suočava s performansama.
Kako funkcionira TimescaleDB, kakve performanse može pružiti u usporedbi s običnim PostgreSQL-om? Koju ulogu igra Zabbix za baze podataka TimescaleDB? Kako pokrenuti od nule i kako migrirati s PostgreSQL-a i koja konfiguracija pruža najbolje performanse? O svemu ovome u nastavku.
Izazovi performansi
Svaki sustav za praćenje suočava se s određenim izazovima performansi. Pričat ću o tri od njih: prikupljanje i obrada podataka, pohrana, čišćenje povijesti.
Brzo prikupljanje i obrada podataka. Dobar sustav za praćenje trebao bi brzo primati sve podatke i obrađivati ih prema uvjetima okidača — prema svojim kriterijima. Nakon obrade sustav također treba brzo pohraniti te podatke u bazu podataka kako bi ih kasnije mogao koristiti.
Pohrana povijesti. Dobar sustav za praćenje trebao bi pohranjivati povijest u bazi podataka i omogućiti jednostavan pristup metrikama. Povijest je potrebna kako bi se koristila u izvještajima, grafikonima, okidačima, granicama i izračunatim elementima podataka za obavijest.
Čišćenje povijesti. Ponekad dođe dan kada vam više nisu potrebne metrike. Zašto biste trebali zadržati podatke prikupljene prije 5 godina, mjesec ili dva: neki čvorovi su obrisani, neki poslužitelji ili metrike više nisu potrebni jer su zastarjeli i prestali su se prikupljati. Dobar sustav praćenja trebao bi zadržavati povijesne podatke i s vremena na vrijeme ih brisati kako bi se baza podataka ne bi prekomjerno povećavala.
Čišćenje zastarjela podataka je akutno pitanje koje značajno utječe na performanse baze podataka.
Keširanje u Zabbixu
U Zabbixu su prvi i drugi pozivi riješeni uz pomoć keširanja. Za prikupljanje i obradu podataka koristi se radna memorija. Za pohranu - povijesti u okidačima, grafikonima i izračunatim elementima podataka. Na strani baze podataka postoji određeno keširanje za glavne upite, na primjer, grafikone.
Keširanje na strani Zabbix poslužitelja je:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Pogledajmo ih detaljnije.
ConfigurationCache
To je glavni keš u kojem čuvamo metrike, poslužitelje, elemente podataka, okidače - sve što je potrebno za PreProcessing i prikupljanje podataka.
Sve to se pohranjuje u ConfigurationCache kako ne bismo stvarali suvišne upite u bazi podataka. Nakon pokretanja poslužitelja ažuriramo ovaj keš, kreiramo i povremeno ažuriramo konfiguracije.
Prikupljanje podataka
Shema je prilično velika, ali osnovno u njoj je sakupljači. To su različiti „pollers“ - procesi prikupljanja. Oni su odgovorni za različite vrste prikupljanja: prikupljaju podatke putem SNMP-a, IPMI-a, i prenose ih na PreProcessing.
Sakupljači su označeni narančastom linijom.
U Zabbixu postoje izračunati agregacijski elementi podataka koji su potrebni za agregiranje provjera. Ako ih imamo, uzimamo podatke za njih izravno iz ValueCache.
PreProcessing HistoryCache
Svi sakupljači koriste ConfigurationCache da bi dobili zadatke. Zatim ih prenose na PreProcessing.
PreProcessing koristi ConfigurationCache da bi dobio korake PreProcessing-a. Obraduje te podatke na različite načine.
Nakon obrade podataka uz pomoć PreProcessing-a, pohranjujemo ih u HistoryCache kako bismo ih obradili. Ovdje završava prikupljanje podataka i prelazimo na glavni proces u Zabbixu - history syncer, budući da je to monolitna arhitektura.
Napomena: PreProcessing je prilično zahtjevna operacija. Od verzije 4.2 premještena je na proxy. Ako imate vrlo veliki Zabbix s velikim brojem elemenata podataka i visokom frekvencijom prikupljanja, to značajno olakšava rad.
ValueCache, povijest & trendovi keš
History syncer — je glavni proces koji atomarno obrađuje svaki element podataka, tj. svaku vrijednost.
History syncer uzima vrijednosti iz HistoryCache i provjerava u Configuration postoje li okidači za proračune. Ako postoje — izračunava.
History syncer stvara događaj, eskalaciju, kako bi stvorio obavijesti, ako je to potrebno prema konfiguraciji, i snima. Ako postoje okidači za daljnju obradu, tada tu vrijednost zapamti u ValueCache, kako ne bi pristupao tablici povijesti. Tako se ValueCache puni podacima koji su potrebni za izračunavanje okidača, izračunatih elemenata.
History syncer zapisuje sve podatke u Bazu podataka, a ona — na disk. Proces obrade na tome se završava.
Keširanje u Bazi podataka
Na strani Baze podataka postoje različiti keševi, kada želite gledati grafikone ili izvještaje o događajima:
Innodb_buffer_poolna strani MySQL;shared_buffersna strani PostgreSQL;effective_cache_sizena strani Oracle;shared_poolna strani DB2.
Postoje još mnogi drugi keševi, ali ovo su osnovni za sve Baze podataka. Oni omogućuju da se u radnoj memoriji drže podaci koji su često potrebni za upite. Imaju svoje tehnologije za to.
Performanse Baze podataka su kritično važne
Zabbix poslužitelj neprekidno prikuplja podatke i zapisuje ih. Kada se ponovno pokrene, također čita iz povijesti kako bi napunio ValueCache. Skripte i izvještaje koriste Zabbix API, koji je temeljen na web sučelju. Zabbix API se obraća bazi podataka i dobiva potrebne podatke za grafikone, izvještaje, popise događaja i posljednjih problema.
Za vizualizaciju — Grafana. Među našim korisnicima ovo je popularno rješenje. Ona može izravno slati zahtjeve putem Zabbix API-ja i u Bazu podataka, i stvara određenu konkurentnost za dobivanje podataka. Stoga je potrebna detaljnija i bolja konfiguracija Baze podataka kako bi se osigurala brza isporuka rezultata i testiranja.
Housekeeper
Treći poziv performansi u Zabbix-u — je čišćenje povijesti pomoću Housekeeper-a. On poštuje sve postavke — u elementima podataka je označeno koliko dana pohranjivati dinamiku promjena (trendova).
TrendsCache računamo u letu. Kada podaci stignu, agregiramo ih za jedan sat i zapisujemo u tablice za dinamiku promjena trendova.
Housekeeper se pokreće i uklanja informacije iz baze podataka običnim «select» upitima. To nije uvijek učinkovito, što se može vidjeti na grafikonima performansi unutarnjih procesa.
Crveni grafikon pokazuje da je History syncer neprekidno zauzet. Narandžasti grafikon iznad - to je Housekeeper koji se neprekidno pokreće. Čeka od baze podataka da ukloni sve redove koje je odredio.
Kada bi trebalo isključiti Housekeeper? Na primjer, ako postoje «Item ID» i potrebno je ukloniti posljednjih 5 tisuća redova tokom određenog vremena. Naravno, to se događa preko indeksa. No obično je dataset vrlo velik, i baza podataka ionako čita s diska i prenosi u cache. To je uvijek vrlo skupa operacija za bazu podataka i, ovisno o veličini baze, može dovesti do problema s performansama.
Housekeeper se može jednostavno isključiti. U web sučelju postoji postavka u «Administration general» za Housekeeper. Isključujemo unutarnje housekeeping za unutarnju povijest trendova i on više ne upravlja time.
Housekeeper je isključen, grafikoni su se stabilizirali - koji bi mogli biti problemi u ovom slučaju i što može pomoći u rješavanju trećeg poziva performansi?
Partitioning - sekcioniranje ili partricioniranje
Obično se partricioniranje postavlja na različite načine na svakoj relacijskoj bazi podataka koju sam spomenuo. Svaka ima svoju tehnologiju, ali su slične, u osnovi. Stvaranje nove particije često dovodi do određenih problema.
Obično se particije postavljaju ovisno o «setup» - količini podataka koja se stvara za jedan dan. Općenito, partricioniranje se postavlja na jedan dan, to je minimum. Za trendove nove particije - za 1 mjesec.
Vrijednosti se mogu mijenjati u slučaju vrlo velikog «setup». Ako je mali «setup» - to je do 5.000 nvps (novih vrijednosti u sekundi), srednji - od 5.000 do 25.000, dok je veliki - iznad 25.000 nvps. To su velike i vrlo velike instalacije koje zahtijevaju pažljivo podešavanje same baze podataka.
Na vrlo velikim instalacijama segment od jednog dana možda nije optimalan. Vidio sam na MySQL particije od 40 GB i više za jedan dan. To je vrlo veliki volumen podataka koji može dovesti do problema, i treba ga smanjiti.
Što donosi partricioniranje?
Sekcioniranje tablica. Često su to odvojene datoteke na disku. Plan upita optimizirano bira jednu particiju. Obično se particioniranje koristi prema rasponu — za Zabbix to također vrijedi. Tamo koristimo "timestamp" — vrijeme od početka epohе. Kod nas su to obični brojevi. Postavljate početak i kraj dana — to je particija.
Brzo brisanje — DELETE. Odabire se jedna datoteka/subtablica, a ne izbor redaka za brisanje.
Značajno ubrzava izbor podataka SELECT — koristi jednu ili više particija, a ne cijelu tablicu. Ako tražite podatke starije od dva dana, oni se brže odabiru iz Baze podataka jer je potrebno učitati u cache i izdati samo jednu datoteku, a ne veliku tablicu.
Često mnoge BD također ubrzava UBACI — umetanja u child-tablicu.
TimescaleDB
Za v 4.2 obratili smo pozornost na TimescaleDB. To je proširenje za PostgreSQL s nativnim sučeljem. Proširenje učinkovito radi s podacima vremenskih serija, a da pritom ne gubi prednosti relacijskih BD. TimescaleDB također automatski particionira.
U TimescaleDB postoji pojam hiperatabla (hypertable), koju kreirate. U njoj se nalaze chunkovi — particije. Chunkovi su automatski upravljani segmenti hiperatabla, koji ne utječu na druge segmente. Za svaki chunk postoji svoj vremenski raspon.
TimescaleDB vs PostgreSQL
TimescaleDB stvarno radi učinkovito. Proizvođači proširenja tvrde da koriste ispravniji algoritam obrade upita, posebice, inserts. Kada veličine dataset-u umetanja rastu, algoritam održava stalnu učinkovitost.
Nakon 200 milijuna redaka PostgreSQL obično počinje znatno usporavati i gubi performanse do 0. TimescaleDB omogućuje učinkovito umetanje "inserts" bez obzira na količinu podataka.
Instalacija
Instalacija TimescaleDB je prilično jednostavna za bilo koje pakete. U sve je detaljno opisano — ovisi o službenim paketima PostgreSQL. TimescaleDB se također može izgraditi i kompajlirati ručno.
Za Zabbix BD jednostavno aktiviramo proširenje:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix Aktivirate proširenje i kreirate ga za BD Zabbix. Posljednji korak — kreiranje hiperatabla.
Migracija tablica povijesti na TimescaleDB
Za to postoji posebna funkcija create_hypertable:
ODABERITE create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
ODABERITE create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
ODABERITE create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
ODABERITE create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
ODABERITE create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
ODABERITE create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
ODABERITE create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
AZURIRAJ config SET db_extension='timescaledb', hk_history_global=1, hk_trends_global=1 Funkcija ima tri parametra. Prvi — tablica u bazi podataka, za koju je potrebno stvoriti hipertablicu. Drugi — polje, po kojem se mora stvoriti chunk_time_interval — interval chunkova particija koje treba koristiti. U mom slučaju interval iznosi jedan dan — 86 400.
Treći parametar — migrirati_podatke. Ako se postavi true, svi trenutni podaci se premještaju u unaprijed stvorene chunkove. Ja sam koristio migrirati_podatke. Imao sam oko 1 TB, što je trajalo više od sat vremena. Čak sam u nekim slučajevima prilikom testiranja brisao nepotrebne povijesne podatke simboličnih tipova da ih ne bih premještao.
Zadnji korak — AZURIRAJ: u db_extension postavljamo timescaledb, kako bi baza podataka razumjela da postoji ovo proširenje. Zabbix ga aktivira i ispravno koristi sintaksu i upite za bazu podataka — one funkcionalnosti koje su potrebne za TimescaleDB.
Konfiguracija hardvera
Koristio sam dva poslužitelja. Prvi — VMware mašina. Ona je dovoljno mala: 20 procesora Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 GB radne memorije i SSD disk od 200 GB.
Na njoj sam instalirao PostgreSQL 10.8 s OS Debian 10.8-1.pgdg90+1 i datotečnim sustavom xfs. Sve je minimalno podešeno da koristi baš ovu bazu podataka, osim onoga što će koristiti sam Zabbix.
Na ovoj mašini je bio Zabbix-poslužitelj, PostgreSQL i agents for load testing. Imao sam 50 aktivnih agenata koji su koristili LoadableModule, kako bi vrlo brzo generirali različite rezultate: brojeve, nizove. Punio sam bazu velikom količinom podataka.
Izvorna konfiguracija je sadržavala 5 000 elemenata podataka za svaki host. Skoro svaki element je imao okidač kako bi to izgledalo slično stvarnim instalacijama. U nekim slučajevima je bilo više od jednog okidača. Na jedan čvor mreže dolazilo je 3 000-7 000 okidača.
Interval ažuriranja elemenata podataka — 4-7 sekundiOpterećenje sam regulirao tako da nisam koristio samo 50 agenata, već sam ih dodavao i više. Također, pomoću dinamičkih podataka regulirao sam opterećenje i smanjio interval ažuriranja na 4 sekunde.
PostgreSQL. 35 000 nvps
Prvo pokretanje na ovom hardveru imao sam s čistim PostgreSQL — 35 tisuća vrijednosti u sekundi. Kao što se može vidjeti, umetanje podataka traje djelić sekunde — sve je dobro i brzo. Jedina stvar je što se SSD disk od 200 GB brzo popunio.
Ovo je standardna Zabbix dashboard performansi — servera.
Prva plava grafikon — broj vrijednosti u sekundi. Drugi grafikon s desne strane — opterećenje procesa sakupljanja. Treći — opterećenje unutarnjih procesa sakupljanja: history syncers i Housekeeper, koji je ovdje radio dovoljno dugo.
Četvrti grafikon prikazuje korištenje HistoryCache. To je svojevrsni buffer prije umetanja u bazu podataka. Zeleni peti grafikon prikazuje korištenje ValueCache, odnosno koliko hitova ValueCache za okidače — to su tisuće vrijednosti u sekundi.
PostgreSQL. 50 000 nvps
Nakon toga, povećao sam opterećenje do 50 tisuća vrijednosti u sekundi na ovom istom hardveru.
Prilikom učitavanja s Housekeeper, umetanje 10 tisuća vrijednosti zapisano je u 2-3 sekunde.
Housekeeper već počinje ometati rad.
Na trećem grafikonu se može vidjeti da je, u cjelini, opterećenje trapera i history syncersa još uvijek na razini od 60%. Na četvrtom grafikonu, HistoryCache tijekom rada Housekeepera počinje se već aktivno puniti. Napunio se za 20% — što je otprilike 0,5 GB.
PostgreSQL. 80 000 nvps
Nakon toga, povećao sam opterećenje do 80 tisuća vrijednosti u sekundi. To je otprilike 400 tisuća elemenata podataka i 280 tisuća okidača.
Umetanje uz opterećenje trideset history syncersa već je dovoljno visoko.
Također sam povećavao različite parametre: history syncers, cache.
Na mom hardveru opterećenje history syncersa povećavalo se do maksimuma. HistoryCache se brzo ispunjavao podacima — u bufferu su se nakupili podaci za obradu.
Durante cijelo to vreme, pratio sam kako se koriste procesor, radna memorija i drugi sustavni parametri, i otkrio da je iskorištenost diskova bila maksimalna.
Postigao sam korištenje maksimalnih mogućnosti diska na ovom hardveru i na ovoj virtualnoj mašini. Pri ovoj intenzivnoj upotrebi, PostgreSQL je počeo aktivno odbacivati podatke i disk više nije mogao raditi na zapisivanje i čitanje.
Drugi server
Uzeo sam drugi server koji je već imao 48 procesora i 128 GB radne memorije. Modificirao sam ga — instalirao 60 history syncer i postigao zadovoljavajuću brzinu.
U suštini, ovo je već granica performansi na kojoj je potrebno poduzeti neke korake.
TimescaleDB. 80 000 nvps
Moj glavni zadatak je bio provjeriti mogućnosti TimescaleDB pod opterećenjem Zabbixa. 80 tisuća vrijednosti u sekundi — to je mnogo, učestalost prikupljanja metrika (osim Yandexa, naravno) i prilično veliki 'setup'.
Na svakom grafikonu dolazi do pada — to je upravo migracija podataka. Nakon padova na Zabbix serveru, profil opterećenja history syncer se vrlo jako promijenio — pao je tri puta.
TimescaleDB omogućava umetanje podataka gotovo tri puta brže i korištenje manje HistoryCache.
Prema tome, vaši podaci će biti isporučeni na vrijeme.
TimescaleDB. 120 000 nvps
Zatim sam povećao broj elemenata podataka na 500 tisuća. Glavni zadatak bio je provjeriti mogućnosti TimescaleDB — dobio sam procijenjenu vrijednost od 125 tisuća vrijednosti u sekundi.
To je radni 'setup' koji može dugo raditi. Međutim, jer je moj disk imao samo 1,5 TB, napunio sam ga za nekoliko dana.
Najvažnije je da su u isto vrijeme stvarane nove particije TimescaleDB.
Za performanse to je potpuno neprimjetno. Kada se stvaraju particije u MySQL-u, na primjer, sve je drugačije. Obično se to događa noću, jer blokira opće umetanje, rad s tablicama i može uzrokovati degradaciju usluge. U slučaju TimescaleDB to nije slučaj.
Za primjer, pokazat ću jedan grafikon iz mnogih u zajednici. Na slici je uključen TimescaleDB, što je dovelo do smanjenja opterećenja po korištenju io.weight na procesoru. Korištenje elemenata unutarnjih procesa također se smanjilo. Ipak, ovo je obična virtualka na običnim diskovima, a ne SSD.
Zaključci
TimescaleDB je dobro rješenje za male 'setup'., koji se suočavaju s performansama diska. Omogućit će dobar rad prije migracije Baze podataka na brže hardvere.
TimescaleDB je jednostavan za postavljanje, pruža porast performansi, dobro radi s Zabbixom i ima prednosti u odnosu na PostgreSQL..
Ako koristite PostgreSQL i ne planirate ga mijenjati, preporučujem koristiti PostgreSQL s ekstenzijom TimescaleDB u kombinaciji sa Zabbixom.Ovo rješenje učinkovito radi za srednje 'setup'.
Kada kažemo 'visoke performanse' — podrazumijevamo . Čekajte da se upoznate s tehnologijama i praksama koje omogućuju uslugama da opslužuju milijune korisnika, neće dugo trajati. Popis za 7. i 8. studenog već smo sastavili, a to još možemo predložiti.
Pratite našu i , u kojima otkrivamo tajne nadolazeće konferencije i saznajte kako izvući maksimum korist.
Izvor: habr.com
