Nästa HighLoad++-konferens kommer att hållas den 6 och 7 april 2020 i St. Petersburg. Detaljer och biljetter . HighLoad++ Moskva 2018. Hall “Moskva”. 9 november, 15:00. Avhandlingar och .
* Övervakning - online och analys.
* Grundläggande begränsningar för ZABBIX-plattformen.
* Lösning för skalning av analyslagring.
* Optimering av ZABBIX-servern.
* Optimering av användargränssnitt.
* Erfarenhet av att använda systemet under belastningar på mer än 40k NVPS.
* Korta slutsatser.
Mikhail Makurov (nedan – MM): - Hej alla!
Maxim Chernetsov (nedan – MCH): - God eftermiddag!
MM: – Låt mig presentera Maxim. Max är en talangfull ingenjör, den bästa nätverkare jag vet. Maxim är involverad i nätverk och tjänster, deras utveckling och drift.
MCH: – Och jag skulle vilja berätta om Mikhail. Mikhail är en C-utvecklare. Han skrev flera högbelastningslösningar för trafikhantering för vårt företag. Vi bor och arbetar i Ural, i de tuffa männens stad Chelyabinsk, i företaget Intersvyaz. Vårt företag är en leverantör av internet- och kabel-tv-tjänster för en miljon människor i 16 städer.
MM: – Och det är värt att säga att Intersvyaz är mycket mer än bara en leverantör, det är ett IT-företag. De flesta av våra lösningar är gjorda av vår IT-avdelning.
A: från servrar som bearbetar trafik till ett callcenter och mobilapplikation. IT-avdelningen har nu ett 80-tal personer med väldigt, väldigt varierande kompetenser.
Om Zabbix och dess arkitektur
MCH: – Och nu ska jag försöka sätta ett personligt rekord och på en minut säga vad Zabbix är (nedan kallat "Zabbix").
Zabbix positionerar sig som ett out-of-the-box övervakningssystem på företagsnivå. Den har många funktioner som gör livet enklare: avancerade eskaleringsregler, API för integration, gruppering och automatisk upptäckt av värdar och mätvärden. Zabbix har så kallade skalningsverktyg – proxyservrar. Zabbix är ett system med öppen källkod.
Kort om arkitektur. Vi kan säga att den består av tre komponenter:
- Server. Skrivet i C. Med ganska komplex bearbetning och överföring av information mellan trådar. All bearbetning sker i den: från att ta emot till att spara till databasen.
- All data lagras i databasen. Zabbix stöder MySQL, PostreSQL och Oracle.
- Webbgränssnittet är skrivet i PHP. På de flesta system kommer den med en Apache-server, men fungerar mer effektivt i kombination med nginx + php.
Idag skulle vi vilja berätta en historia från vårt företags liv relaterad till Zabbix...
En berättelse från livet för företaget Intersvyaz. Vad har vi och vad behöver vi?
5 eller 6 månader sedan. En dag efter jobbet...
MCH: - Misha, hej! Jag är glad att jag lyckades fånga dig - det är ett samtal. Vi hade återigen problem med övervakningen. Vid en större olycka gick allt långsamt och det fanns ingen information om tillståndet på nätet. Tyvärr är det inte första gången det händer. Jag behöver din hjälp. Låt oss få vår övervakning att fungera under alla omständigheter!
MM: – Men låt oss synkronisera först. Jag har inte tittat där på ett par år. Såvitt jag minns så övergav vi Nagios och bytte till Zabbix för cirka 8 år sedan. Och nu verkar vi ha 6 kraftfulla servrar och ett dussin proxyservrar. Förvirrar jag något?
MCH: - Nästan. 15 servrar, varav några är virtuella maskiner. Det viktigaste är att det inte räddar oss i det ögonblick då vi behöver det som mest. Som en olycka - servrarna saktar ner och du kan inte se någonting. Vi försökte optimera konfigurationen, men detta gav inte den optimala prestandaökningen.
MM: - Kusten är klar. Har du tittat på något, har du redan grävt fram något från diagnostiken?
MCH: – Det första du måste ta itu med är databasen. MySQL laddas ständigt, lagrar nya mätvärden, och när Zabbix börjar generera en massa händelser, går databasen i överväxling i bokstavligen några timmar. Jag har redan berättat om optimering av konfigurationen, men bokstavligen i år uppdaterade de hårdvaran: servrarna har mer än hundra gigabyte minne och diskarrayer på SSD RAID - det är ingen idé att växa linjärt på lång sikt. Vad gör vi?
MM: - Kusten är klar. I allmänhet är MySQL en LTP-databas. Tydligen är det inte längre lämpligt för att lagra ett arkiv med mätvärden av vår storlek. Låt oss ta reda på det.
MCH: - Låt oss!
Integrering av Zabbix och Clickhouse som ett resultat av hackathon
Efter en tid fick vi intressanta uppgifter:
Större delen av utrymmet i vår databas upptogs av mätvärdesarkivet och mindre än 1 % användes för konfiguration, mallar och inställningar. Vid den tiden hade vi använt Big data-lösningen baserad på Clickhouse i mer än ett år. Rörelseriktningen var uppenbar för oss. På vårens Hackathon skrev jag integrationen av Zabbix med Clickhouse för servern och frontend. Då hade Zabbix redan stöd för ElasticSearch, och vi bestämde oss för att jämföra dem.
Jämförelse av Clickhouse och Elasticsearch
MM: – Som jämförelse genererade vi samma belastning som Zabbix-servern ger och tittade på hur systemen skulle bete sig. Vi skrev data i satser om 1000 rader, med hjälp av CURL. Vi antog på förhand att Clickhouse skulle vara mer effektivt för den lastprofil som Zabbix gör. Resultaten överträffade till och med våra förväntningar:
Under samma testförhållanden skrev Clickhouse tre gånger mer data. Samtidigt förbrukade båda systemen mycket effektivt (en liten mängd resurser) vid läsning av data. Men Elastics krävde en stor mängd processor vid inspelning:
Totalt sett var Clickhouse betydligt överlägsen Elastix vad gäller processorförbrukning och hastighet. Samtidigt, på grund av datakomprimering, använder Clickhouse 11 gånger mindre på hårddisken och utför cirka 30 gånger färre diskoperationer:
MCH: – Ja, Clickhouses arbete med diskundersystemet implementeras mycket effektivt. Du kan använda enorma SATA-diskar för databaser och få skrivhastigheter på hundratusentals rader per sekund. Out-of-the-box-systemet stöder skärning, replikering och är mycket lätt att konfigurera. Vi är mer än nöjda med dess användning under hela året.
För att optimera resurser kan du installera Clickhouse bredvid din befintliga huvuddatabas och därigenom spara mycket CPU-tid och diskoperationer. Vi har flyttat arkivet med mätvärden till befintliga Clickhouse-kluster:
Vi avlastade den huvudsakliga MySQL-databasen så mycket att vi kunde kombinera den på en maskin med Zabbix-servern och överge den dedikerade servern för MySQL.
Hur fungerar omröstning i Zabbix?
4 månader sedan
MM: – Tja, kan vi glömma problemen med basen?
MCH: - Det är säkert! Ett annat problem vi måste lösa är långsam datainsamling. Nu är alla våra 15 proxyservrar överbelastade med SNMP och pollingprocesser. Och det finns inget annat sätt än att installera nya och nya servrar.
MM: - Bra. Men först, berätta för oss hur omröstning fungerar i Zabbix?
MCH: – Kort sagt, det finns 20 typer av mätvärden och ett dussin sätt att få dem. Zabbix kan samla in data antingen i "request-response"-läget eller vänta på ny data via "Trapper Interface".
Det är värt att notera att i den ursprungliga Zabbix är denna metod (Trapper) den snabbaste.
Det finns proxyservrar för lastdistribution:
Proxies kan utföra samma insamlingsfunktioner som Zabbix-servern, ta emot uppgifter från den och skicka insamlade mätvärden via Trapper-gränssnittet. Detta är det officiellt rekommenderade sättet att fördela belastningen. Proxies är också användbara för att övervaka fjärrinfrastruktur som fungerar via NAT eller en långsam kanal:
MM: – Allt är klart med arkitektur. Vi måste titta på källorna...
Ett par dagar senare
Historien om hur nmap fping vann
MM: "Jag tror att jag grävde fram något."
MCH: - Berätta för mig!
MM: – Jag upptäckte att när Zabbix kontrollerar tillgänglighet kontrollerar Zabbix maximalt 128 värdar åt gången. Jag försökte öka detta antal till 500 och ta bort intervallet mellan paket i deras ping (ping) - detta fördubblade prestandan. Men jag skulle vilja ha större antal.
MCH: – I min praktik måste jag ibland kontrollera tillgängligheten för tusentals värdar, och jag har aldrig sett något snabbare än nmap för detta. Jag är säker på att detta är det snabbaste sättet. Låt oss testa det! Vi måste avsevärt öka antalet värdar per iteration.
MM: – Kontrollera mer än femhundra? 600?
MCH: - Minst ett par tusen.
MM: - Okej. Det viktigaste jag ville säga är att jag upptäckte att de flesta omröstningar i Zabbix görs synkront. Vi måste definitivt ändra det till asynkront läge. Då kan vi dramatiskt öka antalet mätvärden som samlas in av pollare, särskilt om vi ökar antalet mätvärden per iteration.
MCH: - Bra! Och när?
MM: – Som vanligt igår.
MCH: – Vi jämförde båda versionerna av fping och nmap:
På ett stort antal värdar förväntades nmap vara upp till fem gånger effektivare. Eftersom nmap endast kontrollerar tillgänglighet och svarstid flyttade vi beräkningen av förluster till triggers och minskade tillgänglighetskontrollintervallen avsevärt. Vi fann att det optimala antalet värdar för nmap var cirka 4 tusen per iteration. Nmap gjorde det möjligt för oss att minska CPU-kostnaden för tillgänglighetskontroller med tre gånger och minska intervallet från 120 sekunder till 10.
Pollingsoptimering
MM: ”Sedan började vi göra pollers. Vi var främst intresserade av SNMP-detektion och agenter. I Zabbix sker polling synkront och särskilda åtgärder har vidtagits för att öka effektiviteten i systemet. I synkront läge orsakar värdens otillgänglighet betydande försämring av avfrågningen. Det finns ett helt system av stater, det finns speciella processer - de så kallade unreachable pollers, som bara fungerar med onåbara värdar:
Detta är en kommentar som visar tillståndsmatrisen, all komplexiteten i systemet av övergångar som krävs för att systemet ska förbli effektivt. Dessutom är synkron polling i sig ganska långsam:
Det är därför tusentals pollerströmmar på dussintals proxyservrar inte kunde samla in den nödvändiga mängden data åt oss. Den asynkrona implementeringen löste inte bara problemen med antalet trådar, utan förenklade också avsevärt tillståndssystemet för otillgängliga värdar, eftersom den maximala väntetiden var 1 timeout för vilket antal som helst som kontrollerades i en pollingiteration:
Dessutom modifierade och förbättrade vi pollingsystemet för SNMP-förfrågningar. Faktum är att de flesta människor inte kan svara på flera SNMP-förfrågningar samtidigt. Därför gjorde vi ett hybridläge när SNMP-avfrågning av samma värd görs asynkront:
Detta görs för hela paketet med värdar. Detta läge är i slutändan inte långsammare än ett helt asynkront, eftersom polling av ett och ett halvt hundra SNMP-värden fortfarande är mycket snabbare än 1 timeout.
Våra experiment har visat att det optimala antalet förfrågningar i en iteration är cirka 8 tusen med SNMP-undersökning. Totalt tillät övergången till asynkront läge oss att påskynda pollingprestanda med 200 gånger, flera hundra gånger.
MCH: – De resulterande pollingsoptimeringarna visade att vi inte bara kan bli av med alla proxyservrar, utan också minska intervallen för många kontroller, och fullmakter kommer inte längre att behövas som ett sätt att dela belastningen.
För ungefär tre månader sedan
Ändra arkitekturen – öka belastningen!
MM: - Nåväl, Max, är det dags att bli produktiv? Jag behöver en kraftfull server och en bra ingenjör.
MCH: - Okej, låt oss planera det. Det är hög tid att gå från dödpunkten på 5 tusen mätvärden per sekund.
Morgon efter uppgraderingen
MCH: – Misha, vi uppdaterade oss, men på morgonen rullade vi tillbaka... Gissa vilken hastighet vi lyckades uppnå?
MM: – max 20 tusen.
MCH: - Ja, 25! Tyvärr är vi precis där vi började.
MM: - Varför? Körde du någon diagnos?
MCH: - Ja visst! Här är till exempel en intressant topp:
MM: - Låt oss se. Jag ser att vi har provat ett stort antal omröstningstrådar:
Men samtidigt kunde de inte återvinna systemet ens till hälften:
Och den övergripande prestandan är ganska liten, cirka 4 tusen mätvärden per sekund:
Finns det något annat?
MCH: – Ja, spår av en av pollarna:
MM: – Här kan man tydligt se att valprocessen väntar på "semaforer". Dessa är låsen:
MCH: - Oklart.
MM: – Titta, det här liknar en situation där ett gäng trådar försöker arbeta med resurser som bara en kan arbeta med åt gången. Allt de kan göra är att dela den här resursen över tid:
Och den totala prestandan för att arbeta med en sådan resurs begränsas av hastigheten på en kärna:
Det finns två sätt att lösa detta problem.
Uppgradera maskinens hårdvara, byt till snabbare kärnor:
Eller ändra arkitekturen och samtidigt ändra belastningen:
MCH: – Förresten, på testmaskinen kommer vi att använda färre kärnor än på stridsmaskinen, men de är 1,5 gånger snabbare i frekvens per kärna!
MM: - Klar? Du måste titta på serverkoden.
Datasökväg i Zabbix-servern
MCH: – För att ta reda på det började vi analysera hur data överförs inuti Zabbix-servern:
Cool bild, eller hur? Låt oss gå igenom det steg för steg för att göra det mer eller mindre tydligt. Det finns trådar och tjänster som ansvarar för att samla in data:
De överför de insamlade mätvärdena via en socket till Preprocessor-hanteraren, där de sparas i en kö:
"Förbearbetningshanteraren" överför data till sina arbetare, som utför förbearbetningsinstruktioner och returnerar dem tillbaka genom samma uttag:
Efter detta lagrar förprocessorhanteraren dem i historikcachen:
Därifrån tas de av historiesänkare, som utför ganska många funktioner: till exempel beräkna triggers, fylla värdecachen och, viktigast av allt, spara mätvärden i historiklagringen. I allmänhet är processen komplex och mycket förvirrande.
MM: – Det första vi såg var att de flesta trådar konkurrerar om den så kallade "konfigurationscachen" (minnesområdet där alla serverkonfigurationer lagras). Trådar som ansvarar för att samla in data blockerar särskilt mycket:
...eftersom konfigurationen lagrar inte bara mätvärden med sina parametrar, utan också köer från vilka pollare tar information om vad de ska göra härnäst. När det finns många pollers och en blockerar konfigurationen, väntar de andra på förfrågningar:
Pollers bör inte komma i konflikt
Därför var det första vi gjorde var att dela upp kön i fyra delar och låta pollare blockera dessa köer, dessa delar samtidigt, under säkra förhållanden:
Detta tog bort konkurrensen om konfigurationscachen, och pollarnas hastighet ökade avsevärt. Men så stötte vi på det faktum att förprocessorchefen började samla en kö av jobb:
Förbehandlare måste kunna prioritera
Detta skedde i de fall han saknade prestation. Sedan kunde han bara samla förfrågningar från datainsamlingsprocesser och lägga till deras buffert tills den förbrukade allt minne och kraschade:
För att lösa detta problem lade vi till en andra socket som var dedikerad specifikt till arbetare:
Således hade förprocessorchefen möjlighet att prioritera sitt arbete och om bufferten växer är uppgiften att bromsa borttagningen, vilket ger arbetarna möjlighet att ta denna buffert:
Sedan upptäckte vi att en av orsakerna till avmattningen var arbetarna själva, eftersom de konkurrerade om en resurs som var helt oviktig för deras arbete. Vi dokumenterade det här problemet som en buggfix, och det har redan lösts i nya versioner av Zabbix:
Vi ökar antalet uttag - vi får resultatet
Vidare blev förprocessorhanteraren själv en flaskhals, eftersom det är en tråd. Den vilade på kärnhastigheten, vilket gav en maximal hastighet på cirka 70 tusen meter per sekund:
Därför gjorde vi fyra, med fyra uppsättningar uttag, arbetare:
Och detta gjorde det möjligt för oss att öka hastigheten till cirka 130 tusen mätvärden:
Tillväxtens icke-linjäritet förklaras av det faktum att konkurrens om historiecachen har dykt upp. 4 förprocessorchefer och historiesänkare tävlade om det. Vid det här laget fick vi cirka 130 tusen mätvärden per sekund på testmaskinen, och använde den av cirka 95 % av processorn:
För ca 2,5 månader sedan
Avslag från snmp-community ökade NVP med en och en halv gånger
MM: – Max, jag behöver en ny testbil! Vi passar inte längre in i den nuvarande.
MCH: - Vad har du nu?
MM: – Nu – 130 XNUMX NVP:er och en hyllfärdig processor.
MCH: - Wow! Häftigt! Vänta, jag har två frågor. Enligt mina beräkningar är vårt behov runt 15-20 tusen mätvärden per sekund. Varför behöver vi mer?
MM: "Jag vill avsluta jobbet." Jag skulle vilja se hur mycket vi kan pressa ur det här systemet.
MCH: - Men...
MM: "Men det är värdelöst för affärer."
MCH: - Kusten är klar. Och den andra frågan: kan vi stödja det vi har nu på egen hand, utan hjälp av en utvecklare?
MM: - Jag tror inte. Att ändra hur konfigurationscachen fungerar är ett problem. Det påverkar förändringar i de flesta trådar och är ganska svårt att underhålla. Troligtvis kommer det att vara mycket svårt att underhålla det.
MCH: "Då behöver vi något slags alternativ."
MM: – Det finns ett sådant alternativ. Vi kan byta till snabba kärnor, samtidigt som vi överger det nya låssystemet. Vi kommer fortfarande att få en prestanda på 60-80 tusen mätvärden. Samtidigt kan vi lämna resten av koden. Clickhouse och asynkron polling kommer att fungera. Och det blir lätt att underhålla.
MCH: - Fantastisk! Jag föreslår att vi slutar här.
Efter att ha optimerat serversidan kunde vi äntligen lansera den nya koden i produktion. Vi övergav en del av förändringarna till förmån för att byta till en maskin med snabba kärnor och minimera antalet kodändringar. Vi har också förenklat konfigurationen och eliminerat makron i dataobjekt där det är möjligt, eftersom de introducerar ytterligare låsning.
Till exempel, att överge snmp-community-makrot, som ofta finns i dokumentation och exempel, gjorde det i vårt fall möjligt att ytterligare snabba upp NVPs med cirka 1,5 gånger.
Efter två dagar i produktion
Ta bort popup-fönster för incidenthistorik
MCH: – Misha, vi har använt systemet i två dagar och allt fungerar. Men bara när allt fungerar! Vi hade planerat arbete med överföringen av ett ganska stort segment av nätverket, och vi kontrollerade igen med våra händer vad som gick upp och vad som inte gjorde det.
MM: - Kan inte vara det! Vi kollade allt 10 gånger. Servern hanterar till och med fullständig otillgänglighet i nätverket direkt.
MCH: - Ja, jag förstår allt: server, databas, topp, austat, loggar - allt är snabbt... Men vi tittar på webbgränssnittet, och det finns en processor "i hyllan" på servern och detta:
MM: - Kusten är klar. Låt oss titta på webben. Vi upptäckte att i situationer där det förekom ett stort antal aktiva incidenter började de flesta live-widgets att fungera mycket långsamt:
Anledningen till detta var genereringen av popup-fönster för incidenthistorik som genereras för varje objekt i listan. Därför övergav vi genereringen av dessa fönster (kommenterade 5 rader i koden), och detta löste våra problem.
Laddningstiden för widgets, även när de är helt otillgängliga, har minskat från flera minuter till acceptabla 10-15 sekunder för oss, och historiken kan fortfarande ses genom att klicka på tiden:
Efter jobbet. 2 månader sedan
MCH: - Misha, ska du gå? Vi måste prata.
MM: – Det hade jag inte tänkt. Något med Zabbix igen?
MCH: – Nej, slappna av! Jag ville bara säga: allt fungerar, tack! Jag har en öl.
Zabbix är effektivt
Zabbix är ett ganska universellt och rikt system och funktion. Den kan användas för små installationer direkt, men när behoven växer måste den optimeras. För att lagra ett stort arkiv med mätvärden, använd en lämplig lagring:
- du kan använda inbyggda verktyg i form av integration med Elasticsearch eller ladda upp historik till textfiler (tillgänglig från version XNUMX);
- Du kan dra nytta av vår erfarenhet och integration med Clickhouse.
För att dramatiskt öka hastigheten för insamling av mätvärden, samla in dem med asynkrona metoder och överför dem via trapr-gränssnittet till Zabbix-servern; eller så kan du använda en patch för att göra Zabbix pollers asynkrona.
Zabbix är skrivet i C och är ganska effektivt. Genom att lösa flera arkitektoniska flaskhalsar kan du ytterligare öka dess prestanda och, enligt vår erfarenhet, få mer än 100 tusen mätvärden på en enprocessormaskin.
Samma Zabbix patch
MM: – Jag vill lägga till ett par punkter. Hela den aktuella rapporten, alla tester, siffror anges för den konfiguration som vi använder. Vi tar nu cirka 20 tusen mätvärden per sekund från det. Om du försöker förstå om detta kommer att fungera för dig kan du jämföra. Det som diskuterades idag publiceras på GitHub i form av en patch:
Plåstret innehåller:
- fullständig integration med Clickhouse (både Zabbix-server och frontend);
- lösa problem med förprocessorhanteraren;
- asynkron polling.
Patchen är kompatibel med alla versioner 4, inklusive lts. Troligtvis kommer det att fungera på version 3.4 med minimala ändringar.
Tack för er uppmärksamhet.
frågor
Fråga från publiken (nedan – A): – God eftermiddag! Snälla, berätta för mig, har du planer på intensiv interaktion med Zabbix-teamet eller med dem med dig, så att detta inte är en patch, utan normalt beteende hos Zabbix?
MM: – Ja, vi kommer definitivt att genomföra några av förändringarna. Något kommer att hända, något kommer att finnas kvar i lappen.
A: – Tack så mycket för den utmärkta rapporten! Snälla berätta för mig, efter att ha applicerat patchen kommer stödet från Zabbix att finnas kvar och hur man fortsätter att uppdatera till högre versioner? Kommer det att vara möjligt att uppdatera Zabbix efter din patch till 4.2, 5.0?
MM: – Jag kan inte säga något om support. Om jag var Zabbix teknisk support skulle jag förmodligen säga nej, eftersom det här är någon annans kod. När det gäller 4.2-kodbasen är vår position: "Vi kommer att röra oss med tiden och vi kommer att uppdatera oss själva om nästa version." Därför kommer vi under en tid att publicera en patch för uppdaterade versioner. Jag sa redan i rapporten: antalet ändringar med versioner är fortfarande ganska litet. Jag tror att övergången från 3.4 till 4 tog oss cirka 15 minuter. Något förändrades där, men inte särskilt viktigt.
A: – Så du planerar att stödja din patch och du kan säkert installera den i produktionen och få uppdateringar på något sätt i framtiden?
MM: – Vi rekommenderar det starkt. Detta löser många problem för oss.
MCH: – Jag vill återigen uppmärksamma det faktum att de förändringar som inte berör arkitekturen och inte berör blockering eller köer är modulära, de är i separata moduler. Även med mindre ändringar kan du underhålla dem ganska enkelt.
MM: – Om du är intresserad av detaljerna använder "Clickhouse" det så kallade historiebiblioteket. Det är obundet - det är en kopia av Elastics-stödet, det vill säga det är konfigurerbart. Omröstning ändrar bara pollare. Vi tror att detta kommer att fungera under lång tid.
A: - Tack så mycket. Säg mig, finns det någon dokumentation av de ändringar som gjorts?
MM: – Dokumentation är en patch. Uppenbarligen, med införandet av Clickhouse, med införandet av nya typer av pollers, uppstår nya konfigurationsalternativ. Länken från den sista bilden har en kort beskrivning av hur man använder den.
Om att ersätta fping med nmap
A: – Hur genomförde du det här till slut? Kan du ge specifika exempel: har du strappers och ett externt manus? Vad slutar med att kontrollera ett så stort antal värdar så snabbt? Hur bryter du dessa värdar? Behöver vi mata dem för att kartlägga på något sätt, hämta dem någonstans ifrån, sätta in dem, köra något?
MM: - Häftigt. En mycket korrekt fråga! Poängen är detta. Vi modifierade biblioteket (ICMP-ping, en del av Zabbix) för ICMP-kontroller, som indikerar antalet paket - ett (1), och koden försöker använda nmap. Det vill säga, detta är Zabbix' interna arbete, som har blivit pingarens interna arbete. Följaktligen krävs ingen synkronisering eller användning av en fällare. Detta gjordes medvetet för att lämna systemet intakt och inte behöva ta itu med synkroniseringen av två databassystem: vad ska man kontrollera, ladda upp via pollern och är vår uppladdning trasig?.. Detta är mycket enklare.
A: – Fungerar det för proxyservrar också?
MM: – Ja, men vi kollade inte. Pollingkoden är densamma i både Zabbix och servern. Borde fungera. Låt mig återigen betona: systemets prestanda är sådan att vi inte behöver en proxy.
MCH: – Det korrekta svaret på frågan är: "Varför behöver du en proxy med ett sådant system?" Bara på grund av NAT eller övervakning genom någon sorts långsam kanal...
A: – Och du använder Zabbix som allertor, om jag förstår det rätt. Eller har din grafik (där arkivlagret finns) flyttats till ett annat system, som Grafana? Eller använder du inte den här funktionen?
MM: – Jag kommer ännu en gång att betona: vi har uppnått fullständig integration. Vi häller historia i Clickhouse, men samtidigt har vi ändrat php-gränssnittet. Php-gränssnittet går till Clickhouse och gör all grafik därifrån. Samtidigt har vi, om jag ska vara ärlig, en del som bygger data i andra grafiska displaysystem från samma Clickhouse, från samma Zabbix-data.
MCH: – I ”Grafan” också.
Hur togs besluten om fördelningen av resurser?
A: – Dela lite av ditt inre kök. Hur togs beslutet att det var nödvändigt att avsätta resurser för seriös bearbetning av produkten? Dessa är i allmänhet vissa risker. Och snälla berätta för mig, i samband med det faktum att du kommer att stödja nya versioner: hur motiverar detta beslut ur förvaltningssynpunkt?
MM: – Tydligen berättade vi inte historiens drama så bra. Vi befann oss i en situation där något måste göras, och vi gick i huvudsak med två parallella team:
- Det ena var att lansera ett övervakningssystem med nya metoder: övervakning som en tjänst, en standarduppsättning med öppen källkodslösningar som vi kombinerar och sedan försöker förändra affärsprocessen för att kunna arbeta med det nya övervakningssystemet.
- Samtidigt hade vi en entusiastisk programmerare som höll på med detta (om sig själv). Det blev så att han vann.
A: – Och hur stor är laget?
MCH: - Hon är framför dig.
A: – Så, som alltid, behöver du en passionerad?
MM: – Jag vet inte vad en passionerad är.
A: - I det här fallet, tydligen, du. Tack så mycket, du är fantastisk.
MM: - Tack.
Om patchar för Zabbix
A: – För ett system som använder proxyservrar (till exempel i vissa distribuerade system), är det möjligt att anpassa och lappa till exempel pollers, proxyservrar och delvis själva förprocessorn för Zabbix; och deras interaktion? Är det möjligt att optimera befintliga utvecklingar för ett system med flera proxyservrar?
MM: – Jag vet att Zabbix-servern är sammansatt med en proxy (koden kompileras och erhålls). Vi har inte testat detta i produktionen. Jag är inte säker på detta, men jag tror att förprocessorhanteraren inte används i proxyn. Uppgiften för proxyn är att ta en uppsättning mätvärden från Zabbix, slå samman dem (den registrerar också konfigurationen, den lokala databasen) och ge tillbaka den till Zabbix-servern. Servern själv kommer sedan att göra förbearbetningen när den tar emot den.
Intresset för fullmakter är förståeligt. Vi ska kolla upp det. Det här är ett intressant ämne.
A: – Tanken var denna: om du kan patcha pollers kan du patcha dem på proxyn och patcha interaktionen med servern, och anpassa förprocessorn för dessa ändamål endast på servern.
MM: – Jag tror att det är ännu enklare. Du tar koden, applicerar en patch och konfigurerar den sedan som du behöver – samla in proxyservrar (till exempel med ODBC) och distribuera den patchade koden över system. Vid behov - samla in en proxy, vid behov - en server.
A: – Troligtvis behöver du inte patcha proxyöverföringen till servern ytterligare?
MCH: – Nej, det är standard.
MM: – Faktum är att en av idéerna inte lät. Vi har alltid upprätthållit en balans mellan explosionen av idéer och mängden förändringar och enkel support.
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com