HighLoad++, Michail Makurov, Maxim Tjernetsov (Intersvyaz): Zabbix, 100kNVPS på en server

Nästa konferens HighLoad++ äger rum den 6 och 7 april 2020 i Sankt Petersburg. Mer information och biljetter. via länken. HighLoad++ Moskva 2018. Sal "Moskva". 9 november, 15:00. Sammanfattningar och presentation.

* Övervakning – online och analys.
* Grundläggande begränsningar av plattformen ZABBIX.
* Lösning för skalning av analyslagring.
* Optimering av ZABBIX-servern.
* Optimering av UI.
* Erfarenhet av systemdrift med belastningar över 40k NVPS.
* Kort sammanfattning.

Mikhail Makurov (hädanefter – MM): – Hej allihopa!

Maxim Chernytsov (hädanefter – MC): – God eftermiddag!

MM: – Låt mig få presentera Maxim. Max – en talangfull ingenjör, den bästa nätverksspecialisten jag känner. Maxim arbetar med nätverk och tjänster, deras utveckling och drift.

MC: – Och jag skulle vilja berätta om Mikhail. Mikhail – en programmerare i C. Han har skrivit flera högpresterande lösningar för trafikbehandling för vårt företag. Vi bor och arbetar i Ural, i staden med stränga män Tjeljabinsk, på företaget "Intersvyaz". Vårt företag är en internet- och kabel-TV-leverantör till en miljon människor i 16 städer.

MM: – Och det är värt att nämna att "Intersvyaz" är mycket mer än bara en leverantör, det är ett IT-företag. De flesta av våra lösningar har skapats av vår IT-avdelning.

A: Från servrar som hanterar trafik till callcenter och mobilapplikationer. IT-avdelningen har för närvarande cirka 80 personer med mycket varierande kompetens.

Om Zabbix och dess arkitektur

MC: – Och nu ska jag försöka sätta ett personligt rekord och på en minut förklara vad Zabbix (hädanefter – "Zabbix") är.

"Zabbix" positionerar sig som ett övervakningssystem "out of the box" på företagsnivå. Det har många funktioner som förenklar livet: avancerade eskaleringsregler, API för integration, gruppering och automatisk upptäckte av värdar och mätvärden. I "Zabbix" finns så kallade skalningsverktyg – proxyer. "Zabbix" är ett system med öppen källkod.

Kort om arkitekturen. Man kan säga att den består av tre komponenter:

• Server. Skriven i C. Med relativt komplex bearbetning och överföring av information mellan trådar. All bearbetning sker där: från mottagning till lagring i databasen.
• All data lagras i en databas. "Zabbix" stödjer MySQL, PostgreSQL och Oracle.
• Webbgränssnittet är skrivet i PHP. I de flesta system levereras det med Apache-servern, men det fungerar effektivare i kombination med nginx + php.

I dag skulle vi vilja berätta en historia från vårt företags liv, kopplad till "Zabbix"…

En historia från företaget "Intersvyaz". Vad vi har och vad vi behöver?

För 5 eller 6 månader sedan. En dag efter arbetet…

MC: – Misha, hej! Kul att jag lyckades få tag på dig – vi måste prata. Vi har haft problem med övervakningen igen. Under en stor olycka stannade allt, och det fanns ingen information om nätverksstatusen. Tyvärr upprepas det här inte för första gången. Jag behöver din hjälp. Låt oss se till att vår övervakning fungerar under alla omständigheter!

MM: – Men först låt oss synkronisera oss. Jag har inte tittat där på ett par år. Såvitt jag minns avsade vi oss Nagios och gick över till "Zabbix" för ungefär 8 år sedan. Och nu har vi, verkar det som, 6 kraftfulla servrar och cirka ett dussin proxys. Jag blandar inte ihop något?

