Zabbix je sustav za nadzor. Kao i svaki drugi sustav, suočava se s tri glavna problema svih sustava za praćenje: prikupljanje i obrada podataka, pohranjivanje povijesti i njezino čišćenje.
Faze primanja, obrade i snimanja podataka zahtijevaju vrijeme. Nije puno, ali za veliki sustav to može rezultirati velikim kašnjenjima. Problem pohrane je problem pristupa podacima. Koriste se za izvješća, provjere i okidače. Latencije u pristupu podacima također utječu na performanse. Kada baze podataka rastu, nevažni podaci moraju se brisati. Uklanjanje je teška operacija koja također troši neke resurse.
Problemi kašnjenja tijekom prikupljanja i pohranjivanja u Zabbixu rješavaju se predmemoriranjem: nekoliko vrsta predmemorija, predmemoriranje u bazi podataka. Za rješavanje trećeg problema, predmemoriranje nije prikladno, pa je Zabbix koristio TimescaleDB. On će vam reći o tome Andrej Guščin - inženjer tehničke podrške . Andrey podržava Zabbix više od 6 godina i ima izravno iskustvo s izvedbom.
Kako TimescaleDB radi, kakve performanse može dati u usporedbi s običnim PostgreSQL-om? Kakvu ulogu igra Zabbix za bazu podataka TimescaleDB? Kako krenuti od nule i kako migrirati s PostgreSQL-a i koja konfiguracija ima bolje performanse? O svemu ovome pod rezom.
Izazovi produktivnosti
Svaki nadzorni sustav suočava se sa specifičnim izazovima performansi. Govorit ću o tri od njih: prikupljanje i obrada podataka, pohranjivanje i brisanje povijesti.
Brzo prikupljanje i obrada podataka. Dobar nadzorni sustav trebao bi brzo primati sve podatke i obrađivati ih prema trigger izrazima – prema svojim kriterijima. Nakon obrade, sustav također mora brzo spremiti te podatke u bazu podataka za kasniju upotrebu.
Pohrana povijesti. Dobar sustav praćenja trebao bi pohraniti povijest u bazu podataka i omogućiti jednostavan pristup metrici. Povijest je potrebna za korištenje u izvješćima, grafikonima, okidačima, pragovima i izračunatim stavkama podataka upozorenja.
Brisanje povijesti. Ponekad dođe dan kada ne trebate pohranjivati mjerne podatke. Zašto su vam potrebni podaci koji su prikupljeni prije 5 godina, mjesec ili dva: neki čvorovi su izbrisani, neki hostovi ili metrike više nisu potrebni jer su zastarjeli i više se ne prikupljaju. Dobar sustav praćenja trebao bi pohranjivati povijesne podatke i brisati ih s vremena na vrijeme kako se baza podataka ne bi povećavala.
Čišćenje zastarjelih podataka kritičan je problem koji uvelike utječe na performanse baze podataka.
Predmemoriranje u Zabbixu
U Zabbixu, prvi i drugi poziv se rješavaju korištenjem predmemoriranja. RAM se koristi za prikupljanje i obradu podataka. Za pohranu - povijest u okidačima, grafikonima i izračunatim elementima podataka. Na strani baze podataka postoji nešto predmemoriranja za osnovne odabire, na primjer, grafikone.
Predmemoriranje na strani samog Zabbix poslužitelja je:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Razmotrite ih detaljnije.
ConfigurationCache
Ovo je glavna predmemorija u koju pohranjujemo metrike, hostove, podatkovne stavke, okidače - sve što nam je potrebno za pretprocesiranje i prikupljanje podataka.
Sve se to pohranjuje u ConfigurationCache kako se ne bi stvarali nepotrebni upiti u bazi podataka. Nakon što se poslužitelj pokrene, ažuriramo ovu predmemoriju, stvaramo i povremeno ažuriramo konfiguracije.
Prikupljanje podataka
Dijagram je prilično velik, ali glavna stvar u njemu jest kolekcionari. To su razni “polleri” - procesi sklapanja. Oni su odgovorni za različite vrste sklopova: prikupljaju podatke putem SNMP-a, IPMI-ja i sve to prenose u PreProcessing.
Kolektori su označeni narančastom bojom.
Zabbix je izračunao stavke agregacije koje su potrebne za agregiranje provjera. Ako ih imamo, podatke za njih dohvaćamo izravno iz ValueCache-a.
Pretprocessing HistoryCache
Svi sakupljači koriste ConfigurationCache za primanje poslova. Zatim ih prenose u predobradu.
Predobrada koristi ConfigurationCache za primanje koraka predobrade. Te podatke obrađuje na različite načine.
Nakon obrade podataka pomoću PreProcessinga, spremamo ih u HistoryCache za obradu. Ovo završava prikupljanje podataka i prelazimo na glavni proces u Zabbixu - povijest syncer, budući da se radi o monolitnoj arhitekturi.
Napomena: Predobrada je prilično teška operacija. S v. 4.2 premješten je na proxy. Ako imate jako veliki Zabbix s velikim brojem podatkovnih elemenata i učestalošću prikupljanja, onda to znatno olakšava rad.
ValueCache, predmemorija povijesti i trendova
Povijest syncer je glavni proces koji atomski obrađuje svaki element podataka, odnosno svaku vrijednost.
Sinkronizator povijesti preuzima vrijednosti iz HistoryCache-a i provjerava prisutnost okidača za izračune u konfiguraciji. Ako postoje, izračunava.
Sinkronizator povijesti stvara događaj, eskalaciju za stvaranje upozorenja ako to zahtijeva konfiguracija i zapise. Ako postoje okidači za naknadnu obradu, tada pohranjuje ovu vrijednost u ValueCache kako ne bi pristupio tablici povijesti. Ovako se ValueCache puni podacima koji su potrebni za izračunavanje okidača i izračunatih elemenata.
Povijest sinkronizira sve podatke u bazu podataka, a ona na disk. Proces obrade ovdje završava.
Predmemoriranje u bazi podataka
Na strani baze podataka postoje različiti predmemorije kada želite vidjeti grafikone ili izvješća o događajima:
Innodb_buffer_poolna strani MySQL;shared_buffersna strani PostgreSQL;effective_cache_sizena strani Oraclea;shared_poolna strani DB2.
Postoji mnogo drugih predmemorija, ali ove su glavne za sve baze podataka. Omogućuju pohranu podataka u RAM koji su često potrebni za upite. Za to imaju vlastite tehnologije.
Performanse baze podataka su kritične
Zabbix poslužitelj neprestano prikuplja podatke i zapisuje ih. Kada se ponovno pokrene, također čita iz povijesti kako bi ispunio ValueCache. Koristi skripte i izvješća Zabbix API, koji je izgrađen na web sučelju. Zabbix API pristupa bazi podataka i dohvaća potrebne podatke za grafikone, izvješća, popise događaja i najnovije probleme.
Za vizualizaciju - grafana. Ovo je popularno rješenje među našim korisnicima. Može izravno slati zahtjeve kroz Zabbix API i u bazu podataka te stvara određenu konkurenciju za primanje podataka. Stoga je potrebno finije i bolje podešavanje baze podataka kako bi se uskladila brza isporuka rezultata i testiranje.
Domaćin
Treći izazov performansi u Zabbixu je brisanje povijesti pomoću Housekeepera. Prati sve postavke - podatkovni elementi pokazuju koliko dugo treba pohraniti dinamiku promjena (trendove) u danima.
Izračunavamo TrendsCache u hodu. Kada podaci stignu, agregiramo ih sat vremena i bilježimo u tablice za dinamiku promjene trenda.
Housekeeper pokreće i briše podatke iz baze podataka koristeći uobičajene "selecte". To nije uvijek učinkovito, što se može vidjeti iz grafikona performansi internih procesa.
Crveni grafikon pokazuje da je sinkronizator povijesti stalno zauzet. Narančasti grafikon na vrhu je Housekeeper, koji stalno radi. Čeka da baza podataka izbriše sve retke koje je naveo.
Kada biste trebali onemogućiti Housekeeper? Na primjer, postoji “Item ID” i trebate izbrisati zadnjih 5 tisuća redaka unutar određenog vremena. Naravno, to se događa prema indeksu. Ali obično je skup podataka vrlo velik, a baza podataka i dalje čita s diska i stavlja ga u predmemoriju. Ovo je uvijek vrlo skupa operacija za bazu podataka i, ovisno o veličini baze podataka, može dovesti do problema s izvedbom.
Domaćicu je lako onemogućiti. U web sučelju postoji postavka u “Općoj administraciji” za Housekeeper. Onemogućujemo interno održavanje za internu povijest trendova i ono više ne upravlja njime.
Housekeeper je isključen, grafikoni su izravnani - koji bi problemi mogli biti u ovom slučaju i što bi moglo pomoći u rješavanju trećeg izazova performansi?
Pregrađivanje – pregrađivanje ili pregrađivanje
Tipično, particioniranje je konfigurirano na drugačiji način za svaku relacijsku bazu podataka koju sam naveo. Svaki ima svoju tehnologiju, ali su općenito slični. Stvaranje nove particije često dovodi do određenih problema.
Tipično, particije se konfiguriraju ovisno o "postavci" - količini podataka koja se stvori u jednom danu. U pravilu, Particioniranje se izdaje u jednom danu, to je minimum. Za trendove nove serije - 1 mjesec.
Vrijednosti se mogu promijeniti ako je "postavka" vrlo velika. Ako je mali “setup” do 5 nvps (nove vrijednosti u sekundi), srednji je od 000 do 5, a veliki je iznad 000 nvps. To su velike i vrlo velike instalacije koje zahtijevaju pažljivo konfiguriranje baze podataka.
Na vrlo velikim instalacijama, razdoblje od jednog dana možda neće biti optimalno. Vidio sam MySQL particije od 40 GB ili više dnevno. To je vrlo velika količina podataka koja može uzrokovati probleme i treba je smanjiti.
Što daje particioniranje?
Pregradni stolovi. Često su to zasebne datoteke na disku. Plan upita odabire jednu particiju optimalnije. Obično se particioniranje koristi prema rasponu - ovo također vrijedi za Zabbix. Tamo koristimo "vremenski žig" - vrijeme od početka ere. To su za nas obične brojke. Vi postavljate početak i kraj dana - ovo je podjela.
Brzo uklanjanje - DELETE. Odabrana je jedna datoteka/podtablica, umjesto odabira redaka za brisanje.
Značajno ubrzava dohvaćanje podataka SELECT - koristi jednu ili više particija, umjesto cijele tablice. Ako pristupate podacima koji su stari dva dana, oni se brže dohvaćaju iz baze podataka jer trebate učitati samo jednu datoteku u predmemoriju i vratiti je, a ne veliku tablicu.
Često su mnoge baze podataka također ubrzane INSERT — umetanja u podređenu tablicu.
Vremenska skalaDB
Za verziju 4.2 obratili smo pažnju na TimescaleDB. Ovo je proširenje za PostgreSQL s izvornim sučeljem. Proširenje učinkovito radi s vremenskim serijama podataka, bez gubitka prednosti relacijskih baza podataka. TimescaleDB također se automatski particionira.
TimescaleDB ima koncept hipertablica (hipertablica) koju stvarate. Sadrži komadići - pregrade. Dijelovi su automatski upravljani fragmenti hipertablice koji ne utječu na druge fragmente. Svaki dio ima svoj vremenski raspon.
TimescaleDB protiv PostgreSQL
TimescaleDB radi stvarno učinkovito. Proizvođači proširenja tvrde da koriste ispravniji algoritam za obradu upita, posebno inserts . Kako veličina umetnutog skupa podataka raste, algoritam održava konstantnu izvedbu.
Nakon 200 milijuna redaka, PostgreSQL obično počinje značajno padati i gubi performanse na 0. TimescaleDB vam omogućuje da učinkovito umetnete "umetke" za bilo koju količinu podataka.
Instalacija
Instalacija TimescaleDB-a prilično je jednostavna za bilo koji paket. U sve je detaljno opisano - ovisi o službenim PostgreSQL paketima. TimescaleDB također se može izgraditi i kompajlirati ručno.
Za Zabbix bazu podataka jednostavno aktiviramo ekstenziju:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Vi aktivirate extension i kreirajte ga za Zabbix bazu podataka. Posljednji korak je stvaranje hipertablice.
Premještanje tablica povijesti u TimescaleDB
Za to postoji posebna funkcija 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
Funkcija ima tri parametra. Prvo - tablica u bazi podataka, za što trebate izraditi hipertablicu. drugo - polje, prema kojem trebate stvoriti chunk_time_interval — interval particijskih dijelova koji će se koristiti. Kod mene je interval jedan dan - 86.
Treći parametar - migrate_data. Ako postavite true, tada se svi trenutni podaci prenose u unaprijed stvorene dijelove. I sam sam ga koristio migrate_data. Imao sam oko 1 TB, što je trajalo više od sat vremena. Čak sam u nekim slučajevima tijekom testiranja izbrisao povijesne podatke tipova znakova koji nisu bili potrebni za pohranu, kako ih ne bih prenio.
Posljednji korak - UPDATE: v db_extension staviti timescaledbtako da baza podataka razumije da ovo proširenje postoji. Zabbix ga aktivira i ispravno koristi sintaksu i upite prema bazi podataka - one značajke koje su neophodne za TimescaleDB.
Konfiguracija hardvera
Koristio sam dva servera. Prvo - VMware stroj. Prilično je malen: 20 procesora Intel® Xeon® CPU E5-2630 v 4 @ 2.20 GHz, 16 GB RAM-a i SSD od 200 GB.
Instalirao sam PostgreSQL 10.8 na njega s Debian 10.8-1.pgdg90+1 OS i xfs datotečnim sustavom. Konfigurirao sam sve minimalno za korištenje ove određene baze podataka, minus ono što će sam Zabbix koristiti.
Na istom stroju nalazio se Zabbix poslužitelj, PostgreSQL i agenti opterećenja. Imao sam 50 aktivnih tvari koje sam koristio LoadableModuleza vrlo brzo generiranje različitih rezultata: brojeva, nizova. Napunio sam bazu s puno podataka.
U početku je konfiguracija sadržavala 5 elemenata podataka po hostu. Gotovo svaki element sadržavao je okidač kako bi bio sličan pravim instalacijama. U nekim slučajevima bilo je više od jednog okidača. Za jedan mrežni čvor bilo je 3-000 okidača.
Interval ažuriranja podatkovne stavke − 4-7 sekundi. Samo opterećenje sam regulirao tako što sam koristio ne samo 50 sredstava, već sam ih dodavao još. Također, koristeći podatkovne elemente, dinamički sam prilagodio opterećenje i smanjio interval ažuriranja na 4 s.
PostgreSQL. 35 000 nvps
Moje prvo pokretanje na ovom hardveru bilo je na čistom PostgreSQL-u - 35 tisuća vrijednosti u sekundi. Kao što vidite, umetanje podataka traje djelić sekunde - sve je dobro i brzo. Jedino što se SSD disk od 200 GB brzo puni.
Ovo je standardna nadzorna ploča Zabbix poslužitelja.
Prvi plavi grafikon je broj vrijednosti u sekundi. Drugi grafikon s desne strane je učitavanje procesa izgradnje. Treći je učitavanje internih procesa izgradnje: history syncers i Housekeeper, koji se ovdje izvodi već neko vrijeme.
Četvrti grafikon prikazuje korištenje HistoryCachea. Ovo je neka vrsta međuspremnika prije umetanja u bazu podataka. Zeleni peti grafikon prikazuje upotrebu ValueCachea, odnosno koliko ValueCache pogodaka za okidače - to je nekoliko tisuća vrijednosti u sekundi.
PostgreSQL. 50 000 nvps
Zatim sam povećao opterećenje na 50 tisuća vrijednosti u sekundi na istom hardveru.
Prilikom učitavanja iz Housekeepera, umetanje 10 tisuća vrijednosti trajalo je 2-3 sekunde.
Domaćica se već počela miješati u posao.
Treći grafikon pokazuje da je općenito opterećenje trapera i sinkronera povijesti još uvijek na 60%. Na četvrtom grafikonu, HistoryCache se već počinje prilično aktivno puniti tijekom rada Housekeeper-a. Popunjen je 20%, što je oko 0,5 GB.
PostgreSQL. 80 000 nvps
Zatim sam povećao opterećenje na 80 tisuća vrijednosti u sekundi. To je otprilike 400 tisuća podatkovnih elemenata i 280 tisuća okidača.
Trošak učitavanja trideset sinkronera povijesti već je prilično visok.
Također sam povećao razne parametre: sinkronizere povijesti, predmemorije.
Na mom hardveru učitavanje sinkrona povijesti se povećalo do maksimuma. HistoryCache se brzo napunio podacima - podaci za obradu su se nakupili u međuspremniku.
Cijelo to vrijeme promatrao sam kako se koriste procesor, RAM i ostali parametri sustava i ustanovio da je iskorištenost diska maksimalna.
Postigao sam korištenje maksimalne mogućnosti diska na ovom hardveru i na ovom virtualnom stroju. S takvim intenzitetom, PostgreSQL je počeo prilično aktivno ispirati podatke, a disk više nije imao vremena za pisanje i čitanje.
Drugi poslužitelj
Uzeo sam drugi server, koji je već imao 48 procesora i 128 GB RAM-a. Ugodio sam ga - postavio na 60 history syncer i postigao prihvatljive performanse.
Zapravo, to je već granica produktivnosti na kojoj treba nešto raditi.
TimescaleDB. 80 000 nvps
Moj glavni zadatak je testirati mogućnosti TimescaleDB u odnosu na Zabbix opterećenje. 80 tisuća vrijednosti u sekundi je puno, učestalost prikupljanja metrika (osim za Yandex, naravno) i prilično velika "postavka".
U svakom grafikonu postoji pad - to je upravo migracija podataka. Nakon kvarova na Zabbix poslužitelju, profil učitavanja syncera povijesti se jako promijenio - pao je tri puta.
TimescaleDB omogućuje umetanje podataka gotovo 3 puta brže i korištenje manje HistoryCachea.
Sukladno tome, podatke ćete dobiti na vrijeme.
TimescaleDB. 120 000 nvps
Zatim sam povećao broj podatkovnih elemenata na 500 tisuća.Glavni zadatak bio je testirati mogućnosti TimescaleDB-a - dobio sam izračunatu vrijednost od 125 tisuća vrijednosti u sekundi.
Ovo je radna "postavka" koja može raditi dugo vremena. Ali pošto je moj disk bio samo 1,5 TB, napunio sam ga za par dana.
Najvažnije je da su u isto vrijeme stvorene nove TimescaleDB particije.
To je potpuno neprimjetno za performanse. Kada se particije kreiraju u MySQL-u, na primjer, sve je drugačije. To se obično događa noću jer blokira opće umetanje, rad s tablicama i može uzrokovati degradaciju usluge. To nije slučaj s TimescaleDB-om.
Kao primjer, pokazat ću jedan grafikon od mnogih u zajednici. Na slici je uključen TimescaleDB zahvaljujući čemu je palo opterećenje procesora korištenjem io.weight. Također se smanjila upotreba internih procesnih elemenata. Štoviše, ovo je obični virtualni stroj na običnim palačinka diskovima, a ne SSD.
Zaključci
TimescaleDB je dobro rješenje za male "postavke", koji utječu na performanse diska. To će vam omogućiti da nastavite s dobrim radom dok se baza podataka ne preseli na hardver što je brže moguće.
TimescaleDB se lako konfigurira, daje povećanje performansi, dobro radi sa Zabbixom i ima prednosti u odnosu na PostgreSQL.
Ako koristite PostgreSQL i ne planirate ga mijenjati, preporučujem koristite PostgreSQL s ekstenzijom TimescaleDB u kombinaciji sa Zabbixom. Ovo rješenje učinkovito radi do srednjeg "postavljanja".
Kad kažemo "visoka izvedba", mislimo . Nećete morati dugo čekati da naučite o tehnologijama i praksama koje omogućuju uslugama da služe milijunima korisnika. Popis za 7. i 8. studenog smo već sastavili, ali ovdje više se može predložiti.
Pretplatite se na naše и , u kojem otkrivamo značajke nadolazeće konferencije, te saznajemo kako iz nje izvući maksimum.
Izvor: www.habr.com