Zabbix is 'n moniteringstelsel. Soos enige ander stelsel, het dit drie hoofprobleme van alle moniteringstelsels: die insameling en verwerking van data, die stoor van geskiedenis en die skoonmaak daarvan.
Die stadiums van ontvangs, verwerking en optekening van data neem tyd. Nie veel nie, maar vir 'n groot stelsel kan dit groot vertragings tot gevolg hê. Die stoorprobleem is 'n kwessie van datatoegang. Hulle word gebruik vir verslae, tjeks en snellers. Datatoegangvertragings beïnvloed ook prestasie. Wanneer die databasis groei, moet irrelevante data uitgevee word. Skrap is 'n swaar operasie wat ook 'n paar hulpbronne opvreet.
Versamelings- en bergingsvertragingsprobleme in Zabbix word opgelos deur kas: verskeie soorte kas, kas in die databasis. Om die derde probleem op te los, is caching nie geskik nie, daarom is TimescaleDB in Zabbix gebruik. Sal daarvan vertel Andrey Gushchin - tegniese ondersteuning ingenieur . Andrey ondersteun Zabbix al vir meer as 6 jaar en is direk betrokke by prestasie.
Hoe werk TimescaleDB, watter prestasie kan dit lewer in vergelyking met gewone PostgreSQL? Watter rol speel Zabbix in TimescaleDB? Hoe om van voor af te begin en hoe om van PostgreSQL af te migreer en watter konfigurasieprestasie is beter? Dit alles onder die knie.
Prestasie-uitdagings
Elke moniteringstelsel staar sekere prestasie-uitdagings in die gesig. Ek sal oor drie van hulle praat: data-insameling en -verwerking, berging, geskiedenisskoonmaak.
Vinnige data-insameling en verwerking. ’n Goeie moniteringstelsel behoort vinnig al die data te ontvang en dit volgens sneller-uitdrukkings te verwerk – volgens sy eie kriteria. Na verwerking moet die stelsel ook hierdie data vinnig in die databasis stoor om dit later te kan gebruik.
Geskiedenisberging. 'n Goeie moniteringstelsel behoort geskiedenis in 'n databasis te stoor en maklike toegang tot metrieke te bied. Die geskiedenis is nodig om gebruik te word in verslae, grafieke, snellers, drempels en berekende waarskuwingsitems.
Vee geskiedenis uit. Soms kom daar 'n dag wanneer jy nie statistieke hoef te stoor nie. Hoekom het jy data nodig wat 5 jaar gelede, 'n maand of twee ingesamel is: sommige nodusse is verwyder, sommige gashere of metrieke is nie meer nodig nie, want hulle is verouderd en nie meer versamel nie. 'n Goeie moniteringstelsel behoort historiese data te stoor en dit van tyd tot tyd uit te vee sodat die databasis nie groei nie.
Die skoonmaak van verouderde data is 'n netelige kwessie wat 'n groot impak op databasisprestasie het.
Kas in Zabbix
In Zabbix word die eerste en tweede oproepe opgelos deur kas te gebruik. RAM word gebruik om data te versamel en te verwerk. Vir berging - geskiedenis in snellers, grafieke en berekende items. Aan die DB-kant is daar 'n mate van kas vir basiese keuses, soos grafieke.
Cache aan die kant van die Zabbix-bediener self is:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Laat ons dit in meer besonderhede oorweeg.
ConfigurationCache
Dit is die hoofkas waarin ons statistieke, gashere, data-items, snellers stoor - alles wat nodig is vir Voorverwerking en vir data-insameling.
Dit alles word in die ConfigurationCache gestoor om nie onnodige navrae in die databasis te skep nie. Nadat die bediener begin het, werk ons hierdie kas op, skep en werk ons gereeld konfigurasies op.
Data-insameling
Die skema is redelik groot, maar die belangrikste ding daarin is versamelaars. Dit is verskeie "pollers" - samestelling prosesse. Hulle is verantwoordelik vir verskillende soorte samestelling: hulle versamel data via SNMP, IPMI, en dra dit alles oor na PreProcessing.
Plukkers is in oranje omsirkel.
Zabbix het samevoegingsitems bereken wat nodig is om tjeks saam te voeg. As ons dit het, neem ons die data vir hulle direk vanaf die ValueCache.
Voorverwerking HistoryCache
Alle versamelaars gebruik die ConfigurationCache om poste te ontvang. Dan gee hulle dit deur na PreProcessing.
PreProcessing gebruik ConfigurationCache om PreProcessing-stappe te kry. Dit verwerk hierdie data op verskeie maniere.
Nadat ons die data met PreProcessing verwerk het, stoor ons dit in die HistoryCache om dit te verwerk. Dit voltooi die data-insameling en ons gaan aan na die hoofproses in Zabbix - geskiedenis sinchroniseer, aangesien dit 'n monolitiese argitektuur is.
Let wel: Voorverwerking is 'n redelik swaar operasie. Sedert v 4.2 is dit na 'n proxy geskuif. As jy 'n baie groot Zabbix het met 'n groot aantal items en versamelingsfrekwensie, maak dit dinge baie makliker.
ValueCache, geskiedenis en tendense kas
Geskiedenis sincer is die hoofproses wat elke data-element, dit wil sê elke waarde, atoomies verwerk.
Geskiedenissynchroniseerder neem waardes van HistoryCache en kontroleer die konfigurasie vir snellers vir berekeninge. As hulle is - bereken.
Geskiedenis-sinchronisasie skep 'n gebeurtenis, eskaleer om waarskuwings te skep indien dit deur konfigurasie vereis word, en rekords. As daar snellers vir verdere verwerking is, onthou dit hierdie waarde in die ValueCache om nie na die geskiedenistabel te verwys nie. Dit is hoe die ValueCache gevul word met die data wat nodig is om snellers, berekende items te bereken.
Geskiedenissynchroniseerder skryf alle data na die databasis, en dit skryf na skyf. Die verwerkingsproses eindig hier.
DB caching
Daar is verskeie kas aan die DB-kant wanneer jy na grafieke of gebeurtenisverslae wil kyk:
Innodb_buffer_poolaan die MySQL-kant;shared_buffersaan die PostgreSQL-kant;effective_cache_sizeaan die Oracle-kant;shared_poolaan die DB2-kant.
Daar is baie ander kas, maar dit is die belangrikste vir alle databasisse. Hulle laat jou toe om data in RAM te hou wat dikwels vir navrae benodig word. Hulle het hul eie tegnologie hiervoor.
Databasisprestasie is krities
Zabbix-bediener versamel voortdurend data en skryf dit neer. Wanneer dit weer begin word, lees dit ook uit die geskiedenis om die ValueCache te vul. Skripte en verslae gebruik Zabbix API, wat gebou is op die basis van die webkoppelvlak. Die Zabbix API kry toegang tot die databasis en haal die nodige data vir grafieke, verslae, gebeurtenislyste en onlangse kwessies op.
Vir visualisering - grafana. Dit is 'n gewilde oplossing onder ons gebruikers. Sy kan versoeke direk deur die Zabbix API en na die databasis stuur, en skep 'n sekere sameloop vir die verkryging van data. Daarom is 'n fyner en beter databasisinstelling nodig om by die vinnige lewering van resultate en toetsing te pas.
Huishulp
Die derde prestasie-uitdaging in Zabbix is om geskiedenis met Housekeeper skoon te maak. Dit respekteer al die instellings - die data-elemente dui aan hoe lank om die dinamika van veranderinge (tendense) in dae te stoor.
TrendsCache wat ons op die vlug bereken. Wanneer die data inkom, versamel ons dit in een uur en plaas dit in tabelle vir die dinamika van tendensveranderinge.
Huishulp begin en verwyder inligting van die databasis met die gewone "selekteer". Dit is nie altyd doeltreffend nie, wat uit die prestasiegrafieke van interne prosesse verstaan kan word.
Die rooi grafiek wys dat die Geskiedenis-sinchroniseerder voortdurend besig is. Die oranje grafiek aan die bokant is Housekeeper, wat voortdurend aan die gang is. Dit wag vir die databasis om al die rye wat dit gespesifiseer het uit te vee.
Wanneer moet jy huishoudster deaktiveer? Byvoorbeeld, daar is 'n "Item ID" en jy moet die laaste 5 duisend reëls in 'n sekere tyd uitvee. Natuurlik gebeur dit deur indekse. Maar gewoonlik is die datastel baie groot, en die databasis lees steeds van die skyf af en plaas dit in die kas. Dit is altyd 'n baie duur bewerking vir die databasis en kan, afhangende van die grootte van die databasis, tot prestasieprobleme lei.
Huishulp is maklik om uit te skakel. In die webkoppelvlak is daar 'n instelling in "Administrasie algemeen" vir Huishoudster. Deaktiveer interne huishouding vir interne tendensgeskiedenis en dit beheer dit nie meer nie.
Huishoudster is gedeaktiveer, grafika het afgeplat - wat kan die probleme in hierdie geval wees en wat kan help om die derde prestasie-uitdaging op te los?
Partisionering - partisionering of partisionering
Partisionering word gewoonlik op 'n ander manier opgestel op elke relasionele databasis wat ek gelys het. Elkeen het sy eie tegnologie, maar hulle is oor die algemeen soortgelyk. Die skep van 'n nuwe partisie lei dikwels tot sekere probleme.
Gewoonlik word partisies gekonfigureer na gelang van die "opstelling" - die hoeveelheid data wat op een dag geskep word. As 'n reël word partisionering in een dag opgestel, dit is die minimum. Vir nuwe partisieneigings - 1 maand.
Die waardes kan verander in die geval van 'n baie groot "opstelling". As 'n klein "opstelling" tot 5 000 nvps (nuwe waardes per sekonde) is, is 'n gemiddelde een van 5 000 tot 25 000, dan is 'n groot een bo 25 000 nvps. Dit is groot en baie groot installasies wat noukeurige konfigurasie van die databasis self vereis.
Op baie groot installasies is een dag dalk nie optimaal nie. Ek het MySQL-partisies van 40 GB of meer per dag gesien. Dit is 'n baie groot hoeveelheid data wat tot probleme kan lei en moet verminder word.
Wat gee partisionering?
Afskortingstafels. Dikwels is dit aparte lêers op skyf. Die navraagplan kies een partisie meer optimaal. Gewoonlik word partisionering volgens reeks gebruik - dit geld ook vir Zabbix. Ons gebruik daar "tydstempel" - die tyd sedert die begin van die epog. Ons het gereelde getalle. Jy stel die begin en einde van die dag - dit is 'n partisie.
Vinnige verwydering - DELETE. Een lêer/subtabel is gekies, nie 'n seleksie van rye vir uitvee nie.
Versnel datamonsterneming aansienlik SELECT - gebruik een of meer partisies, nie die hele tabel nie. As jy toegang tot twee dae oue data kry, haal dit dit vinniger van die databasis af, want jy hoef dit net in die kas te laai en net een lêer terug te stuur, nie 'n groot tabel nie.
Dikwels versnel baie databasisse ook INSERT - plaas in die kindertabel.
TydskaalDB
Vir v 4.2 het ons ons aandag op TimescaleDB gevestig. Dit is 'n PostgreSQL-uitbreiding met 'n inheemse koppelvlak. Die uitbreiding werk doeltreffend met tydreeksdata sonder om die voordele van relasionele databasisse te verloor. TimescaleDB partisies ook outomaties.
TimescaleDB het 'n konsep hipertabel (hiperbaar) wat jy skep. Daarin is stukke - afskortings. Brokkies is outomaties bestuurde fragmente van 'n hipertabel wat nie ander fragmente beïnvloed nie. Elke stuk het sy eie tydreeks.
TydskaalDB vs PostgreSQL
TimescaleDB is regtig doeltreffend. Die vervaardigers van die uitbreiding beweer dat hulle 'n meer korrekte navraagverwerkingsalgoritme gebruik, veral inserts . Soos die grootte van die datastel-insetsel groei, handhaaf die algoritme konstante werkverrigting.
Na 200 miljoen rye begin PostgreSQL gewoonlik baie sak en werkverrigting tot 0 verloor. TimescaleDB laat jou toe om doeltreffend "inserts" met enige hoeveelheid data in te voeg.
installasie
Die installering van TimescaleDB is maklik genoeg vir enige pakkette. IN alles is gedetailleerd - dit hang af van die amptelike PostgreSQL-pakkette. TimescaleDB kan ook met die hand gebou en saamgestel word.
Vir die Zabbix-databasis, aktiveer ons eenvoudig die uitbreiding:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
jy aktiveer extension en skep dit vir die Zabbix-databasis. Die laaste stap is om 'n hipertabel te skep.
Migreer geskiedenistabelle na TimescaleDB
Daar is 'n spesiale funksie hiervoor. 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
Die funksie het drie parameters. Eerstens - tabel in databasisDie waarvoor jy 'n hipertabel wil skep. Tweedens - gebied, waarvolgens dit nodig is om te skep chunk_time_interval - interval van partisie stukke wat gebruik moet word. In my geval is die interval een dag - 86 400.
Die derde parameter is migrate_data. Indien gestel true, dan word alle huidige data na voorafgeskepte stukke oorgedra. Ek het self gebruik migrate_data. Ek het omtrent 1 TB gehad wat meer as 'n uur geneem het. Selfs in sommige gevalle het ek tydens die toets die historiese data van karaktertipes wat opsioneel is vir berging uitgevee om dit nie oor te dra nie.
Laaste stap - UPDATE: in db_extension sit timescaledbsodat die databasis verstaan dat daar hierdie uitbreiding is. Zabbix aktiveer dit en gebruik die sintaksis en navrae korrek na die databasis - daardie kenmerke wat nodig is vir TimescaleDB.
Hardeware konfigurasie
Ek het twee bedieners gebruik. Eerstens - VMware masjien. Dit is klein genoeg: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 GB RAM en 'n 200 GB SSD-aandrywer.
Ek het PostgreSQL 10.8 daarop geïnstalleer met Debian OS 10.8-1.pgdg90+1 en xfs-lêerstelsel. Ek het alles minimaal gekonfigureer om hierdie spesifieke databasis te gebruik, minus wat Zabbix self sal gebruik.
Op dieselfde masjien was daar 'n Zabbix-bediener, PostgreSQL en laai agente. Ek het 50 aktiewe agente gehad wat gebruik het LoadableModuleom verskeie resultate baie vinnig te genereer: getalle, stringe. Ek het die databasis met baie data gevul.
Aanvanklik het die konfigurasie bevat 5 000 items data per gasheer. Byna elke element het 'n sneller bevat om dit soos regte installasies te laat lyk. In sommige gevalle was daar meer as een sneller. Een netwerknodus het 3 000-7 000 snellers.
Itemopdateringsinterval − 4-7 sekondes. Ek het die vrag self gereguleer deur nie net 50 agente te gebruik nie, maar meer by te voeg. Ook, met behulp van data-elemente, het ek die las dinamies gereguleer en die opdateringsinterval tot 4 s verminder.
PostgreSQL. 35 000 nvps
My eerste lopie op hierdie hardeware was op suiwer PostgreSQL - 35 duisend waardes per sekonde. Soos u kan sien, neem die invoeging van data breukdele van 'n sekonde - alles is goed en vinnig. Die enigste ding is dat die 200 GB SSD-stasie vinnig vol raak.
Dit is 'n standaard Zabbix-bedienerprestasie-kontroleskerm.
Die eerste blou grafiek is die aantal waardes per sekonde. Die tweede grafiek aan die regterkant is die laai van bouprosesse. Die derde is die laai van interne bouprosesse: geskiedenissinkers en Housekeeper, wat al 'n geruime tyd hier aan die gang is.
Die vierde grafiek toon die gebruik van HistoryCache. Dit is 'n soort buffer voordat dit in die databasis ingevoeg word. Die groen vyfde grafiek toon die gebruik van ValueCache, dit wil sê, hoeveel ValueCache-treffers vir snellers 'n paar duisend waardes per sekonde is.
PostgreSQL. 50 000 nvps
Toe het ek die las verhoog tot 50 duisend waardes per sekonde op dieselfde hardeware.
By die laai van huishoudster het die invoeging van 10 duisend waardes 2-3 sekondes geneem.
Huishulp begin al in die pad staan.
Die derde grafiek toon dat, oor die algemeen, die laai van trappers en geskiedenissineerders steeds op die vlak van 60% is. Op die vierde grafiek begin die HistoryCache tydens die werking van Housekeeper reeds taamlik aktief vol word. Dit is 20% vol - ongeveer 0,5 GB.
PostgreSQL. 80 000 nvps
Toe het ek die vrag verhoog tot 80 duisend waardes per sekonde. Dit is ongeveer 400 duisend data-elemente en 280 duisend snellers.
Die laai-insetsel van dertig geskiedenis-sinkers is reeds redelik hoog.
Ek het ook verskeie parameters verhoog: geskiedenissinceerders, caches.
Op my hardeware het die laai van geskiedenissinceerders tot die maksimum toegeneem. HistoryCache het vinnig opgevul met data - die buffer het data opgehoop vir verwerking.
Al hierdie tyd het ek gekyk hoe die verwerker, RAM en ander stelselparameters gebruik word, en gevind dat skyfbenutting maksimum was.
Ek het gebruik gemaak van maksimum skyfkapasiteit op hierdie hardeware en op hierdie virtuele masjien. Met so intensiteit het PostgreSQL data redelik aktief begin stort, en die skyf het nie meer tyd gehad om te skryf en te lees nie.
Tweede bediener
Ek het 'n ander bediener geneem wat reeds 48 verwerkers en 128 GB RAM gehad het. Ek het dit ingestel - 60-geskiedenissynchroniseerder gestel en aanvaarbare prestasie behaal.
Trouens, dit is reeds 'n prestasielimiet waar iets gedoen moet word.
tydskaalb. 80 000 nvps
My hooftaak is om die vermoëns van TimescaleDB teen 'n Zabbix-lading te toets. 80 duisend waardes per sekonde is baie, die frekwensie van die insameling van statistieke (behalwe vir Yandex, natuurlik) en 'n redelik groot "opstelling".
Daar is 'n daling op elke grafiek - dit is net 'n data-migrasie. Na die mislukkings in die Zabbix-bediener het die laaiprofiel van die geskiedenissinchronisasie baie verander - dit het drie keer geval.
TimescaleDB laat jou toe om data byna 3 keer vinniger in te voeg en minder HistoryCache te gebruik.
Gevolglik sal u data betyds ontvang.
tydskaalb. 120 000 nvps
Toe het ek die aantal data-elemente verhoog tot 500 duisend. Die hooftaak was om die vermoëns van TimescaleDB na te gaan - ek het 'n berekende waarde van 125 duisend waardes per sekonde gekry.
Dit is 'n werkende "opstelling" wat lank kan neem om te werk. Maar aangesien my skyf net 1,5 TB was, het ek dit binne 'n paar dae volgemaak.
Die belangrikste is dat nuwe TimescaleDB-partisies op dieselfde tyd geskep is.
Vir prestasie is dit heeltemal onopvallend. Wanneer partisies byvoorbeeld in MySQL geskep word, is dinge anders. Dit gebeur gewoonlik in die nag, want dit blokkeer algemene invoeging, tabelmanipulasie en kan agteruitgang van die diens veroorsaak. Dit is nie die geval met TimescaleDB nie.
Ek sal byvoorbeeld een grafiek van die stel in gemeenskap wys. Op die foto is TimescaleDB geaktiveer, waardeur die las op die gebruik van io.weight op die verwerker gedaal het. Die gebruik van elemente van interne prosesse het ook afgeneem. Boonop is dit 'n gewone virtuele masjien op gewone pannekoekskywe, en nie 'n SSD nie.
Bevindinge
TimescaleDB is 'n goeie oplossing vir klein "opstellings", wat berus op die werkverrigting van die skyf. Dit sal jou toelaat om voort te gaan om goed te werk totdat die databasis vinniger na hardeware gemigreer word.
TimescaleDB is maklik om op te stel, gee 'n prestasie-hupstoot, werk goed met Zabbix en het voordele bo PostgreSQL.
As jy PostgreSQL gebruik en nie van plan is om dit te verander nie, beveel ek aan gebruik PostgreSQL met TimescaleDB-uitbreiding in samewerking met Zabbix. Hierdie oplossing werk effektief tot medium "opstelling".
Ons sê "hoë prestasie" - ons bedoel . Dit sal nie lank duur voordat jy die tegnologieë en praktyke leer ken wat dienste toelaat om miljoene gebruikers te bedien nie. Lys vir 7 en 8 November het ons reeds opgestel, maar meer kan voorgestel word.
Teken in op ons и , waarin ons die kenmerke van die komende konferensie onthul, en uitvind hoe om die meeste daaruit te kry.
Bron: will.com