Den nÊste HighLoad++ konference finder sted den 6. og 7. april 2020 i Sankt Petersborg. Detaljer og billetter . HighLoad++ Moskva 2018. Sal "Moskva". 9. november, 15:00. Resumé og .
* OvervĂ„gning â online og analyse.
* PrimĂŠre begrĂŠnsninger ved ZABBIX platformen.
* LĂžsning til skalerbar analyseopbevaring.
* Optimering af ZABBIX serveren.
* Optimering af UI.
* Erfaring med systemdrift med belastninger over 40k NVPS.
* Kort konklusion.
Mikhail Makurov (herefter â MM): â Hej alle sammen!
Maksim Chernetsov (herefter â MCh): â Goddag!
MM: â Tillad mig at prĂŠsentere Maksim. Maks â en talentfuld ingeniĂžr, den bedste netvĂŠrksekspert, jeg kender. Maksim arbejder med netvĂŠrk og services, deres udvikling og drift.
MCh: â Og jeg vil gerne fortĂŠlle om Mikhail. Mikhail â en udvikler i C. Han har skrevet flere hĂžjtydende lĂžsninger til trafikbehandling for vores virksomhed. Vi lever og arbejder i Ural, i byen med de hĂ„rde mĂŠnd, Tjeljabinsk, i firmaet "Intersvyaz". Vores firma er en udbyder af internet- og kabel-tv-services til en million mennesker i 16 byer.
MM: â Og det skal siges, at "Intersvyaz" er meget mere end bare en udbyder, det er et IT-firma. StĂžrstedelen af vores lĂžsninger er udviklet af vores IT-afdeling.
A: fra servere, der behandler trafik, til callcenter og mobilapplikation. IT-afdelingen har nu cirka 80 medarbejdere med meget forskellige kompetencer.
Om Zabbix og dets arkitektur
MCh: â Og nu vil jeg forsĂžge at sĂŠtte personlig rekord og pĂ„ et minut fortĂŠlle, hvad Zabbix (herefter â "Zabbix") er.
"Zabbix" positionerer sig som et enterprise overvĂ„gningssystem "out of the box". Det har mange funktioner, der gĂžr livet lettere: avancerede eskalationsregler, API til integration, gruppering og automatisk opdagelse af vĂŠrter og metrikker. I "Zabbix" er der sĂ„kaldte skaleringsvĂŠrktĂžjer â proxyer. "Zabbix" er et open source system.
Kort om arkitekturen. Man kan sige, at den bestÄr af tre komponenter:
- Server. Skrevet i C. Med rimeligt kompleks behandling og overfÞrsel af information mellem trÄde. Al behandling sker her: fra modtagelse til lagring i database.
- Alle data opbevares i databasen. "Zabbix" understĂžtter MySQL, PostgreSQL og Oracle.
- WebgrĂŠnsefladen er skrevet i PHP. Den leveres som regel med Apache-serveren, men fungerer mere effektivt i kombination med nginx + php.
I dag vil vi gerne fortĂŠlle en historie fra vores virksomhed, der handler om 'Zabbix'âŠ
En historie fra virksomheden 'Intersvyaz'. Hvad har vi, og hvad har vi brug for?
For 5 eller 6 mĂ„neder siden. En dag efter arbejdeâŠ
MCh: â Misha, hej! Glad for at jeg fik fat i dig â jeg har noget at tale om. Vi har igen haft problemer med overvĂ„gningen. Under en stor nedetid gik alt i stĂ„, og der var ingen information om netvĂŠrkets tilstand. DesvĂŠrre sker det ikke for fĂžrste gang. Jeg har brug for din hjĂŠlp. Lad os sĂžrge for, at vores overvĂ„gning fungerer under alle omstĂŠndigheder!
MM: â Men lad os fĂžrst synkronisere os. Jeg har ikke kigget derovre i et par Ă„r. Hvis jeg husker korrekt, sĂ„ skiftede vi fra Nagios til 'Zabbix' for omkring 8 Ă„r siden. Og nu har vi, virker det som om, 6 kraftige servere og omkring et dusin proxies. Jeg blander ikke noget sammen?
MCh: â NĂŠsten. 15 servere, hvoraf nogle er virtuelle maskiner. Det vigtigste er, at det ikke redder os i det Ăžjeblik, hvor vi har brug for det mest. Hver gang der er en nedetid, hĂŠnger serverne, og vi ser ingenting. Vi har forsĂžgt at optimere konfigurationen, men det giver ikke et optimalt lĂžft i ydeevnen.
MM: â ForstĂ„eligt. Har I allerede kigget pĂ„ noget, eller har I fundet noget i diagnostikken?
MCh: â Det fĂžrste, vi skal tage fat pĂ„, er faktisk databasen. MySQL er konstant belasted med at gemme nye mĂ„linger, og nĂ„r 'Zabbix' begynder at generere en masse hĂŠndelser, gĂ„r databasen bogstaveligt talt i stĂ„ i flere timer. Jeg har allerede fortalt dig om optimeringen af konfigurationen, men vi opdaterede faktisk hardwaren i Ă„r: serverne har over hundrede gigabyte RAM, og der er SSD RAID-array pĂ„ disken â der er ikke nogen mening i at vokse det lineĂŠrt. Hvad skal vi gĂžre?
MM: â ForstĂ„eligt. Generelt set er MySQL en LTP-database. Det ser ud til, at den ikke lĂŠngere egner sig til at gemme arkivet af mĂ„linger i vores stĂžrrelse. Lad os finde ud af det.
MCh: â Lad os gĂžre det!
Integration af Zabbix og Clickhouse som resultat af hackathonen
Efter noget tid fik vi interessante data:
StÞrstedelen af pladsen i vores database var optaget af metrics-arkivet, og mindre end 1 % blev brugt til konfiguration, skabeloner og indstillinger. PÄ det tidspunkt havde vi allerede anvendt en Big Data-lÞsning baseret pÄ Clickhouse i over et Är. Retningen for os var klar. PÄ vores forÄr 'Hackathon' skrev jeg en integration mellem Zabbix og Clickhouse for serveren og frontend. PÄ det tidspunkt havde Zabbix allerede stÞtte til ElasticSearch, og vi besluttede at sammenligne dem.
Sammenligning af Clickhouse og Elasticsearch
MM: â Til sammenligningen genererede vi en belastning svarende til den, som Zabbix-serveren skaber, og sĂ„ pĂ„, hvordan systemerne ville klare sig. Vi skrev data i mellem 1000 rĂŠkker pr. gang og brugte CURL. Vi formodede pĂ„ forhĂ„nd, at Clickhouse ville vĂŠre mere effektiv til den belastningsprofil, som Zabbix skaber. Resultaterne overraskede os endda:
Under ens betingelser skrev Clickhouse tre gange sÄ mange data under testen. Begge systemer brugte meget fÄ ressourcer til at lÊse data. Men ElasticSearch krÊvede betydeligt flere CPU-ressourcer ved skrivning:
Generelt overgik Clickhouse ElasticSearch betydeligt bÄde i CPU-forbrug og hastighed. Desuden bruger Clickhouse 11 gange mindre plads pÄ harddisken takket vÊre datakompression og udfÞrer omtrent 30 gange fÊrre diskoperationer:
MCh: â Ja, arbejdet med disksystemet i Clickhouse er meget effektivt. Store SATA-diske kan bruges til databaser og opnĂ„ skrivehastigheder pĂ„ hundredtusinder af rĂŠkker pr. sekund. Systemet understĂžtter 'out of the box' sharding, replikering og er meget nemt at konfigurere. Vi er mere end tilfredse med driften i et Ă„r.
For at optimere ressourcerne kan Clickhouse installeres ved siden af den eksisterende hoveddatabase, hvilket sparer meget CPU-tid og diskoperationer. Vi har flyttet metrics-arkivet til allerede eksisterende Clickhouse-klynger:
Vi har lettet den primÊre MySQL-database sÄ meget, at vi kunne kombinere den pÄ én maskine med Zabbix-serveren og undgÄ at have en dedikeret server til MySQL.
Hvordan fungerer polling i Zabbix?
4 mÄneder siden
MM: â NĂ„, kan vi glemme problemerne med databasen?
MCh: â Det er helt rigtigt! En anden opgave, vi skal lĂžse, er langsom datainsamling. Nu er alle vores 15 proxy-servere overbelastede med SNMP-processer og polling. Vi har ikke andet valg end at anskaffe nye servere igen og igen.
MM: â Fantastisk. Men fortĂŠl mig fĂžrst, hvordan polling fungerer i 'Zabbix'?
MCh: â Kort sagt er der 20 typer metric og ti mĂ„der at indsamle dem pĂ„. 'Zabbix' kan samle data enten i 'request â response' tilstand, eller vente pĂ„ nye data via 'Trapper Interface'.
Det er vĂŠrd at bemĂŠrke, at denne metode (Trapper) i den originale 'Zabbix' er den hurtigste.
Der findes proxy-servere til belastningsfordeling:
Proxy kan udfÞre de samme indsamlingfunktioner som 'Zabbix'-serveren ved at modtage opgaver fra den og sende de indsamlede metrics via Trapper-interfacet. Dette er den officielt anbefalede metode til at fordele belastningen. Proxy'er er ogsÄ nyttige til at overvÄge fjerna infrastrukturen, der arbejder gennem NAT eller en langsom forbindelse:
MM: â Arkitekturen er forstĂ„et. Vi skal kigge pĂ„ kildekodenâŠ
Et par dage senere
Sagnet om, hvordan nmap fping besejrede
MM: â Det ser ud til, at jeg har fundet noget.
MCh: â FortĂŠl!
MM: â Jeg har opdaget, at 'Zabbix' ved tilgĂŠngelighedskontroller kun tjekker maksimalt 128 vĂŠrter samtidigt. Jeg prĂžvede at Ăžge dette tal til 500 og fjernede inter-pakke intervallet i deres ping â det fordoblede hastigheden. Men jeg vil gerne have stĂžrre tal.
MCh: â I mit arbejde mĂ„ jeg nogle gange kontrollere tilgĂŠngeligheden af tusinder af vĂŠrter, og jeg har ikke set noget hurtigere end nmap til dette. Jeg er sikker pĂ„, at det er den hurtigste metode. Lad os prĂžve det! Vi skal markant Ăžge antallet af vĂŠrter ad gangen.
MM: â Tjekke mere end fem hundrede? 600?
MCh: â Minimum et par tusinde.
MM: â Okay. Det vigtigste, jeg gerne vil sige: jeg fandt ud af, at det meste af polling i 'Zabbix' bliver udfĂžrt synkront. Vi skal helt sikkert ĂŠndre det til asynkront. SĂ„ kan vi dramatisk Ăžge antallet af metrics, der indsamles af pollere, isĂŠr hvis vi Ăžger antallet af metrics per iteration.
MCh: â Det lyder godt! Og hvornĂ„r?
MM: â Som sĂŠdvanligt, i gĂ„r.
MCh: â Vi sammenlignede begge versioner af fping og nmap:
PÄ et stort antal vÊrter var nmap forventeligt op til fem gange mere effektivt. Da nmap kun tjekker for tilgÊngelighed og svartid, har vi flyttet tabstÊlling til triggere og betydeligt forkortet intervallerne for tilgÊngelighedstjek. Det optimale antal vÊrter til nmap, fandt vi, lÄ omkring 4000 pr. iteration. Nmap har gjort det muligt for os at reducere CPU-omkostningerne til tilgÊngelighedstjek med tre gange og forkorte intervallet fra 120 sekunder til 10.
Optimering af polling
MM: â Derefter tog vi fat pĂ„ pollere. Vi var isĂŠr interesserede i SNMP-aflĂŠsninger og agenter. I "Zabbix" er polling lavet synkront, og der er truffet sĂŠrlige foranstaltninger for at Ăžge systemets effektivitet. I det synkrone regime forĂ„rsager utilgĂŠngelighed af vĂŠrter betydelig nedgradering af polling. Der findes et helt system af tilstande og specielle processer â sĂ„kaldte unreachable-pollere, som kun arbejder med utilgĂŠngelige vĂŠrter:
Dette er en kommentar, der demonstrerer tilstandsmatrixen, hele kompleksiteten af de overgange, der krĂŠves for at systemet kan forblive effektivt. Derudover er selve den synkrone polling ret langsom:
Netop derfor kunne tusinder af pollertrÄde pÄ et dusin proxies ikke samle det nÞdvendige antal data til os. Den asynkrone implementering lÞste ikke kun problemerne med antallet af trÄde, men forenklede ogsÄ betydeligt systemet for tilstande af utilgÊngelige vÊrter, fordi uanset hvor mange der blev tjekket i én polling-iteration, var den maksimale ventetid 1 timeout:
Derudover modificerede og forbedrede vi polling-systemet for SNMP-forespÞrgsler. Problemet er, at de fleste ikke kan svare pÄ flere SNMP-forespÞrgsler samtidigt. Derfor lavede vi en hybridtilstand, hvor SNMP-polling af den samme vÊrt udfÞres asynkront:
Dette gĂžres for en hel bunke vĂŠrter. Denne tilstand er i sidste ende ikke langsommere end den helt asynkrone, da forespĂžrgslen af 150 SNMP-vĂŠrdier stadig er meget hurtigere end 1 timeout.
Vores eksperimenter viste, at det optimale antal forespĂžrgsler pr. iteration er omkring 8000 ved SNMP-polling. Samlet set har overgangen til den asynkrone tilstand gjort det muligt at fremskynde pollingens ydeevne med 200 gange, i flere hundrede gange.
MCh: â De optimeringer af polling har vist, at vi ikke kun kan slippe af med alle proxies, men ogsĂ„ forkorte intervallerne for mange kontroller, sĂ„ proxies ikke lĂŠngere er nĂždvendige som en metode til belastningsfordeling.
For cirka tre mÄneder siden
Ăndr arkitekturen â Ăžg belastningen!
MM: â NĂ„, Max, er det tid til produktion? Jeg har brug for en kraftfuld server og en god ingeniĂžr.
MCh: â Godt, lad os planlĂŠgge det. Det er pĂ„ hĂžje tid at komme videre fra de 5.000 metrics i sekundet.
Morgen efter opgraderingen
MCh: â Misha, vi er blevet opgraderet, men til morgen er vi tilbage igen⊠GĂŠt hvilken hastighed vi nĂ„ede?
MM: â Maksimalt 20.000.
MCh: â Aha, 25! DesvĂŠrre er vi der, hvor vi startede.
MM: â Hvad er der galt? Har I foretaget nogen diagnose?
MCh: â Ja, selvfĂžlgelig! Her, for eksempel, et interessant top:
MM: â Lad os tage et kig. Jeg kan se, at vi har forsĂžgt med en enorm mĂŠngde polling-trĂ„de:
Men samtidig kunne vi ikke engang udnytte systemet halvt:
Og den samlede ydeevne er ret lav, omkring 4.000 metrics i sekundet:
Er der noget andet?
MCh: â Ja, strace fra en af pollerne:
MM: â Her kan man tydeligt se, at polling-processen venter pĂ„ 'semaforer'. Det er lĂ„sninger:
MCh: â UforstĂ„eligt.
MM: â Se, det ligner en situation, hvor en masse trĂ„de forsĂžger at arbejde med en ressource, som kun Ă©n kan arbejde med ad gangen. SĂ„ alt, hvad de kan gĂžre, er at dele denne ressource over tid:
Og den samlede ydeevne ved arbejde med en sÄdan ressource er begrÊnset af hastigheden pÄ én kerne:
SÄdan et problem kan lÞses pÄ to mÄder.
Opgradere maskinens hardware, skifte til hurtigere kerner:
Eller ĂŠndre arkitekturen og samtidig â belastningen:
MCh: â For Ăžvrigt, pĂ„ den testmaskine bruger vi fĂŠrre kerner end pĂ„ den produktionsmaskine, men de er 1,5 gange hurtigere i frekvens pr. kerne!
MM: â ForstĂ„et? Vi mĂ„ se pĂ„ serverkoden.
Dataflowet i Zabbix-serveren
MCh: â For at finde ud af det, begyndte vi at analysere, hvordan data overfĂžres inden i 'Zabbix'-serveren:
En flot illustration, ikke? Lad os se pÄ den trin for trin for at gÞre det mere klart. Der er trÄde og tjenester, der er ansvarlige for indsamling af data:
De indsamlede metrics sendes via en socket til Preprocessor manager, hvor de gemmes i en kĂž:
Preprocessor manageren sender dataene til sine arbejdere, som udfĂžrer forbehandlingsinstruktionerne og sender dem tilbage gennem den samme socket:
Efter dette gemmer forbehandlingschefen dem i historikens cache:
Derfra hentes de af historik-synkere, der udfÞrer en hel del funktioner: for eksempel trigonometrisk beregning, udfyldning af cachevÊrdier og, vigtigst af alt, lagring af mÄlinger i historiklagringen. Generelt er processen kompleks og ret forvirrende.
MM: â Det fĂžrste, vi sĂ„, var, at de fleste trĂ„de konkurrerede om den sĂ„kaldte "konfigurationscache" (et hukommelsesomrĂ„de, hvor alle serverkonfigurationer opbevares). IsĂŠr mange lĂ„sninger stammer fra trĂ„de, der er ansvarlige for at hente data:
âŠda konfigurationen ikke kun indeholder mĂ„linger med deres parametre, men ogsĂ„ kĂžer, hvorfra pollere henter information om, hvad de skal gĂžre nĂŠste gang. NĂ„r der er mange pollere, og en lĂ„ser konfigurationen, venter de andre pĂ„ anmodninger:
Pollere mÄ ikke konflikte
SÄ det fÞrste, vi gjorde, var at opdele kÞen i 4 dele og tillade pollerne at lÄse disse kÞer, disse dele samtidigt under sikre forhold:
Dette fjernede konkurrencen om konfigurationscachen, og pollernes hastighed steg betydeligt. Men derefter stÞdte vi pÄ, at forbehandlingschefen begyndte at opbygge en pulje af opgaver:
Forbehandlingschefen skal kunne prioritere
Dette skete i tilfĂŠlde, hvor han manglede ydeevne. SĂ„ alt, hvad han kunne gĂžre, var at samle anmodninger fra dataindsamlingsprocesserne og lĂŠgge dem i en buffer indtil han fyldte al hukommelsen og gik ned:
For at lĂžse dette problem tilfĂžjede vi en anden sokkel, der var dedikeret specifikt til arbejderne:
Dermed fik forbehandlingschefen mulighed for at prioritere sit arbejde, og i tilfĂŠlde af at bufferen voksede, ville opgaven bremse indsamlingen og give arbejderne mulighed for at tage bufferen:
Derefter opdagede vi, at en af Ă„rsagerne til bremserne var selve arbejderne, da de konkurrerede om en ressource, der ikke var vigtig for deres arbejde. Dette problem blev lĂžst med en bug-fix, og i de nye versioner af "Zabbix" er det allerede afhjulpet:
Vi Ăžger antallet af sokler â vi fĂ„r resultater
DernÊst blev selve forbehandlingschefen et snÊvert punkt, da det er en enkelt trÄd. Den ramte hastigheden af kernen, hvilket gav en maksimal hastighed pÄ cirka 70.000 mÄlinger pr. sekund:
Derfor har vi lavet fire, med fire sĂŠt af stik, arbejdere:
Og det har gjort det muligt at Ăžge hastigheden til cirka 130.000 metrikker:
Den ikke-lineÊre vÊkst skyldes, at der er kommet konkurrence om cache-historikken. Fire prÊprocessormanager og history-synkere konkurrerede om det. PÄ det tidspunkt opnÄede vi omkring 130.000 metrikker pr. sekund pÄ testmaskinen, og udnyttede den cirka 95 % pÄ CPU'en:
For omkring 2,5 mÄneder siden
Afskaffelse af snmp-community Ăžgede NVP'erne med halvanden gang
MM: â Max, jeg har brug for en ny testmaskine! Vi passer ikke lĂŠngere ind i den nuvĂŠrende.
MCh: â Hvad har vi nu?
MM: â Lige nu â 130k NVP'er og CPU'en "i stedet".
MCh: â Wow! Fantastisk! Vent, jeg har to spĂžrgsmĂ„l. IfĂžlge mine beregninger har vi brug for omkring 15-20.000 metrikker pr. sekund. Hvorfor har vi brug for mere?
MM: â Jeg vil gerne gĂžre arbejdet helt fĂŠrdigt. Jeg vil gerne se, hvor meget vi kan presse ud af dette system.
MCh: â MenâŠ
MM: â Men det er ubrugeligt for forretningen.
MCh: â ForstĂ„et. Og det andet spĂžrgsmĂ„l: kan vi selv vedligeholde det, vi har nu, uden hjĂŠlp fra udvikleren?
MM: â Jeg tror ikke det. Ăndring af arbejdet med konfigurationscachen er et problem. Det involverer ĂŠndringer i de fleste strĂžmme og er ret komplekst at vedligeholde. Det vil sandsynligvis vĂŠre meget svĂŠrt at vedligeholde.
MCh: â SĂ„ skal vi find en alternativ lĂžsning.
MM: â Der er en mulighed. Vi kan skifte til hurtige kerner, samtidig med at vi opgiver det nye lĂ„sesystem. Vi vil stadig opnĂ„ en ydeevne pĂ„ 60-80.000 metrikker. Samtidig kan vi bevare al anden kode. 'ClickHouse', asynkron polling vil fungere. Og det vil vĂŠre nemt at vedligeholde.
MCh: â Fantastisk! Jeg foreslĂ„r, at vi stopper her.
Efter optimeringen af serverdelen kunne vi endelig lancerer den nye kode i produktion. Vi opgav nogle Êndringer til fordel for overgangen til en maskine med hurtige kerner og minimalisering af antallet af Êndringer i koden. Vi forenklede ogsÄ konfigurationen og opgav makroer i datakomponenterne, nÄr det var muligt, da de er kilden til yderligere blokeringer.
For eksempel har afskaffelsen af den makro, der ofte findes i dokumentationen og eksemplerne, snmp-community, i vores tilfĂŠlde tilladt yderligere at accelerere NVP'erne med cirka 1,5 gang.
Efter to dage i produktion
Vi fjerner pop op-vinduerne for hĂŠndelseshistorik
MCh: â Misha, vi har brugt systemet i to dage, og det fungerer. Men kun nĂ„r det fungerer! Vi havde planlagt vedligeholdelse med flytning af et ret stort netvĂŠrkssegment, og vi kontrollerede manuelt, hvad der var oppe, og hvad der ikke var.
MM: â Det kan ikke vĂŠre muligt! Vi har tjekket det 10 gange. Serveren hĂ„ndterer selv en komplet netvĂŠrksnedbrud Ăžjeblikkeligt.
MCh: â Jeg forstĂ„r det hele: server, database, top, austat, logs â alt gĂ„r hurtigt⊠Men vi kigger pĂ„ webgrĂŠnsefladen, og der er CPU'en "i hvile" pĂ„ serveren, og sĂ„ er der dette:
MM: â ForstĂ„et. Lad os kigge pĂ„ web'en. Vi opdagede, at i situationer med mange aktive hĂŠndelser, begyndte de fleste operativwidgetter at kĂžre meget langsomt:
Ă
rsagen var genereringen af pop-up vinduer med hĂŠndelseshistorik, der genereres for hvert element i listen. Derfor stoppede vi med at generere disse vinduer (vi kommenterede 5 linjer i koden), og det lĂžste vores problemer.
IndlÊsningstiden for widgetter selv ved komplet nedbrud reduceredes fra flere minutter til acceptable 10-15 sekunder for os, og historien kan stadig ses med et klik pÄ tiden:
Efter arbejdet. For 2 mÄneder siden
MCh: â Misha, gĂ„r du? Vi skal tale.
MM: â Jeg havde ikke tĂŠnkt mig det. Er der igen noget med "Zabbix"?
MCh: â Nej, slap af! Jeg ville bare sige: alt fungerer, tak! Ăl pĂ„ mig.
Zabbix er effektivt
"Zabbix" er et ret universelt og rigt system og funktion. Det kan sagtens bruges til smÄ installationer "out of the box", men med voksende behov skal det optimeres. Brug et passende lager til at opbevare et stort arkiv af mÄlinger:
- du kan bruge de indbyggede vĂŠrktĂžjer i form af integration med "Elasticsearch" eller eksportere historikken til tekstfiler (tilgĂŠngeligt fra fjerde version);
- du kan dra nytte af vores erfaring og integration med "ClickHouse".
For at radikalt Ăžge hastigheden af dataindsamling, saml dem med asynkrone metoder og overfĂžr dem via trapper-interface til "Zabbix"-serveren; eller du kan bruge en patch til asynkronitet for selve "Zabbix"'s pollere.
«Zabbix» er skrevet i C og er ret effektiv. Nogle lÞsninger pÄ smalle arkitektoniske steder gÞr det muligt at Þge dens ydeevne yderligere, og efter vores erfaring kan man fÄ mere end 100.000 metrikker pÄ en enkeltprocessor-maskine.
Den samme Zabbix-patch
MM: â Jeg vil gerne tilfĂžje et par punkter. Hele den nuvĂŠrende prĂŠsentation, alle testene, tallene er givet for den konfiguration, vi bruger. Fra den tager vi nu cirka 20.000 metrikker i sekundet. Hvis du forsĂžger at forstĂ„, om det vil fungere for dig â kan du sammenligne. Det, vi har prĂŠsenteret i dag, er tilgĂŠngeligt pĂ„ GitHub som en patch:
Patchen inkluderer:
- fuld integration med «ClickHouse» (bÄde Zabbix-servere og frontend);
- lĂžsning af problemer med prĂŠprocessor-manageren;
- asynkron polling.
Patchen er kompatibel med hele version 4, inklusive lts. Sandsynligvis vil den fungere med minimale Êndringer pÄ version 3.4.
Tak for opmĂŠrksomheden.
SpÞrgsmÄl
SpĂžrgsmĂ„l fra publikum (herefter â A): â Goddag! Kan I fortĂŠlle mig, om I har planer om intenst samarbejde med Zabbix-teamet eller de med jer, sĂ„ dette ikke vil vĂŠre en patch, men et normalt adfĂŠrd for «Zabbix»?
MM: â Ja, nogle ĂŠndringer vil vi helt sikkert commite. Nogle ting vil blive, som de er, i patchen.
A: â Tusind tak for en fremragende prĂŠsentation! Kan I fortĂŠlle mig, efter anvendelse af patchen, vil stĂžtten fra «Zabbix» forblive, og hvordan kan man derefter opgradere til hĂžjere versioner? Vil det vĂŠre muligt at opgradere «Zabbix» til 4.2, 5.0 efter jeres patch?
MM: â Om support kan jeg ikke sige. Hvis jeg var support for «Zabbix», ville jeg sandsynligvis sige nej, fordi det er anden parts kode. Hvad angĂ„r kodebasen 4.2, er vores position sĂ„dan: «Vi vil fĂžlge med tiden og selv opgradere til den nĂŠste version». Derfor vil vi i et stykke tid udgive patchen til de opdaterede versioner. Jeg sagde allerede i prĂŠsentationen: Antallet af ĂŠndringer mellem versionerne er indtil videre ret lille. Jeg tror, at overgangen fra 3.4 til 4 tog os cirka 15 minutter. Der ĂŠndrede sig lidt, men ikke noget vigtigt.
A: â SĂ„ I planlĂŠgger at stĂžtte jeres patch, og man kan trygt installere det i produktionen, og senere fĂ„ opdateringer pĂ„ en eller anden mĂ„de?
MM: â Vi anbefaler det kraftigt. Det lĂžser mange problemer for os.
MCh: â Jeg vil endnu engang understrege, at ĂŠndringer, der ikke vedrĂžrer arkitekturen og ikke involverer blokeringer eller kĂžer, de er modulerede, de er i separate moduler. Selv ved mindre ĂŠndringer kan de holdes ret nemt.
MM: â Hvis du er interesseret i detaljerne, sĂ„ bruger «Klikhaus» det sĂ„kaldte historiebibliotek. Det er adskilt â det er en kopi af «Elastix»'s stĂžtte, det vil sige, det kan konfigureres. Polling ĂŠndrer kun pollere. Vi mener, at det vil fungere i lang tid.
A: â Mange tak. Kan du fortĂŠlle, om der findes nogen dokumentation for de foretagne ĂŠndringer?
MM: â Dokumentationen er et patch. Det er Ă„benlyst, at med introduktionen af «Klikhaus», med indfĂžrelsen af nye typer pollere, opstĂ„r der nye konfigurationsmuligheder. Der er et kort beskrivelser i linket fra den sidste slide, om hvordan man bruger dette.
Om udskiftning af fping med nmap
A: â Hvordan har I i sidste ende implementeret dette? Kan du give konkrete eksempler: bruger I strappere og et eksternt script? Hvad kontrollerer sĂ„ hurtigt et sĂ„ stort antal vĂŠrter? Hvordan fĂ„r I de vĂŠrter? Skal man pĂ„ en eller anden mĂ„de fodre nmap med dem, fĂ„ dem fra et sted, lĂŠgge dem ind, starte noget op?..
MM: â Fedt. Meget relevant spĂžrgsmĂ„l! Essensen er denne. Vi har modificeret biblioteket (ICMP ping, en del af «Zabbix») til ICMP-tjek, hvor antallet af pakker er Ă©n (1), og koden forsĂžger at bruge nmap. SĂ„ det er Zabbix' interne arbejde, det er blevet til pingers interne arbejde. Derfor krĂŠves der ingen synkronisering eller brug af en trapper. Dette blev gjort bevidst for at bevareystemet intakt og undgĂ„ at synkronisere to systemer, som skal kontrolleres, uploads via polleren, og om vores upload er brudt?.. Det er meget enklere.
A: â GĂŠlder dette ogsĂ„ for proxy?
MM: â Ja, men vi har ikke testet det. Koden til polling er den samme i bĂ„de Zabbix og serveren. Det burde fungere. Jeg vil endnu en gang understrege: systemets ydeevne er sĂ„dan, at vi ikke har brug for en proxy.
MCh: â Det rigtige svar pĂ„ spĂžrgsmĂ„let er: «Hvorfor har I brug for en proxy med et sĂ„dant system?» Kun pĂ„ grund af NAT eller for at overvĂ„ge gennem en langsom kanalâŠ
A: â Og bruger I «Zabbix» som alerter, hvis jeg har forstĂ„et det korrekt? Eller er grafikkerne (hvor det arkiverede lag er) flyttet til et andet system, som Grafana? Eller bruger I ikke denne funktion?
MM: â Jeg vil endnu en gang understrege: vi har gennemfĂžrt fuld integration. Vi sender historikken til âClickhouseâ, men har samtidig ĂŠndret PHP-frontenden. PHP-frontenden henter data fra âClickhouseâ og laver alle grafer derfra. Ărligt talt har vi ogsĂ„ en del, der bygger data i andre grafiske systemer baseret pĂ„ de samme data fra âZabbixâ.
MCh: â Inkluderet i âGrafanaâ.
Hvordan blev beslutningen om tildeling af ressourcer truffet?
A: â Del lidt af den interne proces. Hvordan blev beslutningen om at tildele ressourcer til en seriĂžs omarbejdning af produktet truffet? Det indebĂŠrer jo visse risici. Og fortĂŠl mig venligst i forhold til at I planlĂŠgger at stĂžtte nye versioner: hvordan retfĂŠrdiggĂžres denne beslutning i forhold til ledelsen?
MM: â Tilsyneladende har vi ikke fortalt dramaet i historien sĂŠrlig godt. Vi befandt os i en situation, hvor der skulle gĂžres noget, og vi gik i praksis med to parallelle teams:
- Det ene arbejdede pÄ at lancere et overvÄgningssystem med nye metoder: overvÄgning som en service, et standard sÊt af open source-lÞsninger, som vi kombinerer og derefter forsÞger at Êndre forretningsprocesserne for at arbejde med det nye overvÄgningssystem.
- Samtidig havde vi en entusiastisk programmĂžr, der beskĂŠftigede sig med det (om sig selv). Det viste sig, at han vandt.
A: â Og hvad er teamets stĂžrrelse?
MCh: â De stĂ„r foran jer.
A: â SĂ„ som altid er der brug for en passioneret leder?
MM: â Jeg ved ikke, hvad en passioneret leder er.
A: â I det tilfĂŠlde, ser det ud til, at det er dig. Mange tak, I er fantastiske.
MM: â Tak.
Om patches til Zabbix
A: â For et system, der bruger proxy (for eksempel i nogle distribuerede systemer), er det muligt at tilpasse og patch dine lĂžsninger, lad os sige, pullere, proxy og delvist prĂŠprocessor for selve âZabbixâ; og deres interaktion? Er det muligt at optimere de eksisterende lĂžsninger til et system med flere proxyer?
MM: â Jeg ved, at âZabbixâ-serveren bygges med hjĂŠlp fra proxy (kompileres og koden genereres). Vi har ikke testet dette i produktion. Jeg er ikke sikker pĂ„ det, men efter min mening bruges prĂŠprocessor-manager ikke i proxy. Proxyens opgave er at tage et sĂŠt metric fra âZabbixâ, indsamle dem (den registrerer ogsĂ„ konfigurationen, den lokale database) og sende dem tilbage til âZabbixâ-serveren. PrĂŠprocesseringen vil blive udfĂžrt af serveren selv, nĂ„r den modtager dataene.
Interessen for proxy er forstÄelig. Vi vil undersÞge det. Det er et interessant emne.
A: â Ideen var, at hvis man kan patche pollere, kan man patche dem til proxy og tilpasse interaktionen med serveren, og preprocessoren kun tilpasse disse formĂ„l pĂ„ serveren.
MM: â Jeg tror, det er faktisk enklere. Du tager koden, anvender patchen, konfigurerer som du Ăžnsker â samler proxy-servere (for eksempel med ODBC) og distribuerer den patcherede kode til systemerne. Hvor det er nĂždvendigt, samler du proxy, hvor det er nĂždvendigt, server.
A: â Skal man ikke ogsĂ„ patch overfĂžrslen af proxy til serveren, sandsynligvis?
MCh: â Nej, det er standard.
MM: â Faktisk lĂžd det ikke som en af idĂ©erne. Vi har altid strĂŠbt efter at opretholde en balance mellem ideernes eksplosion og antallet af ĂŠndringer, nemhedsgraden ved vedligeholdelse.
Lidt reklame đ
Tak fordi du bliver hos os. Kan du lide vores artikler? Ănsker du at se flere interessante materialer? StĂžt os ved at bestille eller anbefale os til dine bekendte, , en unik analog til entry-level servere, som vi har designet til dig: (tilgĂŠngelige muligheder med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd til halv pris i datacenteret Equinix Tier IV i Amsterdam? Kun hos os i Holland! Dell R420 - 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra 99 $! LĂŠs om hvordan
Kilde: habr.com
