Kõrge jõudluse ja kohandatud partitsioneerimisega: Zabbix koos TimescaleDB toega

Zabbix — see monitooring süsteem. Nagu iga teine süsteem, seisab ka see silmitsi kolme peamise probleemiga: andmete kogumine ja töötlemine, ajaloo säilitamine ning selle puhastamine.

Andmete saamise, töötlemise ja salvestamise etapid võtavad aega. Veidi, kuid suure süsteemi puhul võib see tähendada suuri viivitusi. Säilitamise probleem on seotud andmete ligipääsuga. Need on vajalikud aruannete, kontrollide ja käivitajate jaoks. Andmete ligipääsu viivitused mõjutavad samuti jõudlust. Kui andmebaasid kasvavad, tuleb outdated andmed eemaldada. Eemaldamine on keeruline operatsioon, mis sööb samuti osa ressurssidest.

Zabbixi andmete kogumise ja säilitamise viivituste probleem lahendatakse vahemälu kasutamisega: erinevad vahemälu tüübid, vahemälu andmebaasis. Kolmanda probleemi lahendamiseks vahemälu ei sobi, seetõttu kasutab Zabbix TimescaleDB-d. Selle kohta räägib Andrei Gushchin — tehnilise toe insener Zabbix SIA. Zabbixi tehnikatoe valdkonnas on Andrei tegelenud juba üle 6 aasta ning ta tegeleb otse tootlikkuse küsimustega.

Kuidas TimescaleDB töötab, millist jõudlust see võib pakkuda 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õudluse väljakutsed

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

Kiire andmete kogumine ja töötlemine. Hea monitooringusüsteem peab kiiresti koguma kõik andmed ja töötlema need vastavalt triggeri väljenditele - oma kriteeriumide järgi. Pärast töötlemist peab süsteem need andmed ka kiiresti andmebaasi salvestama, et neid hiljem kasutada.

Ajaloo salvestamine. Hea monitooringusüsteem peab salvestama ajaloo andmebaasi ning andma mugava juurdepääsu mõõdikutele. Ajalugu on vajalik, et kasutada seda aruannetes, graafikutes, triggerites, läve väärtustes ja arvutatud andmeelementides teavitamiseks.

Ajaloo puhastamine. Mõnikord tuleb päev, mil te ei vaja enam mõõdikute salvestamist. Miks peaksid teid huvitama viis aastat tagasi kogutud andmed, kuu või kaks: mõned sõlmed on eemaldatud, mõned hostid või mõõdikud ei ole enam vajalikud, kuna need on aegunud ja lakanud kogumast. Hea jälgimissüsteem peaks säilitama ajaloolisi andmeid ja aeg-ajalt need kustutama, et andmebaas ei laieneks.

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

Zabbixi vahemälu

Zabbixis lahendatakse esimene ja teine ​​kõne vahemälu abil. Andmete kogumiseks ja töötlemiseks kasutatakse töömälu. Ajaloo säilitamiseks kasutatakse triggereid, graafikuid ja arvutatud andmeelemente. Andmebaasi pool on teatav vahemälu peamiste valikute jaoks, näiteks graafikute jaoks.

Zabbixi serveri enda poolel on vahemälu:

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

Vaatame neid lähemalt.

ConfigurationCache

See on põhivahemälu, kus hoiame mõõdikuid, hoste, andmeelemente, triggereid — kõike, mis on vajalik eelprotsessimiseks ja andmete kogumiseks.

Kõik see salvestatakse ConfigurationCache'i, et vältida tarbetuid päringuid andmebaasi. Pärast serveri käivitamist uuendame selle vahemaa, loome ja perioodiliselt uuendame konfiguratsioone.

Andmete kogumine

Skeem on piisavalt suur, kuid peamine on see — kogujad. Need on erinevad «pollers» — kogumisprotsessid. Need vastutavad erinevat tüüpi kogumise eest: koguvad andmeid SNMP, IPMI kaudu ja edastavad need PreProcessingule.

Kogujad on märgitud oranži joonega.

Zabbixis on arvutatud aggregatsioonielemente, mis on vajalikud kontrollide kogumiseks. Kui meil on need olemas, saame andmed otse ValueCache'ist.

