Zabbix er et overvåkingssystem. Som ethvert annet system, står det overfor tre hovedproblemer for alle overvåkingssystemer: innsamling og behandling av data, lagring av historikk og rengjøring.
Stadiene med å motta, behandle og registrere data tar tid. Ikke mye, men for et stort system kan dette føre til store forsinkelser. Lagringsproblemet er et problem med datatilgang. De brukes til rapporter, kontroller og triggere. Forsinkelser i datatilgang påvirker også ytelsen. Når databaser vokser, må irrelevante data slettes. Å fjerne er en vanskelig operasjon som også spiser opp en del ressurser.
Problemer med forsinkelser under innsamling og lagring i Zabbix løses ved caching: flere typer cacher, caching i databasen. For å løse det tredje problemet er caching ikke egnet, så Zabbix brukte TimescaleDB. Han vil fortelle deg om det Andrey Gushchin - teknisk støtteingeniør . Andrey har støttet Zabbix i mer enn 6 år og har direkte erfaring med ytelse.
Hvordan fungerer TimescaleDB, hvilken ytelse kan det gi sammenlignet med vanlig PostgreSQL? Hvilken rolle spiller Zabbix for TimescaleDB-databasen? Hvordan starte fra bunnen av og hvordan migrere fra PostgreSQL og hvilken konfigurasjon har bedre ytelse? Om alt dette under kuttet.
Produktivitetsutfordringer
Hvert overvåkingssystem står overfor spesifikke ytelsesutfordringer. Jeg vil snakke om tre av dem: datainnsamling og -behandling, lagring og historikk.
Rask datainnsamling og behandling. Et godt overvåkingssystem bør raskt motta alle data og behandle dem etter trigger-uttrykk – etter sine kriterier. Etter behandling må systemet også raskt lagre disse dataene i databasen for senere bruk.
Historikklagring. Et godt overvåkingssystem bør lagre historikk i en database og gi enkel tilgang til beregninger. Historie er nødvendig for å brukes i rapporter, grafer, utløsere, terskler og beregnede varslingsdataelementer.
Sletter historikk. Noen ganger kommer det en dag da du ikke trenger å lagre beregninger. Hvorfor trenger du data som ble samlet inn for 5 år siden, en måned eller to: noen noder er slettet, noen verter eller beregninger er ikke lenger nødvendig fordi de er utdaterte og ikke lenger samlet inn. Et godt overvåkingssystem bør lagre historiske data og slette dem fra tid til annen slik at databasen ikke vokser.
Å rydde opp i foreldede data er et kritisk problem som i stor grad påvirker databaseytelsen.
Buffer i Zabbix
I Zabbix løses det første og andre anropet ved hjelp av caching. RAM brukes til å samle inn og behandle data. For lagring - historikk i triggere, grafer og beregnede dataelementer. På databasesiden er det noe caching for grunnleggende valg, for eksempel grafer.
Bufring på siden av selve Zabbix-serveren er:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Vurder dem mer detaljert.
ConfigurationCache
Dette er hovedbufferen hvor vi lagrer beregninger, verter, dataelementer, triggere - alt vi trenger for forhåndsbehandling og for datainnsamling.
Alt dette lagres i ConfigurationCache for ikke å lage unødvendige spørringer i databasen. Etter at serveren starter oppdaterer vi denne cachen, oppretter og oppdaterer konfigurasjoner med jevne mellomrom.
Datainnsamling
Diagrammet er ganske stort, men det viktigste i det er samlere. Dette er forskjellige "pollere" - monteringsprosesser. De er ansvarlige for ulike typer montering: de samler inn data via SNMP, IPMI og overfører alt til PreProcessing.
Samlerne er skissert i oransje.
Zabbix har beregnet aggregeringselementer som er nødvendige for å samle sjekker. Hvis vi har dem, henter vi dataene for dem direkte fra ValueCache.
PreProcessing HistoryCache
Alle samlere bruker ConfigurationCache for å motta jobber. Deretter overfører de dem til PreProcessing.
PreProcessing bruker ConfigurationCache for å motta forhåndsbehandlingstrinn. Den behandler disse dataene på forskjellige måter.
Etter å ha behandlet dataene ved hjelp av PreProcessing, lagrer vi dem i HistoryCache for behandling. Dette avslutter datainnsamlingen og vi går videre til hovedprosessen i Zabbix - historiesynkronisering, siden det er en monolitisk arkitektur.
Merk: Forbehandling er en ganske vanskelig operasjon. Med v 4.2 er den flyttet til proxy. Hvis du har en veldig stor Zabbix med et stort antall dataelementer og innsamlingsfrekvens, så gjør dette arbeidet mye enklere.
ValueCache, historie og trendbuffer
Historiesynkronisering er hovedprosessen som atomisk behandler hvert dataelement, det vil si hver verdi.
History syncer tar verdier fra HistoryCache og sjekker konfigurasjonen for tilstedeværelse av triggere for beregninger. Hvis de finnes, beregner den.
Historikksynkronisering oppretter en hendelse, eskalering for å lage varsler hvis det kreves av konfigurasjonen, og poster. Hvis det er triggere for påfølgende behandling, lagrer den denne verdien i ValueCache for ikke å få tilgang til historikktabellen. Slik fylles ValueCache med data som er nødvendig for å beregne triggere og beregnede elementer.
History syncer skriver alle data til databasen, og den skriver til disk. Behandlingsprosessen avsluttes her.
Bufring i databasen
På databasesiden er det ulike cacher når du ønsker å se grafer eller rapporter om hendelser:
Innodb_buffer_poolpå MySQL-siden;shared_bufferspå PostgreSQL-siden;effective_cache_sizepå Oracle-siden;shared_poolpå DB2-siden.
Det finnes mange andre cacher, men disse er de viktigste for alle databaser. De lar deg lagre data i RAM som ofte er nødvendig for spørringer. De har sine egne teknologier for dette.
Databaseytelse er kritisk
Zabbix-serveren samler stadig inn data og skriver dem. Når den startes på nytt, leser den også fra historien for å fylle ValueCache. Bruker skript og rapporter Zabbix API, som er bygget på et webgrensesnitt. Zabbix API får tilgang til databasen og henter nødvendige data for grafer, rapporter, hendelseslister og siste problemer.
For visualisering - grafana. Dette er en populær løsning blant våre brukere. Den kan sende forespørsler direkte gjennom Zabbix API og til databasen, og skaper en viss konkurranse om å motta data. Derfor er det nødvendig med finere og bedre tuning av databasen for å matche rask levering av resultater og testing.
Vaktmester
Den tredje ytelsesutfordringen i Zabbix er historierydding med Housekeeper. Den følger alle innstillingene - dataelementene indikerer hvor lenge du skal lagre dynamikken til endringer (trender) i dager.
Vi beregner TrendsCache på farten. Når dataene kommer, samler vi dem i én time og registrerer dem i tabeller for dynamikken i trendendringer.
Husholderske starter og sletter informasjon fra databasen ved å bruke de vanlige "velger". Dette er ikke alltid effektivt, som man kan se fra ytelsesgrafene til interne prosesser.
Den røde grafen viser at History syncer er konstant opptatt. Den oransje grafen øverst er Housekeeper, som er i konstant drift. Han venter på at databasen skal slette alle radene han spesifiserte.
Når bør du deaktivere Housekeeper? For eksempel er det en "Vare-ID", og du må slette de siste 5 tusen radene innen en viss tid. Dette skjer selvfølgelig etter indeks. Men vanligvis er datasettet veldig stort, og databasen leser fortsatt fra disken og legger den inn i cachen. Dette er alltid en svært kostbar operasjon for databasen og kan, avhengig av størrelsen på databasen, føre til ytelsesproblemer.
Husholderske er lett å deaktivere. I webgrensesnittet er det en innstilling i "Administrasjon generelt" for husholderske. Vi deaktiverer intern Housekeeping for intern trendhistorikk, og den administrerer det ikke lenger.
Husholderske ble slått av, grafene jevnet seg ut - hvilke problemer kan det være i dette tilfellet og hva kan bidra til å løse den tredje ytelsesutfordringen?
Partisjonering - partisjonering eller partisjonering
Vanligvis er partisjonering konfigurert på en annen måte på hver relasjonsdatabase som jeg har listet opp. Hver har sin egen teknologi, men de er generelt like. Å lage en ny partisjon fører ofte til visse problemer.
Vanligvis konfigureres partisjoner avhengig av "oppsettet" - mengden data som opprettes på en dag. Som regel utstedes partisjonering på en dag, dette er minimum. For trender for en ny batch - 1 måned.
Verdiene kan endres hvis "oppsettet" er veldig stort. Hvis et lite "oppsett" er opptil 5 000 nvps (nye verdier per sekund), er et middels fra 5 000 til 25 000, så er et stort over 25 000 nvps. Dette er store og veldig store installasjoner som krever nøye konfigurering av databasen.
På svært store installasjoner kan en periode på én dag ikke være optimal. Jeg har sett MySQL-partisjoner på 40 GB eller mer per dag. Dette er en svært stor mengde data som kan skape problemer og som må reduseres.
Hva gir partisjonering?
Skillebord. Ofte er dette separate filer på disk. Spørringsplanen velger én partisjon mer optimalt. Vanligvis brukes partisjonering etter rekkevidde - dette gjelder også for Zabbix. Vi bruker "tidsstempel" der - tid siden begynnelsen av epoken. Dette er vanlige tall for oss. Du angir begynnelsen og slutten av dagen - dette er en partisjon.
Rask fjerning - DELETE. Én fil/undertabell er valgt, i stedet for et utvalg rader for sletting.
Gir betydelig hastighet på datainnhenting SELECT - bruker en eller flere partisjoner, i stedet for hele tabellen. Hvis du får tilgang til data som er to dager gamle, hentes de raskere fra databasen fordi du bare trenger å laste en fil inn i cachen og returnere den, ikke en stor tabell.
Ofte blir mange databaser også akselerert INSERT — innsettinger i underordnet tabell.
TidsskalaDB
For v 4.2 vendte vi oppmerksomheten mot TimescaleDB. Dette er en utvidelse for PostgreSQL med et innebygd grensesnitt. Utvidelsen fungerer effektivt med tidsseriedata, uten å miste fordelene med relasjonsdatabaser. TimescaleDB partisjonerer også automatisk.
TimescaleDB har et konsept hypertabell (hypertable) som du oppretter. Det inneholder biter - skillevegger. Chunks er automatisk administrerte hypertabellfragmenter som ikke påvirker andre fragmenter. Hver del har sin egen tidsperiode.
TimescaleDB vs PostgreSQL
TimescaleDB fungerer veldig effektivt. Utvidelsens produsenter hevder at de bruker en mer korrekt spørringsbehandlingsalgoritme, spesielt inserts . Ettersom størrelsen på datasettinnsatsen vokser, opprettholder algoritmen konstant ytelse.
Etter 200 millioner rader begynner PostgreSQL vanligvis å synke betydelig og mister ytelsen til 0. TimescaleDB lar deg effektivt sette inn "innlegg" for en hvilken som helst mengde data.
Installasjon
Å installere TimescaleDB er ganske enkelt for enhver pakke. I alt er beskrevet i detalj - det avhenger av de offisielle PostgreSQL-pakkene. TimescaleDB kan også bygges og kompileres manuelt.
For Zabbix-databasen aktiverer vi ganske enkelt utvidelsen:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Du aktiverer extension og lag den for Zabbix-databasen. Det siste trinnet er å lage en hypertabell.
Migrerer historikktabeller til TimescaleDB
Det er en spesiell funksjon for dette 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
Funksjonen har tre parametere. Først - tabell i databasen, som du må lage en hypertabell for. Sekund - felt, i henhold til hvilken du må opprette chunk_time_interval — intervall av partisjonsbiter som skal brukes. I mitt tilfelle er intervallet en dag - 86 400.
Tredje parameter - migrate_data. Hvis du setter true, så overføres alle gjeldende data til forhåndslagrede biter. Jeg brukte det selv migrate_data. Jeg hadde omtrent 1 TB, som tok over en time. Selv i noen tilfeller, under testing, slettet jeg historiske data for karaktertyper som ikke var nødvendige for lagring, for ikke å overføre dem.
Siste steg - UPDATE: i db_extension sette timescaledbslik at databasen forstår at denne utvidelsen eksisterer. Zabbix aktiverer den og bruker syntaksen og spørringene riktig til databasen - de funksjonene som er nødvendige for TimescaleDB.
Maskinvarekonfigurasjon
Jeg brukte to servere. Først - VMware maskin. Den er ganske liten: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20 GHz prosessorer, 16 GB RAM og en 200 GB SSD.
Jeg installerte PostgreSQL 10.8 på den med Debian 10.8-1.pgdg90+1 OS og xfs filsystem. Jeg konfigurerte alt minimalt for å bruke denne databasen, minus det Zabbix selv vil bruke.
På samme maskin var det en Zabbix-server, PostgreSQL og lastemidler. Jeg hadde 50 aktive midler som brukte LoadableModulefor veldig raskt å generere forskjellige resultater: tall, strenger. Jeg fylte databasen med mye data.
Opprinnelig inneholdt konfigurasjonen 5 elementer data per vert. Nesten hvert element inneholdt en trigger for å gjøre det likt ekte installasjoner. I noen tilfeller var det mer enn én utløser. For en nettverksnode var det 3-000 utløsere.
Oppdateringsintervall for dataelement − 4-7 sekunder. Jeg regulerte selve belastningen ved å bruke ikke bare 50 midler, men legge til flere. Ved å bruke dataelementer justerte jeg også lasten dynamisk og reduserte oppdateringsintervallet til 4 s.
PostgreSQL. 35 000 nvps
Min første kjøring på denne maskinvaren var på ren PostgreSQL - 35 tusen verdier per sekund. Som du kan se, tar det å sette inn data brøkdeler av et sekund – alt er bra og raskt. Det eneste er at en 200 GB SSD-disk fylles raskt opp.
Dette er et standard dashbord for Zabbix-serverytelse.
Den første blå grafen er antall verdier per sekund. Den andre grafen til høyre er lasting av byggeprosesser. Den tredje er å laste inn interne byggeprosesser: historiesynkronisering og Housekeeper, som har kjørt her en stund.
Den fjerde grafen viser HistoryCache-bruk. Dette er en slags buffer før det settes inn i databasen. Den grønne femte grafen viser ValueCache-bruk, det vil si hvor mange ValueCache-treff for triggere - dette er flere tusen verdier per sekund.
PostgreSQL. 50 000 nvps
Så økte jeg belastningen til 50 tusen verdier per sekund på samme maskinvare.
Når du lastet fra Housekeeper, tok det 10-2 sekunder å sette inn 3 tusen verdier.
Husholderske begynner allerede å forstyrre arbeidet.
Den tredje grafen viser at generelt er belastningen på fangstmenn og historiesynkere fortsatt på 60 %. I den fjerde grafen begynner HistoryCache allerede å fylles ganske aktivt under Housekeeper-drift. Den er 20 % full, som er omtrent 0,5 GB.
PostgreSQL. 80 000 nvps
Så økte jeg belastningen til 80 tusen verdier per sekund. Dette er omtrent 400 tusen dataelementer og 280 tusen triggere.
Lastekostnadene for tretti historiesynchere er allerede ganske høye.
Jeg økte også forskjellige parametere: historiesynkronisering, cacher.
På maskinvaren min økte belastningen av historiesynkronisering maksimalt. HistoryCache ble raskt fylt med data - data for behandling hadde samlet seg i bufferen.
Hele denne tiden observerte jeg hvordan prosessoren, RAM og andre systemparametere ble brukt, og fant ut at diskutnyttelsen var på sitt maksimale.
Jeg har oppnådd bruken maksimale diskkapasiteter på denne maskinvaren og på denne virtuelle maskinen. Med en slik intensitet begynte PostgreSQL å skylle data ganske aktivt, og disken hadde ikke lenger tid til å skrive og lese.
Andre server
Jeg tok en annen server, som allerede hadde 48 prosessorer og 128 GB RAM. Jeg stilte den - satte den til 60 historiesyncer, og oppnådde akseptabel ytelse.
Faktisk er dette allerede grensen for produktivitet der noe må gjøres.
TidsskalaDB. 80 000 nvps
Min hovedoppgave er å teste egenskapene til TimescaleDB mot Zabbix-belastning. 80 tusen verdier per sekund er mye, frekvensen for å samle inn beregninger (bortsett fra Yandex, selvfølgelig) og et ganske stort "oppsett".
Det er et fall i hver graf - dette er nettopp datamigrasjonen. Etter feil i Zabbix-serveren endret lasteprofilen til historiesynkronisering seg mye - den falt tre ganger.
TimescaleDB lar deg sette inn data nesten 3 ganger raskere og bruke mindre HistoryCache.
Følgelig vil du motta data i tide.
TidsskalaDB. 120 000 nvps
Deretter økte jeg antall dataelementer til 500 tusen. Hovedoppgaven var å teste egenskapene til TimescaleDB - jeg mottok en beregnet verdi på 125 tusen verdier per sekund.
Dette er et fungerende "oppsett" som kan fungere lenge. Men siden disken min var på bare 1,5 TB, fylte jeg den opp på et par dager.
Det viktigste er at det samtidig ble opprettet nye TimescaleDB-partisjoner.
Dette er helt umerkelig for ytelsen. Når partisjoner lages i MySQL, for eksempel, er alt annerledes. Dette skjer vanligvis om natten fordi det blokkerer generell innsetting, arbeider med tabeller og kan skape tjenesteforringelse. Dette er ikke tilfelle med TimescaleDB.
Som et eksempel vil jeg vise én graf fra mange i samfunnet. På bildet er TimescaleDB aktivert, takket være at belastningen på å bruke io.weight på prosessoren har falt. Bruken av interne prosesselementer gikk også ned. Dessuten er dette en vanlig virtuell maskin på vanlige pannekakedisker, ikke en SSD.
Funn
TimescaleDB er en god løsning for små "oppsett", som påvirker diskytelsen. Det vil tillate deg å fortsette å jobbe godt til databasen er migrert til maskinvare så raskt som mulig.
TimescaleDB er enkel å konfigurere, gir ytelsesgevinster, fungerer godt med Zabbix og har fordeler fremfor PostgreSQL.
Hvis du bruker PostgreSQL og ikke planlegger å endre det, anbefaler jeg bruk PostgreSQL med TimescaleDB-utvidelsen i forbindelse med Zabbix. Denne løsningen fungerer effektivt opp til et middels "oppsett".
Når vi sier "høy ytelse", mener vi . Du vil ikke ha lenge å vente på å lære om teknologiene og fremgangsmåtene som gjør det mulig for tjenester å betjene millioner av brukere. Liste for 7. og 8. november har vi allerede samlet, men her mer kan foreslås.
Abonner på vår и , der vi avslører funksjonene til den kommende konferansen, og finner ut hvordan du får mest mulig ut av den.
Kilde: www.habr.com