MC: – Nästan. 15 servrar, varav en del är virtuella maskiner. Det viktigaste är att det inte räddar oss i de ögonblick när vi behöver det som mest. Vid olyckor – servrarna hänger sig och inget syns. Vi har försökt optimera konfigurationen, men det ger ingen optimal prestandaförbättring.

MM: – Jag förstår. Har ni sett på något, har ni redan grävt i diagnostiken?

MC: – Det första vi har att göra med är just databasen. MySQL är ständigt belastad och lagrar nya mätvärden, och när "Zabbix" börjar generera en massa händelser – går databasen in i sig själv i bokstavligen flera timmar. Jag har redan berättat om optimering av konfigurationen, men just i år har vi uppdaterat hårdvaran: servrarna har över hundra gigabyte minne och diskar på SSD RAID – det finns ingen poäng i att öka storleken längre. Vad ska vi göra?

MM: – Jag förstår. Generellt är MySQL en LTP-databas. Det verkar som att den inte längre passar för lagring av arkivet av mätvärden av vår storlek. Låt oss analysera det.

MC: – Låt oss göra det!

Integrationen av Zabbix och Clickhouse som en resultat av hackathonet

Efter en tid fick vi intressanta data:

Den största delen av utrymmet i vår databas var upptagen av en arkiv av mätningar och mindre än 1 % användes för konfiguration, mallar och inställningar. Vid den tidpunkten hade vi redan använt en Big Data-lösning baserad på Clickhouse i över ett år. Riktningen för oss var uppenbar. På vår vår Hackathon skrev jag en integration av Zabbix med Clickhouse för servern och fronten. Vid den tidpunkten hade Zabbix redan stöd för ElasticSearch, och vi bestämde oss för att jämföra dem.

Jämförelse mellan Clickhouse och Elasticsearch

MM: – För jämförelsen genererade vi en belastning som motsvarade den som Zabbix-servern levererar och såg hur systemen skulle prestera. Vi skrev data i batchar om 1000 rader och använde CURL. Vi antog på förhand att Clickhouse skulle vara mer effektivt för den belastningsprofil som Zabbix producerar. Resultaten överträffade till och med våra förväntningar:

Under samma förutsättningar vid testerna skrev Clickhouse tre gånger så mycket data. Båda systemen konsumerade mycket effektivt (lite resurser) vid läsning av data. Men ElasticSearch krävde en stor mängd processorkraft vid skrivning:

Sammanfattningsvis överträffade Clickhouse ElasticSearch betydligt både vad gäller processoranvändning och hastighet. Genom datakomprimering använder Clickhouse dessutom 11 gånger mindre utrymme på hårddisken och gör ungefär 30 gånger färre diskoperationer:

MC: – Ja, arbetet med diskunderlaget i Clickhouse är väldigt effektivt implementerat. För databaser kan man använda stora SATA-diskar och uppnå skrivhastigheter på hundratusentals rader per sekund. Systemet stödjer sharding och replikering direkt ur lådan och är ganska enkelt att ställa in. Vi är mer än nöjda med dess drift under ett år.

För att optimera resurser kan Clickhouse installeras bredvid den befintliga huvuddatabasen och därmed spara en hel del processor- och diskoperationstid. Vi har flyttat arkivet av mätningar till redan existerande Clickhouse-kluster:

Vi har avlastat den huvudsakliga MySQL-databasen så mycket att vi kunde kombinera den på en och samma maskin med Zabbix-servern och avstå från en dedikerad server för MySQL.

Hur fungerar polling i Zabbix?

4 månader sedan

MM: – Tja, kan vi glömma problemen med databasen?

MC: – Det stämmer! En annan uppgift vi behöver lösa är den långsamma datainsamlingen. Nu är alla våra 15 proxyservrar överbelastade med SNMP-processer och polling. Och det finns inget annat alternativ än att sätta upp fler och fler servrar.

MM: – Utmärkt. Men berätta först hur polling fungerar i "Zabbix"?

