Die volgende HighLoad++-konferensie sal op 6 en 7 April 2020 in St. Petersburg gehou word. Besonderhede en kaartjies . HighLoad++ Moskou 2018. Moskousaal. 9 November, 15:00. Abstracts en .
* Monitering - aanlyn en analise.
* Belangrikste beperkings van die ZABBIX-platform.
* Oplossing vir die skaal van analitiese berging.
* Optimalisering van die ZABBIX-bediener.
* UI-optimalisering.
* Ervaring in die bedryf van die stelsel onder vragte van meer as 40k NVPS.
* Kort gevolgtrekkings.
Mikhail Makurov (hierna - MM): - Hi almal!
Maxim Chernetsov (hierna - MCH): - Goeie middag!
MM: Kom ek stel Maxim voor. Max is 'n talentvolle ingenieur, die beste netwerker wat ek ken. Maxim handel oor netwerke en dienste, die ontwikkeling en bedryf daarvan.
MCH: – En ek wil jou graag van Michael vertel. Michael is 'n C-ontwikkelaar. Hy het verskeie hoë-lading verkeer verwerking oplossings vir ons maatskappy geskryf. Ons woon en werk in die Oeral, in die stad van geharde mans Chelyabinsk, in die Intersvyaz-maatskappy. Ons maatskappy is 'n internet- en kabel-TV-diensverskaffer vir een miljoen mense in 16 stede.
MM: - En dit is die moeite werd om te sê dat Intersvyaz veel meer is as net 'n verskaffer, dit is 'n IT-maatskappy. Die meeste van ons oplossings word deur ons IT-afdeling gemaak.
A: van bedieners wat verkeer verwerk tot 'n oproepsentrum en 'n mobiele toepassing. Die IT-afdeling het nou sowat 80 mense met baie, baie uiteenlopende bevoegdhede.
Oor Zabbix en sy argitektuur
MCH: - En nou sal ek probeer om 'n persoonlike rekord op te stel en in een minuut sê wat Zabbix (hierna - "Zabbiks") is.
Zabbix posisioneer homself as 'n out-of-the-box ondernemingsvlak moniteringstelsel. Dit het baie kenmerke wat die lewe makliker maak: gevorderde eskalasiereëls, API vir integrasie, groepering en outo-ontdekking van gashere en statistieke. Zabbix het sogenaamde skaalinstrumente – gevolmagtigdes. Zabbix is 'n oopbronstelsel.
Kortliks oor argitektuur. Ons kan sê dat dit uit drie komponente bestaan:
- Bediener. Geskryf in C. Met taamlik komplekse verwerking en oordrag van inligting tussen drade. Alle verwerking vind daarin plaas: van ontvang tot stoor na die databasis.
- Alle data word in die databasis gestoor. Zabbix ondersteun MySQL, PostreSQL en Oracle.
- Die webkoppelvlak is in PHP geskryf. In die meeste stelsels kom dit saam met die Apache-bediener, maar dit werk meer doeltreffend in kombinasie met nginx + php.
Vandag wil ons graag een storie vertel wat verband hou met Zabbix uit die lewe van ons maatskappy ...
'n Verhaal uit die lewe van die Intersvyaz-maatskappy. Wat het ons en wat het ons nodig?
5 of 6 maande gelede. Een dag na werk...
MCH: - Misha, hallo! Ek is bly ek het dit reggekry om jou te vang – daar is ’n gesprek. Ons het weer probleme gehad met monitering. Tydens 'n groot ongeluk het alles vertraag, en daar was geen inligting oor die toestand van die netwerk nie. Ongelukkig is dit nie die eerste keer dat dit gebeur nie. Ek het jou hulp nodig. Kom ons laat ons monitering onder enige omstandighede werk!
MM: Maar kom ons sinchroniseer eers. Ek het 'n paar jaar nie daar gekyk nie. Sover ek onthou, het ons Nagios verlaat en so 8 jaar gelede na Zabbix oorgeskakel. En nou lyk dit of ons 6 kragtige bedieners en ongeveer 'n dosyn gevolmagtigdes het. Verwar ek enigiets?
MCH: - Amper. 15 bedieners, waarvan sommige virtuele masjiene is. Die belangrikste is dat dit ons nie red op die oomblik wanneer ons dit die nodigste het nie. Soos 'n ongeluk - die bedieners vertraag en niks is sigbaar nie. Ons het probeer om die konfigurasie te optimaliseer, maar dit gee nie 'n optimale prestasie-hupstoot nie.
MM: - Dit is duidelik. Het jy na iets gekyk, het jy al iets uit die diagnostiek opgegrawe?
MCH: - Die eerste ding waarmee jy te doen het, is net die databasis. MySQL word reeds voortdurend gelaai, wat nuwe statistieke stoor, en wanneer Zabbix 'n klomp gebeurtenisse begin genereer, gaan die databasis vir letterlik 'n paar uur in homself. Ek het jou reeds vertel van die konfigurasie-optimalisering, maar letterlik hierdie jaar het hulle die hardeware opgedateer: die bedieners het meer as honderd gigagrepe geheue en skyfskikkings op SSD RAID's - dit is geen sin om dit lineêr te laat groei nie. Wat maak ons?
MM: - Dit is duidelik. Oor die algemeen is MySQL 'n LTP-databasis. Dit is blykbaar nie meer geskik vir die stoor van 'n argief van metrieke van ons grootte nie. Kom ons vind dit uit.
MCH: - Kom ons!
Zabbix en Clickhouse-integrasie as gevolg van die hackathon
Na 'n rukkie het ons interessante data ontvang:
Die meeste van die spasie in ons databasis is in beslag geneem deur die argief van metrieke en minder as 1% is gebruik vir konfigurasie, sjablone en instellings. Teen daardie tyd het ons vir meer as 'n jaar 'n Big data-oplossing gebaseer op Clickhouse bedryf. Die rigting van beweging vir ons was duidelik. By ons lente-Hackathon het ek die integrasie van Zabbix met Clickhouse vir die bediener en frontend geskryf. Op daardie tydstip het Zabbix reeds ondersteuning vir ElasticSearch gehad, en ons het besluit om dit te vergelyk.
Vergelyking van Clickhouse en Elasticsearch
MM: - Ter vergelyking het ons die las dieselfde gegenereer as wat deur die Zabbix-bediener verskaf word en gekyk hoe die stelsels sou optree. Ons het data in bondels van 1000 reëls geskryf deur CURL te gebruik. Ons het vooraf aanvaar dat Clickhouse meer doeltreffend sou wees vir die vragprofiel wat Zabbix doen. Die resultate het selfs ons verwagtinge oortref:
Onder dieselfde toetstoestande het Clickhouse drie keer soveel data geskryf. Terselfdertyd het beide stelsels baie doeltreffend ('n klein hoeveelheid hulpbronne) verbruik wanneer data gelees word. Maar Elastics het 'n groot hoeveelheid verwerker benodig tydens opname:
In totaal het Clickhouse aansienlik beter gevaar as Elastics wat verwerkerverbruik en spoed betref. Terselfdertyd, as gevolg van datakompressie, gebruik Clickhouse 11 keer minder op die hardeskyf en doen ongeveer 30 keer minder skyfbewerkings:
MCH: - Ja, Clickhouse se werk met die skyfsubstelsel word baie doeltreffend geïmplementeer. Jy kan groot SATA-aandrywers vir databasisse gebruik en skryfspoed van honderdduisende reëls per sekonde kry. Die stelsel uit die boks ondersteun versplintering, replikasie en is baie maklik om op te stel. Ons is meer as tevrede met die werking daarvan gedurende die jaar.
Om hulpbronne te optimaliseer, kan jy Clickhouse langs die bestaande hoofbasis installeer en daardeur baie SVE-tyd en skyfbewerkings bespaar. Ons het die argief van metrieke na die bestaande Clickhouse-klusters geskuif:
Ons het die hoof MySQL-databasis soveel afgelaai dat ons dit op dieselfde masjien met die Zabbix-bediener kon kombineer en die toegewyde bediener vir MySQL laat vaar.
Hoe werk stemming in Zabbix?
4 maande gelede
MM: - Wel, jy kan vergeet van die probleme met die basis?
MCH: - Dit is vir seker! Nog 'n uitdaging wat ons moet oplos, is stadige data-insameling. Nou is al ons 15 instaanbedieners oorlaai met SNMP en stembusprosesse. En daar is geen ander manier as om nuwe en nuwe bedieners te installeer nie.
MM: - Groot. Maar eerstens, hoe werk peiling in Zabbix?
MCH: - Kortom, daar is 20 soorte statistieke en 'n dosyn maniere om dit te kry. Zabbix kan data insamel of in die "versoek-antwoord"-modus, of wag vir nuwe data deur die "Trapper Interface".
Dit is opmerklik dat in die oorspronklike Zabbix hierdie metode (Trapper) die vinnigste is.
Daar is instaanbedieners vir lasbalansering:
Gevolmagtigdes kan dieselfde versamelingsfunksies as die Zabbix-bediener uitvoer, take daarvan ontvang en die versamelde statistieke net deur die Trapper-koppelvlak stuur. Dit is die amptelik aanbevole manier om die vrag te versprei. Gevolmagtigdes is ook nuttig vir die monitering van 'n afgeleë infrastruktuur wat deur NAT of 'n stadige skakel loop:
MM: Alles is duidelik met argitektuur. Ek moet na die bron kyk...
'n Paar dae later
Die storie van hoe nmap fping gewen het
MM: “Dit lyk of ek iets opgegrawe het.
MCH: - Vertel my!
MM: - Ek het gevind dat Zabbix tot 'n maksimum van 128 gashere gelyktydig nagaan wanneer hulle beskikbaarheid nagaan. Ek het probeer om hierdie syfer na 500 te verhoog en die interpakkie-interval in hul ping (ping) verwyder - dit het die prestasie verdubbel. Maar ek wil graag groot getalle hê.
MCH: - In my praktyk moet ek soms die beskikbaarheid van duisende gashere nagaan, en ek het niks vinniger as nmap hiervoor gesien nie. Ek is seker dit is die vinnigste manier. Kom ons probeer dit! U moet die aantal gashere in een iterasie aansienlik verhoog.
MM: – Gaan meer as vyfhonderd na? 600?
MCH: “Ten minste 'n paar duisend.
MM: - OK. Die belangrikste ding wat ek wou sê, is dat ek gevind het dat die meeste van die stemming in Zabbix sinchronies gedoen word. Ons moet dit na asinchroniese modus verander. Dan kan ons die aantal metrieke wat deur die pollers ingesamel word drasties verhoog, veral as ons die aantal metrieke per iterasie verhoog.
MCH: - Groot! En wanneer?
MM: - Soos gewoonlik, gister.
MCH: - Ons het beide weergawes van fping en nmap vergelyk:
Op 'n groot aantal gashere is verwag dat nmap tot vyf keer meer doeltreffend sou wees. Aangesien nmap slegs beskikbaarheid en reaksietyd nagaan, het ons die verliesberekening na snellers verskuif en die beskikbaarheidkontrole-intervalle aansienlik verminder. Ons het gevind dat die optimale aantal gashere vir nmap ongeveer 4 duisend per iterasie is. Nmap het ons toegelaat om die SVE-koste van beskikbaarheidkontroles met 'n faktor van drie te verminder en die interval van 120 sekondes tot 10 te verminder.
Polling optimering
MM: “Toe het ons in pollers beland. Ons was hoofsaaklik geïnteresseerd in SNMP-vaslegging en agente. In Zabbix word stemming sinchronies gedoen en spesiale maatreëls word getref om die doeltreffendheid van die stelsel te verhoog. In sinchroniese modus veroorsaak die onbeskikbaarheid van gashere aansienlike polling-agteruitgang. Daar is 'n hele stelsel van state, daar is spesiale prosesse - die sogenaamde onbereikbare pollers, wat net met onbereikbare gashere werk:
Hierdie is 'n kommentaar wat die toestandmatriks demonstreer, die kompleksiteit van die oorgangstelsel wat nodig is vir die stelsel om doeltreffend te bly. Daarbenewens is sinchroniese peiling self redelik stadig:
Dit is hoekom duisende poller-drade op 'n dosyn gevolmagtigdes nie die vereiste hoeveelheid data vir ons kon insamel nie. Die asynchrone implementering het nie net die probleme met die aantal drade opgelos nie, maar het ook die toestandstelsel van onbeskikbare gashere aansienlik vereenvoudig, want vir enige getal wat in een peilingiterasie nagegaan is, was die maksimum wagtyd 1 uitteltyd:
Daarbenewens het ons die stemstelsel vir SNMP-versoeke gewysig en verbeter. Die feit is dat die meeste nie gelyktydig op verskeie SNMP-versoeke kan reageer nie. Daarom het ons 'n hibriede modus gemaak wanneer SNMP-peiling van dieselfde gasheer asynchronies gedoen word:
Dit word gedoen vir die hele bondel gashere. Hierdie modus is uiteindelik nie stadiger as ten volle asinchroon nie, aangesien die peiling van een en 'n half honderd SNMP-waardes steeds baie vinniger is as 1 time-out.
Ons eksperimente het getoon dat die optimale aantal versoeke in een iterasie ongeveer 8 duisend is met SNMP-peiling. In totaal het die oorgang na asinchroniese modus ons in staat gestel om stemverrigting met 200 keer, 'n paar honderd keer te versnel.
MCH: – Die gevolglike stemmingsoptimalisasies het getoon dat ons nie net van alle gevolmagtigdes ontslae kan raak nie, maar ook die intervalle vir baie kontroles kan verminder, en gevolmagtigdes sal nie meer nodig wees as 'n manier om die las te deel nie.
So drie maande gelede
Verander die argitektuur - verhoog die las!
MM: - Wel, Max, is dit tyd om produktief te wees? Ek benodig 'n kragtige bediener en 'n goeie ingenieur.
MCH: - Goed, kom ons beplan. Dit is hoog tyd om van die dooie punt te beweeg in 5 duisend metrieke per sekonde.
Oggend na opgradering
MCH: – Misha, ons het opgegradeer, maar in die oggend teruggerol … Raai watter spoed het jy daarin geslaag om te bereik?
MM: - Maksimum 20 duisend.
MCH: - Ja, 25! Ongelukkig is ons presies waar ons begin het.
MM: - Hoekom? Het jy enige diagnose gedoen?
MCH: - Ja seker! Hier is byvoorbeeld 'n interessante top:
MM: - Kom ons kyk. Ek sien dat ons 'n groot aantal peilingsdrade probeer het:
Maar terselfdertyd kon hulle nie die stelsel selfs met die helfte gebruik nie:
En die algehele prestasie is redelik klein, ongeveer 4 duisend metrieke per sekonde:
Is daar enigiets anders?
MCH: – Ja, die spoor van een van die pollers:
MM: - Hier kan jy duidelik sien dat die stemproses wag vir "semafoor". Dit is die slotte:
MCH: - Onduidelik.
MM: – Kyk, dit is soos 'n situasie waar 'n klomp drade probeer werk met hulpbronne waarmee net een gelyktydig kan werk. Dan is al wat hulle kan doen, om hierdie hulpbron volgens tyd te verdeel:
En die totale prestasie van die werk met so 'n hulpbron word beperk deur die spoed van een kern:
Daar is twee maniere om hierdie probleem op te los.
Gradeer masjienhardeware op, skakel oor na vinniger kerne:
Of verander die argitektuur en in parallel - die las:
MCH: - Terloops, op die toetsmasjien sal ons 'n kleiner aantal kerne gebruik as op die gevegsmasjien, maar hulle is 1,5 keer vinniger in terme van frekwensie per kern!
MM: - Duidelik? Dit is nodig om na die bedienerkode te kyk.
Datapad in Zabbix-bediener
MCH: - Om te verstaan, het ons begin analiseer hoe data binne die Zabbix-bediener oorgedra word:
Cool foto, reg? Kom ons gaan dit stap vir stap deur om min of meer op te klaar. Daar is drade en dienste wat verantwoordelik is vir die insameling van data:
Hulle gee die versamelde statistieke deur die sok na die voorverwerkerbestuurder, waar hulle in die tou gestoor word:
Die voorverwerkerbestuurder" gee die data aan sy werkers deur, wat die voorverwerkingsinstruksies uitvoer en dit terugstuur deur dieselfde sok:
Die voorverwerkerbestuurder stoor dit dan in die geskiedeniskas:
Van daar af word hulle geneem deur geskiedenissinkers wat 'n hele paar funksies verrig: byvoorbeeld die berekening van snellers, die vul van die waardekas en, bowenal, die stoor van statistieke in die geskiedeniswinkel. Oor die algemeen is die proses kompleks en baie verwarrend.
MM: - Die eerste ding wat ons gesien het, is dat die meeste drade meeding vir die sogenaamde "config cache" (die geheue area waar alle bediener konfigurasies gestoor word). Veral baie slotte word gemaak deur die drade wat verantwoordelik is vir die herwinning van data:
...aangesien die konfigurasie nie net metrieke met hul parameters stoor nie, maar ook rye waaruit pollers inligting neem oor wat om volgende te doen. Wanneer daar baie pollers is, en een blokkeer die konfigurasie, wag die res vir versoeke:
Polleerders moet nie konflik nie
Daarom, die eerste ding wat ons gedoen het, was om die tou in 4 dele te verdeel en pollers toe te laat om hierdie toue veilig te blokkeer, hierdie dele op dieselfde tyd:
Dit het die kompetisie vir die konfigurasiekas verwyder, en die spoed van die pollers het aansienlik toegeneem. Maar toe word ons gekonfronteer met die feit dat die voorverwerkerbestuurder 'n werkswag begin opbou het:
Voorverwerkerbestuurder moet in staat wees om te prioritiseer
Dit het gebeur in gevalle waar dit 'n gebrek aan prestasie gehad het. Al wat dit dan kon doen, was om versoeke van data-insamelingsprosesse te versamel en hul buffer by te voeg totdat dit al die geheue geëet het en neergestort het:
Om hierdie probleem op te los, het ons 'n tweede sok bygevoeg wat spesifiek vir werkers toegewy is:
Die voorverwerkerbestuurder het dus die geleentheid gekry om sy werk te prioritiseer, en in geval van buffergroei is die taak om die verwydering te vertraag, wat werkers die geleentheid gee om hierdie buffer op te tel:
Toe ontdek ons dat een van die redes vir die verlangsaming die werkers self was, aangesien hulle meegeding het vir 'n hulpbron wat heeltemal onbelangrik vir hul werk was. Ons het 'n foutoplossing vir hierdie probleem uitgereik, en dit is reeds in die nuwe weergawes van Zabbix opgelos:
Ons verhoog die aantal voetstukke - ons kry die resultaat
Verder het die voorverwerker-bestuurder self 'n bottelnek geword, aangesien dit een draad is. Dit het op die spoed van die kern gerus, wat 'n maksimum spoed van ongeveer 70 duisend metrieke per sekonde gee:
So het ons vier, met vier sokstelle, werkers gemaak:
En dit het ons toegelaat om die spoed tot ongeveer 130 duisend metrieke te verhoog:
Die nie-lineariteit van groei word verklaar deur die feit dat daar mededinging is vir die geskiedeniskas. 4 voorverwerkerbestuurders en geskiedenissinkers het daarvoor meegeding. Op hierdie stadium het ons ongeveer 130 duisend metrieke per sekonde op die toetsmasjien gekry, wat dit deur ongeveer 95% van die verwerker gebruik het:
Sowat 2,5 maande gelede
Verwerping van snmp-gemeenskap het NVP's met een en 'n half keer verhoog
MM: Max, ek kort 'n nuwe toetsmotor! Ons pas nie meer in by die huidige een nie.
MCH: – Wat het jy nou?
MM: - Nou - 130k NVP's en 'n rakverwerker.
MCH: - Sjoe! Koel! Wag, ek het twee vrae. Volgens my berekeninge is ons behoefte in die omgewing van 15-20 duisend metrieke per sekonde. Hoekom het ons meer nodig?
MM: - Ek wil die werk klaarmaak. Ek wil sien hoeveel ons uit hierdie stelsel kan druk.
MCH: - Maar...
MM: Maar dit is nutteloos vir besigheid.
MCH: - Dit is duidelik. En die tweede vraag: sal ons dit wat ons nou het op ons eie kan ondersteun, sonder die hulp van 'n ontwikkelaar?
MM: - Ek dink nie. Dit is 'n probleem om te verander hoe die konfigurasiekas werk. Dit handel oor veranderinge in die meeste strome en is redelik moeilik om in stand te hou. Heel waarskynlik sal dit baie moeilik wees om dit in stand te hou.
MCH: "Dan het ons 'n alternatief nodig."
MM: - Daar is so 'n opsie. Ons kan oorskakel na vinnige kerns, terwyl ons die nuwe blokkeerstelsel laat vaar. Ons sal steeds 'n prestasie van 60-80 duisend metrieke kry. In hierdie geval kan ons die res van die kode verlaat. Clickhouse, asinchroniese peiling sal werk. En dit sal maklik wees om te onderhou.
MCH: - Wonderlik! Ek stel voor om daar te stop.
Nadat ons die bedienerkant geoptimaliseer het, kon ons uiteindelik die nuwe kode in produksie laat loop. Ons het sommige van die veranderinge laat vaar ten gunste van die skuif na 'n masjien met vinnige pitte en die vermindering van die aantal veranderinge in die kode. Ons het ook die konfigurasie vereenvoudig en makro's in items waar moontlik vermy, aangesien dit 'n bron van bykomende slotte is.
Byvoorbeeld, die verwerping van die snmp-gemeenskapmakro, wat dikwels in die dokumentasie en voorbeelde gevind word, het ons in ons geval in staat gestel om NVP's bykomend met ongeveer 1,5 keer te bespoedig.
Na twee dae in produksie
Verwyder voorvalgeskiedenis-opspringers
MCH: – Misha, ons gebruik die stelsel al twee dae, en alles werk. Maar net wanneer alles werk! Ons het werk beplan met die oordrag van 'n redelike groot segment van die netwerk, en ons het weer met ons hande nagegaan wat opgegaan het en wat nie.
MM: - Kan nie wees nie! Ons het alles 10 keer nagegaan. Die bediener hanteer selfs volledige netwerk onbeskikbaarheid onmiddellik.
MCH: - Ja, ek verstaan alles: bediener, databasis, top, austat, logs - alles is vinnig ... Maar ons kyk na die webkoppelvlak, en daar is 'n verwerker "in die rak" op die bediener en dit:
MM: - Dit is duidelik. Kom ons kyk na die web. Ons het gevind dat in 'n situasie waar daar 'n groot aantal aktiewe voorvalle was, die meeste van die operasionele legstukke baie stadig begin werk het:
Die rede hiervoor was die generering van voorvalgeskiedenis-opspringers wat vir elke item in die lys gegenereer word. Daarom het ons geweier om hierdie vensters te genereer (het 5 reëls in die kode opgemerk), en dit het ons probleme opgelos.
Die laaityd van die legstuk, selfs wanneer dit heeltemal onbeskikbaar is, is van etlike minute tot 10-15 sekondes verminder, wat vir ons aanvaarbaar is, en jy kan steeds die geskiedenis kyk deur op die tyd te klik:
Na werk. 2 maande gelede
MCH: Misha, gaan jy weg? Ons moet praat.
MM: - Ek het nie bedoel nie. Weer iets met Zabbix?
MCH: - Nee, ontspan! Ek wou net sê: alles werk, dankie! Bier van my.
Zabbix is doeltreffend
Zabbix is 'n redelik veelsydige en ryk stelsel en funksie. Dit kan gebruik word vir klein installasies uit die boks, maar soos behoeftes groei, moet dit geoptimaliseer word. Om 'n groot argief van metrieke te stoor, gebruik 'n geskikte berging:
- jy kan die ingeboude gereedskap gebruik in die vorm van integrasie met Elasticsearch of die oplaai van geskiedenis na tekslêers (beskikbaar vanaf die vierde weergawe);
- jy kan ons ervaring en integrasie met Clickhouse gebruik.
Om die spoed van die insameling van statistieke drasties te verhoog, versamel dit met asynchroniese metodes en dra dit oor deur die trapper-koppelvlak na die Zabbix-bediener; of jy kan die pleister gebruik vir asynchrone pollers van Zabbix self.
Zabbix is in C geskryf en is redelik doeltreffend. Die oplossing van verskeie argitektoniese knelpunte maak dit moontlik om sy werkverrigting verder te verhoog en, volgens ons ervaring, meer as 100 XNUMX metrieke op 'n enkelverwerkermasjien te verkry.
Dieselfde Zabbix-pleister
MM: – Ek wil 'n paar punte byvoeg. Die hele huidige verslag, alle toetse, syfers word gegee vir die konfigurasie wat ons gebruik. Ons neem nou ongeveer 20 duisend metrieke per sekonde daaruit. As jy probeer verstaan of dit vir jou sal werk - jy kan vergelyk. Waaroor ons vandag gepraat het, word as 'n pleister op GitHub geplaas:
Die pleister sluit in:
- volledige integrasie met Clickhouse (beide Zabbix-bediener en frontend);
- die oplossing van probleme met die voorverwerkerbestuurder;
- asynchrone peiling.
Die pleister is versoenbaar met alle weergawe 4, insluitend lts. Waarskynlik, met minimale veranderinge, sal dit op weergawe 3.4 werk.
Dankie vir jou aandag.
vrae
Vraag van die gehoor (hierna - A): - Goeie middag! Sê asseblief vir my, het jy planne vir intensiewe interaksie met die Zabbix-span of het hulle met jou, sodat dit nie 'n pleister is nie, maar die normale gedrag van Zabbix?
MM: – Ja, ons sal beslis van die veranderinge aangaan. Iets sal wees, iets sal in die kol bly.
A: – Baie dankie vir die uitstekende verslag! Sê vir my asseblief, na die toepassing van die pleister, sal ondersteuning van Zabbix behoue bly en hoe om op te gradeer na hoër weergawes? Sal dit moontlik wees om Zabbix op te dateer na jou pleister na 4.2, 5.0?
MM: Ek kan nie vir ondersteuning praat nie. As ek Zabbix tegniese ondersteuning was, sou ek blykbaar nee sê, want dit is iemand anders se kode. Wat die 4.2-kodebasis betref, is ons posisie: "Ons sal met tyd gaan, en ons sal onsself opdateer oor die volgende weergawe." Daarom sal ons vir 'n geruime tyd 'n pleister vir opgedateerde weergawes oplaai. Ek het reeds in die verslag gesê: die aantal veranderinge met weergawes is nog redelik klein. Ek dink die oorgang van 3.4 na 4 het ons, so lyk dit, omtrent 15 minute geneem.Iets het daar verander, maar nie baie belangrik nie.
A: - So jy beplan om jou pleister te ondersteun en jy kan dit veilig in produksie plaas, in die toekoms op een of ander manier opdaterings ontvang?
MM: - Ons beveel dit sterk aan. Dit los baie probleme vir ons op.
MCH: - Weereens wil ek beklemtoon dat die veranderinge wat nie die argitektuur raak nie en nie slotte aangaan nie, rye - hulle is modulêr, dit is in aparte modules. Selfs op hul eie met klein veranderinge, kan hulle redelik maklik in stand gehou word.
MM: - As jy belangstel in besonderhede, dan gebruik Clickhouse die sogenaamde geskiedenisbiblioteek. Dit is nie vasgemaak nie - dit is 'n kopie van Elastics-ondersteuning, dit wil sê dit is konfigureerbaar. Stemming verander net stembusse. Ons glo dat dit vir 'n lang tyd sal werk.
A: - Baie dankie. En sê vir my, is daar enige dokumentasie van die veranderinge wat gemaak is?
MM: – Dokumentasie is 'n pleister. Dit is duidelik dat met die bekendstelling van Clickhouse, met die bekendstelling van nuwe soorte pollers, nuwe konfigurasie-opsies verskyn. Die skakel van die laaste skyfie het 'n kort beskrywing van hoe om dit te gebruik.
Oor die vervanging van fping met nmap
A: - Hoe het jy dit uiteindelik gedoen? Kan jy spesifieke voorbeelde gee: het jy strappers en 'n eksterne skrif? Wat uiteindelik so baie gashere nagaan so vinnig? Hoe myn jy hierdie gashere? Moet nmap hulle op een of ander manier voer, hulle van iewers af kry, hulle insit, iets laat loop?
MM: - Koel. 'n Baie geldige vraag! Die punt is dit. Ons het die biblioteek (ICMP ping, 'n integrale deel van Zabbix) gewysig vir ICMP-kontroles, wat die aantal pakkies aandui - een (1), en die kode probeer nmap gebruik. Dit wil sê, dit is die interne werk van Zabbix, dit het die interne werk van die pinger geword. Gevolglik is geen sinchronisasie of gebruik van 'n trapper nodig nie. Dit is doelbewus gedoen om die stelsel ongeskonde te hou en nie om die twee basisstelsels te sinchroniseer nie: wat om na te gaan, op te laai deur die poller, en of ons oplaai stukkend is?.. Dit is baie makliker.
A: – Werk dit ook vir gevolmagtigdes?
MM: Ja, maar ons het nie nagegaan nie. Die stemkode is dieselfde in beide Zabbix en die bediener. Moet werk. Ek beklemtoon weereens: die werkverrigting van die stelsel is sodanig dat ons nie 'n volmag nodig het nie.
MCH: - Die korrekte antwoord op die vraag is: "Hoekom het jy 'n volmag met so 'n stelsel nodig?" Slegs as gevolg van NAT'a of om sommige deur 'n stadige kanaal te monitor ...
A: - En jy gebruik Zabbix as 'n allertor, as ek reg verstaan. Of het die grafika (waar is die argieflaag) na 'n ander stelsel gegaan, soos Grafana? Of gebruik jy nie hierdie funksie nie?
MM: – Ek sal weer beklemtoon: ons het volle integrasie gemaak. Ons gooi geskiedenis in Clickhouse, maar ons het terselfdertyd die php-frontend verander. Php-frontend gaan na Clickhouse en doen alle grafika van daar af. Terselfdertyd, om eerlik te wees, het ons 'n deel wat data bou in ander grafiese vertoonstelsels van dieselfde Clickhouse, van dieselfde Zabbix-data.
MCH: - In "Grafana" insluitend.
Hoe is die besluit geneem om hulpbronne toe te wys?
A: – Deel 'n bietjie van die binnekombuis. Hoe is die besluit geneem dat dit nodig is om hulpbronne vir 'n ernstige verwerking van die produk toe te wys? Dit is oor die algemeen sekere risiko's. En sê asseblief vir my, in die konteks van die feit dat jy nuwe weergawes gaan ondersteun: hoe regverdig hierdie besluit vanuit 'n bestuursoogpunt?
MM: – Ons het blykbaar nie die drama van die geskiedenis baie goed vertel nie. Ons het onsself in 'n situasie bevind waar iets gedoen moes word, en het eintlik met twee parallelle opdragte gegaan:
- Een was betrokke by die bekendstelling van 'n moniteringstelsel gebaseer op nuwe metodes: monitering as 'n diens, 'n standaard stel oopbronoplossings wat ons kombineer en dan probeer om die besigheidsproses te verander om met die nuwe moniteringstelsel te werk.
- Terselfdertyd het ons 'n entoesiastiese programmeerder gehad wat dit (oor homself) gedoen het. Dit het so gebeur dat hy gewen het.
A: – En wat is die grootte van die span?
MCH: Sy is voor jou.
A: - Dit is, soos altyd, 'n passievolle is nodig?
MM: - Ek weet nie wat 'n passievol is nie.
A: In hierdie geval blyk dit jy te wees. Baie dankie, jy is awesome.
MM: - Dankie.
Oor pleisters vir Zabbix
A: - Vir 'n stelsel wat 'n proxy gebruik (byvoorbeeld in sommige verspreide stelsels), is dit moontlik om aan te pas en te pleister, sê pollers, gevolmagtigdes en gedeeltelik die voorverwerker van Zabbix self; en hul interaksie? Is dit moontlik om bestaande ontwikkelings vir 'n stelsel met veelvuldige gevolmagtigdes te optimaliseer?
MM: - Ek weet dat die "Zabbix"-bediener saamgestel word met behulp van 'n instaanbediener (dit word saamgestel en die kode word verkry). Ons het dit nie in produksie getoets nie. Ek is nie seker hieroor nie, maar ek dink nie die voorverwerkerbestuurder word in die instaanbediener gebruik nie. Die taak van die instaanbediener is om 'n stel metrieke van Zabbix af te neem, dit te stort (dit teken ook die konfigurasie, plaaslike databasis aan) en gee dit terug aan die Zabbix-bediener. Die bediener self sal dan die voorverwerking doen wanneer dit dit ontvang.
Die belangstelling in gevolmagtigdes is verstaanbaar. Ons sal dit nagaan. Dit is 'n interessante onderwerp.
A: – Die idee was dit: as jy pollers kan pleister, kan jy hulle op 'n instaanbediener pleister en die interaksie met die bediener pleister, en die voorverwerker vir hierdie doeleindes net op die bediener aanpas.
MM: - Ek dink dit is selfs makliker. Jy neem die kode, pas 'n pleister toe en stel dit dan op soos jy nodig het - jy versamel instaanbedieners (byvoorbeeld met ODBC) en versprei die gelapte kode onder die stelsels. Waar nodig - versamel die proxy, waar nodig - die bediener.
A: - Boonop hoef u waarskynlik nie die proxy-oordrag na die bediener te pleister nie?
MCH: Nee, dit is standaard.
MM: - Trouens, een van die idees het nie geklink nie. Ons het nog altyd 'n balans gehou tussen die ontploffing van idees en die aantal veranderinge, gemak van ondersteuning.
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com