PreProcessing HistoryCache

Kõik kogujad kasutavad ConfigurationCache'i ülesannete saamiseks. Edasi edastavad nad need PreProcessingule.

PreProcessing kasutab ConfigurationCache'i, et saada PreProcessing'i samme. Ta töötleb neid andmeid erinevate viisidega.

Andmete töötlemise järel PreProcessinguga salvestame need HistoryCache'i, et neid töödelda. Sellega lõpeb andmete kogumine ja liigume Zabbixis peamise protsessi juurde — history syncer, kuna see on monoliitne arhitektuur.

Märkus: PreProcessing on piisavalt raske operatsioon. Alates versioonist 4.2 on see viidud proxy'le. Kui teil on väga suur Zabbix koos suure andmeelemendite ja kogumisvõimega, lihtsustab see tööd oluliselt.

ValueCache, ajalugu & trendide vahemälu

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

Ajaloo sünkroniseerija võtab väärtused HistoryCache'st ja kontrollib Configuration'is, kas on olemas käivitajaid arvutuste jaoks. Kui need on olemas — arvutab.

Ajaloo sünkroniseerija loob sündmuse, eskaleerimise, et genereerida teateid, kui see on konfigureeritud, ja salvestab. Kui on käivitajad edasiseks töötluseks, salvestab see väärtuse ValueCache'sse, et mitte pöörduda ajaloote tabelisse. Nii täidetakse ValueCache andmetega, mis on vajalikud käivitajate ja arvutatud elementide arvutamiseks.

Ajaloo sünkroniseerija salvestab kõik andmed andmebaasi, mis salvestab need ketta peale. Töötlusprotsess lõpeb sellega.

Vahemälu andmebaasis

Andmebaasi poolest on olemas erinevad vahemälu, kui soovite vaadata graafikuid või aruandeid sündmuste kohta:

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

On veel teisi vahemälusid, kuid need on põhilised kõikide andmebaaside jaoks. Need võimaldavad hoida operatiivmälu andmeid, mis on sageli vajalikud päringute jaoks. Neil on selleks oma tehnoloogiad.

Andmebaasi jõudlus on kriitilise tähtsusega

Zabbix-server kogub pidevalt andmeid ja salvestab neid. Ta loeb ka käivitamisel ajaloost, et täita ValueCache'i. Skripte ja aruandeid kasutatakse Zabbix API, mis on üles ehitatud Web-liidese alusel. Zabbix API pöördub andmebaasi ja saadab vajalikud andmed graafikute, aruannete, sündmuste loendite ja viimaste probleemide jaoks.

Visualiseerimiseks — Grafana. Meie kasutajate seas on see populaarne lahendus. See oskab otse saata päringuid nii Zabbix API kaudu kui ka andmebaasi ning loob teatava konkurentsi andmete saamisel. Seetõttu on vajalik peen ja hea andmebaasi seadistus, et vastata kiirete tulemuste ja testimise nõuetele.

Housekeeper

Zabbixi kolmas jõudluse väljakutse on ajaloo puhastamine Housekeeperi abil. See järgib kõiki seadeid — andmeelementides on määratud, kui kaua säilitada muutuste dünaamikat (trendide) päevades.

TrendsCache arvutame reaalajas. Andmete saabumisel kogume need kokku ühe tunni jooksul ja salvestame tabelitesse trendimuutuste dünaamika jaoks.

Housekeeper käivitub ja kustutab andmed andmebaasist tavapäraste «select» päringutega. See pole alati efektiivne, mida võib näha sisemiste protsesside jõudluse graafikutelt.

Punane graafik näitab, et History syncer on pidevalt koormatud. Ülemine oranž graafik — see on Housekeeper, mis käivitub pidevalt. Ta ootab andmebaasilt, et see kustutaks kõik realood, mille ta on seadnud.