MC: – Kort sagt finns det 20 typer av mätvärden och ett dussin sätt att få dem. "Zabbix" kan samla in data antingen i läget "request – response" eller vänta på nya data via "Trappergränssnittet".

Det är värt att notera att i det ursprungliga "Zabbix" är den här metoden (Trapper) den snabbaste.

Det finns proxyservrar för lastbalansering:

Proxyer kan utföra samma insamlingsfunktioner som "Zabbix-servern", genom att få uppgifter från den och skicka de insamlade mätvärdena direkt via Trapper-gränssnittet. Detta är det officiellt rekommenderade sättet att balansera lasten. Proxyer är också användbara för att övervaka fjärrinfrastruktur som arbetar genom NAT eller en långsam kanal:

MM: – Arkitekturen är tydlig. Vi måste titta på källkoden...

Några dagar senare

Sagan om hur nmap fping segrade

MM: – Det verkar som om jag har hittat något.

MC: – Berätta!

MM: – Jag upptäckte att när "Zabbix" gör tillgänglighetstester kontrollerar den högst 128 värdar samtidigt. Jag försökte öka det här talet till 500 och tog bort mellanpaketsintervallet i deras ping – vilket dubblerade prestandan. Men jag skulle vilja ha större siffror.

MC: – I min praktik måste jag ibland kontrollera tillgängligheten av tusentals värdar, och jag har inte sett något som är snabbare än nmap för det. Jag är säker på att det är det snabbaste sättet. Låt oss prova det! Vi måste signifikant öka antalet värdar per iteration.

MM: – Kontrollera fler än fem hundra? 600?

MC: – Minst ett par tusen.

MM: – Okej. Det viktigaste jag ville säga: jag har funnit att det mesta av pollingen i "Zabbix" görs synkront. Vi måste definitivt göra om det i asynkront läge. Då kan vi radikalt öka antalet mätvärden som samlas in av pollers, speciellt om vi ökar antalet mätvärden per iteration.

MC: – Fantastiskt! Och när?

MM: – Som vanligt, igår.

MC: – Vi jämförde båda versionerna av fping och nmap:

På ett stort antal värdar visade sig nmap vara upp till fem gånger effektivare än väntat. Eftersom nmap bara kontrollerar tillgänglighet och svarstid flyttade vi förlustberäkningarna till triggers och minskade avsevärt intervallen för tillgänglighetskontroll. Det optimala antalet värdar för nmap fann vi vara runt 4000 per iteration. Nmap gjorde det möjligt för oss att minska CPU-kostnaderna för tillgänglighetskontroller med tre gånger och förkorta intervallet från 120 sekunder till 10.

Optimering av polling

MM: – Sedan tog vi oss an pollarna. Framförallt var vi intresserade av att hämta SNMP och agenter. I "Zabbix" görs polling synkront och speciella åtgärder har vidtagits för att öka systemets effektivitet. I synkront läge orsakar otillgänglighet av värdar en betydande nedgång i pollingen. Det finns ett helt system av tillstånd och speciella processer – de så kallade unreachable-pollarna, som endast arbetar med otillgängliga värdar:

Detta är en kommentar som visar tillståndsmatrisen, hela komplexiteten i tillståndsövergångarna som krävs för att systemet ska förbli effektivt. Dessutom är själva den synkrona pollingen ganska långsam:

Det är därför tusentals trådar av pollare på ett dussin proxyservrar inte kunde samla in det önskade antalet uppgifter för oss. Den asynkrona implementeringen löste inte bara problemen med antalet trådar, utan förenklade också tillståndssystemet för otillgängliga värdar avsevärt, eftersom den maximala väntetiden vid vilket antal kontrollerade i en iterationspolling var 1 timeout:

Dessutom modifierade och utvecklade vi polling-systemet för SNMP-förfrågningar. Det är så att de flesta inte kan svara på flera SNMP-förfrågningar samtidigt. Därför gjorde vi ett hybridläge, där SNMP-pollingen för samma värd görs asynkront:

