Zabbix er et overvågningssystem. Som ethvert andet system står det over for tre hovedproblemer i alle overvågningssystemer: indsamling og behandling af data, lagring af historik og sletning.
Stadierne med at modtage, behandle og registrere data tager tid. Ikke meget, men for et stort system kan dette resultere i store forsinkelser. Opbevaringsproblemet er et spørgsmål om dataadgang. De bruges til rapporter, kontroller og triggere. Forsinkelser i dataadgang påvirker også ydeevnen. Når databasen vokser, skal irrelevante data slettes. Sletning er en tung operation, der også æder nogle ressourcer.
Problemer med indsamling og lagringsforsinkelse i Zabbix løses ved caching: flere typer caches, caching i databasen. For at løse det tredje problem er caching ikke egnet, så TimescaleDB blev brugt i Zabbix. vil fortælle om det Andrey Gushchin - teknisk supportingeniør . Andrey har støttet Zabbix i over 6 år og er direkte involveret i performance.
Hvordan fungerer TimescaleDB, hvilken ydeevne kan det give sammenlignet med almindelig PostgreSQL? Hvilken rolle spiller Zabbix i TimescaleDB? Hvordan starter man fra bunden, og hvordan migrerer man fra PostgreSQL, og hvilken konfigurationsydelse er bedre? Alt dette under snittet.
Præstationsudfordringer
Hvert overvågningssystem står over for visse præstationsudfordringer. Jeg vil tale om tre af dem: dataindsamling og -behandling, lagring, historierensning.
Hurtig dataindsamling og behandling. Et godt overvågningssystem bør hurtigt modtage alle data og behandle dem efter trigger-udtryk - efter egne kriterier. Efter behandlingen skal systemet også hurtigt gemme disse data i databasen for at kunne bruge dem senere.
Opbevaring af historie. Et godt overvågningssystem bør gemme historie i en database og give nem adgang til metrics. Historien er nødvendig for at blive brugt i rapporter, grafer, triggere, tærskler og beregnede advarselselementer.
Rydning af historik. Nogle gange kommer der en dag, hvor du ikke behøver at gemme metrics. Hvorfor har du brug for data, der blev indsamlet for 5 år siden, en måned eller to: nogle noder er blevet fjernet, nogle værter eller metrics er ikke længere nødvendige, fordi de er forældede og ikke længere indsamlet. Et godt overvågningssystem bør gemme historiske data og slette dem fra tid til anden, så databasen ikke vokser.
At rydde op i forældede data er et vanskeligt problem, som har stor indflydelse på databasens ydeevne.
Caching i Zabbix
I Zabbix løses det første og andet opkald ved hjælp af caching. RAM bruges til at indsamle og behandle data. Til opbevaring - historik i triggere, grafer og beregnede varer. På DB-siden er der noget caching til grundlæggende valg, såsom grafer.
Caching på siden af selve Zabbix-serveren er:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Overvej dem mere detaljeret.
ConfigurationCache
Dette er hovedcachen, hvori vi gemmer metrics, værter, dataelementer, triggere - alt hvad der er nødvendigt for PreProcessing og til dataindsamling.
Alt dette er gemt i ConfigurationCache for ikke at skabe unødvendige forespørgsler i databasen. Efter serveren starter, opdaterer vi denne cache, opretter og opdaterer periodisk konfigurationer.
Dataindsamling
Ordningen er ret stor, men det vigtigste i det er plukkere. Det er forskellige "pollere" - monteringsprocesser. De er ansvarlige for forskellige typer montering: De indsamler data via SNMP, IPMI og overfører det hele til PreProcessing.
Plukkerne er cirklet i orange.
Zabbix har beregnet aggregeringselementer, der er nødvendige for at aggregere checks. Hvis vi har dem, tager vi dataene for dem direkte fra ValueCache.
PreProcessing HistoryCache
Alle samlere bruger ConfigurationCache til at modtage jobs. Så sender de dem videre til PreProcessing.
PreProcessing bruger ConfigurationCache til at få PreProcessing-trin. Den behandler disse data på forskellige måder.
Efter at have behandlet dataene med PreProcessing, gemmer vi dem i HistoryCache for at behandle dem. Dette fuldender dataindsamlingen, og vi går videre til hovedprocessen i Zabbix - historie syncer, da det er en monolitisk arkitektur.
Bemærk: Forbehandling er en ret tung operation. Siden v 4.2 er den blevet flyttet til en proxy. Hvis du har en meget stor Zabbix med et stort antal genstande og afhentningsfrekvens, gør dette tingene meget nemmere.
ValueCache, historie og trends cache
History syncer er den vigtigste proces, der atomisk behandler hvert dataelement, det vil sige hver værdi.
History syncer tager værdier fra HistoryCache og kontrollerer konfigurationen for udløsere til beregninger. Hvis de er - beregner.
Historiesynkronisering opretter en begivenhed, eskalerer for at oprette advarsler, hvis det kræves af konfigurationen, og registrerer. Hvis der er triggere for yderligere behandling, så husker den denne værdi i ValueCache for ikke at referere til historiktabellen. Sådan fyldes ValueCache med de data, der er nødvendige for at beregne triggere, beregnede elementer.
History syncer skriver alle data til databasen, og den skriver til disk. Behandlingsprocessen slutter her.
DB caching
Der er forskellige caches på DB-siden, når du vil se på grafer eller hændelsesrapporter:
Innodb_buffer_poolpå MySQL-siden;shared_bufferspå PostgreSQL-siden;effective_cache_sizepå Oracle-siden;shared_poolpå DB2-siden.
Der er mange andre caches, men disse er de vigtigste for alle databaser. De giver dig mulighed for at opbevare data i RAM, som ofte er nødvendige for forespørgsler. De har deres egen teknologi til dette.
Databasens ydeevne er kritisk
Zabbix-serveren indsamler konstant data og skriver det ned. Når den genstartes, læser den også fra historikken for at fylde ValueCache. Brug af scripts og rapporter Zabbix API, som er bygget på basis af webgrænsefladen. Zabbix API får adgang til databasen og henter de nødvendige data til grafer, rapporter, hændelseslister og seneste problemer.
Til visualisering - grafana. Dette er en populær løsning blandt vores brugere. Hun kan sende anmodninger direkte gennem Zabbix API og til databasen og skaber en vis samtidighed for at få data. Derfor er der behov for en finere og bedre databasejustering for at matche den hurtige levering af resultater og test.
Housekeeper
Den tredje præstationsudfordring i Zabbix er at rense historien med Housekeeper. Det respekterer alle indstillinger - dataelementerne angiver, hvor længe ændringernes (trends) dynamik skal lagres i dage.
TrendsCache beregner vi i farten. Når dataene kommer ind, samler vi dem på en time og sætter dem i tabeller for at se dynamikken i trendændringer.
Housekeeper starter og fjerner information fra databasen med de sædvanlige "selects". Dette er ikke altid effektivt, hvilket kan forstås ud fra præstationsgraferne for interne processer.
Den røde graf viser, at History syncer er konstant optaget. Det orange diagram øverst er Housekeeper, som konstant kører. Den venter på, at databasen sletter alle de rækker, den har angivet.
Hvornår skal du deaktivere Housekeeper? For eksempel er der et "Vare-ID", og du skal slette de sidste 5 tusinde linjer på et bestemt tidspunkt. Dette sker naturligvis ved hjælp af indekser. Men normalt er datasættet meget stort, og databasen læser stadig fra disken og lægger den i cachen. Dette er altid en meget dyr operation for databasen og kan afhængigt af databasens størrelse føre til ydeevneproblemer.
Husholderske er nem at deaktivere. I webgrænsefladen er der en indstilling i "Administration generelt" for Housekeeper. Deaktiver intern husholdning for intern trendhistorik, og den kontrollerer ikke længere dette.
Housekeeper er blevet deaktiveret, grafikken er jævnet ud - hvad kan problemerne være i dette tilfælde, og hvad kan hjælpe med at løse den tredje præstationsudfordring?
Partitionering - partitionering eller partitionering
Partitionering er normalt konfigureret på en anden måde på hver relationel database, som jeg har angivet. Hver har sin egen teknologi, men de ligner generelt hinanden. Oprettelse af en ny partition fører ofte til visse problemer.
Typisk konfigureres partitioner afhængigt af "setup" - mængden af data, der oprettes på en dag. Som regel sættes partitionering op på én dag, dette er minimum. For nye partitionstrends - 1 måned.
Værdierne kan ændre sig i tilfælde af et meget stort "setup". Hvis et lille "setup" er op til 5 nvps (nye værdier pr. sekund), er et gennemsnit fra 000 til 5, så er et stort over 000 nvps. Det er store og meget store installationer, der kræver omhyggelig konfiguration af selve databasen.
På meget store installationer er en dag måske ikke optimal. Jeg har set MySQL-partitioner på 40 GB eller mere om dagen. Dette er en meget stor mængde data, der kan føre til problemer og bør reduceres.
Hvad giver partitionering?
Skilleborde. Ofte er disse separate filer på disken. Forespørgselsplanen vælger en partition mere optimalt. Normalt bruges partitionering efter rækkevidde - dette gælder også for Zabbix. Vi bruger der "tidsstempel" - tiden siden begyndelsen af epoken. Vi har faste numre. Du indstiller begyndelsen og slutningen af dagen - dette er en partition.
Hurtig fjernelse — DELETE. Én fil/undertabel er valgt, ikke et udvalg af rækker til sletning.
Fremskynder datasampling markant SELECT - bruger en eller flere partitioner, ikke hele tabellen. Hvis du får adgang til to dage gamle data, henter den dem hurtigere fra databasen, fordi du kun skal indlæse den i cachen og kun returnere én fil, ikke en stor tabel.
Ofte går mange databaser også hurtigere INSERT - indsættes i børnebordet.
TidsskalaDB
Til v 4.2 vendte vi vores opmærksomhed mod TimescaleDB. Dette er en PostgreSQL-udvidelse med en indbygget grænseflade. Udvidelsen arbejder effektivt med tidsseriedata uden at miste fordelene ved relationelle databaser. TimescaleDB partitionerer også automatisk.
TimescaleDB har et koncept hypertabel (hypertabel), som du opretter. I det er bidder - skillevægge. Chunks er automatisk administrerede fragmenter af en hypertabel, der ikke påvirker andre fragmenter. Hver del har sit eget tidsinterval.
TimescaleDB vs PostgreSQL
TimescaleDB er virkelig effektiv. Producenterne af udvidelsen hævder, at de bruger en mere korrekt forespørgselsbehandlingsalgoritme, især inserts . Efterhånden som størrelsen af datasættets indsættelse vokser, bevarer algoritmen konstant ydeevne.
Efter 200 millioner rækker begynder PostgreSQL normalt at synke meget og miste ydeevnen til 0. TimescaleDB giver dig mulighed for effektivt at indsætte "inserts" med enhver mængde data.
Installation
Installation af TimescaleDB er let nok til alle pakker. I alt er detaljeret - det afhænger af de officielle PostgreSQL-pakker. TimescaleDB kan også bygges og kompileres i hånden.
For Zabbix-databasen aktiverer vi blot udvidelsen:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
du aktiverer extension og opret det til Zabbix-databasen. Det sidste trin er at oprette en hypertabel.
Migrering af historietabeller til TimescaleDB
Der er en særlig funktion til 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
Funktionen har tre parametre. Først - tabel i databasenDen, som du vil oprette en hypertabel til. Anden - felt, ifølge hvilken det er nødvendigt at skabe chunk_time_interval — interval af skillevægsstykker, der skal bruges. I mit tilfælde er intervallet en dag - 86.
Den tredje parameter er migrate_data. Hvis indstillet true, så overføres alle aktuelle data til præ-oprettede bidder. Jeg har selv brugt migrate_data. Jeg havde omkring 1 TB, hvilket tog over en time. Selv i nogle tilfælde, når jeg testede, slettede jeg de historiske data for tegntyper, der er valgfrie til opbevaring for ikke at overføre dem.
Sidste trin - UPDATE: kl db_extension sætte timescaledbså databasen forstår, at der er denne udvidelse. Zabbix aktiverer det og bruger syntaksen og forespørgslerne korrekt til databasen - de funktioner, der er nødvendige for TimescaleDB.
Hardware konfiguration
Jeg brugte to servere. Først - VMware maskine. Den er lille nok: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 GB RAM og et 200 GB SSD-drev.
Jeg installerede PostgreSQL 10.8 på den med Debian OS 10.8-1.pgdg90+1 og xfs filsystem. Jeg konfigurerede alt minimalt til at bruge denne særlige database, minus hvad Zabbix selv vil bruge.
På samme maskine var der en Zabbix-server, PostgreSQL og belastningsmidler. Jeg havde 50 aktive midler, der brugte LoadableModuleat generere forskellige resultater meget hurtigt: tal, strenge. Jeg fyldte databasen med en masse data.
Oprindeligt indeholdt konfigurationen 5 genstande data pr. vært. Næsten hvert element indeholdt en trigger for at få det til at ligne rigtige installationer. I nogle tilfælde var der mere end én udløser. En netværksknude havde 3-000 udløsere.
Vareopdateringsinterval − 4-7 sekunder. Jeg regulerede selve belastningen ved at bruge ikke kun 50 midler, men tilføje flere. Også ved hjælp af dataelementer regulerede jeg dynamisk belastningen og reducerede opdateringsintervallet til 4 s.
PostgreSQL. 35 nvps
Min første kørsel på denne hardware var på ren PostgreSQL - 35 tusinde værdier pr. sekund. Som du kan se, tager det brøkdele af et sekund at indsætte data - alt er fint og hurtigt. Det eneste er, at 200 GB SSD-drevet fyldes hurtigt.
Dette er et standard Zabbix-serverydelses-dashboard.
Den første blå graf er antallet af værdier pr. sekund. Den anden graf til højre er indlæsning af byggeprocesser. Den tredje er indlæsningen af interne byggeprocesser: historiesyncere og Housekeeper, som har kørt i et stykke tid her.
Den fjerde graf viser brugen af HistoryCache. Dette er en slags buffer før indsættelse i databasen. Den grønne femte graf viser brugen af ValueCache, det vil sige, hvor mange ValueCache-hits for triggere er flere tusinde værdier pr. sekund.
PostgreSQL. 50 nvps
Så øgede jeg belastningen til 50 tusinde værdier i sekundet på den samme hardware.
Ved indlæsning fra Housekeeper tog det 10-2 sekunder at indsætte 3 tusinde værdier.
Husholderske er allerede begyndt at stå i vejen.
Den tredje graf viser, at belastningen af fangere og historiesyncere generelt stadig er på niveauet 60 %. På den fjerde graf begynder HistoryCache under driften af Housekeeper allerede at blive fyldt ret aktivt. Den er 20 % fuld - omkring 0,5 GB.
PostgreSQL. 80 nvps
Så øgede jeg belastningen til 80 tusinde værdier i sekundet. Dette er cirka 400 tusinde dataelementer og 280 tusinde triggere.
Indlæsningsindsatsen på tredive historiesyncere er allerede ret høj.
Jeg øgede også forskellige parametre: historiesynkronisering, cache.
På min hardware steg indlæsningen af historiesynkronisering til det maksimale. HistoryCache blev hurtigt fyldt op med data - bufferen har akkumuleret data til behandling.
Hele denne tid så jeg, hvordan processoren, RAM og andre systemparametre blev brugt, og fandt ud af, at diskudnyttelsen var maksimal.
jeg har gjort brug af maksimal diskkapacitet på denne hardware og på denne virtuelle maskine. Med en sådan intensitet begyndte PostgreSQL at dumpe data ret aktivt, og disken havde ikke længere tid til at skrive og læse.
Anden server
Jeg tog en anden server, der allerede havde 48 processorer og 128 GB RAM. Jeg tunede den - indstillede 60 historie-synkronisering og opnåede acceptabel ydeevne.
Faktisk er dette allerede en præstationsgrænse, hvor der skal gøres noget.
tidsskaleretb. 80 nvps
Min hovedopgave er at teste funktionerne i TimescaleDB mod en Zabbix-belastning. 80 tusinde værdier pr. sekund er meget, hyppigheden af indsamling af metrikker (undtagen Yandex, selvfølgelig) og en ret stor "opsætning".
Der er et fald på hver graf - dette er blot en datamigrering. Efter fejlene i Zabbix-serveren har indlæsningsprofilen for historiesynkroniseringen ændret sig meget - den faldt tre gange.
TimescaleDB giver dig mulighed for at indsætte data næsten 3 gange hurtigere og bruge mindre HistoryCache.
Du vil derfor modtage data rettidigt.
tidsskaleretb. 120 nvps
Derefter øgede jeg antallet af dataelementer til 500 tusinde. Hovedopgaven var at kontrollere funktionerne i TimescaleDB - jeg fik en beregnet værdi på 125 tusinde værdier i sekundet.
Dette er et fungerende "setup", der kan tage lang tid at virke. Men da min disk kun var på 1,5 TB, fyldte jeg den op på et par dage.
Det vigtigste er, at nye TimescaleDB-partitioner blev oprettet på samme tid.
For ydeevne er dette fuldstændig umærkeligt. Når partitioner oprettes i MySQL, for eksempel, er tingene anderledes. Dette sker normalt om natten, fordi det blokerer generel indsættelse, tabelmanipulation og kan skabe forringelse af tjenesten. Dette er ikke tilfældet med TimescaleDB.
For eksempel vil jeg vise en graf fra sættet i fællesskabet. På billedet er TimescaleDB aktiveret, takket være, at belastningen på brugen af io.weight på processoren er faldet. Brugen af elementer fra interne processer er også faldet. Desuden er dette en almindelig virtuel maskine på almindelige pandekagediske og ikke en SSD.
Fund
TimescaleDB er en god løsning til små "opsætninger", som hviler på diskens ydeevne. Det giver dig mulighed for at fortsætte med at arbejde godt, indtil databasen er migreret til hardware hurtigere.
TimescaleDB er let at sætte op, giver et ydelsesboost, fungerer godt med Zabbix og har fordele i forhold til PostgreSQL.
Hvis du bruger PostgreSQL og ikke planlægger at ændre det, så anbefaler jeg brug PostgreSQL med TimescaleDB-udvidelse i forbindelse med Zabbix. Denne løsning fungerer effektivt op til medium "setup".
Vi siger "high performance" - vi mener . Det vil ikke vare længe, før du lærer de teknologier og praksisser at kende, der gør det muligt for tjenester at betjene millioner af brugere. Liste for 7. og 8. november har vi allerede tegnet, men mere kan foreslås.
Abonner på vores и , hvor vi afslører funktionerne i den kommende konference, og finder ud af, hvordan du får mest muligt ud af den.
Kilde: www.habr.com