Kõrge jõudlus ja natiivne jaotamine: Zabbix TimescaleDB toega

Zabbix on jälgimissüsteem. Nagu iga teine süsteem, seisab see silmitsi kolme põhiprobleemiga, mis on iseloomulikud kõikidele jälgimissüsteemidele: andmete kogumine ja töötlemine, ajaloo säilitamine, selle puhastamine.

Andmete saamise, töötlemise ja salvestamise etapid võtavad aega. Veidi, kuid suures süsteemis võivad need viivitused muutuda märkimisväärseteks. Säilitamise probleem on andmete juurde pääsemise küsimus. Neid kasutatakse aruandeid, kontrolle ja aktiveerimisi silmas pidades. Andmetele juurdepääsu viivitused mõjutavad samuti jõudlust. Kui andmebaasid suurenevad, tuleb vanad andmed eemaldada. Eemaldamine on nõudlik operatsioon, mis samuti neelab ära osa ressurssidest.

Aja viivituste probleemid andmete kogumisel ja hoiustamisel Zabbixis lahendatakse vahemäluga: erinevad vahemälude tüübid, andmebaasis vahemälu. Kolmanda probleemi lahendamiseks ei sobi vahemälu, seetõttu on Zabbixis kasutusele võetud TimescaleDB. Sellest räägib Andrei Guštin — tehnilise toe insener Zabbix SIA. Zabbixi tugiteenuste juures on Andrei töötanud üle 6 aasta ja puutub otseselt kokku jõudlusega.

Kuidas toimib TimescaleDB, millist jõudlust see võib anda võrreldes tavalise PostgreSQL-iga? Milline roll on Zabbixil TimescaleDB andmebaasis? Kuidas alustada nullist ja kuidas migreerida PostgreSQL-ilt ning millise konfiguratsiooni jõudlus on parem? Kõigest sellest allpool.

Jõudlusväljakutsed

Iga jälgimissüsteem seisab silmitsi teatud jõudlusväljakutsetega. Räägin kolmest: andmete kogumine ja töötlemine, salvestamine, ajaloo puhastamine.

Kiire andmete kogumine ja töötlemine. Hea jälgimissüsteem peaks kiiresti koguma kõik andmed ja töötlema need vastavalt aktiveerimiskriteeriumidele. Pärast töötlemist peaks süsteem samuti kiiresti salvestama need andmed andmebaasi, et neid hiljem kasutada.

Ajaloo säilitamine. Hea jälgimissüsteem peaks andmebaasis säilitama ajaloo ja pakkuma mugavat juurdepääsu mõõdikutele. Ajalugu on vajalik, et kasutada seda aruannetes, graafikutes, aktiveerimistes, lävendites ja arvutatud andmeelementides teavitamiseks.

Ajaloo puhastamine. Mõnikord tekib päev, kus te ei vaja metrikate salvestamist. Miks teil on andmeid, mis on kogutud viie aasta, kuu või kahe tagant: mõned sõlmed on eemaldatud, mõned hostid või meetrichad ei ole enam vajalikud, kuna need on vananenud ja lõppenud. Hea seire süsteem peaks salvestama ajaloolisi andmeid ja aeg-ajalt neid eemaldama, et andmebaas ei paisuks.

Vananevate andmete puhastamine on terav küsimus, mis mõjutab andmebaasi jõudlust.

Vahemälu Zabbixis

Zabbixis on esimene ja teine ülesanne lahendatud vahemäluga. Andmete kogumiseks ja töötlemiseks kasutatakse RAM-i. Ajaloo salvestamiseks kasutatakse triggereid, graafikuid ja arvutatud andmeelemente. Andmebaasi küljel on põhivõtmete jaoks teatud vahemälu, näiteks graafikute puhul.

Zabbix-serveri enda poolel on vahemälu:

• ConfigurationCache;
• ValueCache;
• HistoryCache;
• TrendsCache.

Vaatame neid lähemalt.

ConfigurationCache

See on peamine vahemälu, kus salvestame meetrikad, hostid, andmeelementid, triggereid — kõike, mis on vajalik eelprotsessinguks ja andmete kogumiseks.

Kõik see salvestatakse ConfigurationCache'i, et vältida liigseid päringuid andmebaasi. Pärast serveri käivitamist uuendame seda vahemälu, loome ja perioodiliselt värskendame konfigureeringud.

Andmete kogumine

Schéma on üsna suur, kuid peamine selles on kogujad. Need on erinevad „pollers” — kogumisprotsessid. Need vastutavad erinevate kogumise liikide eest: koguvad andmeid SNMP, IPMI kaudu ja edastavad kõik eelprotsessimisele.