Detta görs för hela gruppen av värdar. Detta läge är i slutändan inte långsammare än helt asynkront, eftersom en förfrågan av 150 SNMP-värden fortfarande är mycket snabbare än 1 timeout.

Våra experiment visade att det optimala antalet förfrågningar per iteration är cirka 8000 vid SNMP-polling. Sammanfattningsvis har övergången till asynkront läge möjliggjort att öka pollingens prestanda 200 gånger, i flera hundra gånger.

MC: De erhållna optimeringarna av polling har visat att vi inte bara kan bli av med alla proxyer, utan också minska intervallen för många kontroller, och proxyer kommer att bli överflödiga som metod för lastfördelning.

För cirka tre månader sedan

Ändra arkitekturen – öka lasten!

MM: Nåväl, Max, är det dags för produktion? Jag behöver en kraftfull server och en bra ingenjör.

MC: Okej, vi planerar det. Det är verkligen dags att komma vidare från deadlocken på 5 000 mätvärden per sekund.

Morgonen efter uppgraderingen

MC: Misha, vi uppdaterade, men till morgonen återgick vi tillbaka… Gissa vilken hastighet vi lyckades uppnå?

MM: Cirka 20 tusen högst.

MC: Aha, 25! Tyvärr är vi där vi började.

MM: Vad hände? Har ni gjort någon diagnos?

MC: Ja, självklart! Här är till exempel en intressant top:

MM: Låt oss titta. Jag ser att vi försökte med ett enormt antal pollingtrådar:

Men vi har samtidigt inte kunnat utnyttja systemet ens till hälften:

Och den totala prestandan är ganska låg, runt 4 000 mätvärden per sekund:

Finns det något mer?

MC: Ja, strace av en av pollrarna:

MM: Här ser vi tydligt att pollingprocessen väntar på "semaforer". Det är blockeringar:

MC: Oklart.

MM: Titta, det liknar en situation där många trådar försöker arbeta med en resurs, som bara kan användas av en åt gången. Då kan de allt de kan göra – dela den här resursen över tid:

Och den sammanlagda prestandan med en sådan resurs begränsas av hastigheten av en kärna:

Det finns två sätt att lösa ett sådant problem.

Uppgradera maskinens hårdvara, gå till snabbare kärnor:

Eller ändra arkitektur och parallellt – lasten:

MC: För övrigt kommer vi att använda ett mindre antal kärnor på testmaskinen än på produktionsmaskinen, men de är cirka 1,5 gånger snabbare i klockfrekvens per kärna!

MM: Förstår du? Vi måste kolla serverkoden.

Datavägen i Zabbix-servern

MC: För att förstå, började vi analysera hur data överförs inom "Zabbix"-servern:

En cool bild, eller hur? Låt oss gå igenom den steg för steg för att mer eller mindre klargöra. Det finns trådar och tjänster som är ansvariga för att samla in data:

De insamlade mätvärdena skickar de via en socket till Preprocessor manager, där de sparas i en kö:

"Preprocessor manager" vidarebefordrar data till sina arbetare, som utför instruktionerna för förbehandling och returnerar dem tillbaka via samma socket:

Efter detta sparar preprocessormanagern dem i historikkölen:

Där hämtas de av historiesynkroniserare som utför flera funktioner: till exempel beräkning av triggar, fyllning av värdekölen och, viktigast av allt, lagring av mätvärden i historiklagret. Sammanfattningsvis är processen komplicerad och ganska förvirrande.

MM: – Det första vi såg var att de flesta trådar konkurrerade om den så kallade "konfigurationscache" (ett minnesområde där alla serverkonfigurationer lagras). Särskilt många lås görs av trådar som ansvarar för datainsamling:

…eftersom konfigurationen lagrar inte bara mätvärden med deras parametrar, utan också köer från vilka pollare hämtar information om vad de ska göra härnäst. När det finns många pollare, och en blockerar konfigurationen, väntar de andra på förfrågningar:

