Zabbix on seiresüsteem. Nagu iga teine süsteem, seisab see silmitsi kõigi seiresüsteemide kolme peamise probleemiga: andmete kogumine ja töötlemine, ajaloo salvestamine ja kustutamine.
Andmete vastuvõtmise, töötlemise ja salvestamise etapid võtavad aega. Mitte palju, kuid suure süsteemi puhul võib see põhjustada suuri viivitusi. Salvestusprobleem on andmetele juurdepääsu küsimus. Neid kasutatakse aruannete, kontrollide ja käivitajate jaoks. Andmetele juurdepääsu viivitused mõjutavad ka jõudlust. Kui andmebaas kasvab, tuleb ebaolulised andmed kustutada. Kustutamine on raske toiming, mis kulutab ka osa ressursse.
Kogumise ja salvestamise viivitusprobleemid Zabbixis lahendatakse vahemällu salvestamisega: mitut tüüpi vahemälu, vahemälu andmebaasis. Kolmanda probleemi lahendamiseks ei sobi vahemälu, mistõttu kasutati Zabbixis TimescaleDB-d. Räägib sellest Andrei Guštšin - tehnilise toe insener . Andrey on Zabbixit toetanud üle 6 aasta ja on otseselt seotud esinemisega.
Kuidas TimescaleDB töötab, millist jõudlust suudab see tavalise PostgreSQL-iga võrreldes pakkuda? Millist rolli mängib Zabbix TimescaleDB-s? Kuidas alustada nullist ja kuidas migreerida PostgreSQL-ist ning milline konfiguratsiooni jõudlus on parem? Kõik see lõike all.
Tulemuslikkuse väljakutsed
Igal seiresüsteemil on teatud jõudlusprobleemid. Räägin neist kolmest: andmete kogumine ja töötlemine, säilitamine, ajaloo puhastamine.
Kiire andmete kogumine ja töötlemine. Hea monitooringusüsteem peaks kõik andmed kiiresti vastu võtma ja neid trigger-avaldiste järgi töötlema – oma kriteeriumide järgi. Peale töötlemist peab süsteem ka need andmed kiiresti andmebaasi salvestama, et neid hiljem kasutada.
Ajaloo salvestamine. Hea jälgimissüsteem peaks salvestama ajaloo andmebaasi ja pakkuma lihtsat juurdepääsu mõõdikutele. Ajalugu on vaja aruannetes, graafikutes, päästikutes, lävedes ja arvutatud hoiatusüksustes kasutamiseks.
Ajaloo kustutamine. Mõnikord tuleb päev, mil pole vaja mõõdikuid salvestada. Miks on vaja andmeid, mis koguti 5 aastat tagasi, kuu või kaks: osa sõlmedest on eemaldatud, mõnda hosti või mõõdikut pole enam vaja, sest need on aegunud ja neid enam ei koguta. Hea seiresüsteem peaks salvestama ajaloolisi andmeid ja neid aeg-ajalt kustutama, et andmebaas ei kasvaks.
Vananenud andmete puhastamine on keeruline probleem, millel on suur mõju andmebaasi jõudlusele.
Vahemällu salvestamine Zabbixis
Zabbixis lahendatakse esimene ja teine kõne vahemällu kasutades. RAM-i kasutatakse andmete kogumiseks ja töötlemiseks. Salvestamiseks - ajalugu päästikutes, graafikutes ja arvutatud üksustes. DB poolel on põhivalikute, näiteks graafikute jaoks mõningane vahemälu.
Vahemällu salvestamine Zabbixi serveri enda küljel on järgmine:
- Configuration Cache;
- ValueCache;
- ajaloo vahemälu;
- TrendsCache.
Vaadake neid üksikasjalikumalt.
Konfiguratsiooni vahemälu
See on peamine vahemälu, kuhu salvestame mõõdikuid, hoste, andmeüksusi, trigereid – kõike, mis on vajalik eeltöötluseks ja andmete kogumiseks.
Kõik see salvestatakse ConfigurationCache'i, et mitte tekitada andmebaasis tarbetuid päringuid. Pärast serveri käivitumist värskendame seda vahemälu, loome ja värskendame perioodiliselt konfiguratsioone.
Andmete kogumine
Skeem on üsna suur, kuid peamine asi selles on kollektsionäärid. Need on erinevad "pollerid" - montaažiprotsessid. Nad vastutavad erinevat tüüpi kooste eest: nad koguvad andmeid SNMP, IPMI kaudu ja edastavad kõik eeltöötlusele.
Korjajad on ümbritsetud oranžiga.
Zabbixil on välja arvutatud koondüksused, mis on vajalikud kontrollide koondamiseks. Kui meil on need olemas, võtame nende andmed otse ValueCache'ist.
Eeltöötluse ajaloo vahemälu
Kõik kogujad kasutavad tööde vastuvõtmiseks ConfigurationCache'i. Seejärel edastavad nad need eeltöötlusele.
Eeltöötlus kasutab eeltöötluse sammude saamiseks ConfigurationCache'i. See töötleb neid andmeid mitmel viisil.
Pärast andmete töötlemist eeltöötlusega salvestame need töötlemiseks HistoryCache'i. See lõpetab andmete kogumise ja liigume edasi Zabbixi põhiprotsessi juurde - ajaloo sünkronisaator, kuna see on monoliitne arhitektuur.
Märkus. Eeltöötlus on üsna raske toiming. Alates versioonist 4.2 on see teisaldatud puhverserverile. Kui teil on väga suur Zabbix suure hulga esemete ja kogumissagedusega, teeb see asja palju lihtsamaks.
ValueCache, ajaloo ja trendide vahemälu
Ajaloo sünkroonimine on põhiprotsess, mis töötleb iga andmeelementi, st iga väärtust atomaarselt.
Ajaloo sünkroonija võtab väärtused HistoryCache'ist ja kontrollib arvutuste käivitajate konfiguratsiooni. Kui nad on - arvutab.
Ajaloo sünkroonija loob sündmuse, eskaleerub, et luua hoiatusi, kui konfiguratsioon seda nõuab, ja salvestab. Kui edasiseks töötlemiseks on käivitajaid, jätab see selle väärtuse ValueCache'is meelde, et mitte viidata ajalootabelile. Nii täidetakse ValueCache andmetega, mida on vaja käivitajate, arvutatud üksuste arvutamiseks.
Ajaloo sünkroonija kirjutab kõik andmed andmebaasi ja see kirjutab kettale. Töötlemisprotsess lõpeb siin.
DB vahemällu salvestamine
Kui soovite vaadata graafikuid või sündmuste aruandeid, on DB poolel erinevad vahemälud:
Innodb_buffer_poolMySQL-i poolel;shared_buffersPostgreSQL-i poolel;effective_cache_sizeOracle'i poolel;shared_poolDB2 poolel.
On palju muid vahemälu, kuid need on kõigi andmebaaside peamised. Need võimaldavad teil hoida RAM-is andmeid, mida sageli päringute jaoks vaja läheb. Neil on selleks oma tehnoloogia.
Andmebaasi jõudlus on kriitiline
Zabbixi server kogub pidevalt andmeid ja kirjutab neid üles. Taaskäivitamisel loeb see ValueCache'i täitmiseks ka ajaloost. Skriptide ja aruannete kasutamine Zabbix API, mis on üles ehitatud veebiliidese baasil. Zabbixi API pääseb juurde andmebaasile ja hangib graafikute, aruannete, sündmuste loendite ja hiljutiste probleemide jaoks vajalikud andmed.
Visualiseerimiseks - grafana. See on meie kasutajate seas populaarne lahendus. Ta saab saata päringuid otse Zabbixi API kaudu ja andmebaasi ning loob andmete hankimiseks teatud samaaegsuse. Seetõttu on tulemuste ja testimise kiireks edastamiseks vaja peenemat ja paremat andmebaasi häälestamist.
Majapidaja
Kolmas Zabbixi jõudluse väljakutse on majahoidjaga ajaloo puhastamine. See austab kõiki seadistusi – andmeelemendid näitavad, kui kaua muutuste (trendide) dünaamikat päevades salvestada.
TrendsCache arvutame käigu pealt. Kui andmed laekuvad, koondame need ühe tunni jooksul ja paneme need tabelitesse trendimuutuste dünaamika jaoks.
Majahoidja käivitab ja eemaldab teabe andmebaasist tavapäraste "valimiste" abil. See ei ole alati tõhus, mida saab mõista sisemiste protsesside toimivusgraafikutelt.
Punane graafik näitab, et History syncer on pidevalt hõivatud. Ülaosas olev oranž diagramm on Housekeeper, mis töötab pidevalt. See ootab, kuni andmebaas kustutab kõik määratud read.
Millal peaksite majahoidja keelama? Näiteks on olemas "Kauba ID" ja peate teatud aja jooksul kustutama viimased 5 tuhat rida. Muidugi juhtub see indeksite järgi. Kuid tavaliselt on andmestik väga suur ja andmebaas loeb ikkagi kettalt ja paneb selle vahemällu. See on andmebaasi jaoks alati väga kulukas toiming ja võib olenevalt andmebaasi suurusest põhjustada jõudlusprobleeme.
Majahoidjat on lihtne keelata. Veebiliideses on majahoidja jaotises "Üldine haldus" säte. Keelake sisemine majapidamine sisemise trendi ajaloo jaoks ja see ei kontrolli enam seda.
Majahoidja on invaliidistunud, graafika ühtlustunud - milles võiks sel juhul olla probleeme ja mis võib aidata kolmanda jõudluse väljakutse lahendamisel?
Partitsioneerimine – partitsioonide jagamine või sektsioonide eraldamine
Partitsioonid on tavaliselt igas loetletud relatsiooniandmebaasis konfigureeritud erineval viisil. Igal neist on oma tehnoloogia, kuid üldiselt on need sarnased. Uue partitsiooni loomine põhjustab sageli teatud probleeme.
Sektsioonid konfigureeritakse tavaliselt olenevalt "seadistustest" - andmete hulgast, mis ühe päeva jooksul luuakse. Reeglina seadistatakse partitsioonid ühe päevaga, see on miinimum. Uute jaotussuundade puhul - 1 kuu.
Väga suure "seadistuse" korral võivad väärtused muutuda. Kui väike "seadistus" on kuni 5 nvps (uued väärtused sekundis), siis keskmine on 000 kuni 5 000, siis suur üle 25 000 nvps. Need on suured ja väga suured installatsioonid, mis nõuavad andmebaasi enda hoolikat seadistamist.
Väga suurte paigalduste puhul ei pruugi üks päev olla optimaalne. Olen näinud MySQL-i partitsioone mahuga 40 GB või rohkem päevas. See on väga suur andmehulk, mis võib põhjustada probleeme ja mida tuleks vähendada.
Mis annab partitsiooni?
Jaotuslauad. Sageli on need eraldi failid kettal. Päringuplaan valib ühe partitsiooni optimaalsemalt. Tavaliselt kasutatakse partitsiooni vahemiku järgi – see kehtib ka Zabbixi puhul. Me kasutame seal "ajatemplit" - aega epohhi algusest. Meil on tavalised numbrid. Määrate päeva alguse ja lõpu - see on partitsioon.
Kiire eemaldamine - DELETE. Valitud on üks fail/alamtabel, mitte ridade valik kustutamiseks.
Kiirendab oluliselt andmete proovivõttu SELECT - kasutab ühte või mitut partitsiooni, mitte kogu tabelit. Kui pääsete juurde kahe päeva vanustele andmetele, hangib see need andmebaasist kiiremini, kuna peate need vahemällu laadima ja tagastama ainult ühe faili, mitte suurt tabelit.
Sageli kiirendavad ka paljud andmebaasid INSERT - sisestab lapse lauale.
AjakavaDB
Versiooni 4.2 puhul pöörasime tähelepanu TimescaleDB-le. See on PostgreSQL-i laiendus, millel on loomulik liides. Laiendus töötab tõhusalt aegridade andmetega, kaotamata relatsiooniandmebaaside eeliseid. TimescaleDB jaotub ka automaatselt.
TimescaleDB-l on kontseptsioon hüpertabel (hüpertabel), mille loote. Selles on tükid - vaheseinad. Tükid on automaatselt hallatavad hüpertabeli fragmendid, mis ei mõjuta teisi fragmente. Igal tükil on oma ajavahemik.
TimescaleDB vs PostgreSQL
TimescaleDB on tõesti tõhus. Laienduse tootjad väidavad, et kasutavad õigemat päringutöötlusalgoritmi, eelkõige inserts . Andmestiku lisamise suuruse kasvades säilitab algoritm pideva jõudluse.
Pärast 200 miljonit rida hakkab PostgreSQL tavaliselt palju langema ja kaotab jõudluse 0-ni. TimescaleDB võimaldab teil tõhusalt sisestada "lisandeid" mis tahes andmemahuga.
Paigaldamine
TimescaleDB installimine on kõigi pakettide jaoks piisavalt lihtne. IN kõik on üksikasjalik - see sõltub ametlikest PostgreSQL-i pakettidest. TimescaleDB saab ehitada ja kompileerida ka käsitsi.
Zabbixi andmebaasi jaoks aktiveerime lihtsalt laienduse:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
aktiveerite extension ja looge see Zabbixi andmebaasi jaoks. Viimane samm on hüpertabeli loomine.
Ajaloo tabelite migreerimine TimescaleDB-sse
Selleks on spetsiaalne funktsioon. 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
Funktsioonil on kolm parameetrit. Esiteks - tabel andmebaasisMille jaoks soovite hüpertabeli luua. Teine - väli, mille järgi on vaja luua chunk_time_interval — kasutatavate partitsioonitükkide intervall. Minu puhul on intervall üks päev - 86 400.
Kolmas parameeter on migrate_data. Kui määratud true, siis kantakse kõik praegused andmed üle eelnevalt loodud tükkidesse. Ise olen kasutanud migrate_data. Mul oli umbes 1 TB, mis võttis aega üle tunni. Isegi mõnel juhul kustutasin testimisel nende märgitüüpide ajaloolised andmed, mis on salvestamiseks valikulised, et neid mitte üle kanda.
Viimane samm - UPDATE: sisse db_extension pane timescaledbet andmebaas saaks selle laienduse olemasolust aru. Zabbix aktiveerib selle ja kasutab õigesti juba andmebaasis olevat süntaksit ja päringuid – neid funktsioone, mis on TimescaleDB jaoks vajalikud.
Riistvara konfiguratsioon
Kasutasin kahte serverit. Esiteks - VMware masin. See on piisavalt väike: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20 GHz, 16 GB muutmälu ja 200 GB SSD-draiv.
Installisin sellele PostgreSQL 10.8 koos Debian OS 10.8-1.pgdg90+1 ja xfs failisüsteemiga. Seadistasin kõik minimaalselt selle konkreetse andmebaasi kasutamiseks, miinus see, mida Zabbix ise kasutab.
Samas masinas oli Zabbixi server, PostgreSQL ja laadimisagendid. Mul oli 50 toimeainet, kes kasutasid LoadableModuleet genereerida väga kiiresti erinevaid tulemusi: numbreid, stringe. Täitsin andmebaasi suure hulga andmetega.
Esialgu sisaldas konfiguratsioon 5 eset andmed hosti kohta. Peaaegu iga element sisaldas päästikut, et muuta see tõeliseks installatsiooniks. Mõnel juhul oli päästik rohkem kui üks. Ühel võrgusõlmel oli 3-000 päästikut.
Kauba värskendamise intervall − 4-7 sekundit. Reguleerisin koormust ise, kasutades mitte ainult 50 vahendit, vaid lisades rohkem. Samuti reguleerisin andmeelementide abil dünaamiliselt koormust ja vähendasin uuendusintervalli 4 s-ni.
PostgreSQL. 35 000 nvps
Minu esimene selle riistvara kasutamine oli puhtal PostgreSQL-il - 35 tuhat väärtust sekundis. Nagu näete, võtab andmete sisestamine sekundi murdosa – kõik on korras ja kiire. Ainuke asi on see, et 200 GB SSD-draiv saab kiiresti täis.
See on standardne Zabbixi serveri jõudluse armatuurlaud.
Esimene sinine graafik on väärtuste arv sekundis. Teine paremal olev graafik on ehitusprotsesside laadimine. Kolmas on sisemiste ehitusprotsesside laadimine: ajaloo sünkroonijad ja Housekeeper, mis on siin juba mõnda aega töötanud.
Neljas graafik näitab HistoryCache'i kasutamist. See on omamoodi puhver enne andmebaasi sisestamist. Roheline viies graafik näitab ValueCache'i kasutamist, st kui palju ValueCache'i tabamust päästikutele on mitu tuhat väärtust sekundis.
PostgreSQL. 50 000 nvps
Seejärel suurendasin sama riistvara koormust 50 tuhande väärtuseni sekundis.
Majahoidjast laadides võttis 10 tuhande väärtuse sisestamine 2-3 sekundit.
Majahoidja hakkab juba segama.
Kolmas graafik näitab, et üldiselt on trapperite ja ajaloo sünkronisaatorite laadimine endiselt 60% tasemel. Neljandal graafikul hakkab Housekeeperi töö ajal olev HistoryCache juba üsna aktiivselt täituma. See on 20% täis - umbes 0,5 GB.
PostgreSQL. 80 000 nvps
Seejärel suurendasin koormust 80 tuhande väärtuseni sekundis. See on ligikaudu 400 tuhat andmeelementi ja 280 tuhat käivitajat.
Kolmekümne ajaloo sünkronisaatori laadimissisend on juba üsna kõrge.
Suurendasin ka erinevaid parameetreid: ajaloo sünkroonijad, vahemälud.
Minu riistvaral tõusis ajaloo sünkroonijate laadimine maksimumini. HistoryCache täitus kiiresti andmetega - puhver on kogunud andmeid töötlemiseks.
Kogu selle aja jälgisin, kuidas kasutatakse protsessorit, RAM-i ja muid süsteemi parameetreid ning leidsin, et ketta kasutamine on maksimaalne.
Olen kasutanud ketta maksimaalne maht selles riistvaras ja selles virtuaalmasinas. Sellise intensiivsusega hakkas PostgreSQL üsna aktiivselt andmeid tühjendama ning kettal ei olnud enam aega kirjutada ega lugeda.
Teine server
Võtsin teise serveri, millel oli juba 48 protsessorit ja 128 GB muutmälu. Ma häälestasin seda - seadsin 60 ajaloo sünkroonija ja saavutasin vastuvõetava jõudluse.
Tegelikult on see juba jõudluspiir, kus on vaja midagi ette võtta.
ajaskaalagab. 80 000 nvps
Minu põhiülesanne on testida TimescaleDB võimalusi Zabbixi koormuse suhtes. 80 tuhat väärtust sekundis on palju, mõõdikute kogumise sagedus (muidugi välja arvatud Yandex) ja üsna suur "seadistus".
Igal graafikul on langus – see on lihtsalt andmete migratsioon. Pärast Zabbixi serveri tõrkeid on ajaloo sünkroonija laadimisprofiil palju muutunud - see langes kolm korda.
TimescaleDB võimaldab sisestada andmeid peaaegu 3 korda kiiremini ja kasutada vähem HistoryCache'i.
Sellest lähtuvalt saate andmed õigeaegselt.
ajaskaalagab. 120 000 nvps
Seejärel suurendasin andmeelementide arvu 500 tuhandeni. Peamine ülesanne oli kontrollida TimescaleDB võimalusi - sain arvutatud väärtuseks 125 tuhat väärtust sekundis.
See on töötav "seadistus", mille toimimine võib võtta kaua aega. Aga kuna mu ketas oli vaid 1,5 TB, täitsin selle paari päevaga täis.
Kõige tähtsam on see, et samal ajal loodi uued TimescaleDB partitsioonid.
Jõudluse jaoks on see täiesti märkamatu. Kui partitsioonid luuakse näiteks MySQL-is, on asjad teisiti. See juhtub tavaliselt öösel, kuna see blokeerib üldise sisestamise, tabeliga manipuleerimise ja võib põhjustada teenuse halvenemist. TimescaleDB puhul see nii ei ole.
Näiteks näitan ühte graafikut kogukonnas olevast komplektist. Pildil on lubatud TimescaleDB, tänu millele on protsessori io.weight kasutamise koormus langenud. Vähenenud on ka sisemiste protsesside elementide kasutamine. Pealegi on see tavaline virtuaalne masin tavalistel pannkoogiketastel, mitte SSD.
Järeldused
TimescaleDB on hea lahendus väikeste "seadistuste" jaoks, mis põhinevad ketta jõudlusel. See võimaldab teil hästi töötada, kuni andmebaas on kiiremini riistvarale üle viidud.
TimescaleDB-d on lihtne seadistada, see suurendab jõudlust, töötab hästi Zabbixi ja omab eeliseid PostgreSQL-i ees.
Kui kasutad PostgreSQL-i ja ei plaani seda muuta, siis soovitan kasutage PostgreSQL-i koos TimescaleDB laiendiga koos Zabbixiga. See lahendus töötab tõhusalt kuni keskmise "seadistuseni".
Me ütleme "kõrge jõudlus" - me mõtleme . Ei lähe kaua aega, kui õpite tundma tehnoloogiaid ja tavasid, mis võimaldavad teenustel teenindada miljoneid kasutajaid. Nimekiri 7. ja 8. novembriks oleme juba koostanud, kuid rohkem võib soovitada.
Telli meie и , milles paljastame eelseisva konverentsi eripärad ja uurime, kuidas sellest maksimumi võtta.
Allikas: www.habr.com