Kogujad on tähistatud oranži joontega.

Zabbixis on olemas arvutatud agregatsioonielemendid, mis on vajalikud kontrollide agregatsiooniks. Kui meil neid on, siis saame andmed nende jaoks otse ValueCache'ist.

Eelprotsessimise Ajaloo vahemälu

Kõik kogujad kasutavad ConfigurationCache'i, et saada ülesandeid. Edasi edastavad nad need eelprotsessimisele.

Eelprotsessimine kasutab ConfigurationCache'i, et saada eelprotsessimise samme. See töötleb andmeid erinevatel viisidel.

Andmete töötlemise pärast eelprotsessimist salvestame need HistoryCache'i, et töödelda. Sellega lõpeb andmete kogumine ja liigume edasi Zabbixis põhiprotsessile — ajaloo sünkroniseerija, kuna see on monoliitne arhitektuur.

Märkuseks: eelprotsessimine on üsna ressursimahukas tehing. Alates versioonist 4.2 on see viidud proxyle. Kui teie Zabbix on väga suur ja tal on palju andmeelemente ning kogumissagedust, siis see kergendab tööd oluliselt.

ValueCache, ajalugu ja trendide cache

Ajaloo sünkroniseerija on peamine protsess, mis töötleb iga andme elementi atomaarsetena, st iga väärtust.

Ajaloo sünkroniseerija võtab väärtused HistoryCache'ist ja kontrollib konfiguratsiooni, et leida triggereid arvutamiseks. Kui need on olemas, arvutab ta.

Ajaloo sünkroniseerija loob sündmuse, eskaleerimise, et luua teateid, kui konfigureeritud, ja salvestab. Kui on triggereid edasise töötlemise jaoks, salvestab ta selle väärtuse ValueCache'isse, et mitte pöörduda ajaloote tabeli poole. Nii täiendatakse ValueCache'i andmetega, mis on vajalikud triggereid arvutamise elementide jaoks.

Ajaloo sünkroniseerija salvestab kõik andmed andmebaasi ja see salvestab andmed kettale. Töötlemise protsess lõpeb sellega.

Kätšimine andmebaasis

Andmebaasi poolel on erinevad kätšid, kui soovite vaadata graafikuid või aruandeid sündmuste kohta:

• Innodb_buffer_pool MySQL pool;
• shared_buffers PostgreSQL pool;
• effective_cache_size Oracle'i pool;
• shared_pool DB2 poolel.

On veel palju teisi kätše, aga need on peamised kõigi andmebaaside jaoks. Need võimaldavad hoida faile mälus, mis on sageli vajalikud päringute jaoks. Neil on selleks oma tehnoloogiad.

Andmebaasi jõudlus on kriitiliselt tähtis

Zabbix-server kogub pidevalt andmeid ja salvestab neid. Ta ka loeb ajaloost, et täita ValueCache'i pärast taaskäivitamist. Skripte ja aruandeid kasutatakse Zabbix API, mis on rajatud veebiliidese baasil. Zabbix API pöördub andmebaasi poole ja saab vajalikud andmed graafikute, aruannete, sündmuste loendite ja viimaste probleemide jaoks.

Visualiseerimiseks — Grafana. Meie kasutajate seas on see populaarne lahendus. See oskab otse Zabbix API ja andmebaasi kaudu päringuid saata ja loob teatava konkurentsi andmete saamiseks. Seetõttu on vaja peent ja head andmebaasi seadistust, et tagada kiire tulemuste väljastamine ja testimine.

Housekeeper

Kolmas jõudluse väljakutse Zabbixis on ajaloo puhastamine Housekeeper'iga. See järgib kõik seadistused — andmeelementides on määratud, kui palju hoida dünaamikat muutuste osas päevade jooksul.

TrendsCache'i arvutame jooksvalt. Kui andmed saavad, kogume need ühe tunni jooksul ja salvestame need tabelitesse muutuste dünaamika jaoks.

Housekeeper käivitub ja eemaldab andmeid andmebaasist tavaliste "selectide" kaudu. See ei ole alati efektiivne, mida saab aru performance graafikutest sisestes protsessides.

Punane graafik näitab, et History syncer on pidevalt hõivatud. Ülemine oranž graafik on Housekeeper, mis käivitub pidevalt. Ta ootab andmebaasilt, millal see kustutab kõik read, mille ta on määranud.