Pollare bör inte konfliktera

Därför var det första vi gjorde att dela upp kön i 4 delar och tillåta pollarna att säkert blockera dessa köer, dessa delar samtidigt:

Detta eliminerade konkurrensen om konfigurationscache, och pollarnas arbets hastighet ökade avsevärt. Men sedan stötte vi på problemet att preprocessormanagern började samla på sig en kö av uppgifter:

Preprocessormanagern måste kunna prioritera

Detta hände när det saknades prestanda. Då var allt han kunde göra att samla in förfrågningar från datainsamlingsprocesser och lagra dem i bufferten tills den tog hela minnet och kraschade:

För att lösa detta problem lade vi till en andra socket som var speciellt avsedd för arbetare:

Således fick preprocessormanagern möjlighet att prioritera sitt arbete och i händelse av bufferttillväxt fördröja insamlingen, vilket gav arbetarna möjlighet att ta den bufferten:

Därefter upptäckte vi att en av anledningarna till fördröjningen var arbetarna själva, eftersom de konkurrerade om en resurs som var helt oviktig för deras arbete. Detta problem formulerade vi som en buggfix, och i de nya versionerna av "Zabbix" är det redan löst:

Ökar antalet sockets – får resultat

Därefter blev själva preprocessormanagern en flaskhals, eftersom detta är en tråd. Den nådde kärnans hastighet och gav en maximal hastighet på cirka 70 000 mätvärden per sekund:

Så vi gjorde fyra, med fyra uppsättningar av sockets, arbetare:

Och det gjorde att vi kunde öka hastigheten till ungefär 130 000 mätningar:

Icke-linjäriteten i tillväxten förklaras av att det uppstod konkurrens om cache-historiken. Fyra preprocessormanagers och history-synkroniserare tävlade om den. Vid den tidpunkten fick vi på testmaskinen ungefär 130 000 mätningar per sekund, och utnyttjade den ungefär 95 % av processorn:

För ungefär 2,5 månader sedan

Att överge snmp-community ökade NVP:erna med en och en halv gång

MM: – Max, jag behöver en ny testmaskin! I den nuvarande får vi inte plats längre.

MC: – Vad har vi just nu?

MM: – Just nu – 130k NVP:er och processorn "i hyllan".

MC: – Wow! Coolt! Vänta, jag har två frågor. Enligt mina beräkningar ligger vårt behov på cirka 15-20 000 mätningar per sekund. Varför behöver vi mer?

MM: – Jag vill göra jobbet färdigt. Jag vill se hur mycket vi kan få ut av det här systemet.

MC: – Men…

MM: – Men det är värdelöst för verksamheten.

MC: – Förstår. Och den andra frågan: kommer vi att kunna stödja det vi har nu på egen hand, utan hjälp av utvecklaren?

MM: – Jag tror inte det. Att ändra hur konfigurationscachen fungerar är ett problem. Det berör ändringar i de flesta trådar och är ganska svårt att underhålla. Det kommer sannolikt att bli väldigt tufft att stödja.

MC: – Då behöver vi något alternativ.

MM: – Det finns ett alternativ. Vi kan gå över till snabba kärnor och överge det nya låsningssystemet. Vi får fortfarande en prestanda på 60-80 000 mätningar. Samtidigt kan vi behålla all annan kod. "Clickhouse" och asynkron polling kommer att fungera. Och det kommer att vara lätt att underhålla.

MC: – Utmärkt! Jag föreslår att vi stannar här.

Efter optimering av serverdelen kunde vi äntligen lansera den nya koden i produktion. Vi avstod från vissa ändringar för att gå över till en maskin med snabba kärnor och minimera antalet ändringar i koden. Vi förenklade också konfigurationen och avstod från makron i datakomponenterna när det var möjligt, eftersom de är en källa till extra låsningar.

