Zabbix je sistem za nadzor. Kao i svaki drugi sistem, suočava se sa tri glavna problema svih sistema za praćenje: prikupljanje i obrada podataka, čuvanje istorije i brisanje.
Faze prijema, obrade i snimanja podataka zahtijevaju vrijeme. Ne mnogo, ali za veliki sistem to može rezultirati velikim kašnjenjima. Problem skladištenja je stvar pristupa podacima. Koriste se za izvještaje, provjere i okidače. Kašnjenja u pristupu podacima također utiču na performanse. Kada baza podataka raste, nebitni podaci moraju biti obrisani. Brisanje je teška operacija koja također troši neke resurse.
Problemi sa odlaganjem prikupljanja i skladištenja u Zabbixu se rješavaju keširanjem: nekoliko tipova keša, keširanje u bazi podataka. Za rješavanje trećeg problema, keširanje nije prikladno, pa je TimescaleDB korišten u Zabbixu. Reći ću o tome Andrey Gushchin - inženjer tehničke podrške . Andrey podržava Zabbix više od 6 godina i direktno je uključen u performanse.
Kako radi TimescaleDB, kakve performanse može dati u poređenju sa običnim PostgreSQL-om? Koju ulogu Zabbix igra u TimescaleDB-u? Kako početi od nule i kako preći sa PostgreSQL-a i koje konfiguracijske performanse su bolje? Sve ovo ispod reza.
Izazovi performansi
Svaki sistem praćenja suočava se sa određenim izazovima performansi. Govoriću o tri od njih: prikupljanju i obradi podataka, skladištenju, čišćenju istorije.
Brzo prikupljanje i obrada podataka. Dobar sistem za praćenje treba brzo primiti sve podatke i obraditi ih prema triger izrazima - prema vlastitim kriterijima. Nakon obrade, sistem također mora brzo pohraniti ove podatke u bazu podataka kako bi ih kasnije koristio.
Pohrana historije. Dobar sistem za praćenje treba da čuva istoriju u bazi podataka i da omogući lak pristup metrikama. Povijest je potrebna za korištenje u izvještajima, grafikonima, okidačima, pragovima i izračunatim stavkama upozorenja.
Brisanje istorije. Ponekad dođe dan kada ne morate da pohranjujete metriku. Zašto su vam potrebni podaci koji su prikupljeni prije 5 godina, mjesec ili dva: neki čvorovi su uklonjeni, neki hostovi ili metrika više nisu potrebni, jer su zastarjeli i više se ne prikupljaju. Dobar sistem za praćenje treba da skladišti istorijske podatke i briše ih s vremena na vreme kako baza podataka ne bi rasla.
Čišćenje zastarjelih podataka je trnovit problem koji ima veliki utjecaj na performanse baze podataka.
Keširanje u Zabbixu
U Zabbixu, prvi i drugi poziv se rješavaju pomoću keširanja. RAM se koristi za prikupljanje i obradu podataka. Za pohranu - povijest u okidačima, grafikonima i izračunatim stavkama. Na strani DB-a postoji nešto keširanja za osnovne odabire, kao što su grafovi.
Keširanje na strani samog Zabbix servera je:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Razmotrite ih detaljnije.
ConfigurationCache
Ovo je glavna predmemorija u kojoj pohranjujemo metrike, hostove, stavke podataka, trigere - sve što je potrebno za prethodnu obradu i prikupljanje podataka.
Sve se to pohranjuje u ConfigurationCache kako ne bi stvarali nepotrebne upite u bazi podataka. Nakon što se server pokrene, ažuriramo ovu keš memoriju, kreiramo i povremeno ažuriramo konfiguracije.
Prikupljanje podataka
Shema je prilično velika, ali glavna stvar u njoj je kolekcionari. To su razni "poleri" - procesi montaže. Oni su odgovorni za različite vrste sklapanja: prikupljaju podatke preko SNMP-a, IPMI-ja i sve to prenose u PreProcessing.
Berači su zaokruženi narandžastom bojom.
Zabbix je izračunao stavke agregacije koje su potrebne za agregiranje provjera. Ako ih imamo, podatke za njih preuzimamo direktno iz ValueCache-a.
Preprocessing HistoryCache
Svi sakupljači koriste ConfigurationCache za primanje poslova. Zatim ih prosljeđuju u prethodnu obradu.
PreProcessing koristi ConfigurationCache da bi dobio korake PreProcessing. Ove podatke obrađuje na različite načine.
Nakon obrade podataka pomoću PreProcessinga, pohranjujemo ih u HistoryCache da bismo ih obradili. Ovo završava prikupljanje podataka i prelazimo na glavni proces u Zabbixu - sinhronizator istorije, jer se radi o monolitnoj arhitekturi.
Napomena: prethodna obrada je prilično teška operacija. Od v 4.2 je premješten na proxy. Ako imate vrlo veliki Zabbix sa velikim brojem stavki i učestalošću prikupljanja, to čini stvari mnogo lakšim.
ValueCache, predmemorija istorije i trendova
Sincer historije je glavni proces koji atomski obrađuje svaki element podataka, odnosno svaku vrijednost.
Sincer historije preuzima vrijednosti iz HistoryCache-a i provjerava konfiguraciju za okidače za proračune. Ako jesu - računa.
Sincer historije kreira događaj, eskalira kako bi kreirao upozorenja ako to zahtijeva konfiguracija i bilježi. Ako postoje okidači za dalju obradu, on pamti ovu vrijednost u ValueCache-u kako ne bi upućivao na tabelu istorije. Ovako se ValueCache puni podacima koji su potrebni za izračunavanje okidača, izračunatih stavki.
Sincer historije zapisuje sve podatke u bazu podataka, a oni zapisuje na disk. Proces obrade se ovdje završava.
DB keširanje
Postoje razne keš memorije na DB strani kada želite da pogledate grafikone ili izveštaje o događajima:
Innodb_buffer_poolna strani MySQL;shared_buffersna strani PostgreSQL;effective_cache_sizena strani Oraclea;shared_poolna strani DB2.
Postoje mnoge druge keš memorije, ali ove su glavne za sve baze podataka. Omogućuju vam da čuvate podatke u RAM-u koji su često potrebni za upite. Za to imaju vlastitu tehnologiju.
Performanse baze podataka su kritične
Zabbix server neprestano prikuplja podatke i zapisuje ih. Kada se ponovo pokrene, takođe čita iz istorije da bi popunio ValueCache. Upotreba skripti i izvještaja Zabbix API, koji je izgrađen na bazi web interfejsa. Zabbix API pristupa bazi podataka i preuzima potrebne podatke za grafikone, izvještaje, liste događaja i nedavne probleme.
Za vizualizaciju - grafana. Ovo je popularno rješenje među našim korisnicima. Ona može direktno slati zahtjeve preko Zabbix API-ja i u bazu podataka, te stvara određenu konkurentnost za dobijanje 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 čišćenje istorije sa Housekeeper-om. Poštuje sve postavke - elementi podataka pokazuju koliko dugo treba pohraniti dinamiku promjena (trendova) u danima.
TrendsCache izračunavamo u hodu. Kada podaci stignu, agregiramo ih za jedan sat i stavljamo u tabele za dinamiku promjena trenda.
Domaćica pokreće i briše informacije iz baze uobičajenim "selektovima". Ovo nije uvijek efikasno, što se može razumjeti iz grafova performansi internih procesa.
Crveni grafikon pokazuje da je sinhronizator istorije stalno zauzet. Narandžasti grafikon na vrhu je Housekeeper, koji stalno radi. Čeka da baza podataka izbriše sve redove koje je specificirala.
Kada treba da onemogućite kućnu pomoćnicu? Na primjer, postoji “ID stavke” i potrebno je da obrišete zadnjih 5 hiljada redova u određenom vremenu. Naravno, to se dešava pomoću indeksa. Ali obično je skup podataka veoma velik, a baza podataka i dalje čita sa diska i stavlja ga u keš memoriju. Ovo je uvijek vrlo skupa operacija za bazu podataka i, ovisno o veličini baze podataka, može dovesti do problema s performansama.
Domaćica je jednostavno onemogućiti. U web sučelju postoji postavka u "Opšta administracija" za Domaćica. Onemogućite interno održavanje za internu istoriju trendova i to više ne kontroliše.
Housekeeper je onemogućen, grafika je izjednačena - koji bi mogli biti problemi u ovom slučaju i šta može pomoći u rješavanju trećeg izazova performansi?
Particioniranje - particioniranje ili particioniranje
Particioniranje se obično konfigurira na drugačiji način na svakoj relacijskoj bazi podataka koju sam naveo. Svaki od njih ima svoju tehnologiju, ali su generalno slični. Kreiranje nove particije često dovodi do određenih problema.
Tipično, particije se konfiguriraju ovisno o "postavci" - količini podataka koja se kreira u jednom danu. Po pravilu, particioniranje se postavlja za jedan dan, to je minimum. Za nove trendove particija — 1 mjesec.
Vrijednosti se mogu promijeniti u slučaju vrlo velike "postavke". Ako je mala "postavka" do 5 nvps (nove vrijednosti u sekundi), prosječna je od 000 do 5, onda je velika iznad 000 nvps. To su velike i vrlo velike instalacije koje zahtijevaju pažljivu konfiguraciju same baze podataka.
Na vrlo velikim instalacijama, jedan dan možda neće biti optimalan. Vidio sam MySQL particije od 40 GB ili više dnevno. Ovo je vrlo velika količina podataka koja može dovesti do problema i treba je smanjiti.
Šta daje Particioniranje?
Pregradni stolovi. Često su to zasebne datoteke na disku. Plan upita odabire jednu particiju optimalnije. Obično se particioniranje koristi po opsegu - to vrijedi i za Zabbix. Tu koristimo "vremensku oznaku" - vrijeme od početka epohe. Imamo redovne brojeve. Postavite početak i kraj dana - ovo je particija.
Brzo uklanjanje - DELETE. Odabrana je jedna datoteka/podtabela, a ne izbor redova za brisanje.
Značajno ubrzava uzorkovanje podataka SELECT - koristi jednu ili više particija, a ne cijelu tablicu. Ako pristupate podacima starim dva dana, brže ih dohvaćate iz baze podataka jer ih morate samo učitati u keš memoriju i vratiti samo jednu datoteku, a ne veliku tabelu.
Često se mnoge baze podataka također ubrzavaju INSERT - umeće u dečiji sto.
TimescaleDB
Za v 4.2 skrenuli smo pažnju na TimescaleDB. Ovo je PostgreSQL ekstenzija sa izvornim interfejsom. Proširenje radi efikasno sa podacima vremenskih serija bez gubljenja prednosti relacionih baza podataka. TimescaleDB se također automatski particionira.
TimescaleDB ima koncept hipertable (hipertabela) koju kreirate. U njemu su komadi - particije. Komadići su automatski upravljani fragmenti hipertabele koji ne utječu na druge fragmente. Svaki dio ima svoj vremenski raspon.
TimescaleDB vs PostgreSQL
TimescaleDB je zaista efikasan. Proizvođači ekstenzije tvrde da koriste ispravniji algoritam za obradu upita, posebno inserts . Kako veličina umetka skupa podataka raste, algoritam održava konstantne performanse.
Nakon 200 miliona redova, PostgreSQL obično počinje mnogo da pada i gubi performanse na 0. TimescaleDB vam omogućava da efikasno ubacite "umetke" sa bilo kojom količinom podataka.
postavljanje
Instalacija TimescaleDB je dovoljno jednostavna za sve pakete. IN sve je detaljno - zavisi od zvaničnih PostgreSQL paketa. TimescaleDB se također može izraditi i kompajlirati ručno.
Za Zabbix bazu podataka jednostavno aktiviramo ekstenziju:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
aktivirate extension i kreirajte ga za Zabbix bazu podataka. Poslednji korak je kreiranje hipertabele.
Migracija tabela istorije 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 - tabela u bazi podatakaZa koji želite da kreirate hipertabelu. Sekunda - polje, prema kojem je potrebno kreirati chunk_time_interval — interval particionih komada koji će se koristiti. U mom slučaju interval je jedan dan - 86.
Treći parametar je migrate_data. Ako je postavljeno true, tada se svi trenutni podaci prenose u prethodno kreirane komade. I sam sam koristio migrate_data. Imao sam oko 1TB što mi je trebalo više od sat vremena. Čak sam u nekim slučajevima, prilikom testiranja, obrisao istorijske podatke tipova znakova, koji su opcioni za pohranu, kako ih ne bih prenosio.
Poslednji korak - UPDATE: u db_extension staviti timescaledbtako da baza podataka shvati da postoji ova ekstenzija. Zabbix ga aktivira i ispravno koristi sintaksu i upite već prema bazi podataka - one karakteristike koje su neophodne za TimescaleDB.
Konfiguracija hardvera
Koristio sam dva servera. Prvo - VMware mašina. Dovoljno je mali: 20 Intel® Xeon® CPU E5-2630 v 4 na 2.20 GHz, 16 GB RAM-a i SSD disk od 200 GB.
Na njega sam instalirao PostgreSQL 10.8 sa Debian OS 10.8-1.pgdg90+1 i xfs sistemom datoteka. Sve sam konfigurirao minimalno da koristim ovu konkretnu bazu podataka, minus ono što će sam Zabbix koristiti.
Na istoj mašini nalazio se Zabbix server, PostgreSQL i agenti za opterećenje. Imao sam 50 aktivnih agenasa koje sam koristio LoadableModuleza vrlo brzo generiranje različitih rezultata: brojeva, nizova. Popunio sam bazu podataka sa dosta podataka.
U početku je konfiguracija sadržana 5 artikala podataka po hostu. Gotovo svaki element je sadržavao okidač da bi izgledao kao prave instalacije. U nekim slučajevima bilo je više od jednog okidača. Jedan mrežni čvor je imao 3-000 okidača.
Interval ažuriranja stavke − 4-7 sekundi. Regulirao sam samo opterećenje korištenjem ne samo 50 agenasa, već dodavanjem više. Također, uz pomoć elemenata podataka, dinamički sam regulisao opterećenje i smanjio interval ažuriranja na 4 s.
PostgreSQL. 35 nvps
Moje prvo pokretanje na ovom hardveru bilo je na čistom PostgreSQL-u - 35 hiljada vrijednosti u sekundi. Kao što vidite, umetanje podataka traje djeliće sekunde - sve je u redu i brzo. Jedina stvar je da se SSD disk od 200 GB brzo puni.
Ovo je standardna kontrolna tabla performansi Zabbix servera.
Prvi plavi grafikon je broj vrijednosti u sekundi. Drugi grafikon sa desne strane je učitavanje procesa izgradnje. Treći je učitavanje internih procesa izgradnje: historijski sincer i Housekeeper, koji ovdje radi već duže vrijeme.
Četvrti grafikon prikazuje upotrebu HistoryCache-a. Ovo je vrsta bafera prije umetanja u bazu podataka. Zeleni peti grafikon prikazuje upotrebu ValueCache-a, odnosno koliko je ValueCache pogodaka za okidače nekoliko hiljada vrijednosti u sekundi.
PostgreSQL. 50 nvps
Zatim sam povećao opterećenje na 50 hiljada vrijednosti u sekundi na istom hardveru.
Prilikom učitavanja iz Housekeeper-a, umetanje 10 hiljada vrijednosti trajalo je 2-3 sekunde.
Domaćica već počinje da smeta.
Treći grafikon pokazuje da je općenito opterećenje trapera i historijskih sincera još uvijek na nivou od 60%. Na četvrtom grafikonu, HistoryCache tokom rada Housekeeper-a već počinje da se puni prilično aktivno. Popunjen je 20% - oko 0,5 GB.
PostgreSQL. 80 nvps
Zatim sam povećao opterećenje na 80 hiljada vrijednosti u sekundi. To je otprilike 400 hiljada elemenata podataka i 280 hiljada okidača.
Umetanje učitavanja od trideset historijskih sincera je već prilično visoko.
Također sam povećao različite parametre: historijske sincere, keš memorije.
Na mom hardveru, učitavanje historijskih sincera se povećalo do maksimuma. HistoryCache se brzo napunio podacima - bafer je akumulirao podatke za obradu.
Sve ovo vrijeme sam gledao kako se koriste procesor, RAM i drugi sistemski parametri i ustanovio da je iskorištenost diska maksimalno.
Iskoristio sam maksimalni kapacitet diska na ovom hardveru i na ovoj virtuelnoj mašini. Sa takvim intenzitetom, PostgreSQL je počeo prilično aktivno da izbacuje podatke, a disk više nije imao vremena za pisanje i čitanje.
Drugi server
Uzeo sam drugi server koji je već imao 48 procesora i 128 GB RAM-a. Podešavao sam ga - postavio 60 historijski sinhronizator i postigao prihvatljive performanse.
Zapravo, ovo je već granica performansi gdje nešto treba učiniti.
timescaledb. 80 nvps
Moj glavni zadatak je da testiram mogućnosti TimescaleDB-a u odnosu na Zabbix opterećenje. 80 hiljada vrijednosti u sekundi je puno, učestalost prikupljanja metrike (osim Yandexa, naravno) i prilično velika "postavka".
Na svakom grafikonu postoji pad - ovo je samo migracija podataka. Nakon kvarova na Zabbix serveru, profil učitavanja historijskog syncera se dosta promijenio - pao je tri puta.
TimescaleDB vam omogućava da ubacite podatke skoro 3 puta brže i koristite manje HistoryCache-a.
U skladu s tim, podatke ćete dobiti na vrijeme.
timescaledb. 120 nvps
Zatim sam povećao broj stavki podataka na 500 hiljada. Glavni zadatak je bio provjeriti mogućnosti TimescaleDB-a - dobio sam izračunatu vrijednost od 125 hiljada vrijednosti u sekundi.
Ovo je funkcionalna "postavka" za koju može potrajati mnogo vremena. Ali pošto je moj disk imao samo 1,5 TB, napunio sam ga za nekoliko dana.
Što je najvažnije, nove TimescaleDB particije su se kreirale u isto vrijeme.
Što se tiče performansi, to je potpuno neprimjetno. Kada se, na primjer, kreiraju particije u MySQL-u, stvari su drugačije. To se obično dešava noću, jer blokira opšte umetanje, manipulaciju tabelama i može dovesti do degradacije usluge. Ovo nije slučaj sa TimescaleDB.
Na primjer, pokazaću jedan grafikon iz skupa u zajednici. Na slici je TimescaleDB omogućen, zahvaljujući čemu je opterećenje na korištenje io.weight na procesoru palo. Smanjena je i upotreba elemenata internih procesa. Štoviše, ovo je obična virtualna mašina na običnim palačinka diskovima, a ne SSD.
nalazi
TimescaleDB je dobro rješenje za male "postavke", koji počivaju na performansama diska. To će vam omogućiti da nastavite s dobrim radom dok se baza podataka brže ne migrira na hardver.
TimescaleDB je jednostavan za postavljanje, 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 sa ekstenzijom TimescaleDB u sprezi sa Zabbixom. Ovo rješenje efikasno radi do srednjeg "podešavanja".
Kažemo "visoke performanse" - mislimo . Neće proći dugo prije nego što se upoznate s tehnologijama i praksama koje omogućavaju uslugama da služe milionima korisnika. Lista za 7. i 8. novembar, već smo sastavili, ali može se predložiti više.
Pretplatite se na naše и , u kojem otkrivamo čipove nadolazeće konferencije i saznajemo kako iz nje izvući maksimum.
izvor: www.habr.com