Millal tuleks Housekeeper välja lülitada? Näiteks, kui on olemas "Item ID" ja tuleb kustutada viimased 5000 rida teatud ajavahemiku jooksul. Loomulikult toimub see indeksite kaudu. Kuid tavaliselt on andmekogum väga suur, ja andmebaas loeb ikkagi kettalt ja tõstetakse vahemällu. See on alati väga kulukas operatsioon andmebaasi jaoks ja sõltuvalt andmebaasi suurusest võib see põhjustada jõudluse probleeme.

Housekeeperi saab lihtsalt välja lülitada. Veebiliideses on seadistus "Administration general" sektsioonis Housekeeper. Lülitame välja sisemise Housekeeping'i sisemise trendi ajaloos ja ta ei halda seda enam.

Housekeeper on välja lülitatud, graafikud on tasakaalu jõudnud — millised probleemid võivad sel juhul esineda ja mis võib aidata kolmanda jõudluse väljakutse lahendamisel?

Partitioning — sektsioonide loomine või jagamine

Tavaliselt seadistatakse partitsioneerimine erinevate meetoditega igas relaatsioonilises andmebaasis, mille ma loetlesin. Igal on oma tehnoloogia, kuid need on sarnased. Uue partitsiooni loomine toob sageli kaasa teatud probleemid.

Tavaliselt seadistatakse partitsioonid sõltuvalt "setup'ist" — päevade jooksul kogunevate andmete arv. Üldiselt seavad nad Partitioning'i ühe päeva kaupa, see on miinimum. Uute trendide jaoks on partitsioon seadistatud 1 kuu kaupa.

Väärtused võivad muutuda väga suure "setup'i" korral. Kui väike "setup" on kuni 5000 nvps (uus väärtus sekundis), keskmine — 5000 kuni 25000, siis suur — üle 25000 nvps. Need on suured ja väga suured installatsioonid, mis nõuavad andmebaasi täpset seadistamist.

Väga suurte installatsioonide puhul võib ühe päeva lõik mitte olla optimaalne. Olen näinud MySQL partitsioone, mis on 40 GB ja rohkem päevas. See on väga suur andmehulga kogus, mis võib põhjustada probleeme ja seda tuleb vähendada.

Mida annab Partitioning?

Tabelite sektsioneerimine. Sageli on need eraldi failid kettal. Päringute plaan valib optimaalselt ühe partitsiooni. Tavaliselt kasutatakse partitsioneerimist vahemiku järgi — Zabbixi puhul kehtib see samuti. Me kasutame seal "timestamp" — aeg alates ajajoonest. Meil on see tavalised numbrid. Sa määratled päeva alguse ja lõpu — see on partitsioon.

Kiire kustutamine — DELETE. Valitakse üks fail/alamsaal, mitte ridade valik kustutamiseks.

Märgatavalt kiirendab andmete valimist SELECT — kasutab ühte või rohkem partitsiooni, mitte kogu tabelit. Kui sa pöördud kahe päeva taguste andmete poole, valitakse need andmebaasist kiiremini, kuna tuleb laadida ainult üks fail vahemällu, mitte suur tabel.

Sageli kiirendab see ka paljusid andmebaase INSERT — lisamisi lastetabelisse.

TimescaleDB

Versioonis 4.2 oleme tähelepanu pööranud TimescaleDB-le. See on PostgreSQL-i laiendus, millel on natiivne liides. Laiendus töötab efektiivselt ajajoonte andmetega, kaotamata samas relatsiooniliste andmebaaside eeliseid. TimescaleDB ka partitsioneerib automaatselt.

TimescaleDB-s on mõisted hüpertabel (hypertable), mille sa lood. Selle sees on chunkid — partitsioonid. Chunkid on automaatselt hallatavad fraktsioonid hüpertabelist, mis ei mõjuta teisi fraktsioone. Igal chunkil on oma ajavahemik.

TimescaleDB vs PostgreSQL

TimescaleDB töötab tõeliselt efektiivselt. Laienduse tootjad väidavad, et nad kasutavad õiget päringute töötlemise algoritmi, eriti <code>inserts<\/code>. Kui andmehulkade sisestamine kasvab, toetab algoritm pidevat jõudlust.

Pärast 200 miljonit rida hakkab PostgreSQL tavaliselt tugevalt aeglustuma ja kaotab jõudluse kuni 0. TimescaleDB võimaldab tõhusalt "inserts" sisse viia igasugustes andmehulkades.

Paigaldamine

TimescaleDB installimine on piisavalt lihtne igasuguste pakettide jaoks. Kõik sellega seoses on üksikasjalikult kirjeldatud — see sõltub ametlikest PostgreSQL-i paketidest. TimescaleDB-d saab ka käsitsi koostada ja komponeerida. dokumentatsioon Zabbixi andmebaasi jaoks aktiveerime lihtsalt laienduse:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

