Den neste HighLoad++-konferansen holdes 6. og 7. april 2020 i St. Petersburg. Detaljer og billetter . HighLoad++ Moskva 2018. Hall “Moskva”. 9. november, 15:00. Avhandlinger og .
* Overvåking - online og analyser.
* Grunnleggende begrensninger for ZABBIX-plattformen.
* Løsning for skalering av analyselagring.
* Optimalisering av ZABBIX-serveren.
* UI-optimalisering.
* Opplev å bruke systemet under belastninger på mer enn 40k NVPS.
* Korte konklusjoner.
Mikhail Makurov (heretter – MM): - Hei alle sammen!
Maxim Chernetsov (heretter – MCH): - God ettermiddag!
MM: – La meg introdusere Maxim. Max er en talentfull ingeniør, den beste nettverksmannen jeg vet om. Maxim er involvert i nettverk og tjenester, deres utvikling og drift.
MCH: – Og jeg vil gjerne fortelle deg om Mikhail. Mikhail er en C-utvikler. Han skrev flere høybelastningsløsninger for trafikkbehandling for selskapet vårt. Vi bor og jobber i Ural, i byen til tøffe menn Chelyabinsk, i selskapet Intersvyaz. Vårt firma er en leverandør av Internett- og kabel-tv-tjenester for en million mennesker i 16 byer.
MM: – Og det er verdt å si at Intersvyaz er mye mer enn bare en leverandør, det er et IT-selskap. De fleste av våre løsninger er laget av vår IT-avdeling.
og: fra servere som behandler trafikk til et kundesenter og mobilapplikasjon. IT-avdelingen har nå ca 80 personer med svært, veldig mangfoldig kompetanse.
Om Zabbix og dens arkitektur
MCH: – Og nå skal jeg prøve å sette en personlig rekord og si i løpet av ett minutt hva Zabbix er (heretter referert til som "Zabbix").
Zabbix posisjonerer seg som et out-of-the-box overvåkingssystem på bedriftsnivå. Den har mange funksjoner som gjør livet enklere: avanserte eskaleringsregler, API for integrasjon, gruppering og automatisk gjenkjenning av verter og beregninger. Zabbix har såkalte skaleringsverktøy – proxyer. Zabbix er et åpen kildekode-system.
Kort om arkitektur. Vi kan si at den består av tre komponenter:
- Server. Skrevet i C. Med ganske kompleks behandling og overføring av informasjon mellom tråder. All behandling foregår i den: fra mottak til lagring i databasen.
- Alle data lagres i databasen. Zabbix støtter MySQL, PostreSQL og Oracle.
- Nettgrensesnittet er skrevet i PHP. På de fleste systemer kommer den med en Apache-server, men fungerer mer effektivt i kombinasjon med nginx + php.
I dag vil vi gjerne fortelle en historie fra livet til selskapet vårt relatert til Zabbix...
En historie fra livet til Intersvyaz-selskapet. Hva har vi og hva trenger vi?
5 eller 6 måneder siden. En dag etter jobb...
MCH: - Misha, hei! Jeg er glad jeg klarte å fange deg - det er en samtale. Vi hadde igjen problemer med overvåking. Under en storulykke gikk alt sakte og det var ingen informasjon om tilstanden til nettet. Det er dessverre ikke første gang dette har skjedd. Jeg trenger din hjelp. La oss få vår overvåking til å fungere under alle omstendigheter!
MM: – Men la oss synkronisere først. Jeg har ikke sett der på et par år. Så vidt jeg husker, forlot vi Nagios og byttet til Zabbix for omtrent 8 år siden. Og nå ser det ut til at vi har 6 kraftige servere og omtrent et dusin proxyer. Forvirrer jeg noe?
MCH: - Nesten. 15 servere, hvorav noen er virtuelle maskiner. Det viktigste er at det ikke redder oss i det øyeblikket vi trenger det mest. Som en ulykke - serverne bremser ned og du kan ikke se noe. Vi prøvde å optimalisere konfigurasjonen, men dette ga ikke den optimale ytelsesøkningen.
MM: - Det er klart. Så du på noe, har du allerede gravd frem noe fra diagnostikken?
MCH: – Det første du må forholde deg til er databasen. MySQL lastes konstant, og lagrer nye beregninger, og når Zabbix begynner å generere en haug med hendelser, går databasen over i overdrive bokstavelig talt noen timer. Jeg har allerede fortalt deg om å optimalisere konfigurasjonen, men bokstavelig talt i år oppdaterte de maskinvaren: serverne har mer enn hundre gigabyte med minne og diskarrayer på SSD RAID-er - det er ingen vits i å vokse lineært på lang sikt. Hva skal vi gjøre?
MM: - Det er klart. Generelt er MySQL en LTP-database. Tilsynelatende er det ikke lenger egnet for å lagre et arkiv med beregninger av vår størrelse. La oss finne ut av det.
MCH: - La oss!
Integrasjon av Zabbix og Clickhouse som et resultat av hackathon
Etter en tid mottok vi interessante data:
Mesteparten av plassen i databasen vår ble okkupert av metrikkarkivet og mindre enn 1 % ble brukt til konfigurasjon, maler og innstillinger. På det tidspunktet hadde vi drevet Big data-løsningen basert på Clickhouse i mer enn ett år. Bevegelsesretningen var åpenbar for oss. På vårens Hackathon skrev jeg integrasjonen av Zabbix med Clickhouse for serveren og frontend. På det tidspunktet hadde Zabbix allerede støtte for ElasticSearch, og vi bestemte oss for å sammenligne dem.
Sammenligning av Clickhouse og Elasticsearch
MM: – Til sammenligning genererte vi den samme belastningen som Zabbix-serveren gir og så på hvordan systemene ville oppføre seg. Vi skrev data i batcher på 1000 linjer ved å bruke CURL. Vi antok på forhånd at Clickhouse ville være mer effektivt for lastprofilen som Zabbix gjør. Resultatene overgikk til og med våre forventninger:
Under de samme testforholdene skrev Clickhouse tre ganger mer data. Samtidig forbrukte begge systemene svært effektivt (en liten mengde ressurser) når de leste data. Men elastikk krevde en stor mengde prosessor ved opptak:
Totalt sett var Clickhouse betydelig overlegen Elastix når det gjelder prosessorforbruk og hastighet. På samme tid, på grunn av datakomprimering, bruker Clickhouse 11 ganger mindre på harddisken og utfører omtrent 30 ganger færre diskoperasjoner:
MCH: – Ja, Clickhouses arbeid med diskundersystemet er implementert veldig effektivt. Du kan bruke enorme SATA-disker for databaser og få skrivehastigheter på hundretusenvis av linjer per sekund. Ut-av-boksen-systemet støtter sharding, replikering og er veldig enkelt å konfigurere. Vi er mer enn fornøyd med bruken gjennom året.
For å optimalisere ressursene kan du installere Clickhouse ved siden av din eksisterende hoveddatabase og dermed spare mye CPU-tid og diskoperasjoner. Vi har flyttet arkivet med beregninger til eksisterende Clickhouse-klynger:
Vi lettet hoved MySQL-databasen så mye at vi kunne kombinere den på én maskin med Zabbix-serveren og forlate den dedikerte serveren for MySQL.
Hvordan fungerer meningsmåling i Zabbix?
4 måneder siden
MM: – Vel, kan vi glemme problemene med basen?
MCH: - Det er sikkert! Et annet problem vi må løse er langsom datainnsamling. Nå er alle våre 15 proxy-servere overbelastet med SNMP og polling-prosesser. Og det er ingen annen måte enn å installere nye og nye servere.
MM: - Flott. Men først, fortell oss hvordan meningsmåling fungerer i Zabbix?
MCH: – Kort sagt, det er 20 typer beregninger og et dusin måter å få dem på. Zabbix kan samle inn data enten i "request-response"-modus, eller vente på nye data gjennom "Trapper Interface".
Det er verdt å merke seg at i den originale Zabbix er denne metoden (Trapper) den raskeste.
Det er proxy-servere for lastdistribusjon:
Proxyer kan utføre de samme innsamlingsfunksjonene som Zabbix-serveren, motta oppgaver fra den og sende de innsamlede beregningene gjennom Trapper-grensesnittet. Dette er den offisielt anbefalte måten å fordele lasten på. Proxyer er også nyttige for å overvåke ekstern infrastruktur som opererer gjennom NAT eller en langsom kanal:
MM: – Alt er klart med arkitektur. Vi må se på kildene...
Et par dager senere
Historien om hvordan nmap fping vant
MM: "Jeg tror jeg har gravd opp noe."
MCH: - Fortell meg!
MM: – Jeg oppdaget at når Zabbix sjekker tilgjengelighet, sjekker Zabbix maksimalt 128 verter om gangen. Jeg prøvde å øke dette tallet til 500 og fjerne inter-packet intervallet i ping (ping) deres - dette doblet ytelsen. Men jeg vil gjerne ha større antall.
MCH: – I min praksis må jeg noen ganger sjekke tilgjengeligheten til tusenvis av verter, og jeg har aldri sett noe raskere enn nmap for dette. Jeg er sikker på at dette er den raskeste måten. La oss prøve det! Vi må øke antallet verter betraktelig per iterasjon.
MM: – Sjekke mer enn fem hundre? 600?
MCH: - Minst et par tusen.
MM: - OK. Det viktigste jeg ville si er at jeg fant ut at de fleste avstemningene i Zabbix gjøres synkront. Vi må definitivt endre den til asynkron modus. Da kan vi dramatisk øke antallet målinger som samles inn av pollers, spesielt hvis vi øker antallet målinger per iterasjon.
MCH: - Flott! Og når?
MM: – Som vanlig i går.
MCH: – Vi sammenlignet begge versjonene av fping og nmap:
På et stort antall verter var nmap forventet å være opptil fem ganger mer effektiv. Siden nmap kun sjekker tilgjengelighet og responstid, flyttet vi beregningen av tap til utløsere og reduserte tilgjengelighetssjekkintervallene betydelig. Vi fant at det optimale antallet verter for nmap var rundt 4 tusen per iterasjon. Nmap tillot oss å redusere CPU-kostnadene for tilgjengelighetskontroller med tre ganger og redusere intervallet fra 120 sekunder til 10.
Avstemningsoptimalisering
MM: «Så begynte vi å gjøre meningsmålere. Vi var hovedsakelig interessert i SNMP-deteksjon og agenter. I Zabbix gjøres polling synkront og det er gjort spesielle tiltak for å øke effektiviteten i systemet. I synkron modus forårsaker utilgjengelighet på vertssiden betydelig forringelse av polling. Det er et helt system av stater, det er spesielle prosesser - de såkalte unreachable pollers, som bare fungerer med unreachable verter:
Dette er en kommentar som demonstrerer tilstandsmatrisen, all kompleksiteten til systemet med overganger som kreves for at systemet skal forbli effektivt. I tillegg er selve synkron polling ganske treg:
Det er grunnen til at tusenvis av poller-strømmer på dusinvis av proxyer ikke kunne samle inn den nødvendige mengden data for oss. Den asynkrone implementeringen løste ikke bare problemene med antall tråder, men forenklet også tilstandssystemet for utilgjengelige verter betydelig, fordi for et hvilket som helst antall sjekket i en polling-iterasjon, var den maksimale ventetiden 1 timeout:
I tillegg har vi modifisert og forbedret avstemningssystemet for SNMP-forespørsler. Faktum er at folk flest ikke kan svare på flere SNMP-forespørsler samtidig. Derfor laget vi en hybridmodus, når SNMP-polling av samme vert gjøres asynkront:
Dette gjøres for hele pakken med verter. Denne modusen er til syvende og sist ikke tregere enn en helt asynkron, siden polling av halvannet hundre SNMP-verdier fortsatt er mye raskere enn 1 timeout.
Eksperimentene våre har vist at det optimale antallet forespørsler i én iterasjon er omtrent 8 tusen med SNMP-avstemning. Totalt tillot overgangen til asynkron modus oss å øke hastigheten på avstemningsytelsen med 200 ganger, flere hundre ganger.
MCH: – De resulterende avstemningsoptimaliseringene viste at vi ikke bare kan bli kvitt alle fullmakter, men også redusere intervallene for mange kontroller, og fullmakter vil ikke lenger være nødvendig som en måte å dele belastningen på.
For ca tre måneder siden
Endre arkitekturen - øk belastningen!
MM: – Vel, Max, er det på tide å bli produktiv? Jeg trenger en kraftig server og en god ingeniør.
MCH: - Ok, la oss planlegge det. Det er på høy tid å gå fra dødpunktet på 5 tusen metrikker per sekund.
Morgen etter oppgraderingen
MCH: – Misha, vi oppdaterte oss selv, men om morgenen rullet vi tilbake... Gjett hvilken hastighet vi klarte å oppnå?
MM: – Maksimalt 20 tusen.
MCH: - Ja, 25! Dessverre er vi akkurat der vi startet.
MM: - Hvorfor? Har du kjørt noen diagnose?
MCH: - Ja sikkert! Her er for eksempel en interessant topp:
MM: - La oss se på. Jeg ser at vi har prøvd et stort antall avstemningstråder:
Men samtidig kunne de ikke resirkulere systemet med halvparten:
Og den generelle ytelsen er ganske liten, omtrent 4 tusen beregninger per sekund:
Er det noe annet?
MCH: – Ja, spor av en av meningsmålerne:
MM: – Her kan man tydelig se at avstemningsprosessen venter på «semaforer». Dette er låsene:
MCH: - Uklart.
MM: – Se, dette ligner på en situasjon der en haug med tråder prøver å jobbe med ressurser som bare én kan jobbe med om gangen. Så alt de kan gjøre er å dele denne ressursen over tid:
Og den totale ytelsen til å jobbe med en slik ressurs er begrenset av hastigheten til en kjerne:
Det er to måter å løse dette problemet på.
Oppgrader maskinvaren til maskinen, bytt til raskere kjerner:
Eller endre arkitekturen og samtidig endre belastningen:
MCH: – Forresten, på testmaskinen vil vi bruke færre kjerner enn på kamp, men de er 1,5 ganger raskere i frekvens per kjerne!
MM: - Klart? Du må se på serverkoden.
Databane i Zabbix-serveren
MCH: – For å finne ut av det, begynte vi å analysere hvordan data overføres inne i Zabbix-serveren:
Kult bilde, ikke sant? La oss gå gjennom det steg for steg for å gjøre det mer eller mindre klart. Det er tråder og tjenester som er ansvarlige for å samle inn data:
De overfører de innsamlede beregningene via en socket til Preprocessor manager, hvor de lagres i en kø:
"Forbehandlerlederen" overfører data til sine arbeidere, som utfører forbehandlingsinstruksjoner og returnerer dem tilbake gjennom samme kontakt:
Etter dette lagrer forprosessorbehandleren dem i historikkbufferen:
Derfra blir de tatt av historiesynkere, som utfører ganske mange funksjoner: for eksempel å beregne triggere, fylle verdibufferen og, viktigst av alt, lagre beregninger i historielagringen. Generelt er prosessen kompleks og veldig forvirrende.
MM: – Det første vi så var at de fleste tråder konkurrerer om den såkalte «configuration cache» (minneområdet der alle serverkonfigurasjoner er lagret). Tråder som er ansvarlige for å samle inn data blokkerer spesielt mye:
...siden konfigurasjonen lagrer ikke bare beregninger med parameterne deres, men også køer som pollers henter informasjon fra om hva de skal gjøre videre. Når det er mange pollers og en blokkerer konfigurasjonen, venter de andre på forespørsler:
Pollere bør ikke komme i konflikt
Derfor, det første vi gjorde var å dele køen i 4 deler og la pollers blokkere disse køene, disse delene på samme tid, under trygge forhold:
Dette fjernet konkurransen om konfigurasjonscachen, og hastigheten til pollers økte betydelig. Men så møtte vi det faktum at forbehandlerlederen begynte å samle en kø med jobber:
Forbehandlerleder må kunne prioritere
Dette skjedde i tilfeller hvor han manglet prestasjoner. Så alt han kunne gjøre var å samle forespørsler fra datainnsamlingsprosesser og legge til bufferen deres til den tok opp alt minnet og krasjet:
For å løse dette problemet, la vi til en ekstra stikkontakt som var dedikert spesifikt til arbeidere:
Dermed hadde forbehandlerlederen muligheten til å prioritere arbeidet sitt, og hvis bufferen vokser, er oppgaven å bremse fjerningen, noe som gir arbeiderne muligheten til å ta denne bufferen:
Så oppdaget vi at en av årsakene til nedgangen var arbeiderne selv, siden de konkurrerte om en ressurs som var helt uviktig for deres arbeid. Vi dokumenterte dette problemet som en feilretting, og det er allerede løst i nye versjoner av Zabbix:
Vi øker antall stikkontakter - vi får resultatet
Videre ble selve forprosessorsjefen en flaskehals, siden det er én tråd. Den hvilte på kjernehastigheten, og ga en maksimal hastighet på omtrent 70 tusen metrikk per sekund:
Derfor laget vi fire, med fire sett med stikkontakter, arbeidere:
Og dette tillot oss å øke hastigheten til omtrent 130 tusen metrikk:
Ikke-lineariteten i veksten forklares med at det har dukket opp konkurranse om historiecachen. 4 forbehandlerledere og historiesinkere konkurrerte om det. På dette tidspunktet mottok vi omtrent 130 tusen metrikk per sekund på testmaskinen, og brukte den av omtrent 95 % av prosessoren:
For ca 2,5 måneder siden
Avslag fra snmp-fellesskapet økte NVPene med en og en halv ganger
MM: – Max, jeg trenger en ny testbil! Vi passer ikke lenger inn i den nåværende.
MCH: – Hva har du nå?
MM: – Nå – 130 XNUMX NVP-er og en hylleklar prosessor.
MCH: - Wow! Kul! Vent, jeg har to spørsmål. I følge mine beregninger er behovet vårt rundt 15-20 tusen metrikk per sekund. Hvorfor trenger vi mer?
MM: "Jeg vil fullføre jobben." Jeg vil gjerne se hvor mye vi kan presse ut av dette systemet.
MCH: - Men…
MM: "Men det er ubrukelig for virksomheten."
MCH: - Det er klart. Og det andre spørsmålet: kan vi støtte det vi har nå på egen hånd, uten hjelp fra en utvikler?
MM: - Jeg tror ikke. Det er et problem å endre hvordan konfigurasjonsbufferen fungerer. Det påvirker endringer i de fleste tråder og er ganske vanskelig å vedlikeholde. Mest sannsynlig vil det være veldig vanskelig å vedlikeholde det.
MCH: – Da trenger vi et slags alternativ.
MM: – Det finnes et slikt alternativ. Vi kan bytte til raske kjerner, samtidig som vi forlater det nye låsesystemet. Vi vil fortsatt få en ytelse på 60-80 tusen beregninger. Samtidig kan vi la resten av koden ligge igjen. Clickhouse og asynkron polling vil fungere. Og det vil være enkelt å vedlikeholde.
MCH: - Fantastisk! Jeg foreslår at vi stopper her.
Etter å ha optimalisert serversiden, kunne vi endelig lansere den nye koden i produksjon. Vi forlot noen av endringene til fordel for å bytte til en maskin med raske kjerner og minimere antallet kodeendringer. Vi har også forenklet konfigurasjonen og eliminert makroer i dataelementer der det er mulig, ettersom de introduserer ekstra låsing.
For eksempel, å forlate snmp-community-makroen, som ofte finnes i dokumentasjon og eksempler, gjorde det i vårt tilfelle mulig å øke hastigheten på NVP-er ytterligere med omtrent 1,5 ganger.
Etter to dager i produksjon
Fjerner hendelseshistorikk popup-vinduer
MCH: – Misha, vi har brukt systemet i to dager, og alt fungerer. Men bare når alt fungerer! Vi hadde planlagt arbeid med overføring av et ganske stort segment av nettverket, og vi sjekket igjen med hendene hva som gikk opp og ikke.
MM: - Kan ikke være det! Vi sjekket alt 10 ganger. Serveren håndterer selv fullstendig nettverkstilgjengelighet umiddelbart.
MCH: - Ja, jeg forstår alt: server, database, topp, austat, logger - alt er raskt... Men vi ser på nettgrensesnittet, og det er en prosessor "i hyllen" på serveren og dette:
MM: - Det er klart. La oss se på nettet. Vi fant ut at i en situasjon der det var et stort antall aktive hendelser, begynte de fleste live-widgets å fungere veldig sakte:
Årsaken til dette var genereringen av hendelseshistorikk popup-vinduer som genereres for hvert element i listen. Derfor forlot vi genereringen av disse vinduene (kommenterte 5 linjer i koden), og dette løste problemene våre.
Lastetiden for widgets, selv når de er helt utilgjengelige, er redusert fra flere minutter til akseptable 10-15 sekunder for oss, og historikken kan fortsatt sees ved å klikke på tiden:
Etter jobb. 2 måneder siden
MCH: - Misha, drar du? Vi må snakke.
MM: – Det hadde jeg ikke tenkt. Noe med Zabbix igjen?
MCH: – Nei, slapp av! Jeg ville bare si: alt fungerer, takk! Jeg har en øl.
Zabbix er effektivt
Zabbix er et ganske universelt og rikt system og funksjon. Den kan brukes til små installasjoner ut av esken, men etter hvert som behovene vokser, må den optimaliseres. For å lagre et stort arkiv med beregninger, bruk en passende lagring:
- du kan bruke innebygde verktøy i form av integrasjon med Elasticsearch eller opplasting av historikk til tekstfiler (tilgjengelig fra versjon XNUMX);
- Du kan dra nytte av vår erfaring og integrasjon med Clickhouse.
For å dramatisk øke hastigheten på innsamling av beregninger, samle dem ved å bruke asynkrone metoder og overføre dem gjennom trapper-grensesnittet til Zabbix-serveren; eller du kan bruke en patch for å gjøre Zabbix pollers asynkrone.
Zabbix er skrevet i C og er ganske effektiv. Å løse flere arkitektoniske flaskehalser lar deg øke ytelsen ytterligere og, etter vår erfaring, oppnå mer enn 100 tusen beregninger på en enkeltprosessormaskin.
Den samme Zabbix-lappen
MM: – Jeg vil legge til et par punkter. Hele gjeldende rapport, alle tester, tall er gitt for konfigurasjonen vi bruker. Vi tar nå omtrent 20 tusen metrikk per sekund fra det. Hvis du prøver å forstå om dette vil fungere for deg, kan du sammenligne. Det som ble diskutert i dag er lagt ut på GitHub i form av en oppdatering:
Patchen inkluderer:
- full integrasjon med Clickhouse (både Zabbix-server og frontend);
- løse problemer med forbehandlerlederen;
- asynkron polling.
Patchen er kompatibel med all versjon 4, inkludert lts. Mest sannsynlig, med minimale endringer vil det fungere på versjon 3.4.
Takk for oppmerksomheten.
spørsmål
Spørsmål fra salen (heretter – A): – God ettermiddag! Fortell meg, har du planer om intensiv interaksjon med Zabbix-teamet eller med dem med deg, slik at dette ikke er en lapp, men normal oppførsel til Zabbix?
MM: – Ja, vi vil definitivt forplikte noen av endringene. Noe vil skje, noe vil forbli i lappen.
og: – Tusen takk for den flotte rapporten! Fortell meg, etter å ha brukt oppdateringen, vil støtte fra Zabbix forbli, og hvordan fortsette å oppdatere til høyere versjoner? Vil det være mulig å oppdatere Zabbix etter oppdateringen til 4.2, 5.0?
MM: – Jeg kan ikke si noe om støtte. Hvis jeg var Zabbix teknisk støtte, ville jeg sannsynligvis sagt nei, fordi dette er en annens kode. Når det gjelder 4.2-kodebasen, er vår posisjon: "Vi vil bevege oss med tiden, og vi vil oppdatere oss på neste versjon." Derfor vil vi i en stund legge ut en oppdatering for oppdaterte versjoner. Jeg sa allerede i rapporten: antall endringer med versjoner er fortsatt ganske lite. Jeg tror overgangen fra 3.4 til 4 tok oss ca 15 minutter.Noe endret seg der, men ikke veldig viktig.
og: – Så du planlegger å støtte oppdateringen din, og du kan trygt installere den i produksjon og motta oppdateringer på en eller annen måte i fremtiden?
MM: – Vi anbefaler det på det sterkeste. Dette løser mange problemer for oss.
MCH: – Nok en gang vil jeg gjøre oppmerksom på at endringene som ikke gjelder arkitekturen og ikke gjelder blokkering eller køer er modulære, de er i separate moduler. Selv med mindre endringer kan du vedlikeholde dem ganske enkelt.
MM: – Hvis du er interessert i detaljene, så bruker «Clickhouse» det såkalte historiebiblioteket. Den er ubundet - det er en kopi av Elastics-støtten, det vil si at den kan konfigureres. Polling endrer kun meningsmålere. Vi tror dette vil fungere i lang tid.
og: - Takk så mye. Si meg, er det noen dokumentasjon på endringene som er gjort?
MM: – Dokumentasjon er en oppdatering. Åpenbart, med introduksjonen av Clickhouse, med introduksjonen av nye typer pollers, oppstår nye konfigurasjonsalternativer. Linken fra siste lysbilde har en kort beskrivelse av hvordan du bruker den.
Om å erstatte fping med nmap
og: – Hvordan gjennomførte du dette til slutt? Kan du gi konkrete eksempler: har du stropper og et eksternt manus? Hva ender opp med å sjekke et så stort antall verter så raskt? Hvordan miner du disse vertene? Trenger vi å mate dem for å kartlegge på en eller annen måte, hente dem fra et sted, sette dem inn, kjøre noe?
MM: - Kul. Et veldig riktig spørsmål! Poenget er dette. Vi modifiserte biblioteket (ICMP-ping, en del av Zabbix) for ICMP-sjekker, som indikerer antall pakker - en (1), og koden prøver å bruke nmap. Det vil si at dette er det interne arbeidet til Zabbix, som har blitt det interne arbeidet til pingeren. Følgelig er det ikke nødvendig med synkronisering eller bruk av en trapper. Dette ble gjort med vilje for å la systemet være intakt og slippe å synkronisere to databasesystemer: hva skal sjekkes, lastes opp gjennom polleren, og er opplastingen vår ødelagt?.. Dette er mye enklere.
og: – Fungerer det for fullmakter også?
MM: – Ja, men vi sjekket ikke. Avstemningskoden er den samme i både Zabbix og serveren. Burde virke. La meg understreke nok en gang: systemets ytelse er slik at vi ikke trenger en proxy.
MCH: – Det riktige svaret på spørsmålet er: "Hvorfor trenger du en proxy med et slikt system?" Bare på grunn av NAT eller overvåking gjennom en slags treg kanal...
og: – Og du bruker Zabbix som allertor, hvis jeg forstår det rett. Eller har grafikken din (der arkivlaget er) flyttet til et annet system, for eksempel Grafana? Eller bruker du ikke denne funksjonaliteten?
MM: – Jeg vil nok en gang understreke: vi har oppnådd fullstendig integrering. Vi øser historie inn i Clickhouse, men samtidig har vi endret php-frontend. Php-grensesnittet går til Clickhouse og tar all grafikken derfra. Samtidig har vi, for å være ærlig, en del som bygger data i andre grafiske visningssystemer fra samme Clickhouse, fra de samme Zabbix-dataene.
MCH: – I «Grafan» også.
Hvordan ble beslutninger tatt om tildeling av ressurser?
og: – Del litt av ditt indre kjøkken. Hvordan ble beslutningen tatt om at det var nødvendig å avsette ressurser til seriøs behandling av produktet? Dette er generelt sett visse risikoer. Og vennligst fortell meg, i sammenheng med det faktum at du kommer til å støtte nye versjoner: hvordan rettferdiggjør denne beslutningen fra et ledelsessynspunkt?
MM: – Tilsynelatende fortalte vi ikke historiens drama så godt. Vi befant oss i en situasjon der noe måtte gjøres, og vi gikk i hovedsak med to parallelle team:
- Det ene var å lansere et overvåkingssystem med nye metoder: overvåking som en tjeneste, et standardsett med åpen kildekode-løsninger som vi kombinerer og deretter prøver å endre forretningsprosessen for å kunne jobbe med det nye overvåkingssystemet.
- Samtidig hadde vi en entusiastisk programmerer som holdt på med dette (om seg selv). Det hendte at han vant.
og: – Og hva er størrelsen på laget?
MCH: - Hun er foran deg.
og: – Så, som alltid, trenger du en lidenskapelig?
MM: – Jeg vet ikke hva en lidenskapelig er.
og: - I dette tilfellet, tilsynelatende, deg. Tusen takk, du er fantastisk.
MM: - Takk.
Om patcher for Zabbix
og: – For et system som bruker proxyer (for eksempel i noen distribuerte systemer), er det mulig å tilpasse og lappe for eksempel pollers, proxyer og delvis forprosessoren til selve Zabbix; og deres samhandling? Er det mulig å optimalisere eksisterende utvikling for et system med flere proxyer?
MM: – Jeg vet at Zabbix-serveren er satt sammen ved hjelp av en proxy (koden er kompilert og innhentet). Vi har ikke testet dette i produksjon. Jeg er ikke sikker på dette, men jeg tror at preprocessor manager ikke brukes i proxyen. Oppgaven til proxyen er å ta et sett med beregninger fra Zabbix, slå dem sammen (den registrerer også konfigurasjonen, den lokale databasen) og gi den tilbake til Zabbix-serveren. Serveren selv vil da gjøre forhåndsbehandlingen når den mottar den.
Interessen for fullmakter er forståelig. Vi skal sjekke det ut. Dette er et interessant tema.
og: – Ideen var denne: Hvis du kan lappe pollers, kan du lappe dem på proxyen og lappe interaksjonen med serveren, og tilpasse forprosessoren for disse formålene kun på serveren.
MM: – Jeg tror det er enda enklere. Du tar koden, bruker en oppdatering og konfigurerer den slik du trenger - samle inn proxy-servere (for eksempel med ODBC) og distribuer den lappede koden på tvers av systemer. Der det er nødvendig - samle en proxy, der det er nødvendig - en server.
og: – Mest sannsynlig trenger du ikke å lappe proxy-overføringen til serveren i tillegg?
MCH: – Nei, det er standard.
MM: – Faktisk lød en av ideene ikke. Vi har alltid opprettholdt en balanse mellom eksplosjonen av ideer og mengden endringer og enkel støtte.
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com