Zabbix är ett övervakningssystem. Precis som alla andra system står det inför tre huvudproblem för alla övervakningssystem: samla in och bearbeta data, lagra historik och rengöra den.
Stadierna för att ta emot, bearbeta och registrera data tar tid. Inte mycket, men för ett stort system kan detta resultera i stora förseningar. Lagringsproblemet är ett problem med dataåtkomst. De används för rapporter, kontroller och triggers. Latenser i dataåtkomst påverkar också prestandan. När databaser växer måste irrelevanta data raderas. Att ta bort är en svår operation som också tär på en del resurser.
Problem med förseningar under insamling och lagring i Zabbix löses genom cachning: flera typer av cacher, cachning i databasen. För att lösa det tredje problemet är cachning inte lämpligt, så Zabbix använde TimescaleDB. Han kommer att berätta om det Andrey Gushchin - teknisk supportingenjör . Andrey har stöttat Zabbix i mer än 6 år och har direkt erfarenhet av prestanda.
Hur fungerar TimescaleDB, vilken prestanda kan det ge jämfört med vanlig PostgreSQL? Vilken roll spelar Zabbix för TimescaleDB-databasen? Hur börjar man från början och hur man migrerar från PostgreSQL och vilken konfiguration har bättre prestanda? Om allt detta under skärningen.
Produktivitetsutmaningar
Varje övervakningssystem står inför specifika prestandautmaningar. Jag kommer att prata om tre av dem: datainsamling och bearbetning, lagring och historikrensning.
Snabb datainsamling och bearbetning. Ett bra övervakningssystem bör snabbt ta emot all data och bearbeta den enligt triggeruttryck – enligt dess kriterier. Efter bearbetning måste systemet också snabbt spara dessa data i databasen för senare användning.
Historik lagring. Ett bra övervakningssystem bör lagra historik i en databas och ge enkel åtkomst till mätvärden. Historik behövs för att användas i rapporter, grafer, utlösare, trösklar och beräknade varningsdataposter.
Rensa historik. Ibland kommer en dag då du inte behöver lagra mätvärden. Varför behöver du data som samlades in för 5 år sedan, en månad eller två: vissa noder har raderats, vissa värdar eller mätvärden behövs inte längre eftersom de är föråldrade och inte längre insamlade. Ett bra övervakningssystem bör lagra historiska data och radera dem då och då så att databasen inte växer.
Att rensa upp inaktuella data är en kritisk fråga som i hög grad påverkar databasens prestanda.
Cachar i Zabbix
I Zabbix löses det första och andra anropet med hjälp av caching. RAM används för att samla in och bearbeta data. För lagring - historik i triggers, grafer och beräknade dataelement. På databassidan finns en del cachning för grundläggande val, till exempel grafer.
Cachning på sidan av själva Zabbix-servern är:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Tänk dem mer i detalj.
ConfigurationCache
Detta är huvudcachen där vi lagrar mätvärden, värdar, dataobjekt, triggers - allt vi behöver för förbehandling och för datainsamling.
Allt detta lagras i ConfigurationCache för att inte skapa onödiga frågor i databasen. Efter att servern startar uppdaterar vi denna cache, skapar och uppdaterar regelbundet konfigurationer.
Datainsamling
Diagrammet är ganska stort, men det viktigaste i det är plockare. Dessa är olika "pollers" - monteringsprocesser. De ansvarar för olika typer av montering: de samlar in data via SNMP, IPMI och överför allt till PreProcessing.
Samlarna är markerade i orange.
Zabbix har beräknat aggregeringsposter som behövs för att aggregera kontroller. Om vi har dem hämtar vi data för dem direkt från ValueCache.
PreProcessing HistoryCache
Alla samlare använder ConfigurationCache för att ta emot jobb. Sedan överför de dem till PreProcessing.
PreProcessing använder ConfigurationCache för att ta emot förbehandlingssteg. Den behandlar dessa uppgifter på olika sätt.
Efter att ha bearbetat data med PreProcessing sparar vi den i HistoryCache för bearbetning. Detta avslutar datainsamlingen och vi går vidare till huvudprocessen i Zabbix - historia syncer, eftersom det är en monolitisk arkitektur.
Obs: Förbehandling är en ganska svår operation. Med v 4.2 har den flyttats till proxy. Om du har en mycket stor Zabbix med ett stort antal dataelement och insamlingsfrekvens, så underlättar detta arbetet mycket.
ValueCache, historia & trendcache
History syncer är huvudprocessen som atomiskt bearbetar varje dataelement, det vill säga varje värde.
History syncer tar värden från HistoryCache och kontrollerar konfigurationen för närvaron av triggers för beräkningar. Om de finns, räknar den ut.
History syncer skapar en händelse, eskalering för att skapa varningar om det krävs av konfigurationen och poster. Om det finns utlösare för efterföljande bearbetning, lagrar den detta värde i ValueCache för att inte komma åt historiktabellen. Så här fylls ValueCache med data som är nödvändig för att beräkna triggers och beräknade element.
History syncer skriver all data till databasen och den skriver till disk. Bearbetningsprocessen slutar här.
Cachning i databasen
På databassidan finns olika cacher när du vill se grafer eller rapporter om händelser:
Innodb_buffer_poolpå MySQL-sidan;shared_bufferspå PostgreSQL-sidan;effective_cache_sizepå Oracle-sidan;shared_poolpå DB2-sidan.
Det finns många andra cacher, men dessa är de viktigaste för alla databaser. De låter dig lagra data i RAM som ofta behövs för frågor. De har sin egen teknik för detta.
Databasprestanda är avgörande
Zabbix-servern samlar ständigt in data och skriver den. När den startas om läser den också från historiken för att fylla ValueCache. Använder manus och rapporter Zabbix API, som är byggt på ett webbgränssnitt. Zabbix API kommer åt databasen och hämtar nödvändig data för grafer, rapporter, händelselistor och senaste numren.
För visualisering - grafana. Detta är en populär lösning bland våra användare. Den kan skicka förfrågningar direkt via Zabbix API och till databasen, och skapar en viss konkurrens för att ta emot data. Därför behövs finare och bättre justering av databasen för att matcha den snabba leveransen av resultat och testning.
hushållerska
Den tredje prestationsutmaningen i Zabbix är historikrensning med hjälp av Housekeeper. Den följer alla inställningar - dataelementen indikerar hur länge du ska lagra dynamiken för förändringar (trender) i dagar.
Vi beräknar TrendsCache i farten. När data anländer aggregerar vi den i en timme och registrerar den i tabeller för dynamiken i trendförändringar.
Hushållerskan startar och raderar information från databasen med de vanliga "selects". Detta är inte alltid effektivt, vilket framgår av prestandagraferna för interna processer.
Den röda grafen visar att Historiksyncern ständigt är upptagen. Den orangea grafen längst upp är Housekeeper, som är igång hela tiden. Han väntar på att databasen ska ta bort alla rader som han angav.
När ska du inaktivera Housekeeper? Till exempel finns det ett "Artikel-ID" och du måste ta bort de senaste 5 tusen raderna inom en viss tid. Naturligtvis sker detta per index. Men vanligtvis är datasetet väldigt stort, och databasen läser fortfarande från disken och lägger den i cachen. Detta är alltid en mycket dyr operation för databasen och kan, beroende på databasens storlek, leda till prestandaproblem.
Hushållerska är lätt att inaktivera. I webbgränssnittet finns en inställning i "Administration general" för Housekeeper. Vi inaktiverar intern hushållning för intern trendhistorik och den hanterar det inte längre.
Hushållerskan stängdes av, graferna planade ut - vilka problem kan det finnas i det här fallet och vad kan hjälpa till att lösa den tredje prestationsutmaningen?
Partitionering - partitionering eller partitionering
Vanligtvis konfigureras partitionering på ett annat sätt på varje relationsdatabas som jag har listat. Var och en har sin egen teknik, men de liknar i allmänhet. Att skapa en ny partition leder ofta till vissa problem.
Vanligtvis konfigureras partitioner beroende på "inställningen" - mängden data som skapas på en dag. Som regel utfärdas partitionering på en dag, detta är minimum. För trender för en ny sats - 1 månad.
Värdena kan ändras om "inställningen" är mycket stor. Om en liten "setup" är upp till 5 000 nvps (nya värden per sekund), är en medium från 5 000 till 25 000, då är en stor över 25 000 nvps. Det är stora och mycket stora installationer som kräver noggrann konfiguration av databasen.
På mycket stora installationer kanske en period på en dag inte är optimal. Jag har sett MySQL-partitioner på 40 GB eller mer per dag. Detta är en mycket stor mängd data som kan orsaka problem och som måste minskas.
Vad ger partitionering?
Skiljebord. Ofta är dessa separata filer på disk. Frågeplanen väljer en partition mer optimalt. Vanligtvis används partitionering efter intervall - detta gäller även för Zabbix. Vi använder "tidsstämpel" där - tid sedan början av eran. Det här är vanliga siffror för oss. Du ställer in början och slutet av dagen - det här är en partition.
Snabb borttagning - DELETE. En fil/undertabell väljs istället för ett urval av rader för radering.
Snabbar upp datahämtning avsevärt SELECT - använder en eller flera partitioner, snarare än hela tabellen. Om du kommer åt data som är två dagar gammal, hämtas den snabbare från databasen eftersom du bara behöver ladda en fil i cachen och returnera den, inte en stor tabell.
Ofta accelereras också många databaser INSERT — insättningar i den underordnade tabellen.
Tidsskala DB
För v 4.2 riktade vi vår uppmärksamhet mot TimescaleDB. Detta är en tillägg för PostgreSQL med ett inbyggt gränssnitt. Tillägget fungerar effektivt med tidsseriedata, utan att förlora fördelarna med relationsdatabaser. TimescaleDB partitionerar också automatiskt.
TimescaleDB har ett koncept hypertabell (hypertable) som du skapar. Det innehåller bitar - partitioner. Chunks är automatiskt hanterade hypertabellfragment som inte påverkar andra fragment. Varje bit har sitt eget tidsintervall.
TimescaleDB vs PostgreSQL
TimescaleDB fungerar riktigt effektivt. Tilläggets tillverkare hävdar att de använder en mer korrekt frågebehandlingsalgoritm, i synnerhet inserts . När datauppsättningsinfogningens storlek växer bibehåller algoritmen konstant prestanda.
Efter 200 miljoner rader börjar PostgreSQL vanligtvis sjunka avsevärt och förlorar prestanda till 0. TimescaleDB tillåter dig att effektivt infoga "inlägg" för vilken mängd data som helst.
Installation
Att installera TimescaleDB är ganska enkelt för alla paket. I allt beskrivs i detalj - det beror på de officiella PostgreSQL-paketen. TimescaleDB kan också byggas och kompileras manuellt.
För Zabbix-databasen aktiverar vi helt enkelt tillägget:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Du aktiverar extension och skapa den för Zabbix-databasen. Det sista steget är att skapa en hypertabell.
Migrera historiktabeller till TimescaleDB
Det finns en speciell funktion för detta 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 parametrar. Först - tabell i databasen, som du måste skapa en hypertabell för. andra - fält, enligt vilken du måste skapa chunk_time_interval — intervall mellan partitionsbitar som ska användas. I mitt fall är intervallet en dag - 86 400.
Tredje parametern - migrate_data. Om du ställer in true, sedan överförs all aktuell data till förskapade bitar. Jag använde den själv migrate_data. Jag hade ungefär 1 TB, vilket tog över en timme. Till och med i vissa fall, under testningen, raderade jag historiska data av teckentyper som inte krävdes för lagring, för att inte överföra dem.
Sista steget - UPDATE: kl db_extension sätta timescaledbså att databasen förstår att denna tillägg existerar. Zabbix aktiverar den och använder korrekt syntax och frågor till databasen - de funktioner som är nödvändiga för TimescaleDB.
Hårdvarukonfiguration
Jag använde två servrar. Först - VMware maskin. Den är ganska liten: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz-processorer, 16 GB RAM och en 200 GB SSD.
Jag installerade PostgreSQL 10.8 på den med Debian 10.8-1.pgdg90+1 OS och xfs filsystem. Jag konfigurerade allt minimalt för att använda just den här databasen, minus vad Zabbix själv kommer att använda.
På samma maskin fanns en Zabbix-server, PostgreSQL och lastmedel. Jag hade 50 aktiva medel som använde LoadableModuleför att mycket snabbt generera olika resultat: siffror, strängar. Jag fyllde databasen med mycket data.
Ursprungligen innehöll konfigurationen 5 000 element data per värd. Nästan varje element innehöll en trigger för att göra det likt riktiga installationer. I vissa fall fanns det mer än en trigger. För en nätverksnod fanns det 3 000-7 000 triggers.
Uppdateringsintervall för dataobjekt − 4-7 sekunder. Jag reglerade själva belastningen genom att inte bara använda 50 medel, utan lägga till fler. Med hjälp av dataelement justerade jag också belastningen dynamiskt och minskade uppdateringsintervallet till 4 s.
PostgreSQL. 35 000 nvps
Min första körning på den här hårdvaran var på ren PostgreSQL - 35 tusen värden per sekund. Som du kan se tar det bråkdelar av en sekund att infoga data - allt är bra och snabbt. Det enda är att en 200 GB SSD-disk fylls snabbt.
Detta är en standardinstrumentpanel för Zabbix-serverprestanda.
Den första blå grafen är antalet värden per sekund. Den andra grafen till höger är laddningen av byggprocesser. Den tredje är att ladda interna byggprocesser: historiksynkronisering och Housekeeper, som har körts här ganska länge.
Den fjärde grafen visar HistoryCache-användning. Detta är en slags buffert innan det infogas i databasen. Den gröna femte grafen visar ValueCache-användning, det vill säga hur många ValueCache-träffar för triggers - det är flera tusen värden per sekund.
PostgreSQL. 50 000 nvps
Sedan ökade jag belastningen till 50 tusen värden per sekund på samma hårdvara.
När du laddade från Housekeeper tog det 10-2 sekunder att infoga 3 tusen värden.
Hushållerskan börjar redan störa arbetet.
Den tredje grafen visar att belastningen på fångare och historiesynkare i allmänhet fortfarande är 60 %. I den fjärde grafen börjar HistoryCache redan fyllas ganska aktivt under Housekeeper-drift. Den är 20 % full, vilket är cirka 0,5 GB.
PostgreSQL. 80 000 nvps
Sedan ökade jag belastningen till 80 tusen värden per sekund. Detta är cirka 400 tusen dataelement och 280 tusen triggers.
Laddningskostnaden för trettio historiksynkare är redan ganska hög.
Jag ökade också olika parametrar: historiksynkronisering, cachar.
På min hårdvara ökade laddningen av historiksynkroniseringar till det maximala. HistoryCache fylldes snabbt med data - data för bearbetning hade samlats i bufferten.
Hela denna tid observerade jag hur processorn, RAM-minnet och andra systemparametrar användes, och fann att diskutnyttjandet var på sitt maximala.
Jag har uppnått användningen maximal diskkapacitet på den här hårdvaran och på den här virtuella maskinen. Med sådan intensitet började PostgreSQL spola data ganska aktivt, och disken hade inte längre tid att skriva och läsa.
Andra servern
Jag tog en annan server, som redan hade 48 processorer och 128 GB RAM. Jag trimmade den - ställde in den på 60 historiksyncer och uppnådde acceptabel prestanda.
Detta är faktiskt redan gränsen för produktiviteten där något måste göras.
TidsskalaDB. 80 000 nvps
Min huvudsakliga uppgift är att testa funktionerna hos TimescaleDB mot Zabbix-belastning. 80 tusen värden per sekund är mycket, frekvensen för att samla in mätvärden (förutom Yandex, naturligtvis) och en ganska stor "inställning".
Det finns en dipp i varje graf - detta är just datamigreringen. Efter misslyckanden i Zabbix-servern ändrades laddningsprofilen för historiesyncern mycket - den sjönk tre gånger.
TimescaleDB låter dig infoga data nästan 3 gånger snabbare och använda mindre HistoryCache.
Följaktligen kommer du att få information i tid.
TidsskalaDB. 120 000 nvps
Sedan ökade jag antalet dataelement till 500 tusen. Huvuduppgiften var att testa funktionerna hos TimescaleDB - jag fick ett beräknat värde på 125 tusen värden per sekund.
Detta är en fungerande "setup" som kan fungera under lång tid. Men eftersom min disk bara var 1,5 TB fyllde jag på den på ett par dagar.
Det viktigaste är att samtidigt skapades nya TimescaleDB-partitioner.
Detta är helt omärkligt för prestanda. När partitioner skapas i till exempel MySQL är allt annorlunda. Detta händer vanligtvis på natten eftersom det blockerar allmän infogning, arbetar med tabeller och kan skapa tjänsteförsämring. Detta är inte fallet med TimescaleDB.
Som ett exempel kommer jag att visa en graf från många i samhället. På bilden är TimescaleDB aktiverat, tack vare vilket belastningen på att använda io.weight på processorn har sjunkit. Användningen av interna processelement minskade också. Dessutom är detta en vanlig virtuell maskin på vanliga pannkaksskivor, inte en SSD.
Resultat
TimescaleDB är en bra lösning för små "setup", som påverkar diskens prestanda. Det gör att du kan fortsätta arbeta bra tills databasen migreras till hårdvara så snabbt som möjligt.
TimescaleDB är lätt att konfigurera, ger prestandavinster, fungerar bra med Zabbix och har fördelar jämfört med PostgreSQL.
Om du använder PostgreSQL och inte planerar att ändra det rekommenderar jag använd PostgreSQL med tillägget TimescaleDB i kombination med Zabbix. Denna lösning fungerar effektivt upp till en medelstor "setup".
När vi säger "hög prestanda" menar vi . Du kommer inte att behöva vänta länge på att lära dig mer om teknik och praxis som gör det möjligt för tjänster att betjäna miljontals användare. Lista för 7 och 8 november har vi redan sammanställt, men här mer kan föreslås.
Prenumerera på vår и , där vi avslöjar funktionerna i den kommande konferensen och tar reda på hur du får ut det mesta av den.
Källa: will.com