Till exempel ledde övergivandet av det makro snmp-community som ofta förekommer i dokumentationen och exemplen i vårt fall till en ytterligare ökning av NVP:erna med cirka 1,5 gånger.

Efter två dagar i produktion

Vi tar bort popup-fönster för incidenthistorik

MC: – Misha, vi har använt systemet i två dagar, och allt fungerar. Men bara när allt fungerar! Vi hade planerat arbete med att flytta en ganska stor del av nätverket, och vi kontrollerade återigen manuellt vad som fungerade och vad som inte gjorde.

MM: – Det kan inte vara sant! Vi har kontrollerat allt tio gånger. Servern hanterar till och med fullständig nätverksavbrott omedelbart.

MC: – Jag förstår allt: servern, databasen, top, austat, loggar – allt går snabbt… Men vi tittar på webbgränssnittet, och där är CPU:n på servern «i viloläge» och detta:

MM: – Förstår. Låt oss titta på webbgränssnittet. Vi upptäckte att i situationer med ett stort antal aktiva incidenter, började de flesta operativa widgets att arbeta mycket långsamt:

Orsaken till detta var generering av popup-fönster med incidenthistorik, som genereras för varje element i listan. Därför avstod vi från att generera dessa fönster (kommenterade 5 rader i koden), och detta löste våra problem.

Laddningstiden för widgets, även vid fullständig otillgänglighet, minskade från flera minuter till acceptabla 10-15 sekunder för oss, och historik kan fortfarande granskas genom att klicka på tidslinjen:

Efter jobbet. För två månader sedan

MC: – Misha, går du? Vi måste prata.

MM: – Jag tänkte inte göra det. Är det något med «Zabbix» igen?

MC: – Nej, slappna av! Jag ville bara säga: allt fungerar, tack! Jag bjuder på öl.

Zabbix är effektiv

«Zabbix» är ett ganska mångsidigt och rikt system och funktion. Det går bra att använda det för små installationer «ur lådan», men med ökade behov måste det optimeras. För att lagra ett stort arkiv av metrik, använd ett lämpligt lagringssystem:

• Du kan använda de inbyggda funktionerna i form av integration med «Elasticsearch» eller exportering av historik till textfiler (tillgängligt från fjärde versionen);
• Du kan använda vår erfarenhet och integration med «ClickHouse».

För att radikalt öka hastigheten på insamlingen av metrik, samla dem med asynkrona metoder och överför dem via trapper-gränssnittet till «Zabbix»-servern; eller så kan du använda en patch för asynkronitet för Zabbix:s poller.

Zabbix är skrivet i C och är ganska effektivt. De specifika arkitekturproblem som finns gör det möjligt att ytterligare öka dess prestanda och, enligt vår erfarenhet, att få mer än 100 000 metrik på en enprocessor-maskin.

Den där patchen Zabbix

MM: – Jag vill lägga till ett par punkter. Hela den aktuella presentationen, alla tester och siffror är presenterade för den konfiguration som vi använder. Från den får vi just nu cirka 20 000 metrik per sekund. Om du försöker förstå om detta kommer att fungera för dig – kan du jämföra. Det som har presenterats idag finns på GitHub som en patch: github.com/miklert/zabbix

Patchen inkluderar:

• fullständig integration med ClickHouse (både Zabbix-servern och frontend);
• lösning av problem med preprocessormanagern;
• asynkron polling.

Patchen är kompatibel med hela version 4, inklusive lts. Troligtvis kommer den att fungera med minimala ändringar på version 3.4.

Tack för uppmärksamheten.

Frågor

Fråga från publiken (hädanefter – A): – Goddag! Kan ni berätta om ni har planer för intensivt samarbete med Zabbix-teamet eller om de har med er, så att det inte bara blir en patch, utan en normal funktionalitet i Zabbix?

MM: – Ja, vi kommer definitivt att committa delar av ändringarna. Vissa saker kommer att stanna i patchen.

