Zabbix is een monitoringsysteem. Net als elk ander systeem wordt het geconfronteerd met drie hoofdproblemen van alle monitoringsystemen: het verzamelen en verwerken van gegevens, het opslaan van de geschiedenis en het opschonen ervan.
De fasen van het ontvangen, verwerken en vastleggen van gegevens vergen tijd. Niet veel, maar voor een groot systeem kan dit tot grote vertragingen leiden. Het opslagprobleem is een probleem met de gegevenstoegang. Ze worden gebruikt voor rapportages, controles en triggers. Latenties bij gegevenstoegang hebben ook invloed op de prestaties. Wanneer databases groeien, moeten irrelevante gegevens worden verwijderd. Het verwijderen is een moeilijke operatie die ook wat hulpbronnen opslokt.
Problemen met vertragingen tijdens het verzamelen en opslaan in Zabbix worden opgelost door caching: verschillende soorten caches, caching in de database. Om het derde probleem op te lossen is caching niet geschikt, dus gebruikte Zabbix TimescaleDB. Hij zal je erover vertellen Andrej Gushchin - technisch ondersteunende ingenieur . Andrey ondersteunt Zabbix al meer dan 6 jaar en heeft directe ervaring met optredens.
Hoe werkt TimescaleDB, welke prestaties kan het geven vergeleken met regulier PostgreSQL? Welke rol speelt Zabbix voor de TimescaleDB-database? Hoe begin je helemaal opnieuw, hoe migreer je vanuit PostgreSQL en welke configuratie presteert beter? Over dit alles onder de snit.
Productiviteitsuitdagingen
Elk monitoringsysteem wordt geconfronteerd met specifieke prestatie-uitdagingen. Ik zal het over drie ervan hebben: het verzamelen en verwerken van gegevens, opslag en het wissen van de geschiedenis.
Snelle gegevensverzameling en -verwerking. Een goed monitoringsysteem moet snel alle gegevens ontvangen en verwerken volgens triggerexpressies - volgens zijn criteria. Na verwerking moet het systeem deze gegevens ook snel in de database opslaan voor later gebruik.
Geschiedenis opslag. Een goed monitoringsysteem moet de geschiedenis in een database opslaan en gemakkelijke toegang tot statistieken bieden. Geschiedenis moet worden gebruikt in rapporten, grafieken, triggers, drempels en berekende waarschuwingsgegevensitems.
Geschiedenis wissen. Soms komt er een dag waarop u geen statistieken hoeft op te slaan. Waarom heb je gegevens nodig die 5 jaar geleden, een maand of twee zijn verzameld: sommige knooppunten zijn verwijderd, sommige hosts of statistieken zijn niet langer nodig omdat ze verouderd zijn en niet langer worden verzameld. Een goed monitoringsysteem moet historische gegevens opslaan en van tijd tot tijd verwijderen, zodat de database niet groeit.
Het opruimen van verouderde gegevens is een cruciaal probleem dat een grote invloed heeft op de databaseprestaties.
Caching in Zabbix
In Zabbix worden de eerste en tweede oproep opgelost met behulp van caching. RAM wordt gebruikt om gegevens te verzamelen en te verwerken. Voor opslag - geschiedenis in triggers, grafieken en berekende data-elementen. Aan de databasekant is er enige caching voor basisselecties, bijvoorbeeld grafieken.
Caching aan de kant van de Zabbix-server zelf is:
- ConfiguratieCache;
- WaardeCache;
- GeschiedenisCache;
- TrendsCache.
Laten we ze in meer detail bekijken.
Configuratiecache
Dit is de hoofdcache waar we statistieken, hosts, gegevensitems en triggers opslaan - alles wat we nodig hebben voor preprocessing en voor gegevensverzameling.
Dit alles wordt opgeslagen in ConfigurationCache om geen onnodige queries in de database te creëren. Nadat de server is gestart, werken we deze cache bij, maken we configuraties en updaten we deze periodiek.
Gegevensverzameling
Het diagram is vrij groot, maar het belangrijkste is dat het is plukkers. Dit zijn verschillende "pollers" - assemblageprocessen. Ze zijn verantwoordelijk voor verschillende soorten assemblage: ze verzamelen gegevens via SNMP, IPMI en dragen dit allemaal over aan PreProcessing.
De collectoren zijn oranje omlijnd.
Zabbix heeft aggregatie-items berekend die nodig zijn om cheques te aggregeren. Als we die hebben, halen we de gegevens daarvoor rechtstreeks uit de ValueCache.
Geschiedeniscache vooraf verwerken
Alle verzamelprogramma's gebruiken ConfigurationCache om taken te ontvangen. Vervolgens brengen ze deze over naar PreProcessing.
PreProcessing gebruikt ConfigurationCache om PreProcessing-stappen te ontvangen. Zij verwerkt deze gegevens op verschillende manieren.
Nadat we de gegevens hebben verwerkt met PreProcessing, slaan we deze op in HistoryCache voor verwerking. Hiermee wordt de gegevensverzameling beëindigd en gaan we verder met het hoofdproces in Zabbix - geschiedenis synchronisatie, omdat het een monolithische architectuur is.
Let op: PreProcessing is een behoorlijk moeilijke operatie. Met v 4.2 is het verplaatst naar proxy. Als je een hele grote Zabbix hebt met een groot aantal data-elementen en verzamelfrequentie, dan maakt dit het werk veel eenvoudiger.
ValueCache, cache voor geschiedenis en trends
Geschiedenissynchronisatie is het hoofdproces dat elk gegevenselement, dat wil zeggen elke waarde, atomair verwerkt.
History syncer haalt waarden uit HistoryCache en controleert Configuratie op de aanwezigheid van triggers voor berekeningen. Als ze bestaan, wordt er gerekend.
Geschiedenissynchronisatie creëert een gebeurtenis, escalatie om waarschuwingen te creëren indien vereist door de configuratie, en records. Als er triggers zijn voor daaropvolgende verwerking, wordt deze waarde opgeslagen in ValueCache om geen toegang te krijgen tot de geschiedenistabel. Zo wordt ValueCache gevuld met gegevens die nodig zijn om triggers en berekende elementen te berekenen.
Geschiedenissynchronisatie schrijft alle gegevens naar de database en schrijft naar schijf. Het verwerkingsproces eindigt hier.
Caching in de database
Aan de databasekant zijn er verschillende caches wanneer u grafieken of rapporten over gebeurtenissen wilt bekijken:
Innodb_buffer_poolaan de MySQL-kant;shared_buffersaan de PostgreSQL-kant;effective_cache_sizeaan de Oracle-kant;shared_poolaan de DB2-zijde.
Er zijn nog veel meer caches, maar dit zijn de belangrijkste voor alle databases. Hiermee kunt u gegevens in het RAM opslaan die vaak nodig zijn voor vragen. Ze hebben hiervoor hun eigen technologieën.
Databaseprestaties zijn van cruciaal belang
De Zabbix-server verzamelt voortdurend gegevens en schrijft deze. Wanneer het opnieuw wordt opgestart, leest het ook uit de geschiedenis om de ValueCache te vullen. Maakt gebruik van scripts en rapporten Zabbix-API, dat is gebouwd op een webinterface. Zabbix API heeft toegang tot de database en haalt de benodigde gegevens op voor grafieken, rapporten, evenementenlijsten en de nieuwste problemen.
Voor visualisatie - grafana. Dit is een populaire oplossing onder onze gebruikers. Het kan rechtstreeks verzoeken verzenden via de Zabbix API en naar de database, en creëert een zekere concurrentie voor het ontvangen van gegevens. Daarom is een fijnere en betere afstemming van de database nodig om de snelle levering van resultaten en testen te evenaren.
Huishoudster
De derde prestatie-uitdaging in Zabbix is het opschonen van de geschiedenis met behulp van Housekeeper. Het volgt alle instellingen - de gegevenselementen geven aan hoe lang de dynamiek van veranderingen (trends) in dagen moet worden opgeslagen.
We berekenen TrendsCache direct. Wanneer de gegevens binnenkomen, verzamelen we deze gedurende een uur en leggen we deze vast in tabellen voor de dynamiek van trendveranderingen.
De huishoudster start en verwijdert informatie uit de database met behulp van de gebruikelijke “selects”. Dit is niet altijd effectief, zoals blijkt uit de prestatiegrafieken van interne processen.
De rode grafiek laat zien dat de geschiedenissynchronisatie voortdurend bezig is. De oranje grafiek bovenaan is Huishoudster, die voortdurend actief is. Hij wacht tot de database alle rijen heeft verwijderd die hij heeft opgegeven.
Wanneer moet u de huishoudster uitschakelen? Er is bijvoorbeeld een ‘Artikel-ID’ en u moet binnen een bepaalde tijd de laatste 5 rijen verwijderen. Uiteraard gebeurt dit per index. Maar meestal is de dataset erg groot en leest de database nog steeds van schijf en plaatst deze in de cache. Dit is altijd een zeer kostbare operatie voor de database en kan, afhankelijk van de grootte van de database, tot prestatieproblemen leiden.
Huishoudster is gemakkelijk uit te schakelen. In de webinterface is er in “Administratie algemeen” een instelling voor Huishoudster. We hebben de interne huishouding uitgeschakeld voor de interne trendgeschiedenis en deze beheert deze niet langer.
De huishoudster was uitgeschakeld, de grafieken werden genivelleerd - welke problemen zouden er in dit geval kunnen zijn en wat zou kunnen helpen bij het oplossen van de derde prestatie-uitdaging?
Partitioneren - partitioneren of partitioneren
Normaal gesproken wordt de partitie op elke relationele database die ik heb vermeld op een andere manier geconfigureerd. Elk heeft zijn eigen technologie, maar over het algemeen zijn ze vergelijkbaar. Het aanmaken van een nieuwe partitie leidt vaak tot bepaalde problemen.
Normaal gesproken worden partities geconfigureerd afhankelijk van de “setup”: de hoeveelheid gegevens die op één dag wordt aangemaakt. In de regel wordt Partitionering binnen één dag uitgegeven, dit is het minimum. Voor trends van een nieuwe batch - 1 maand.
De waarden kunnen veranderen als de “setup” erg groot is. Als een kleine “setup” maximaal 5 nvps (nieuwe waarden per seconde) is, een middelgrote van 000 tot 5, dan is een grote boven de 000 nvps. Dit zijn grote en zeer grote installaties die een zorgvuldige configuratie van de database vereisen.
Bij zeer grote installaties kan een periode van één dag niet optimaal zijn. Ik heb MySQL-partities gezien van 40 GB of meer per dag. Dit is een zeer grote hoeveelheid gegevens die problemen kan veroorzaken en moet worden verminderd.
Wat levert het partitioneren op?
Tabellen verdelen. Vaak zijn dit losse bestanden op schijf. Het queryplan selecteert één partitie optimaaler. Meestal wordt partitie gebruikt op bereik - dit geldt ook voor Zabbix. We gebruiken daar ‘tijdstempel’: tijd sinds het begin van de jaartelling. Voor ons zijn dit gewone cijfers. U stelt het begin en het einde van de dag in - dit is een partitie.
Snelle verwijdering - DELETE. Er wordt één bestand/subtabel geselecteerd, in plaats van een selectie van rijen om te verwijderen.
Versnelt het ophalen van gegevens aanzienlijk SELECT - gebruikt een of meer partities in plaats van de hele tabel. Als u gegevens opent die twee dagen oud zijn, worden deze sneller uit de database opgehaald omdat u slechts één bestand in de cache hoeft te laden en terug te sturen, en niet een grote tabel.
Vaak worden veel databases ook versneld INSERT — invoegingen in de kindertafel.
Tijdschaal DB
Voor versie 4.2 hebben we onze aandacht gericht op TimescaleDB. Dit is een extensie voor PostgreSQL met een native interface. De extensie werkt effectief met tijdreeksgegevens, zonder de voordelen van relationele databases te verliezen. TimescaleDB partities worden ook automatisch gepartitioneerd.
TimescaleDB heeft een concept hypertabel (hypertabel) die u maakt. Het bevat brokken - partities. Chunks zijn automatisch beheerde hypertabelfragmenten die geen invloed hebben op andere fragmenten. Elk deel heeft zijn eigen tijdsbereik.
TijdschaalDB versus PostgreSQL
TimescaleDB werkt heel efficiënt. De fabrikanten van de extensie beweren dat ze een correcter algoritme voor het verwerken van zoekopdrachten gebruiken, met name inserts . Naarmate de invoeggrootte van de dataset groter wordt, behoudt het algoritme constante prestaties.
Na 200 miljoen rijen begint PostgreSQL meestal aanzienlijk te verzakken en verliest het de prestaties naar 0. Met TimescaleDB kunt u efficiënt “inserts” invoegen voor elke hoeveelheid gegevens.
installatie
Het installeren van TimescaleDB is voor elk pakket vrij eenvoudig. IN alles wordt in detail beschreven - het hangt af van de officiële PostgreSQL-pakketten. TimescaleDB kan ook handmatig worden gebouwd en gecompileerd.
Voor de Zabbix-database activeren we eenvoudig de extensie:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Jij activeert extension en maak het voor de Zabbix-database. De laatste stap is het maken van een hypertabel.
Geschiedenistabellen migreren naar TimescaleDB
Hiervoor bestaat een speciale functie 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
De functie heeft drie parameters. Eerst - tabel in de database, waarvoor u een hypertabel moet maken. Seconde - veld, volgens welke u moet creëren chunk_time_interval — interval van te gebruiken partitieblokken. In mijn geval is het interval één dag: 86.
Derde parameter - migrate_data. Als je instelt true, vervolgens worden alle huidige gegevens overgebracht naar vooraf gemaakte chunks. Ik heb het zelf gebruikt migrate_data. Ik had ongeveer 1 TB, wat meer dan een uur duurde. Zelfs in sommige gevallen heb ik tijdens het testen historische gegevens verwijderd van tekentypen die niet nodig waren voor opslag, om ze niet over te dragen.
Laatste stap - UPDATE: Bij db_extension neerzetten timescaledbzodat de database begrijpt dat deze extensie bestaat. Zabbix activeert het en gebruikt correct de syntaxis en query's naar de database - de functies die nodig zijn voor TimescaleDB.
Hardware configuratie
Ik heb twee servers gebruikt. Eerst - VMware-machine. Hij is vrij klein: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz processors, 16 GB RAM en een 200 GB SSD.
Ik heb PostgreSQL 10.8 erop geïnstalleerd met Debian 10.8-1.pgdg90+1 OS en xfs-bestandssysteem. Ik heb alles minimaal geconfigureerd om deze specifieke database te gebruiken, minus wat Zabbix zelf zal gebruiken.
Op dezelfde machine stond een Zabbix-server, PostgreSQL en agenten laden. Ik had 50 actieve agenten die gebruikten LoadableModuleom zeer snel verschillende resultaten te genereren: getallen, strings. Ik heb de database gevuld met veel gegevens.
Aanvankelijk bevatte de configuratie 5 elementen gegevens per host. Bijna elk element bevatte een trigger om het vergelijkbaar te maken met echte installaties. In sommige gevallen was er meer dan één trigger. Voor één netwerkknooppunt waren dat er wel 3-000 triggers.
Update-interval gegevensitem − 4-7 seconden. Ik regelde de belasting zelf door niet alleen 50 agenten te gebruiken, maar er nog meer toe te voegen. Bovendien heb ik met behulp van data-elementen de belasting dynamisch aangepast en het update-interval teruggebracht tot 4 seconden.
PostgreSQL. 35 nvps
Mijn eerste run op deze hardware was op pure PostgreSQL - 35 duizend waarden per seconde. Zoals u kunt zien, duurt het invoegen van gegevens een fractie van een seconde - alles gaat goed en snel. Het enige is dat een SSD-schijf van 200 GB snel vol raakt.
Dit is een standaard Zabbix-serverprestatiedashboard.
De eerste blauwe grafiek is het aantal waarden per seconde. De tweede grafiek aan de rechterkant toont het laden van bouwprocessen. De derde is het laden van interne bouwprocessen: geschiedenissynchronisatieprogramma's en Housekeeper, die hier al geruime tijd actief zijn.
De vierde grafiek toont het gebruik van HistoryCache. Dit is een soort buffer voordat deze in de database wordt geplaatst. De groene vijfde grafiek toont het ValueCache-gebruik, dat wil zeggen hoeveel ValueCache-hits voor triggers zijn - dit zijn enkele duizenden waarden per seconde.
PostgreSQL. 50 nvps
Vervolgens verhoogde ik de belasting naar 50 waarden per seconde op dezelfde hardware.
Bij het laden vanuit Housekeeper duurde het invoegen van 10 waarden 2-3 seconden.
De huishoudster begint zich al met het werk te bemoeien.
De derde grafiek laat zien dat de belasting van trappers en geschiedenissynchronisaties over het algemeen nog steeds 60% bedraagt. In de vierde grafiek begint HistoryCache al behoorlijk actief te vullen tijdens de Housekeeper-operatie. Hij is voor 20% vol, dat is ongeveer 0,5 GB.
PostgreSQL. 80 nvps
Vervolgens verhoogde ik de belasting tot 80 waarden per seconde. Dit zijn ongeveer 400 duizend data-elementen en 280 duizend triggers.
De laadkosten van dertig geschiedenissynchronisaties zijn al behoorlijk hoog.
Ik heb ook verschillende parameters verhoogd: geschiedenissynchronisatie, caches.
Op mijn hardware is het laden van geschiedenissynchronisatieprogramma's tot het maximum toegenomen. HistoryCache werd snel gevuld met gegevens - gegevens voor verwerking waren in de buffer verzameld.
Al die tijd observeerde ik hoe de processor, het RAM-geheugen en andere systeemparameters werden gebruikt, en ontdekte dat het schijfgebruik maximaal was.
Ik heb het gebruik bereikt maximale schijfmogelijkheden op deze hardware en op deze virtuele machine. Met zo'n intensiteit begon PostgreSQL behoorlijk actief gegevens door te spoelen, en de schijf had geen tijd meer om te schrijven en te lezen.
Tweede server
Ik nam een andere server, die al 48 processors en 128 GB RAM had. Ik heb het afgestemd - stel het in op 60 geschiedenissynchronisatie en behaalde acceptabele prestaties.
In feite is dit al de grens van de productiviteit waar iets gedaan moet worden.
TijdschaalDB. 80 nvps
Mijn belangrijkste taak is het testen van de mogelijkheden van TimescaleDB tegen de Zabbix-belasting. 80 waarden per seconde is veel, de frequentie van het verzamelen van statistieken (behalve Yandex natuurlijk) en een vrij grote “setup”.
In elke grafiek zit een dip – dit is precies de datamigratie. Na storingen in de Zabbix-server veranderde het laadprofiel van de geschiedenissynchronisatie veel: het daalde drie keer.
Met TimescaleDB kunt u gegevens bijna 3 keer sneller invoegen en minder HistoryCache gebruiken.
Dienovereenkomstig ontvangt u de gegevens tijdig.
TijdschaalDB. 120 nvps
Vervolgens verhoogde ik het aantal gegevenselementen tot 500 duizend. De hoofdtaak was het testen van de mogelijkheden van TimescaleDB - ik ontving een berekende waarde van 125 duizend waarden per seconde.
Dit is een werkende “opstelling” die lange tijd kan werken. Maar aangezien mijn schijf slechts 1,5 TB groot was, had ik hem binnen een paar dagen vol.
Het belangrijkste is dat er tegelijkertijd nieuwe TimescaleDB-partities zijn gemaakt.
Dit is volledig onmerkbaar voor de prestaties. Wanneer er bijvoorbeeld partities worden aangemaakt in MySQL, is alles anders. Dit gebeurt meestal 's nachts omdat het algemene invoeging blokkeert, met tabellen werkt en serviceverslechtering kan veroorzaken. Bij TimescaleDB is dit niet het geval.
Als voorbeeld zal ik één grafiek van velen in de gemeenschap laten zien. Op de afbeelding is TimescaleDB ingeschakeld, waardoor de belasting van het gebruik van io.weight op de processor is afgenomen. Ook het gebruik van interne proceselementen nam af. Bovendien is dit een gewone virtuele machine op gewone pannenkoekschijven, geen SSD.
Bevindingen
TimescaleDB is een goede oplossing voor kleine "setup", die de schijfprestaties beïnvloeden. Hiermee kunt u goed blijven werken totdat de database zo snel mogelijk naar hardware is gemigreerd.
TimescaleDB is eenvoudig te configureren, geeft een prestatieverbetering, werkt goed met Zabbix en heeft voordelen ten opzichte van PostgreSQL.
Als u PostgreSQL gebruikt en niet van plan bent dit te wijzigen, raad ik u aan gebruik PostgreSQL met de TimescaleDB-extensie in combinatie met Zabbix. Deze oplossing werkt effectief tot een gemiddelde "opstelling".
Als we ‘hoge prestaties’ zeggen, bedoelen we dat ook . U hoeft niet lang te wachten om meer te weten te komen over de technologieën en praktijken waarmee services miljoenen gebruikers kunnen bedienen. Lijst voor 7 en 8 november hebben we al samengesteld, maar hier er kan meer worden voorgesteld.
Abonneer u op onze и , waarin we de kenmerken van de komende conferentie onthullen en ontdekken hoe u er het maximale uit kunt halen.
Bron: www.habr.com