Millal tuleks Housekeeper välja lülitada? Näiteks, kui on olemas «Item ID» ja tuleb kustutada viimased 5000 rida kindla aja jooksul. Loomulikult toimub see indeksite kaudu. Kuid tavaliselt on andmestik väga suur ja andmebaas loeb ikkagi kettalt ja tõstab andmed vahemälusse. See on alati andmebaasi jaoks väga kulukas operatsioon ja sõltuvalt andmebaasi suurusest võib see põhjustada jõudlusprobleeme.

Housekeeperi saab lihtsalt välja lülitada. Veebiliideses on seadistus «Administration general» all Housekeeperi jaoks. Lülitame välja sisemise Housekeeping'i sisemise trendiajaloo jaoks ja ta ei jälgi seda enam.

Majapidamise teenus on suletud, ajakavad on joondunud — millised võivad olla probleemid ja mis aitavad lahendada kolmandat jõudluskõnet?

Partitsioneerimine — sektsioonimine või partitsioonimine

Tavaliselt seadistatakse partitsioneerimine erinevalt igas relatsioonilises andmebaasis, mille olen loetlenud. Igal on oma tehnoloogia, kuid nad on üldiselt sarnased. Uue partitsiooni loomine toob sageli kaasa teatud probleeme.

Tavaliselt seadistatakse partitsioonid sõltuvalt «setup'ist» — päevast loodud andmete arvust. Üldiselt määratakse partitsioneerimine ühe päeva kohta, see on miinimum. Uute partitsioonide trendide jaoks — 1 kuu.

Väärtused võivad muutuda väga suure «setup'i» puhul. Kui väike «setup» on kuni 5 000 nvps (uus väärtus sekundis), keskmine — 5 000 kuni 25 000, siis suur — üle 25 000 nvps. Need on suured ja väga suured installatsioonid, mis nõuavad hoolikat andmebaasi seadistamist.

Väga suurte installatsioonide puhul ei pruugi ühe päeva andmeosa olla optimaalne. Olen näinud MySQL-is partitsioone, mis ulatuvad 40 GB ja rohkem ühe päeva kohta. See on väga suur andmemahu, mis võib põhjustada probleeme, ning seda tuleks vähendada.

Mida annab partitsioneerimine?

Tabelite sektsioneerimine. Sageli on need eraldi failid kettal. Küsimuste plaan valib optimaalsemalt ühe partitsiooni. Tavaliselt kasutatakse partitsioneerimist vahemiku järgi — Zabbixi puhul kehtib see samuti. Me kasutame seal "timestamp" — aega alates ajaloost. Meil on need tavalised numbrid. Määrate päeva alguse ja lõpu — see on partitsioon.

Kiire eemaldamine — DELETE. Valitakse üks fail/alamtabel, mitte ridade valik kustutamiseks.

Oluliselt kiirendab andmete valikut SELECT — kasutab ühte või enamat partitsiooni, mitte kogu tabelit. Kui pöördute 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 paljude andmebaaside INSERT — sisestusi child-tabelisse.

TimescaleDB

Versioonis 4.2 keskendume TimescaleDB-le. See on PostgreSQL-i täiendus, mis pakub natiivset liidest. Täiendus töötab tõhusalt ajareadade andmetega, kaotamata samas relaatsiooniliste andmebaaside eeliseid. TimescaleDB jagab andmed automaatselt partitsioonidesse.

TimescaleDB-s on kontseptsioon hüperdb (hüperdb), mille te loote. See sisaldab chunk'e — partitsioonid. Chunk'id on automaatselt hallatavad hüperdb-fragmentide tükid, mis ei mõjuta teisi fragmente. Iga chunk omab oma ajavahemikku.

TimescaleDB vs PostgreSQL

TimescaleDB toimib tõeliselt efektiivselt. Täienduse tootjad väidavad, et nad kasutavad paremat päringute töötlemise algoritmi, seal hulgas <code>inserts</code>. Kui dataset-i sisendi suurus kasvab, säilitab algoritm pideva jõudluse.

Pärast 200 miljonit rida hakkab PostgreSQL tavaliselt madalaks jääma ja kaotab jõudluse 0-ni. TimescaleDB võimaldab tõhusalt sisestada ‘inserts’ ükskõik millise andmehulgaga.

Installeerimine