A: – Tack så mycket för den utmärkta presentationen! Kan ni berätta om stöd från Zabbix kommer att finnas kvar efter att patchen har tillämpats och hur man sedan uppdaterar till högre versioner? Kommer det att vara möjligt att uppdatera Zabbix efter er patch till 4.2, 5.0?

MM: – När det gäller stödet kan jag inte säga. Om jag var teknisk support för Zabbix skulle jag förmodligen säga nej, eftersom det är en tredjeparts kod. När det gäller kodbasen 4.2 är vår ståndpunkt denna: "Vi kommer att följa med tiden och själva uppdatera till nästa version." Så under en tid kommer vi att publicera patchar för uppdaterade versioner. Jag sa redan i presentationen att antalet ändringar mellan versionerna hittills är ganska litet. Jag tror att övergången från 3.4 till 4 tog oss, verkar det som, cirka 15 minuter. Det har ändrats något, men inte särskilt viktigt.

A: – Så ni planerar att stödja er patch och man kan tryggt installera den i produktion, och få uppdateringar på något sätt framöver?

MM: – Vi rekommenderar det kraftigt. Det löser många av våra problem.

MC: – Jag vill ännu en gång betona att förändringar som inte rör arkitekturen och som inte rör blockeringar eller köer – de är modulära, de finns i separata moduler. Även vid små förändringar kan de stödjas ganska enkelt.

MM: – Om du är intresserad av detaljer, så använder "ClickHouse" det så kallade historikbiblioteket. Det är oberoende – en kopia av stödet för "Elastix", vilket betyder att det kan ändras i configuration. Polling ändrar bara pollarna. Vi tror att detta kommer att fungera länge.

A: – Tack så mycket. Kan du säga om det finns någon dokumentation för de ändringar som gjorts?

MM: – Dokumentationen är en patch. Det är uppenbart att med införandet av "ClickHouse" och nya typer av pollare uppstår nya konfigurationsalternativ. På länken i den senaste sliden finns en kort beskrivning av hur man använder detta.

Om att byta ut fping mot nmap

A: – Hur genomförde ni detta? Kan ni ge konkreta exempel: har ni strappare och ett externt skript? Vad kontrollerar så snabbt så många värdar? Hur får ni tag på dessa värdar? Måste ni på något sätt mata nmap med dem, hämta dem någonstans, spara dem, och sedan köra något?

MM: – Coolt. Mycket bra fråga! Kärnan är denna. Vi modifierade biblioteket (ICMP-ping, en del av "Zabbix") för ICMP-kontroller, där antalet paket anges – en enhet (1), och koden försöker använda nmap. Det vill säga, detta är Zabbix interna arbete, som blev det interna arbetet för pingaren. Därmed behövs ingen synkronisering eller användning av trapper. Detta gjordes medvetet för att behålla systemet intakt och för att inte behöva sy ihop två system av databaser: vad som ska kontrolleras, laddas upp via pollern, och om vi inte har problem med uppladdningen… Det är mycket enklare.

A: – Fungerar det också för proxy?

MM: – Ja, men vi har inte testat det. Koden för pollingen är densamma i Zabbix och servern. Det borde fungera. Jag betonar igen: systemets prestanda är sådan att vi inte behöver proxy.

MC: – Rätt svar på frågan är: "Varför skulle ni ha proxy i ett sådant system?" Bara på grund av NAT eller om ni ska övervaka genom någon långsam kanal...

A: – Använder ni "Zabbix" som en alert-lösning, om jag förstod rätt. Eller har ni grafer (där arkivlagret finns) flyttat till ett annat system, som Grafana? Eller använder ni inte den funktionen?

MM: – Jag vill betona en gång till: vi har gjort en fullständig integration. Vi dumpade historik i "Clickhouse", men ändrade samtidigt PHP-frontenden. PHP-frontenden går till "Clickhouse" och skapar alla diagram därifrån. Ärligt talat har vi en del som bygger på samma "Clickhouse", från samma data från "Zabbix", data för andra grafiska visningssystem.

