Zabbix on valvontajärjestelmä. Kuten kaikilla muillakin järjestelmillä, sillä on kolme pääongelmaa kaikissa valvontajärjestelmissä: tietojen kerääminen ja käsittely, historian tallentaminen ja tyhjentäminen.
Tiedon vastaanottamisen, käsittelyn ja tallentamisen vaiheet vievät aikaa. Ei paljon, mutta suuressa järjestelmässä tämä voi aiheuttaa suuria viiveitä. Tallennusongelma liittyy tietojen saatavuuteen. Niitä käytetään raporteissa, tarkistuksissa ja laukaisimissa. Myös tietojen käyttöviiveet vaikuttavat suorituskykyyn. Kun tietokanta kasvaa, tarpeettomat tiedot on poistettava. Poistaminen on raskas toimenpide, joka myös syö resursseja.
Keräys- ja tallennusviiveongelmat Zabbixissa ratkaistaan välimuistilla: useita välimuistityyppejä, välimuisti tietokannassa. Kolmannen ongelman ratkaisemiseksi välimuisti ei sovellu, joten TimescaleDB:tä käytettiin Zabbixissa. Kerrotaan siitä Andrei Gushchin - teknisentuen insinööri . Andrey on tukenut Zabbixia yli 6 vuotta ja on suoraan mukana esiintymisessä.
Miten TimescaleDB toimii, mitä suorituskykyä se voi tarjota verrattuna tavalliseen PostgreSQL:ään? Mikä rooli Zabbixilla on TimescaleDB:ssä? Kuinka aloittaa tyhjästä ja miten siirtyä PostgreSQL:stä ja mikä kokoonpanon suorituskyky on parempi? Kaikki tämä leikkauksen alla.
Suorituskyvyn haasteet
Jokaisella valvontajärjestelmällä on tiettyjä suorituskykyhaasteita. Puhun niistä kolmesta: tiedon kerääminen ja käsittely, varastointi, historian puhdistus.
Nopea tiedonkeruu ja käsittely. Hyvän seurantajärjestelmän pitäisi saada nopeasti kaikki tiedot ja käsitellä se trigger-lausekkeiden mukaan - omien kriteeriensä mukaan. Käsittelyn jälkeen järjestelmän on myös tallennettava nämä tiedot nopeasti tietokantaan voidakseen käyttää niitä myöhemmin.
Historian tallennus. Hyvän seurantajärjestelmän tulisi tallentaa historia tietokantaan ja tarjota helppo pääsy mittareihin. Historiaa tarvitaan käytettäväksi raporteissa, kaavioissa, triggereissä, kynnyksissä ja lasketuissa hälytyskohdissa.
Tyhjennä historia. Joskus tulee päivä, jolloin sinun ei tarvitse tallentaa mittareita. Mihin tarvitset tietoja, jotka on kerätty 5 vuotta sitten, kuukausi tai kaksi: jotkut solmut on poistettu, joitain isäntiä tai mittareita ei enää tarvita, koska ne ovat vanhentuneita eikä niitä enää kerätä. Hyvän seurantajärjestelmän tulisi tallentaa historialliset tiedot ja poistaa ne aika ajoin, jotta tietokanta ei kasva.
Vanhentuneiden tietojen puhdistaminen on hankala ongelma, jolla on suuri vaikutus tietokannan suorituskykyyn.
Välimuisti Zabbixissa
Zabbixissa ensimmäinen ja toinen puhelu ratkaistaan välimuistin avulla. RAM-muistia käytetään tietojen keräämiseen ja käsittelyyn. Tallennukseen - historia triggereissä, kaavioissa ja lasketuissa kohteissa. DB-puolella on jonkin verran välimuistia perusvalinnoille, kuten kaavioille.
Välimuisti Zabbix-palvelimen puolella on:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Tarkastele niitä tarkemmin.
ConfigurationCache
Tämä on päävälimuisti, johon tallennamme mittareita, isäntiä, datakohteita, triggereitä - kaiken, mitä tarvitaan esikäsittelyyn ja tiedonkeruuun.
Kaikki tämä on tallennettu ConfigurationCacheen, jotta tietokantaan ei luoda tarpeettomia kyselyitä. Kun palvelin käynnistyy, päivitämme tämän välimuistin, luomme ja päivitämme säännöllisesti määrityksiä.
Tiedonkeruu
Järjestelmä on melko suuri, mutta pääasia siinä on keräilijät. Nämä ovat erilaisia "pollereita" - kokoonpanoprosesseja. He vastaavat erilaisista kokoonpanotyypeistä: he keräävät tietoja SNMP:n, IPMI:n kautta ja siirtävät kaiken PreProcessingille.
Poimijat on ympyröity oranssilla.
Zabbixilla on laskettuja aggregointikohteita, joita tarvitaan tarkistusten yhdistämiseen. Jos meillä on niitä, otamme niiden tiedot suoraan ValueCachesta.
Esikäsittelyhistoriavälimuisti
Kaikki kerääjät käyttävät ConfigurationCacheä töiden vastaanottamiseen. Sitten he välittävät ne PreProcessingille.
PreProcessing käyttää ConfigurationCachea saadakseen esikäsittelyvaiheet. Se käsittelee näitä tietoja eri tavoilla.
Kun tiedot on käsitelty PreProcessingilla, tallennamme ne HistoryCacheen käsittelemään niitä. Tämä päättää tiedonkeruun ja siirrymme Zabbixin pääprosessiin - historian synkronointi, koska se on monoliittinen arkkitehtuuri.
Huomautus: Esikäsittely on melko raskas toimenpide. Vuodesta 4.2 lähtien se on siirretty välityspalvelimelle. Jos sinulla on erittäin suuri Zabbix, jossa on suuri määrä kohteita ja keräystiheys, tämä tekee asioista paljon helpompaa.
ValueCache, historian ja trendien välimuisti
Historian synkronointi on pääprosessi, joka käsittelee atomisesti jokaisen tietoelementin eli jokaisen arvon.
Historian synkronointi ottaa arvot HistoryCachesta ja tarkistaa konfiguraatiosta laskelmien laukaisimia. Jos ne ovat - laskee.
Historian synkronointi luo tapahtuman, eskaloituu luodakseen hälytyksiä, jos määritys vaatii, ja tallentaa. Jos jatkokäsittelyyn on liipaimia, se muistaa tämän arvon ValueCachessa, jotta se ei viittaa historiataulukkoon. Näin ValueCache täytetään tiedoilla, joita tarvitaan liipaisujen, laskettujen kohteiden laskemiseen.
Historia synkronointi kirjoittaa kaikki tiedot tietokantaan, ja se kirjoittaa levylle. Käsittelyprosessi päättyy tähän.
DB-välimuisti
DB-puolella on erilaisia välimuistia, kun haluat tarkastella kaavioita tai tapahtumaraportteja:
Innodb_buffer_poolMySQL-puolella;shared_buffersPostgreSQL-puolella;effective_cache_sizeOracle-puolella;shared_poolDB2-puolella.
On monia muita välimuistia, mutta nämä ovat kaikkien tietokantojen tärkeimmät välimuistit. Niiden avulla voit säilyttää tietoja RAM-muistissa, jota usein tarvitaan kyselyihin. Heillä on tähän oma tekniikkansa.
Tietokannan suorituskyky on kriittinen
Zabbix-palvelin kerää jatkuvasti tietoja ja kirjoittaa niitä muistiin. Kun se käynnistetään uudelleen, se lukee myös historiasta ValueCachen täyttämiseksi. Skriptien ja raporttien käyttö Zabbix API, joka on rakennettu verkkokäyttöliittymän pohjalta. Zabbix API käyttää tietokantaa ja hakee tarvittavat tiedot kaavioita, raportteja, tapahtumaluetteloita ja viimeaikaisia ongelmia varten.
Visualisointia varten - grafana. Tämä on suosittu ratkaisu käyttäjiemme keskuudessa. Hän voi lähettää pyyntöjä suoraan Zabbix API:n kautta ja tietokantaan ja luo tietyn samanaikaisuuden tietojen hankkimiseen. Siksi tarvitaan tarkempaa ja parempaa tietokannan viritystä vastaamaan tulosten ja testauksen nopeaa toimittamista.
Taloudenhoitaja
Kolmas suorituskykyhaaste Zabbixissa on historian siivoaminen Housekeeperin kanssa. Se kunnioittaa kaikkia asetuksia - tietoelementit osoittavat, kuinka kauan muutosten (trendien) dynamiikka päivinä säilytetään.
TrendsCachen laskemme lennossa. Kun tiedot saapuvat, kokoamme ne tunnissa ja laitamme ne taulukoihin trendien muutosten dynamiikkaa varten.
Taloudenhoitaja käynnistää ja poistaa tiedot tietokannasta tavanomaisilla "valitoilla". Tämä ei aina ole tehokasta, mikä voidaan ymmärtää sisäisten prosessien suorituskykykaavioista.
Punainen kaavio osoittaa, että historian synkronointi on jatkuvasti varattu. Yläosassa oleva oranssi kaavio on Housekeeper, joka on jatkuvasti käynnissä. Se odottaa, että tietokanta poistaa kaikki määrittämänsä rivit.
Milloin Housekeeper pitäisi poistaa käytöstä? Esimerkiksi siellä on "Tuotetunnus" ja sinun on poistettava viimeiset 5 tuhatta riviä tietyn ajan kuluessa. Tietysti tämä tapahtuu indeksien mukaan. Mutta yleensä tietojoukko on erittäin suuri, ja tietokanta lukee silti levyltä ja laittaa sen välimuistiin. Tämä on aina erittäin kallis toimenpide tietokannalle ja voi tietokannan koosta riippuen johtaa suorituskykyongelmiin.
Taloudenhoitaja on helppo poistaa käytöstä. Verkkokäyttöliittymän kohdassa "Yleinen hallinto" on asetus Housekeeperille. Poista sisäinen siivous käytöstä sisäisen trendihistorian osalta, eikä se enää hallitse tätä.
Taloudenhoitaja on vammautunut, grafiikka tasoittunut - mitkä voivat olla ongelmat tässä tapauksessa ja mikä voi auttaa ratkaisemaan kolmannen suoritushaasteen?
Osiointi - osiointi tai osiointi
Osiointi määritetään yleensä eri tavalla jokaisessa luettelemassani relaatiotietokannassa. Jokaisella on oma tekniikkansa, mutta ne ovat yleisesti ottaen samanlaisia. Uuden osion luominen johtaa usein tiettyihin ongelmiin.
Tyypillisesti osiot määritetään "asetuksen" mukaan - yhden päivän aikana luotavan tiedon määrästä. Yleensä osiointi määritetään yhdessä päivässä, tämä on minimi. Uusille ositrendeille — 1 kuukausi.
Arvot voivat muuttua erittäin suuren "kokoonpanon" tapauksessa. Jos pieni "asetus" on jopa 5 000 nvps (uudet arvot sekunnissa), keskimääräinen on 5 000 - 25 000, niin suuri on yli 25 000 nvps. Nämä ovat suuria ja erittäin suuria asennuksia, jotka vaativat itse tietokannan huolellisen konfiguroinnin.
Erittäin suurissa asennuksissa yksi päivä ei ehkä ole optimaalinen. Olen nähnyt MySQL-osioita 40 Gt tai enemmän päivässä. Tämä on erittäin suuri tietomäärä, joka voi johtaa ongelmiin, ja sitä pitäisi vähentää.
Mitä osiointi antaa?
Jakotaulukot. Usein nämä ovat erillisiä tiedostoja levyllä. Kyselysuunnitelma valitsee yhden osion optimaalisemmin. Yleensä osiointia käytetään alueen mukaan - tämä koskee myös Zabbixia. Käytämme siellä "aikaleimaa" - aikaa aikakauden alusta. Meillä on säännölliset numerot. Asetat päivän alun ja lopun - tämä on osio.
Nopea poisto - DELETE. Yksi tiedosto/alitaulukko on valittu, ei poistettavien rivien valinta.
Nopeuttaa merkittävästi datan näytteenottoa SELECT - käyttää yhtä tai useampaa osiota, ei koko taulukkoa. Jos käytät kaksi päivää vanhoja tietoja, se hakee ne tietokannasta nopeammin, koska sinun tarvitsee vain ladata ne välimuistiin ja palauttaa vain yksi tiedosto, ei suurta taulukkoa.
Usein myös monet tietokannat nopeutuvat INSERT - lisää lastenpöytään.
AikatauluDB
V 4.2:ssa kiinnitimme huomiomme TimescaleDB:hen. Tämä on PostgreSQL-laajennus, jossa on alkuperäinen käyttöliittymä. Laajennus toimii tehokkaasti aikasarjatietojen kanssa menettämättä relaatiotietokantojen etuja. TimescaleDB myös automaattisesti osioiden.
TimescaleDB:llä on konsepti hypertabletti (hypertable), jonka luot. Siinä ovat paloina - väliseinät. Palat ovat automaattisesti hallittuja hypertaulukon fragmentteja, jotka eivät vaikuta muihin fragmentteihin. Jokaisella palalla on oma aikajaksonsa.
TimescaleDB vs PostgreSQL
TimescaleDB on todella tehokas. Laajennuksen tuottajat väittävät käyttävänsä oikeampaa kyselynkäsittelyalgoritmia, erityisesti inserts . Tietojoukon lisäyksen koon kasvaessa algoritmi ylläpitää jatkuvaa suorituskykyä.
200 miljoonan rivin jälkeen PostgreSQL alkaa yleensä painua paljon ja menettää suorituskykynsä nollaan. TimescaleDB:n avulla voit lisätä tehokkaasti "lisäosia" minkä tahansa tietomäärän kanssa.
Asennus
TimescaleDB:n asentaminen on tarpeeksi helppoa kaikille paketeille. SISÄÄN kaikki on yksityiskohtaista - se riippuu virallisista PostgreSQL-paketeista. TimescaleDB voidaan rakentaa ja kääntää myös käsin.
Zabbix-tietokannassa yksinkertaisesti aktivoimme laajennuksen:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
aktivoit extension ja luo se Zabbix-tietokantaa varten. Viimeinen vaihe on hypertaulukon luominen.
Historiataulukoiden siirtäminen TimescaleDB:hen
Tätä varten on erityinen toiminto. 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
Funktiolla on kolme parametria. Ensimmäinen - taulukko tietokannassaJolle haluat luoda hypertaulukon. Toinen - kenttä, jonka mukaan on luotava chunk_time_interval — käytettävien osiopalojen aikaväli. Minun tapauksessani väli on yksi päivä - 86 400.
Kolmas parametri on migrate_data. Jos asetettu true, sitten kaikki nykyiset tiedot siirretään valmiiksi luotuihin osiin. Itse olen käyttänyt migrate_data. Minulla oli noin 1 Tt, mikä kesti yli tunnin. Jopa joissain tapauksissa testauksen aikana poistin tallennettavaksi valinnaisten merkkityyppien historialliset tiedot, jotta en siirtäisi niitä.
Viimeinen askel - UPDATE: klo db_extension laittaa timescaledbjotta tietokanta ymmärtää, että tämä laajennus on olemassa. Zabbix aktivoi sen ja käyttää oikein tietokannan syntaksia ja kyselyitä - niitä ominaisuuksia, joita TimescaleDB:lle tarvitaan.
Laitteiston konfigurointi
Käytin kahta palvelinta. Ensimmäinen - VMware kone. Se on tarpeeksi pieni: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20 GHz, 16 Gt RAM-muistia ja 200 Gt SSD-asema.
Asensin siihen PostgreSQL 10.8:n Debian OS 10.8-1.pgdg90+1 ja xfs-tiedostojärjestelmällä. Konfiguroin kaiken minimaalisesti käyttämään tätä tiettyä tietokantaa, miinus Zabbix itse käyttämästä.
Samassa koneessa oli Zabbix-palvelin, PostgreSQL ja kuorma-agentit. Minulla oli 50 aktiivista ainetta, jotka käyttivät LoadableModuletuottaa erilaisia tuloksia hyvin nopeasti: numeroita, merkkijonoja. Täytin tietokannan paljon dataa.
Aluksi kokoonpano sisälsi 5 kohdetta data per isäntä. Melkein jokainen elementti sisälsi liipaisimen, jotta se näytti todelliselta installaatiolta. Joissakin tapauksissa laukaisimia oli useampi kuin yksi. Yhdellä verkkosolmulla oli 3 000-7 000 laukaisinta.
Kohteen päivitysväli − 4-7 sekuntia. Säädin itse kuormaa käyttämällä 50 aineen lisäksi lisää. Lisäksi tietoelementtien avulla säädin dynaamisesti kuormitusta ja pienensin päivitysvälin 4 sekuntiin.
PostgreSQL. 35 000 nvps
Ensimmäinen ajo tällä laitteistolla oli puhtaalla PostgreSQL:llä - 35 tuhatta arvoa sekunnissa. Kuten näet, tietojen lisääminen kestää sekunnin murto-osan - kaikki on hyvin ja nopeasti. Ainoa asia on, että 200 Gt:n SSD-asema täyttyy nopeasti.
Tämä on tavallinen Zabbix-palvelimen suorituskyvyn kojelauta.
Ensimmäinen sininen kaavio on arvojen määrä sekunnissa. Toinen oikealla oleva kaavio on rakennusprosessien lataaminen. Kolmas on sisäisten rakennusprosessien lataaminen: historian synkronoijat ja Housekeeper, joka on ollut käynnissä täällä jo jonkin aikaa.
Neljäs kaavio näyttää HistoryCachen käytön. Tämä on eräänlainen puskuri ennen tietokantaan lisäämistä. Vihreä viides kaavio näyttää ValueCachen käytön, eli kuinka monta ValueCache-osumaa triggereille on useita tuhansia arvoja sekunnissa.
PostgreSQL. 50 000 nvps
Sitten lisäsin kuormitusta 50 tuhanteen arvoon sekunnissa samalla laitteistolla.
Ladattaessa Housekeeperista 10 tuhannen arvon lisääminen kesti 2-3 sekuntia.
Taloudenhoitaja alkaa jo olla tiellä.
Kolmas kaavio osoittaa, että yleisesti ottaen trapperien ja historiasynkereiden kuormitus on edelleen 60 prosentin tasolla. Neljännellä kaaviolla Housekeeperin toiminnan aikana oleva HistoryCache alkaa jo täyttyä melko aktiivisesti. Se on 20 % täynnä - noin 0,5 Gt.
PostgreSQL. 80 000 nvps
Sitten lisäsin kuormaa 80 tuhanteen arvoon sekunnissa. Tämä on noin 400 tuhatta tietoelementtiä ja 280 tuhatta laukaisua.
Kolmenkymmenen historiasynkronin latauslisä on jo melko korkea.
Lisäsin myös erilaisia parametreja: historian synkronoijat, välimuistit.
Laitteistollani historian synkronoijien lataus nousi maksimiin. HistoryCache täyttyi nopeasti tiedoilla - puskuriin on kertynyt tietoja käsittelyä varten.
Koko tämän ajan katselin, kuinka prosessoria, RAM-muistia ja muita järjestelmäparametreja käytettiin, ja huomasin, että levyn käyttöaste oli suurin.
Olen käyttänyt levyn enimmäiskapasiteetti tällä laitteistolla ja tällä virtuaalikoneella. Tällaisella intensiteetillä PostgreSQL alkoi tyhjentää tietoja melko aktiivisesti, eikä levyllä enää ollut aikaa kirjoittaa ja lukea.
Toinen palvelin
Otin toisen palvelimen, jossa oli jo 48 prosessoria ja 128 Gt RAM-muistia. Viritin sen - asetin 60 historian synkronoinnin ja saavutin hyväksyttävän suorituskyvyn.
Itse asiassa tämä on jo suoritusraja, jossa jotain on tehtävä.
aikaskaalattub. 80 000 nvps
Päätehtäväni on testata TimescaleDB:n ominaisuuksia Zabbix-kuormitusta vastaan. 80 tuhatta arvoa sekunnissa on paljon, mittareiden keräämisen taajuus (lukuun ottamatta tietysti Yandexia) ja melko suuri "asetus".
Jokaisessa kaaviossa on notkahdus - tämä on vain tietojen siirtoa. Zabbix-palvelimen vikojen jälkeen historian synkronoinnin latausprofiili on muuttunut paljon - se putosi kolme kertaa.
TimescaleDB:n avulla voit lisätä tietoja lähes 3 kertaa nopeammin ja käyttää vähemmän HistoryCachea.
Näin ollen saat tiedot ajoissa.
aikaskaalattub. 120 000 nvps
Sitten lisäsin tietokohteiden määrän 500 tuhanteen. Päätehtävänä oli tarkistaa TimescaleDB:n ominaisuudet - sain laskennallisen arvon 125 tuhatta arvoa sekunnissa.
Tämä on toimiva "asetus", jonka toimiminen voi kestää kauan. Mutta koska levyni oli vain 1,5 TB, täytin sen parissa päivässä.
Mikä tärkeintä, uusia TimescaleDB-osioita luotiin samaan aikaan.
Suorituskyvyn kannalta tämä on täysin huomaamaton. Kun osiot luodaan esimerkiksi MySQL:ssä, asiat ovat toisin. Tämä tapahtuu yleensä yöllä, koska se estää yleisen lisäyksen, taulukon manipuloinnin ja voi aiheuttaa palvelun heikkenemistä. Näin ei ole TimescaleDB:n tapauksessa.
Näytän esimerkiksi yhden kaavion yhteisön joukosta. Kuvassa TimescaleDB on käytössä, minkä ansiosta prosessorin io.weight käytön kuormitus on laskenut. Myös sisäisten prosessien elementtien käyttö on vähentynyt. Lisäksi tämä on tavallinen virtuaalikone tavallisilla pannukakkulevyillä, ei SSD.
Tulokset
TimescaleDB on hyvä ratkaisu pieniin "kokoonpanoihin", jotka perustuvat levyn suorituskykyyn. Sen avulla voit jatkaa työskentelyä hyvin, kunnes tietokanta siirretään laitteistoon nopeammin.
TimescaleDB on helppo asentaa, se parantaa suorituskykyä, toimii hyvin Zabbixin ja on etuja PostgreSQL:ään verrattuna.
Jos käytät PostgreSQL:ää etkä aio muuttaa sitä, suosittelen käytä PostgreSQL:ää TimescaleDB-laajennuksen kanssa yhdessä Zabbixin kanssa. Tämä ratkaisu toimii tehokkaasti keskikokoiseen "asetukseen".
Sanomme "korkea suorituskyky" - tarkoitamme . Ei kestä kauan, kun opit tuntemaan teknologiat ja käytännöt, joiden avulla palvelut voivat palvella miljoonia käyttäjiä. Lista 7. ja 8. marraskuuta olemme jo laatineet, mutta lisää saa ehdottaa.
Tilaa meidän и , jossa paljastamme tulevan konferenssin ominaisuudet ja selvitämme, kuinka saat siitä kaiken irti.
Lähde: will.com