TimescaleDB installimine on piisavalt lihtne kõigi paketide jaoks. Üksikasjad on dokumentatsioonis kõik on hoolikalt dokumenteeritud — see sõltub ametlikest PostgreSQL paketidest. TimescaleDB-d saab ka käsitsi koguda ja kompileerida.

Zabbixi andmete baasi jaoks aktiviseerime lihtsalt laiendi:

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

Te aktiveerite laiendi ja loote selle Zabbixi andmete baasile. Viimane samm on hüpertableti loomine.

Ajaloo tabelite migratsioon 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. Esimene — tabel andmete baasis, mille jaoks tuleb hüpertablett luua. Teine — väli, mille põhjal tuleb luua chunk_time_interval — partitsioonide chunkide intervall, mida kasutada. Minu juhul on intervall üks päev — 86 400.

Kolmas parameeter — andmed_migreerida. Kui seadistada true, siis kõik praegused andmed kantakse üle ettevalmistatud chunk'idesse. Olen ise kasutanud andmed_migreerida. Mul oli umbes 1 TB, mis võttis rohkem kui tunni. Isegi mingites testimiste puhul kustutasin ma valikulised ajaloolised andmed sümbolitest, et neid mitte üle kanda.

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

Riistvara konfiguratsioon

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

Installeerisin selle peale PostgreSQL 10.8 koos Debian 10.8-1.pgdg90+1 ja failisüsteemiga xfs. Kõik oli minimaalne seadistatud, et kasutada just seda andmebaasi, välja arvatud see, mida kasutab Zabbix ise.

Sama masin käitas Zabbix-serveri, PostgreSQL-i ja koormuse agente. Mul oli 50 aktiivset agenti, kes kasutasid LoadableModule, et väga kiiresti genereerida erinevaid tulemusi: numbreid, stringe. Täitsin andmebaasi suure hulga andmetega.

Algne konfiguratsioon sisaldas 5 000 elementi iga hosti kohta. Peaaegu iga element sisaldas käivitajat, et see oleks sarnane reaalsetele installatsioonidele. Mõnel juhul oli rohkem kui üks käivitaja. Ühe võrgu sõlme kohta tuli 3 000–7 000 käivitatavat.

Andmeelementide värskendamise intervall on 4–7 sekundit. Koormust reguleerisin sellega, et kasutasin mitte ainult 50 agendi, vaid lisasin veel. Samuti reguleerisin andmeelementide abil dünaamiliselt koormust ja vähendasin värskendamise intervalli 4 sekundini.

PostgreSQL. 35 000 nvps

Esimene käivitus sellel riistvaral oli puhtal PostgreSQL-il – 35 000 väärtust sekundis. Nagu näha, andmete sisestamine võtab murdosa sekundist – kõik toimib hästi ja kiiresti. Ainus probleem on see, et 200 GB SSD-disk täitub kiiresti.

See on Zabbixi standardne jõudlusjuhtpaneel — serverite jaoks.

Esimene sinine diagramm näitab väärtuste arvu sekundis. Teine diagramm paremal poolel näitab kogumise protsesside koormust. Kolmas diagramm – sisemiste kogumise protsesside koormus: ajaloo sünkroniseerijad ja Housekeeper, mis siin töötas piisavalt kaua.

Neljas graafik näitab HistoryCache'i kasutust. See on vahemälu enne andmebaasi sisestamist. Roheline viies graafik näitab ValueCache'i kasutust, st kui palju ValueCache'i hitte aktiveerijate jaoks — see on mitu tuhat väärtust sekundis.

PostgreSQL. 50 000 nvps

Siis suurendasin koormust kuni 50 000 väärtuseni sekundis samal riistvaral.

Housekeeper'i laadimisel sisestati 10 000 väärtust 2-3 sekundiga.

Housekeeper hakkab juba tööle segama.

Kolmandalt graafikult on näha, et üldiselt on trapperite ja ajaloosünkroniseerijate koormus veel 60% tasemel. Neljandal graafikul täitub HistoryCache Housekeeper'i töö ajal juba piisavalt aktiivselt. See on täitunud 20% — umbes 0,5 GB.

PostgreSQL. 80 000 nvps