Sa aktiveerid

laienduse ja lood selle Zabbixi andmebaasi jaoks. Viimane samm on hüpertabeli loomine. Ajaloo tabelite migreerimine TimescaleDB-s

Selleks on spetsiaalne funktsioon

create_hypertable 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

Funktsiooni kolm parameetrit. Esimene — tabel andmebaasis, mille jaoks tuleb luua hüpertabel. Teine — välja, mille alusel tuleb luua chunk_time_interval — partitsioonide chunkide vaheline intervall, mida tuleb kasutada. Minu puhul on intervall üks päev — 86 400.

Kolmas parameeter — andmete üleviimine. Kui määrata true, siis kõik olemasolevad andmed migreeritakse eelnevalt loodud chunkidesse. Kasutasin ise andmete üleviimine. Mul oli umbes 1 TB, mis võttis rohkem kui tunni. Isegi testimise käigus eemaldasin ma mittevajalikud ajaloolised andmed tähemärgi tüüpides, et neid ei migreeritaks.

Viimane samm — UPDATE: db_extension määra timescaledb, et andmebaas mõistaks, et see laiendus on olemas. Zabbix aktiveerib selle ja kasutab õigesti süntaksit ja päringuid andmebaasi — funktsioonid, mis on vajalikud TimescaleDB jaoks.

Riistvara konfiguratsioon

Kasutasin kahte serverit. Esimene — VMware masin. See on piisavalt väike: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz protsessorit, 16 GB RAM-i ja 200 GB SSD-disk.

Installeerisin sellele PostgreSQL 10.8 koos Debian 10.8-1.pgdg90+1 operatsioonisüsteemiga ja xfs failisüsteemiga. Kõik on minimaalselt seadistatud, et saaks kasutada just seda andmebaasi, välja arvatud see, et Zabbix kasutab seda ise.

Sellel masinal seisis Zabbix-server, PostgreSQL ja koormuse agentuurid. Mul oli 50 aktiivset agenti, mis kasutasid LoadableModule, et väga kiiresti genereerida erinevaid tulemusi: numbreid ja stringe. Täitsin andmebaasi suure hulga andmetega.

Algne konfiguratsioon sisaldas 5 000 andmelementi iga hosti kohta. Peaaegu iga element sisaldas käivitajat, et see sarnaneks reaalsete installeerimisega. Mõnel juhul oli rohkem kui üks käivitaja. Ühe võrgu sõlme kohta tuli 3 000-7 000 käivitajat.

Andmeelementide uuendamise intervall — 4-7 sekunditKoormust reguleerisin sellega, et kasutasin mitte ainult 50 agenti, vaid lisasin veel. Samuti reguleerisin dünaamiliselt koormust andmeelementide abil ja vähendasin värskendamise intervalli 4 sekundini.

PostgreSQL. 35 000 nvps

Esimene käivitamine selle riistvara peal oli mul puhta PostgreSQL-ga — 35 tuhat väärtust sekundis. Nagu näha, kestab andmete sisestamine murdosa sekundist — kõik on hea ja kiire. Üks asi, SSD-disk 200 GB täitub kiiresti.

See on standardne Zabbixi jõudluse armatuurlaud — serverite jaoks.

Esimene sinine graafik — väärtuste arv sekundis. Teine graafik paremal — töötluse koormus. Kolmas — sisemiste töötluse protsesside koormus: ajaloo sünkroniseerijad ja Housekeeper, mis siin töötas küllaltki kaua.

Neljas graafik näitab HistoryCache'i kasutamist. See on mingi puhver enne andmete sisestamist BDsse. Roheline viies graafik näitab ValueCache'i kasutamist, see tähendab, kui palju ValueCache'i hitte käivitajatele — see on mitu tuhat väärtust sekundis.

PostgreSQL. 50 000 nvps

Siit edasi suurendasin koormust 50 tuhande väärtuseni sekundis sellel samal riistvaral.

Housekeeperi laadimise korral sisestati 10 tuhat väärtust 2-3 sekundiga.

Housekeeper hakkab juba tööle segama.

Kolmandast graafikust nähtub, et üldiselt on trapperite ja ajaloo sünkroniseerijate koormus veel 60% tasemel. Neljandas graafikus täitus HistoryCache Housekeeperi töö ajal juba piisavalt aktiivselt. See täitus 20% — see on umbes 0,5 GB.

