Zabbix er eftirlitskerfi. Eins og hvert annað kerfi stendur það frammi fyrir þremur meginvandamálum allra vöktunarkerfa: safna og vinna úr gögnum, geyma sögu og þrífa þau.
Stig móttöku, vinnslu og skráningar gagna taka tíma. Ekki mikið, en fyrir stórt kerfi getur þetta valdið miklum töfum. Geymsluvandamálið er gagnaaðgangsvandamál. Þau eru notuð fyrir skýrslur, athuganir og kveikjur. Töf í gagnaaðgangi hefur einnig áhrif á frammistöðu. Þegar gagnagrunnar stækka þarf að eyða óviðkomandi gögnum. Að fjarlægja er erfið aðgerð sem eyðir líka sumum auðlindum.
Vandamál vegna tafa við söfnun og geymslu í Zabbix eru leyst með skyndiminni: nokkrar gerðir af skyndiminni, skyndiminni í gagnagrunninum. Til að leysa þriðja vandamálið hentar skyndiminni ekki, svo Zabbix notaði TimescaleDB. Hann mun segja þér frá því Andrey Gushchin - tæknifræðingur . Andrey hefur stutt Zabbix í meira en 6 ár og hefur beina reynslu af frammistöðu.
Hvernig virkar TimescaleDB, hvaða afköst getur það gefið miðað við venjulegan PostgreSQL? Hvaða hlutverki gegnir Zabbix fyrir TimescaleDB gagnagrunninn? Hvernig á að byrja frá grunni og hvernig á að flytja frá PostgreSQL og hvaða stillingar hafa betri afköst? Um allt þetta undir skurðinum.
Framleiðniáskoranir
Sérhvert eftirlitskerfi stendur frammi fyrir sérstökum frammistöðuáskorunum. Ég mun tala um þrjú þeirra: gagnasöfnun og vinnslu, geymslu og söguhreinsun.
Hröð gagnasöfnun og úrvinnsla. Gott eftirlitskerfi ætti að taka fljótt við öllum gögnum og vinna úr þeim í samræmi við kveikjutjáningu - samkvæmt forsendum þess. Eftir vinnslu þarf kerfið einnig að vista þessi gögn fljótt í gagnagrunninum til síðari nota.
Sögugeymsla. Gott eftirlitskerfi ætti að geyma sögu í gagnagrunni og veita greiðan aðgang að mælingum. Nota þarf sögu í skýrslum, línuritum, kveikjum, þröskuldum og reiknuðum viðvörunargögnum.
Hreinsar feril. Stundum kemur dagur þegar þú þarft ekki að geyma mælikvarða. Af hverju þarftu gögn sem var safnað fyrir 5 árum, einum eða tveimur mánuðum: sumum hnútum hefur verið eytt, sumum hýslum eða mæligildum er ekki lengur þörf vegna þess að þau eru úrelt og ekki lengur safnað. Gott eftirlitskerfi ætti að geyma söguleg gögn og eyða þeim af og til svo gagnagrunnurinn stækki ekki.
Að hreinsa upp gamaldags gögn er mikilvægt mál sem hefur mikil áhrif á afköst gagnagrunnsins.
Skyndiminni í Zabbix
Í Zabbix er fyrsta og annað símtal leyst með því að nota skyndiminni. RAM er notað til að safna og vinna úr gögnum. Til geymslu - saga í kveikjum, línuritum og reiknuðum gagnaþáttum. Á gagnagrunnshliðinni er nokkur skyndiminni fyrir grunnval, til dæmis, línurit.
Skyndiminni á hlið Zabbix netþjónsins sjálfs er:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Íhuga þau nánar.
ConfigurationCache
Þetta er aðal skyndiminni þar sem við geymum mælikvarða, vélar, gagnaatriði, kveikjur - allt sem við þurfum fyrir forvinnslu og til gagnasöfnunar.
Allt þetta er geymt í ConfigurationCache til að búa ekki til óþarfa fyrirspurnir í gagnagrunninum. Eftir að þjónninn byrjar uppfærum við þetta skyndiminni, búum til og uppfærum stillingar reglulega.
Gagnasafn
Skýringarmyndin er nokkuð stór, en aðalatriðið í henni er safnara. Þetta eru ýmsir „pollers“ - samsetningarferli. Þeir eru ábyrgir fyrir mismunandi gerðum samsetningar: þeir safna gögnum í gegnum SNMP, IPMI og flytja þau öll yfir í PreProcessing.
Safnararnir eru með appelsínugulum útlínum.
Zabbix hefur reiknað samansöfnunarliði sem þarf til að safna saman ávísunum. Ef við höfum þau, sækjum við gögnin fyrir þau beint úr ValueCache.
PreProcessing HistoryCache
Allir safnarar nota ConfigurationCache til að taka á móti störfum. Síðan flytja þeir þær yfir í PreProcessing.
PreProcessing notar ConfigurationCache til að taka á móti PreProcessing skrefum. Það vinnur úr þessum gögnum á ýmsan hátt.
Eftir að hafa unnið gögnin með því að nota PreProcessing vistum við þau í HistoryCache til vinnslu. Þetta lýkur gagnasöfnuninni og við förum yfir í aðalferlið í Zabbix - sögu samstillingartæki, þar sem það er einhæf byggingarlist.
Athugið: Forvinnsla er frekar erfið aðgerð. Með v 4.2 hefur það verið flutt í proxy. Ef þú ert með mjög stóran Zabbix með miklum fjölda gagnaþátta og söfnunartíðni, þá gerir þetta verkið miklu auðveldara.
ValueCache, sögu og þróun skyndiminni
Sögusamstilling er aðalferlið sem vinnur hvern gagnaþátt á frumeindabraut, það er hvert gildi.
Sögusamstillir tekur gildi úr HistoryCache og athugar stillingar fyrir tilvist kveikja fyrir útreikninga. Ef þeir eru til reiknar það út.
Sögusamstillir býr til atburð, stigmögnun til að búa til viðvaranir ef þess er krafist af stillingum og skráir. Ef það eru kveikjur fyrir síðari vinnslu, þá geymir það þetta gildi í ValueCache til að fá ekki aðgang að sögutöflunni. Þannig er ValueCache fyllt með gögnum sem eru nauðsynleg til að reikna út kveikjur og reiknaða þætti.
History syncer skrifar öll gögn í gagnagrunninn og það skrifar á diskinn. Vinnsluferlinu lýkur hér.
Skyndiminni í gagnagrunninum
Á gagnagrunnshliðinni eru ýmis skyndiminni þegar þú vilt skoða línurit eða skýrslur um atburði:
Innodb_buffer_poolá MySQL hliðinni;shared_buffersá PostgreSQL hliðinni;effective_cache_sizeá Oracle hlið;shared_poolá DB2 hliðinni.
Það eru mörg önnur skyndiminni, en þetta eru þau helstu fyrir alla gagnagrunna. Þeir gera þér kleift að geyma gögn í vinnsluminni sem oft er þörf fyrir fyrirspurnir. Þeir hafa sína eigin tækni fyrir þetta.
Afköst gagnagrunnsins eru mikilvæg
Zabbix þjónninn safnar stöðugt gögnum og skrifar þau. Þegar það er endurræst les það einnig úr sögunni til að fylla ValueCache. Notar forskriftir og skýrslur Zabbix API, sem er byggt á vefviðmóti. Zabbix API hefur aðgang að gagnagrunninum og sækir nauðsynleg gögn fyrir línurit, skýrslur, atburðalista og nýjustu útgáfur.
Til sjónrænnar - grafana. Þetta er vinsæl lausn meðal notenda okkar. Það getur sent beiðnir beint í gegnum Zabbix API og í gagnagrunninn og skapar ákveðna samkeppni um móttöku gagna. Þess vegna þarf fínni og betri stillingu á gagnagrunninum til að passa við hraða afhendingu niðurstaðna og prófana.
Matselja
Þriðja frammistöðuáskorunin í Zabbix er söguhreinsun með því að nota Housekeeper. Það fylgir öllum stillingum - gagnaþættirnir gefa til kynna hversu lengi á að geyma gangverki breytinga (strauma) í dögum.
Við reiknum út TrendsCache á flugu. Þegar gögnin berast tökum við þau saman í eina klukkustund og skráum þau í töflur fyrir gangverki þróunarbreytinga.
Húsvörður byrjar og eyðir upplýsingum úr gagnagrunninum með því að nota venjulega „velur“. Þetta er ekki alltaf árangursríkt eins og sjá má af frammistöðuritum innri ferla.
Rauða línuritið sýnir að History syncer er stöðugt upptekinn. Appelsínugula línuritið efst er Housekeeper sem er stöðugt í gangi. Hann bíður eftir að gagnagrunnurinn eyði öllum línum sem hann tilgreindi.
Hvenær ættir þú að slökkva á húshjálp? Til dæmis, það er "Item ID" og þú þarft að eyða síðustu 5 þúsund línum innan ákveðins tíma. Auðvitað gerist þetta með vísitölu. En venjulega er gagnasafnið mjög stórt og gagnagrunnurinn les enn af disknum og setur hann í skyndiminni. Þetta er alltaf mjög dýr aðgerð fyrir gagnagrunninn og getur, allt eftir stærð gagnagrunnsins, leitt til árangursvandamála.
Auðvelt er að slökkva á húsráðanda. Í vefviðmótinu er stilling í „Almennt stjórnun“ fyrir húsvörð. Við slökkva á innri stofuhaldi fyrir innri þróunarsögu og hún stjórnar henni ekki lengur.
Slökkt var á húsverði, línuritin jöfnuðust - hvaða vandamál gætu verið í þessu tilfelli og hvað gæti hjálpað til við að leysa þriðju frammistöðuáskorunina?
Skipting - skipting eða skipting
Venjulega er skipting stillt á annan hátt í hverjum venslagagnagrunni sem ég hef skráð. Hver hefur sína tækni, en þau eru almennt svipað. Að búa til nýja skipting leiðir oft til ákveðinna vandamála.
Venjulega eru skipting stillt eftir „uppsetningu“ - magn gagna sem er búið til á einum degi. Að jafnaði er skipting gefin út á einum degi, þetta er lágmarkið. Fyrir þróun nýrrar lotu - 1 mánuður.
Gildin geta breyst ef „uppsetningin“ er mjög stór. Ef lítil „uppsetning“ er allt að 5 nvps (ný gildi á sekúndu), miðlungs er frá 000 til 5, þá er stór yfir 000 nvps. Þetta eru stórar og mjög stórar uppsetningar sem krefjast vandlegrar uppsetningar á gagnagrunninum.
Á mjög stórum uppsetningum getur verið að einn dagur sé ekki ákjósanlegur. Ég hef séð MySQL skipting upp á 40 GB eða meira á dag. Þetta er mjög mikið gagnamagn sem getur valdið vandræðum og þarf að minnka.
Hvað gefur skipting?
Skiptiborð. Oft eru þetta aðskildar skrár á diski. Fyrirspurnaráætlunin velur eina skiptingu betur. Venjulega er skipting notuð eftir sviðum - þetta á líka við um Zabbix. Við notum „tímastimpil“ þar - tími frá upphafi tímabils. Þetta eru venjulegar tölur hjá okkur. Þú stillir upphaf og lok dagsins - þetta er skipting.
Fljótur flutningur - DELETE. Ein skrá/undirtafla er valin, frekar en úrval af línum til eyðingar.
Flýtir verulega gagnaöflun SELECT - notar eina eða fleiri skipting, frekar en alla töfluna. Ef þú nálgast gögn sem eru tveggja daga gömul eru þau sótt úr gagnagrunninum hraðar því þú þarft bara að hlaða einni skrá inn í skyndiminni og skila henni, ekki stórri töflu.
Oft er mörgum gagnagrunnum líka hraðað INSERT — innsetningar í barnatöfluna.
TímastigDB
Fyrir v 4.2 beinum við athygli okkar að TimescaleDB. Þetta er viðbót fyrir PostgreSQL með innfæddu viðmóti. Framlengingin virkar á áhrifaríkan hátt með tímaraðargögnum, án þess að missa ávinninginn af venslagagnagrunnum. TimescaleDB skiptar einnig sjálfkrafa.
TimescaleDB hefur hugtak ofurtöflu (hypertable) sem þú býrð til. Það inniheldur klumpur - skipting. Klumpar eru sjálfkrafa stjórnaðir ofurtöflubrot sem hafa ekki áhrif á önnur brot. Hver klumpur hefur sitt eigið tímabil.
TimescaleDB vs PostgreSQL
TimescaleDB virkar mjög skilvirkt. Framleiðendur viðbótarinnar halda því fram að þeir noti réttara fyrirspurnavinnslualgrím, sérstaklega inserts . Eftir því sem innskotsstærð gagnasafnsins stækkar heldur reikniritið stöðugri frammistöðu.
Eftir 200 milljón raðir byrjar PostgreSQL venjulega að lækka verulega og tapar afköstum í 0. TimescaleDB gerir þér kleift að setja inn „innskot“ á skilvirkan hátt fyrir hvaða gagnamagn sem er.
Uppsetning
Það er frekar auðvelt að setja upp TimescaleDB fyrir hvaða pakka sem er. IN öllu er lýst í smáatriðum - það fer eftir opinberu PostgreSQL pökkunum. TimescaleDB er einnig hægt að smíða og setja saman handvirkt.
Fyrir Zabbix gagnagrunninn virkjum við einfaldlega viðbótina:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Þú virkjar extension og búa það til fyrir Zabbix gagnagrunninn. Síðasta skrefið er að búa til ofurtöflu.
Flytur sögutöflur yfir í TimescaleDB
Það er sérstök aðgerð fyrir þetta 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
Aðgerðin hefur þrjár breytur. Fyrst - töflu í gagnagrunni, sem þú þarft að búa til hátöflu fyrir. Annað - reit, samkvæmt því sem þú þarft að búa til chunk_time_interval — millibil skiptinga sem á að nota. Í mínu tilfelli er bilið einn dagur - 86.
Þriðja færibreytan - migrate_data. Ef þú stillir true, þá eru öll núverandi gögn flutt í fyrirfram búna bita. Ég notaði það sjálfur migrate_data. Ég var með um 1 TB, sem tók rúman klukkutíma. Jafnvel í sumum tilfellum, meðan á prófun stóð, eyddi ég sögulegum gögnum um persónutegundir sem ekki var krafist fyrir geymslu, til að flytja þær ekki.
Síðasta skrefið - UPDATE: í db_extension setja timescaledbþannig að gagnagrunnurinn skilji að þessi viðbót sé til. Zabbix virkjar það og notar rétt setningafræði og fyrirspurnir í gagnagrunninn - þá eiginleika sem eru nauðsynlegir fyrir TimescaleDB.
Vélbúnaðarstillingar
Ég notaði tvo netþjóna. Fyrst - VMware vél. Hann er frekar lítill: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz örgjörvar, 16 GB af vinnsluminni og 200 GB SSD.
Ég setti upp PostgreSQL 10.8 á það með Debian 10.8-1.pgdg90+1 OS og xfs skráarkerfi. Ég stillti allt í lágmarki til að nota þennan tiltekna gagnagrunn, að frádregnum því sem Zabbix sjálft mun nota.
Á sömu vél var Zabbix server, PostgreSQL og hleðsluefni. Ég var með 50 virk efni sem voru að nota LoadableModuletil að mynda mjög fljótt mismunandi niðurstöður: tölur, strengi. Ég fyllti gagnagrunninn með fullt af gögnum.
Upphaflega innihélt uppsetningin 5 þættir gögn á hvern gestgjafa. Næstum sérhver þáttur innihélt kveikju til að gera það svipað og raunverulegar uppsetningar. Í sumum tilfellum voru fleiri en ein kveikja. Fyrir einn nethnút voru til 3-000 kveikjur.
Uppfærslubil gagnahluta − 4-7 sekúndur. Ég stjórnaði álaginu sjálfu með því að nota ekki aðeins 50 lyf heldur bæta við fleiri. Einnig, með því að nota gagnaþætti, breytti ég álaginu á virkan hátt og minnkaði uppfærslubilið í 4 sek.
PostgreSQL. 35 nvps
Fyrsta keyrsla mín á þessum vélbúnaði var á hreinu PostgreSQL - 35 þúsund gildi á sekúndu. Eins og þú sérð tekur það brot úr sekúndu að setja inn gögn - allt er gott og hratt. Málið er bara að 200 GB SSD diskur fyllist fljótt.
Þetta er venjulegt afköst Zabbix miðlara mælaborð.
Fyrsta bláa línuritið er fjöldi gilda á sekúndu. Annað línuritið til hægri er hleðsla byggingarferla. Þriðja er að hlaða innri byggingarferlum: sögusamstillingar og Housekeeper, sem hefur verið í gangi hér í nokkuð langan tíma.
Fjórða línuritið sýnir HistoryCache notkun. Þetta er eins konar biðminni áður en það er sett inn í gagnagrunninn. Græna fimmta línuritið sýnir ValueCache notkun, það er hversu mörg ValueCache smellir fyrir kallar - þetta eru nokkur þúsund gildi á sekúndu.
PostgreSQL. 50 nvps
Síðan jók ég álagið í 50 þúsund gildi á sekúndu á sama vélbúnaði.
Þegar þú hleður frá Housekeeper tók það 10-2 sekúndur að setja inn 3 þúsund gildi.
Húsvörður er þegar farinn að trufla vinnuna.
Þriðja línuritið sýnir að almennt er álagið á veiðimenn og sögusamstilla enn 60%. Í fjórða línuritinu er HistoryCache þegar byrjað að fyllast nokkuð virkan meðan húsvörður starfar. Hann er 20% fullur, sem er um 0,5 GB.
PostgreSQL. 80 nvps
Síðan jók ég álagið í 80 þúsund gildi á sekúndu. Þetta eru um það bil 400 þúsund gagnaeiningar og 280 þúsund kveikjur.
Hleðslukostnaður þrjátíu sögusamstilla er nú þegar nokkuð hár.
Ég jók líka ýmsar breytur: sögusamstillingar, skyndiminni.
Á vélbúnaðinum mínum jókst hleðsla á sögusamstillingum að hámarki. HistoryCache fylltist fljótt af gögnum - gögn til vinnslu höfðu safnast fyrir í biðminni.
Allan þennan tíma fylgdist ég með því hvernig örgjörvinn, vinnsluminni og aðrar kerfisbreytur voru notaðar og komst að því að nýting disksins var í hámarki.
Ég hef náð notkuninni hámarks getu disks á þessum vélbúnaði og á þessari sýndarvél. Með slíkum styrkleika byrjaði PostgreSQL að skola gögn nokkuð virkan og diskurinn hafði ekki lengur tíma til að skrifa og lesa.
Annar þjónn
Ég tók annan netþjón, sem var þegar með 48 örgjörva og 128 GB af vinnsluminni. Ég stillti það - stillti það á 60 sögu samstillingu og náði viðunandi árangri.
Reyndar eru þetta nú þegar mörk framleiðni þar sem eitthvað þarf að gera.
TimescaleDB. 80 nvps
Aðalverkefni mitt er að prófa getu TimescaleDB gegn Zabbix álagi. 80 þúsund gildi á sekúndu er mikið, tíðni söfnunar mæligilda (fyrir utan Yandex, auðvitað) og nokkuð stórt „uppsetning“.
Það er dýfa í hverju línuriti - þetta er einmitt gagnaflutningurinn. Eftir bilanir í Zabbix þjóninum breyttist hleðslusnið sögusamstillingar mikið - það lækkaði þrisvar sinnum.
TimescaleDB gerir þér kleift að setja inn gögn næstum 3 sinnum hraðar og nota minna HistoryCache.
Í samræmi við það færðu gögn tímanlega.
TimescaleDB. 120 nvps
Síðan jók ég fjölda gagnaþátta í 500 þúsund. Aðalverkefnið var að prófa getu TimescaleDB - ég fékk reiknað gildi upp á 125 þúsund gildi á sekúndu.
Þetta er vinnandi „uppsetning“ sem getur virkað í langan tíma. En þar sem diskurinn minn var aðeins 1,5 TB fyllti ég hann á nokkrum dögum.
Það mikilvægasta er að á sama tíma voru ný TimescaleDB skipting búin til.
Þetta er algjörlega ómerkilegt fyrir frammistöðu. Þegar skipting er búin til í MySQL, til dæmis, er allt öðruvísi. Þetta gerist venjulega á nóttunni vegna þess að það hindrar almenna innsetningu, vinnur með töflur og getur skapað þjónusturýrnun. Þetta er ekki raunin með TimescaleDB.
Sem dæmi mun ég sýna eitt línurit frá mörgum í samfélaginu. Á myndinni er TimescaleDB virkt, þökk sé álaginu á að nota io.weight á örgjörvanum hefur minnkað. Notkun innri ferliþátta minnkaði einnig. Þar að auki er þetta venjuleg sýndarvél á venjulegum pönnukökudiskum, ekki SSD.
Niðurstöður
TimescaleDB er góð lausn fyrir litla „uppsetningu“, sem hafa áhrif á afköst disksins. Það mun leyfa þér að halda áfram að vinna vel þar til gagnagrunnurinn er fluttur yfir í vélbúnað eins fljótt og auðið er.
TimescaleDB er auðvelt að stilla, gefur árangur, virkar vel með Zabbix og hefur kosti umfram PostgreSQL.
Ef þú notar PostgreSQL og ætlar ekki að breyta því mæli ég með notaðu PostgreSQL með TimescaleDB viðbótinni í tengslum við Zabbix. Þessi lausn virkar á áhrifaríkan hátt upp í miðlungs „uppsetningu“.
Þegar við segjum „mikil afköst“ er átt við . Þú munt ekki þurfa að bíða lengi eftir að læra um tækni og venjur sem gera þjónustu kleift að þjóna milljónum notenda. Listi fyrir 7. og 8. nóvember höfum við þegar tekið saman, en hér fleira má benda á.
Gerast áskrifandi að okkar и , þar sem við afhjúpum eiginleika komandi ráðstefnu og komumst að því hvernig á að fá sem mest út úr henni.
Heimild: www.habr.com