Seejärel suurendasin koormust kuni 80 000 väärtuseni sekundis. See on umbes 400 000 andmeelementi ja 280 000 aktiveerijat.

Kolmekümne ajaloosünkroniseerija koormus on juba piisavalt kõrge.

Suurendasin ka erinevaid parameetreid: ajaloosünkroniseerijad, vahemälud.

Minu riistvaral suurenes ajaloosünkroniseerijate koormus maksimumini. HistoryCache täitus kiiresti andmetega — vahemällu kogunesid andmed töötlemiseks.

Kogu selle aja olen jälginud, kuidas protsessor, mälu ja süsteemi teised parameetrid töötavad, ja leidsin, et kettariski kasutus oli maksimaalne.

Olen saavutanud ketta maksimaalsete võimaluste kasutamise selle riistvara ja selle virtuaalmasina puhul. Sellise intensiivsusega hakkas PostgreSQL andmeid piisavalt aktiivselt kustutama ja ketas ei jõudnud enam kirjutada ega lugeda.

Teine server

Võtsin teise serveri, millel oli juba 48 protsessorit ja 128 GB mälu. Häälestasin selle — paigaldasin 60 history syncer'i ja saavutasin rahuldava töökiirus.

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

TimescaleDB. 80 000 nvps

Minu põhieesmärk on testida TimescaleDB võimekust Zabbix'i koormuse all. 80 tuhat väärtust sekundis — see on palju, mõõtmisfrekvents (välja arvatud Yandex, loomulikult) ja üsna suur 'setup'.

Igal graafikul on auk — see on just andmete migratsioon. Pärast auke Zabbix-serveris muutus history syncer'i koormusprofiil väga oluliselt — langes kolmekordseks.

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

Seega, andmed tarnitakse teile õigeaegselt.

TimescaleDB. 120 000 nvps

Siis suurendasin andmeelementide arvu 500 tuhandele. Peamine ülesanne oli testida TimescaleDB võimeid — sain arvutatud väärtuseks 125 tuhat väärtust sekundis.

See on tööalune 'setup', mis suudab pikka aega töötada. Kuid kuna mu kettaruum oli vaid 1,5 TB, täitsin selle paaripäeva jooksul.

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

Sellel on jõudlusele täielik mõju. Kui näiteks MySQL-is luuakse partitsioone, on olukord hoopis teine. Tavaliselt toimub see öösel, kuna see blokeerib üldiseid sisestusi, töötlemist tabelitega ja võib põhjustada teenuse halvenemist. TimescaleDB puhul ei ole seda.

Näiteks näitan üht graafikut paljusid community-st. Pildil on lisatud TimescaleDB, tänu millele CPU io.weighti kasutamine langes. Ka sisemiste protsesside elementide kasutamine vähenes. Ja see on tavaline virtuaalmasin tavalistel ketastel, mitte SSD-del.

Järeldused

TimescaleDB on hea lahendus väikestele 'setup'idele., mis nad sõltuvad ketta jõudlusest. See võimaldab teil kenasti edasi töötada, kuni andmebaasi migreerimine kiiremale riistvarale on lõpule viidud.

TimescaleDB on lihtne seadistada, pakub jõudluse kasvu ja töötab hästi Zabbixi ning omab PostgreSQL-iga võrreldes eeliseid.

Kui kasutate PostgreSQL-i ega plaani seda muuta, soovitan kasutada PostgreSQL-i koos TimescaleDB laiendiga Zabbixiga. See lahendus töötab tõhusalt kuni keskmiste „seadete” korral.

Kui räägime „kõrgest jõudlusest”, siis peame silmas HighLoad++. Ootamine, et tutvuda tehnoloogiate ja praktikatega, mis võimaldab teenustel teenindada miljoneid kasutajaid, ei võta kaua aega. Loetelu ettekandeid 7. ja 8. novembri jaoks oleme juba koostanud, kuid kohtumisi saab veel pakkuda.

Liituge meie uudiskirjaga ja telegram, kus jagame infot tulevase konverentsi kohta ning saate teada, kuidas maksimaalselt kasu saada.

Allikas: habr.com