PostgreSQL. 80 000 nvps

Siit edasi suurendasin koormust 80 tuhande väärtuseni sekundis. See on ligikaudu 400 tuhat andmeelementi ja 280 tuhat käivitajat.

Kolmekümne ajaloo sünkroniseerija koormus on juba piisavalt kõrge sisestamise juures.

Samuti suurendasin erinevaid parameetreid: ajaloo sünkroniseerijad, vahemälud.

Minu riistvaral tõusis ajaloo sünkroniseerijate koormus maksimumini. HistoryCache täitus kiiresti andmetega — puhvri kogunesid andmed töötlemiseks.

Kogu selle aja jälgisin, kuidas kasutati protsessorit, RAM-i ja muid süsteemi parameetreid ning leidsin, et ketaste koormus oli maksimaalne.

Ma saavutasin ketta maksimaalse kasutuse sellel riistvaral ja sellel virtuaalsel masinal. Nii intensiivse töö korral hakkas PostgreSQL andmeid aktiivselt kustutama ja ketas ei suudnud enam kirjutada ja lugeda.

Teine server

Võtsin teise serveri, millel oli juba 48 protsessorit ja 128 GB RAM-i. Häälestasin selle — paigaldasin 60 ajaloosünkroniseerijat ja saavutasin vastuvõetava jõudluse.

Tegelikult on see juba jõudluse piir, kus on vaja midagi ette võtta.

TimescaleDB. 80 000 nvps

Minu peamine ülesanne on testida TimescaleDB võimeid Zabbixi koormuse all. 80 tuhat väärtust sekundis — see on palju, mõõtmiste kogumise sagedus (välja arvatud Yandex, muidugi) ja piisavalt suur „setup“.

Igal graafikul on langus — see on just andmete migratsioon. Pärast langusi Zabbixi serveris muutus ajaloosünkroniseerija koormusprofiil väga palju — langes kolmandiku võrra.

TimescaleDB võimaldab andmeid sisestada praktiliselt 3 korda kiiremini ja kasutada vähem HistoryCache'i.

Seega, andmed tarnitakse teile õigeaegselt.

TimescaleDB. 120 000 nvps

Hiljem suurendasin andmeelementide arvu kuni 500 tuhande. Peamine ülesanne oli testida TimescaleDB võimeid — sain arvutatud väärtuse 125 tuhat väärtust sekundis.

See on töökindel „setup“, mis võib pikalt töötada. Kuid kuna minu ketas oli vaid 1,5 TB, täitsin selle mõne päevaga.

Kõige olulisem on see, et sel ajal loodi uusi TimescaleDB partitsioone.

Jõudluse jaoks on see täiesti märkamatult. Kui MySQL-is luuakse partitsioonid, toimub see hoopis teistmoodi. Reeglina toimub see öösel, sest see blokeerib üldise sisestamise, töötamise tabelitega ja võib tekitada teenuse halvenemist. TimescaleDB korral seda ei juhtu.

Näiteks näitan ühte graafikut paljusid kogukonna graafikuid. Pildil on sisse lülitatud TimescaleDB, tänu millele on io.weight kasutamine protsessoril vähenenud. Sisemiste protsesside elementide kasutamine on samuti vähenenud. Samas on see tavaline virtuaalmasin tavalistel ketastel, mitte SSD-l.

Järeldused

TimescaleDB on hea lahendus väikeste „setup’ide“ jaoks,, mis puutuvad diskide jõudlusest kinni. See võimaldab suhteliselt hästi jätkata tööd enne andmebaasi migratsiooni kiiremaks riistvaraks.

TimescaleDB on lihtne seadistada, annab jõudluskasvu, teeb head koostööd Zabbixi ja omab eeliseid PostgreSQL-i ees..

Kui kasutate PostgreSQL-i ega plaani seda vahetada, siis soovitan kasutada PostgreSQL-i koos TimescaleDB laiendiga koostöös Zabbixiga.See lahendus töötab tõhusalt keskmiste „setup’ide“ puhul.

Kui räägime „kõrgest jõudlusest“ — peame silmas HighLoad++. Oodata, et tutvuda tehnoloogiate ja praktikatega, mis võimaldavad teenustel teenindada miljoneid kasutajaid, ei pea kaua ootama. Loetelu ettekannetest 7. ja 8. novembriks oleme juba koostanud, kuid kohtumisi on veel võimalik pakkuda.

Liituge meiega uudiskirja ja telegram, kus avaldame eeloleva konverentsi nõksud ja saate teada, kuidas maksimaalselt kasu saada.

Allikas: habr.com