Zabbix yra stebėjimo sistema. Kaip ir bet kuri kita sistema, ji susiduria su trimis pagrindinėmis visų stebėjimo sistemų problemomis: duomenų rinkimu ir apdorojimu, istorijos saugojimu ir jos valymu.
Duomenų gavimo, apdorojimo ir įrašymo etapai užtrunka. Nedaug, bet didelėje sistemoje tai gali sukelti didelių vėlavimų. Saugojimo problema yra duomenų prieigos problema. Jie naudojami ataskaitoms, patikrinimams ir paleidimams. Prieigos prie duomenų delsos taip pat turi įtakos našumui. Kai duomenų bazės auga, nereikšmingi duomenys turi būti ištrinti. Pašalinimas yra sudėtinga operacija, kuri taip pat eikvoja tam tikrus išteklius.
Surinkimo ir saugojimo vėlavimų problemos Zabbix sprendžiamos talpyklomis: kelių tipų talpyklos, talpyklos talpinimas duomenų bazėje. Trečiajai problemai išspręsti netinka talpyklos kaupimas, todėl Zabbix naudojo TimescaleDB. Jis tau apie tai papasakos Andrejus Guščinas - techninės pagalbos inžinierius . Andrey'us palaiko Zabbix daugiau nei 6 metus ir turi tiesioginės veiklos patirties.
Kaip veikia TimescaleDB, kokį našumą jis gali suteikti, palyginti su įprastu PostgreSQL? Kokį vaidmenį „Zabbix“ atlieka TimescaleDB duomenų bazėje? Kaip pradėti nuo nulio ir kaip pereiti iš PostgreSQL ir kuri konfigūracija pasižymi geresniu našumu? Apie visa tai po pjūviu.
Produktyvumo iššūkiai
Kiekviena stebėjimo sistema susiduria su specifiniais veiklos iššūkiais. Pakalbėsiu apie tris iš jų: duomenų rinkimą ir apdorojimą, saugojimą ir istorijos išvalymą.
Greitas duomenų rinkimas ir apdorojimas. Gera stebėjimo sistema turėtų greitai gauti visus duomenis ir apdoroti juos pagal trigerines išraiškas – pagal savo kriterijus. Po apdorojimo sistema taip pat turi greitai išsaugoti šiuos duomenis duomenų bazėje, kad būtų galima naudoti vėliau.
Istorijos saugykla. Gera stebėjimo sistema turėtų saugoti istoriją duomenų bazėje ir suteikti lengvą prieigą prie metrikų. Istoriją reikia naudoti ataskaitose, diagramose, aktyvikliuose, slenksčiuose ir apskaičiuotuose įspėjimų duomenų elementuose.
Istorijos išvalymas. Kartais ateina diena, kai nereikia saugoti metrikos. Kam reikalingi duomenys, kurie buvo surinkti prieš 5 metus, mėnesį ar du: kai kurie mazgai buvo ištrinti, kai kurie prieglobos ar metrikos nebereikalingi, nes jie pasenę ir neberenkami. Gera stebėjimo sistema turėtų saugoti istorinius duomenis ir karts nuo karto juos ištrinti, kad duomenų bazė neaugtų.
Pasenusių duomenų išvalymas yra labai svarbi problema, kuri labai veikia duomenų bazės našumą.
Talpykla „Zabbix“.
„Zabbix“ pirmasis ir antrasis skambučiai išsprendžiami naudojant talpyklą. RAM naudojama duomenims rinkti ir apdoroti. Saugojimui – istorija trigeriuose, grafikuose ir apskaičiuotuose duomenų elementuose. Duomenų bazės pusėje yra keletas pagrindinių pasirinkimų, pavyzdžiui, grafikų, talpyklos.
Talpyklos kaupimas paties „Zabbix“ serverio pusėje yra:
- ConfigurationCache;
- „ValueCache“;
- HistoryCache;
- TrendsCache.
Leiskite mums juos išsamiau išnagrinėti.
Konfigūracijos talpykla
Tai yra pagrindinė talpykla, kurioje saugome metriką, pagrindinius kompiuterius, duomenų elementus, trigerius – viską, ko reikia išankstiniam apdorojimui ir duomenų rinkimui.
Visa tai saugoma ConfigurationCache, kad duomenų bazėje nebūtų sukurtos nereikalingos užklausos. Paleidus serverį, atnaujiname šią talpyklą, kuriame ir periodiškai atnaujiname konfigūracijas.
Duomenų rinkimas
Diagrama yra gana didelė, bet pagrindinis dalykas joje yra rinkėjai. Tai įvairūs „polleriai“ – surinkimo procesai. Jie yra atsakingi už įvairius surinkimo tipus: renka duomenis per SNMP, IPMI ir visa tai perduoda į PreProcessing.
Kolektoriai pažymėti oranžine spalva.
„Zabbix“ apskaičiavo sumavimo elementus, reikalingus čekiams apibendrinti. Jei juos turime, gauname jų duomenis tiesiai iš „ValueCache“.
Išankstinio apdorojimo istorijos talpykla
Visi kolekcionieriai naudoja „ConfigurationCache“, kad gautų užduotis. Tada jie perkelia juos į PreProcessing.
Išankstinis apdorojimas naudoja ConfigurationCache, kad gautų išankstinio apdorojimo veiksmus. Šiuos duomenis jis apdoroja įvairiais būdais.
Apdoroję duomenis naudodami išankstinį apdorojimą, išsaugome juos „HistoryCache“ apdorojimui. Tai baigia duomenų rinkimą ir pereiname prie pagrindinio proceso „Zabbix“ – istorijos sinchronizatorius, nes tai monolitinė architektūra.
Pastaba: išankstinis apdorojimas yra gana sudėtinga operacija. Naudojant 4.2 versiją, jis buvo perkeltas į tarpinį serverį. Jei turite labai didelį Zabbix su daugybe duomenų elementų ir rinkimo dažnumu, tai labai palengvina darbą.
„ValueCache“, istorijos ir tendencijų talpykla
Istorijos sinchronizatorius yra pagrindinis procesas, kuris atomiškai apdoroja kiekvieną duomenų elementą, ty kiekvieną vertę.
Istorijos sinchronizatorius paima reikšmes iš HistoryCache ir patikrina konfigūraciją, ar nėra skaičiavimų aktyviklių. Jei jie egzistuoja, jis apskaičiuoja.
Istorijos sinchronizatorius sukuria įvykį, eskalavimą, kad sukurtų įspėjimus, jei to reikalauja konfigūracija, ir įrašus. Jei yra tolesnio apdorojimo aktyvikliai, ji išsaugo šią reikšmę „ValueCache“, kad nepasiektų istorijos lentelės. Taip „ValueCache“ užpildoma duomenimis, reikalingais aktyvikliams ir apskaičiuotiems elementams apskaičiuoti.
Istorijos sinchronizatorius įrašo visus duomenis į duomenų bazę ir įrašo į diską. Apdorojimo procesas baigiasi čia.
Talpykla duomenų bazėje
Duomenų bazės pusėje yra įvairių talpyklų, kai norite peržiūrėti įvykių grafikus ar ataskaitas:
Innodb_buffer_poolMySQL pusėje;shared_buffersPostgreSQL pusėje;effective_cache_sizeOracle pusėje;shared_poolDB2 pusėje.
Yra daug kitų talpyklų, tačiau jos yra pagrindinės visoms duomenų bazėms. Jie leidžia saugoti duomenis RAM, kurie dažnai reikalingi užklausoms. Tam jie turi savo technologijas.
Duomenų bazės našumas yra labai svarbus
„Zabbix“ serveris nuolat renka duomenis ir juos rašo. Paleidus iš naujo, jis taip pat nuskaito istoriją, kad užpildytų „ValueCache“. Naudoja scenarijus ir ataskaitas Zabbix API, kuris sukurtas naudojant žiniatinklio sąsają. Zabbix API pasiekia duomenų bazę ir nuskaito reikiamus duomenis diagramoms, ataskaitoms, įvykių sąrašams ir naujausioms problemoms.
vizualizacijai - grafana. Tai populiarus sprendimas tarp mūsų vartotojų. Jis gali tiesiogiai siųsti užklausas per Zabbix API ir į duomenų bazę bei sukuria tam tikrą konkurenciją dėl duomenų gavimo. Todėl reikia tiksliau ir geriau suderinti duomenų bazę, kad ji atitiktų greitą rezultatų pristatymą ir testavimą.
Namų šeimininkė
Trečiasis „Zabbix“ našumo iššūkis yra istorijos išvalymas naudojant „Housekeeper“. Jis seka visus nustatymus – duomenų elementai nurodo, kiek laiko reikia saugoti pokyčių dinamiką (tendencijas) dienomis.
Mes apskaičiuojame TrendsCache skrydžio metu. Kai gaunami duomenys, mes juos apibendriname vieną valandą ir įrašome į lenteles, kad būtų galima stebėti tendencijų pokyčių dinamiką.
Namų tvarkytoja paleidžia ir ištrina informaciją iš duomenų bazės naudodama įprastą „pasirenka“. Tai ne visada efektyvu, kaip matyti iš vidinių procesų veiklos grafikų.
Raudona diagrama rodo, kad istorijos sinchronizatorius yra nuolat užimtas. Viršuje esantis oranžinis grafikas rodo „Housekeeper“, kuris nuolat veikia. Jis laukia, kol duomenų bazė ištrins visas jo nurodytas eilutes.
Kada turėtumėte išjungti namų tvarkytoją? Pavyzdžiui, yra „Prekės ID“ ir per tam tikrą laiką turite ištrinti paskutines 5 tūkstančius eilučių. Žinoma, tai atsitinka pagal indeksą. Tačiau paprastai duomenų rinkinys yra labai didelis, o duomenų bazė vis tiek skaito iš disko ir įdeda į talpyklą. Tai visada yra labai brangi duomenų bazės operacija ir, priklausomai nuo duomenų bazės dydžio, gali sukelti našumo problemų.
Namų tvarkytoją lengva išjungti. Žiniatinklio sąsajoje yra „Housekeeper“ nustatymas „Administravimas bendrasis“. Išjungiame vidinį namų ruošą, kad būtų rodoma vidinė tendencijų istorija, ir ji jos nebetvarko.
Namų tvarkytoja buvo išjungta, grafikai išsilygino – kokios gali būti problemos šiuo atveju ir kas galėtų padėti išspręsti trečiąjį veiklos iššūkį?
Skirstymas – skaidymas arba skaidymas
Paprastai kiekvienoje mano išvardytoje reliacinėje duomenų bazėje skaidymas sukonfigūruojamas skirtingai. Kiekvienas iš jų turi savo technologiją, tačiau apskritai jos yra panašios. Kuriant naują skaidinį dažnai kyla tam tikrų problemų.
Paprastai skaidiniai sukonfigūruojami atsižvelgiant į „sąranką“ - duomenų kiekį, kuris sukuriamas per vieną dieną. Paprastai skaidymas išduodamas per vieną dieną, tai yra minimumas. Naujos partijos tendencijoms - 1 mėnuo.
Vertės gali keistis, jei „sąranka“ yra labai didelė. Jei maža „sąranka“ yra iki 5 000 nvps (naujos reikšmės per sekundę), vidutinė yra nuo 5 000 iki 25 000, tada didelė yra didesnė nei 25 000 nvps. Tai dideli ir labai dideli įrenginiai, kuriems reikia kruopštaus duomenų bazės konfigūravimo.
Labai dideliuose įrenginiuose vienos dienos laikotarpis gali būti netinkamas. Per dieną mačiau 40 GB ar daugiau „MySQL“ skaidinių. Tai labai didelis duomenų kiekis, dėl kurio gali kilti problemų ir juos reikia sumažinti.
Ką duoda skaidymas?
Skirstymo lentelės. Dažnai tai yra atskiri failai diske. Užklausos planas optimaliau parenka vieną skaidinį. Paprastai skaidymas naudojamas pagal diapazoną – tai pasakytina ir apie Zabbix. Ten naudojame „laiko žymą“ – laiką nuo eros pradžios. Tai mums įprasti skaičiai. Jūs nustatote dienos pradžią ir pabaigą – tai skaidinys.
Greitas pašalinimas - DELETE. Pasirinktas vienas failas / polentelė, o ne eilučių, kurias norite ištrinti, pasirinkimas.
Žymiai pagreitina duomenų gavimą SELECT - naudoja vieną ar daugiau skaidinių, o ne visą lentelę. Jei pasiekiate dviejų dienų senumo duomenis, jie greičiau nuskaitomi iš duomenų bazės, nes į talpyklą reikia įkelti ir grąžinti tik vieną failą, o ne didelę lentelę.
Dažnai daugelis duomenų bazių taip pat yra pagreitintos INSERT - įterpimai į vaikų lentelę.
Laiko skalėDB
4.2 versijos atveju atkreipėme dėmesį į TimescaleDB. Tai yra PostgreSQL plėtinys su vietine sąsaja. Plėtinys efektyviai veikia su laiko eilučių duomenimis, neprarasdamas reliacinių duomenų bazių pranašumų. TimescaleDB taip pat skaidomas automatiškai.
TimescaleDB turi koncepciją hipertable (hipertable), kurį sukuriate. Jame yra gabaliukais - pertvaros. Gabalai yra automatiškai valdomi hipertable fragmentai, kurie neturi įtakos kitiems fragmentams. Kiekviena dalis turi savo laiko intervalą.
TimescaleDB vs PostgreSQL
TimescaleDB veikia tikrai efektyviai. Plėtinio gamintojai teigia, kad jie naudoja teisingesnį užklausų apdorojimo algoritmą, ypač inserts . Didėjant duomenų rinkinio įterpimo dydžiui, algoritmas palaiko pastovų našumą.
Po 200 milijonų eilučių „PostgreSQL“ paprastai pradeda smarkiai smukti ir praranda našumą iki 0. TimescaleDB leidžia efektyviai įterpti „įterpimus“ bet kokiam duomenų kiekiui.
Montavimas
„TimescaleDB“ diegimas yra gana paprastas bet kuriam paketui. IN viskas aprašyta smulkiai – tai priklauso nuo oficialių PostgreSQL paketų. TimescaleDB taip pat galima sukurti ir sudaryti rankiniu būdu.
„Zabbix“ duomenų bazėje tiesiog suaktyviname plėtinį:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Jūs suaktyvinate extension ir sukurkite jį Zabbix duomenų bazei. Paskutinis žingsnis – sukurti hiperlentelę.
Istorijos lentelių perkėlimas į TimescaleDB
Tam yra speciali 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 turi tris parametrus. Pirmas - lentelė duomenų bazėje, kuriam reikia sukurti hiperlentelę. Antra - laukas, pagal kurią reikia kurti chunk_time_interval — naudojamų pertvarų dalių intervalas. Mano atveju intervalas yra viena diena – 86 400.
Trečias parametras - migrate_data. Jei nustatysite true, tada visi esami duomenys perkeliami į iš anksto sukurtas dalis. Pats naudojau migrate_data. Turėjau apie 1 TB, tai užtruko daugiau nei valandą. Net kai kuriais atvejais bandymo metu ištryniau istorinius simbolių tipų duomenis, kurie nebuvo reikalingi saugojimui, kad jų neperkelčiau.
Paskutinis žingsnis - UPDATE: į db_extension įdėti timescaledbkad duomenų bazė suprastų, jog šis plėtinys egzistuoja. „Zabbix“ jį suaktyvina ir teisingai naudoja duomenų bazės sintaksę bei užklausas – tas funkcijas, kurios būtinos „TimescaleDB“.
Aparatinės įrangos konfigūracija
Naudojau du serverius. Pirmas - VMware mašina. Jis yra gana mažas: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20 GHz procesorių, 16 GB RAM ir 200 GB SSD.
Įdiegiau PostgreSQL 10.8 su Debian 10.8-1.pgdg90+1 OS ir xfs failų sistema. Viską sukonfigūravau minimaliai, kad naudočiau šią konkrečią duomenų bazę, atėmus tai, ką naudos pats Zabbix.
Toje pačioje mašinoje buvo Zabbix serveris, PostgreSQL ir krovinių agentai. Naudojau 50 veikliųjų medžiagų LoadableModulelabai greitai generuoti skirtingus rezultatus: skaičius, eilutes. Duomenų bazę užpildžiau daugybe duomenų.
Iš pradžių buvo pateikta konfigūracija 5 elementų duomenys vienam kompiuteriui. Beveik kiekviename elemente buvo paleidiklis, kad jis būtų panašus į tikrus įrenginius. Kai kuriais atvejais buvo daugiau nei vienas trigeris. Vienam tinklo mazgui buvo 3 000–7 000 paleidimų.
Duomenų elemento atnaujinimo intervalas – 4-7 sekundžių. Pačią apkrovą reguliavau naudodamas ne tik 50 agentų, bet pridėdamas daugiau. Taip pat naudodamas duomenų elementus dinamiškai pakoregavau apkrovą ir sumažinau atnaujinimo intervalą iki 4 s.
PostgreSQL. 35 000 nvps
Mano pirmasis paleidimas naudojant šią aparatinę įrangą buvo grynas PostgreSQL - 35 tūkstančiai reikšmių per sekundę. Kaip matote, duomenų įvedimas trunka sekundės dalis – viskas gerai ir greitai. Vienintelis dalykas – 200 GB talpos SSD diskas greitai prisipildo.
Tai standartinė „Zabbix“ serverio našumo prietaisų skydelis.
Pirmasis mėlynas grafikas yra reikšmių skaičius per sekundę. Antrasis grafikas dešinėje yra kūrimo procesų įkėlimas. Trečia – įkeliami vidiniai kūrimo procesai: istorijos sinchronizatoriai ir „Housekeeper“, kuris čia veikia jau gana seniai.
Ketvirtoje diagramoje parodytas HistoryCache naudojimas. Tai yra tam tikras buferis prieš įterpiant į duomenų bazę. Žalia penktoji diagrama rodo „ValueCache“ naudojimą, tai yra, kiek „ValueCache“ paspaudimų veikia aktyvikliai - tai yra keli tūkstančiai reikšmių per sekundę.
PostgreSQL. 50 000 nvps
Tada padidinau apkrovą iki 50 tūkstančių verčių per sekundę toje pačioje aparatinėje įrangoje.
Įkeliant iš „Housekeeper“ 10 tūkstančių reikšmių įvedimas užtruko 2–3 sekundes.
Namų tvarkytoja jau pradeda trukdyti darbui.
Trečiasis grafikas rodo, kad apskritai trapperių ir istorijos sinchronizatorių apkrova vis dar yra 60%. Ketvirtajame grafike „HistoryCache“ jau pradeda gana aktyviai pildytis „Housekeeper“ veikimo metu. Jis užpildytas 20%, tai yra apie 0,5 GB.
PostgreSQL. 80 000 nvps
Tada padidinau apkrovą iki 80 tūkstančių reikšmių per sekundę. Tai yra maždaug 400 tūkstančių duomenų elementų ir 280 tūkstančių aktyviklių.
Trisdešimties istorijos sinchronizatorių pakrovimo kaina jau yra gana didelė.
Taip pat padidinau įvairius parametrus: istorijos sinchronizatorius, talpyklas.
Mano aparatinėje įrangoje istorijos sinchronizatorių įkėlimas padidėjo iki maksimumo. HistoryCache greitai užpildė duomenis – buferyje susikaupė apdorojimui skirti duomenys.
Visą tą laiką stebėjau, kaip naudojamas procesorius, RAM ir kiti sistemos parametrai, ir pastebėjau, kad disko panaudojimas buvo maksimalus.
Aš pasiekiau naudojimą maksimalios disko galimybės šioje aparatinėje įrangoje ir šioje virtualioje mašinoje. Esant tokiam intensyvumui, PostgreSQL pradėjo gana aktyviai valyti duomenis, o diskas nebeturėjo laiko rašyti ir skaityti.
Antras serveris
Paėmiau kitą serverį, kuriame jau buvo 48 procesoriai ir 128 GB RAM. Aš jį sureguliavau - nustatiau į 60 istorijos sinchronizatorių ir pasiekiau priimtiną našumą.
Tiesą sakant, tai jau yra produktyvumo riba, kai reikia ką nors padaryti.
Laiko skalėDB. 80 000 nvps
Mano pagrindinė užduotis yra išbandyti TimescaleDB galimybes prieš Zabbix apkrovą. 80 tūkstančių reikšmių per sekundę yra daug, metrikos rinkimo dažnis (žinoma, išskyrus „Yandex“) ir gana didelis „sąranka“.
Kiekvienoje diagramoje yra nuosmukio – būtent tai yra duomenų perkėlimas. Po gedimų „Zabbix“ serveryje istorijos sinchronizatoriaus įkėlimo profilis labai pasikeitė – nukrito tris kartus.
TimescaleDB leidžia įterpti duomenis beveik 3 kartus greičiau ir naudoti mažiau HistoryCache.
Atitinkamai duomenis gausite laiku.
Laiko skalėDB. 120 000 nvps
Tada padidinau duomenų elementų skaičių iki 500 tūkst.Pagrindinė užduotis buvo išbandyti TimescaleDB galimybes – gavau apskaičiuotą 125 tūkstančių reikšmių per sekundę vertę.
Tai veikianti „sąranka“, kuri gali veikti ilgą laiką. Bet kadangi mano diskas buvo tik 1,5 TB, užpildžiau jį per porą dienų.
Svarbiausia, kad tuo pačiu metu buvo sukurti nauji TimescaleDB skaidiniai.
Tai visiškai nepastebima našumui. Pavyzdžiui, kai skaidiniai kuriami MySQL, viskas skiriasi. Tai dažniausiai atsitinka naktį, nes tai blokuoja bendrą įterpimą, darbą su lentelėmis ir gali sukelti paslaugų pablogėjimą. Taip nėra su TimescaleDB.
Kaip pavyzdį parodysiu vieną grafiką iš daugelio bendruomenės narių. Nuotraukoje įjungta TimescaleDB, dėl kurios sumažėjo procesoriaus naudojimo io.weight apkrova. Taip pat sumažėjo vidinių proceso elementų naudojimas. Be to, tai yra įprasta virtuali mašina įprastuose blynų diskuose, o ne SSD.
išvados
TimescaleDB yra geras sprendimas mažiems "sąrankai", kurios turi įtakos disko veikimui. Tai leis jums toliau gerai dirbti, kol duomenų bazė bus kuo greičiau perkelta į aparatinę įrangą.
TimescaleDB lengva konfigūruoti, ji padidina našumą, gerai veikia su Zabbix ir turi pranašumų prieš PostgreSQL.
Jei naudojate PostgreSQL ir neketinate jo keisti, rekomenduoju naudokite PostgreSQL su TimescaleDB plėtiniu kartu su Zabbix. Šis sprendimas efektyviai veikia iki vidutinės „sąrankos“.
Kai sakome „didelis našumas“, turime omenyje . Jums nereikės ilgai laukti, kol sužinosite apie technologijas ir praktiką, leidžiančią paslaugoms aptarnauti milijonus vartotojų. Sąrašas lapkričio 7 ir 8 d. mes jau sudarėme, bet čia galima pasiūlyti daugiau.
Prenumeruokite mūsų и , kuriame atskleidžiame būsimos konferencijos ypatybes ir sužinome, kaip iš jos išnaudoti visas galimybes.
Šaltinis: www.habr.com