MC: – I "Grafana" också.

Hur fattades beslutet och om resursfördelningen?

A: – Berätta lite om den interna processen. Hur fattades beslutet att resurser skulle avsättas för en betydande omarbetning av produkten? Det medför ju faktiskt vissa risker. Och snälla, berätta i kontexten av att ni avser att stödja nya versioner: hur motiveras detta beslut från ett managementperspektiv?

MM: – Tydligen har vi inte berättat dramahistorien särskilt bra. Vi befann oss i en situation där något behövde göras, och vi gick på sätt och vis fram med två parallella team:

• Ett team arbetade med att starta ett övervakningssystem med nya metoder: övervakning som tjänst, en standard uppsättning av öppen källkods-lösningar som vi kombinerar och sedan försöker ändra affärsprocessen för att arbeta med det nya övervakningssystemet.
• Parallellt hade vi en entusiastisk programmerare som arbetade med detta (om sig själv). Det blev så att han vann.

A: – Hur stor är teamet?

MC: – Det står framför er.

A: – Så en passionerad person behövs alltid?

MM: – Jag vet inte vad en passionerad person är.

A: – I det här fallet är det tydligen du. Tack så mycket, ni är fantastiska.

MM: – Tack.

Om patchar för Zabbix

A: – För ett system som använder proxy (till exempel i vissa distribuerade system), är det möjligt att anpassa och patcha er lösning, säg, pollare, proxy och delvis preprocessor av Zabbix; och deras interaktion? Är det möjligt att optimera befintliga arbetsmetoder för ett system med flera proxys?

MM: – Jag vet att Zabbix-servern kompileras med hjälp av proxy (den kompilerar och ger kod). Vi har inte testat detta i produktion. Jag är osäker på detta, men enligt min mening används preprocessor-managern inte i proxyn. Uppgiften för proxyn är att ta en uppsättning metrik från Zabbix, spola dem (den skriver också konfigurationen och en lokal databas) och ge tillbaka till Zabbix-servern. Preprocessing kommer att göras av servern senare, när den får det.

Intresset för proxy är förståeligt. Vi kommer att kontrollera detta. Det är ett intressant ämne.

A: – Idén var att om man kan patcha pollare, kan man patcha dem på proxy och anpassa interaktionen med servern, medan förprocessorn anpassas för dessa syften endast på servern.

MM: – Jag tror att det är ännu enklare. Du tar koden, lägger på en patch, konfigurerar den som du vill – samlar proxy-servrar (till exempel med ODBC) och distribuerar den patchade koden över systemen. Där det behövs – samlar du proxy, där det behövs – server.

A: – Behöver man inte patcha överföringen av proxy till servern dessutom?

MC: – Nej, den är standard.

MM: – Egentligen lät en av idéerna inte så. Vi har alltid strävat efter att upprätthålla balansen mellan att få nya idéer och mängden förändringar, samt enkelheten i underhållet.

Lite reklam 🙂

Tack för att ni stannar kvar hos oss. Gillar ni våra artiklar? Vill ni se fler intressanta material? Stöd oss genom att göra en beställning eller rekommendera oss till era vänner, moln-VPS för utvecklare från $4,99, en unik motsvarighet till entry-level servrar som vi har skapat för er: Allt om VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps från $19 eller hur man korrekt delar en server? (alternativ med RAID1 och RAID10 finns tillgängliga, upp till 24 kärnor och upp till 40GB DDR4).

Dell R730xd är två gånger billigare i datacentret Equinix Tier IV i Amsterdam? Bara hos oss 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB från $199 i Nederländerna! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — från $99! Läs om Hur man bygger en företagsinfrastruktur med Dell R730xd E5-2650 v4-servrar som kostar 9000 euro för en bråkdel?

Källa: habr.com