A következő HighLoad++ konferenciát 6. április 7-án és 2020-én tartják Szentpéterváron Részletek és jegyek . HighLoad++ Moszkva 2018. Csarnok „Moszkva”. november 9., 15:00. Tézisek és .
* Monitoring - online és elemzés.
* A ZABBIX platform alapvető korlátai.
* Megoldás az analitikai tárolás méretezéséhez.
* A ZABBIX szerver optimalizálása.
* UI optimalizálás.
* Tapasztalat a rendszer üzemeltetésében több mint 40 XNUMX NVPS terhelés mellett.
* Rövid következtetések.
Mihail Makurov (a továbbiakban – MM): - Sziasztok!
Maxim Chernetsov (a továbbiakban – MCH): - Jó napot!
MM: – Hadd mutassam be Maximot. Max tehetséges mérnök, a legjobb hálózatépítő, akit ismerek. A Maxim hálózatok és szolgáltatások, ezek fejlesztése és működtetése terén vesz részt.
MCH: – És szeretnék mesélni neked Mikhailról. Mikhail C fejlesztő. Több nagy terhelésű forgalomfeldolgozási megoldást írt cégünk számára. Az Urálban élünk és dolgozunk, a kemény férfiak Cseljabinszk városában, az Intersvyaz cégnél. Cégünk 16 városban egymillió ember számára nyújt internetes és kábeltelevíziós szolgáltatásokat.
MM: – És érdemes elmondani, hogy az Intersvyaz sokkal több, mint egy szolgáltató, hanem egy informatikai cég. Megoldásaink többségét informatikai részlegünk készíti.
és: a forgalmat feldolgozó szerverektől a call centerig és a mobilalkalmazásig. Az informatikai osztályon jelenleg körülbelül 80 ember dolgozik, nagyon-nagyon sokrétű kompetenciákkal.
A Zabbixról és építészetéről
MCH: – És most megpróbálok személyes rekordot dönteni, és egy percben elmondani, mi az a Zabbix (a továbbiakban: „Zabbix”).
A Zabbix vállalati szintű, készenléti felügyeleti rendszerként pozicionálja magát. Számos funkciója van, amelyek megkönnyítik az életet: fejlett eszkalációs szabályok, API az integrációhoz, csoportosításhoz és a gazdagépek és metrikák automatikus észleléséhez. A Zabbix rendelkezik úgynevezett skálázó eszközökkel - proxykkal. A Zabbix egy nyílt forráskódú rendszer.
Röviden az építészetről. Azt mondhatjuk, hogy három összetevőből áll:
- Szerver. C-ben írva. Meglehetősen bonyolult feldolgozással és információátvitellel a szálak között. Minden feldolgozás benne zajlik: a fogadástól az adatbázisba mentésig.
- Minden adat az adatbázisban tárolódik. A Zabbix támogatja a MySQL-t, a PostreSQL-t és az Oracle-t.
- A webes felület PHP nyelven íródott. A legtöbb rendszeren Apache szerverrel érkezik, de hatékonyabban működik az nginx + php kombinációval.
Ma egy történetet szeretnénk elmesélni a Zabbixhoz kapcsolódó cégünk életéből...
Egy történet az Intersvyaz cég életéből. Mi van és mire van szükségünk?
5 vagy 6 hónapja. Egy nappal munka után...
MCH: - Misha, szia! Örülök, hogy sikerült elkapnom – van egy beszélgetés. Ismét problémáink voltak a megfigyeléssel. Egy súlyos baleset során minden lassú volt, és nem volt információ a hálózat állapotáról. Sajnos nem ez az első eset, hogy ez történik. Szükségem van a segítségedre. Tegyük minden körülmények között működőképessé az ellenőrzésünket!
MM: - De előbb szinkronizáljunk. Pár éve nem néztem oda. Amennyire emlékszem, elhagytuk a Nagiost, és úgy 8 éve váltottunk Zabbix-ra. És most úgy tűnik, hogy van 6 nagy teljesítményű szerverünk és körülbelül egy tucat proxynk. Összekeverek valamit?
MCH: - Majdnem. 15 szerver, amelyek egy része virtuális gép. A legfontosabb dolog az, hogy nem abban a pillanatban ment meg minket, amikor a legnagyobb szükségünk van rá. Mint egy baleset - a szerverek lelassulnak, és nem látsz semmit. Megpróbáltuk optimalizálni a konfigurációt, de ez nem biztosította az optimális teljesítménynövekedést.
MM: - Ez egyértelmű. Néztél valamit, kiástál már valamit a diagnosztikából?
MCH: – Az első dolog, amivel foglalkozni kell, az az adatbázis. A MySQL folyamatosan betöltődik, új mérőszámokat tárol, és amikor a Zabbix elkezd generálni egy csomó eseményt, az adatbázis szó szerint néhány órára túlhajtásba kerül. A konfiguráció optimalizálásáról már meséltem, de szó szerint idén frissítették a hardvert: a szerverek több mint száz gigabájt memóriával és lemeztömbökkel rendelkeznek SSD RAID-en - nincs értelme hosszú távon lineárisan növelni. Mit csináljunk?
MM: - Ez egyértelmű. Általában a MySQL egy LTP adatbázis. Nyilvánvalóan már nem alkalmas a mi méretű metrikák archívumának tárolására. Találjuk ki.
MCH: - Gyerünk!
A Zabbix és a Clickhouse integrációja a hackathon eredményeként
Egy idő után érdekes adatokat kaptunk:
Adatbázisunk helyének nagy részét a metrikák archívuma foglalta el, és kevesebb mint 1%-át használtuk fel konfigurációra, sablonokra és beállításokra. Ekkor már több mint egy éve üzemeltettük a Clickhouse alapú Big data megoldást. A mozgás iránya nyilvánvaló volt számunkra. Tavaszi Hackathonunkon megírtam a Zabbix és a Clickhouse integrációját a szerverhez és a frontendhez. Abban az időben a Zabbix már támogatta az ElasticSearch-t, és úgy döntöttünk, hogy összehasonlítjuk őket.
A Clickhouse és az Elasticsearch összehasonlítása
MM: – Összehasonlításképpen ugyanazt a terhelést generáltuk, mint amit a Zabbix szerver biztosít, és megnéztük, hogyan viselkednek a rendszerek. Az adatokat 1000 soros kötegekben írtuk, CURL használatával. Előzetesen feltételeztük, hogy a Clickhouse hatékonyabb lesz a terhelési profilhoz, mint a Zabbix. Az eredmények még várakozásainkat is felülmúlták:
Ugyanezen tesztkörülmények között a Clickhouse háromszor több adatot írt le. Ugyanakkor mindkét rendszer nagyon hatékonyan (kis mennyiségű erőforrást) fogyasztott az adatok olvasásakor. Az Elastics azonban nagy mennyiségű processzort igényelt a rögzítéshez:
Összességében a Clickhouse jelentősen felülmúlta az Elastixot a processzorfogyasztás és a sebesség tekintetében. Ugyanakkor az adattömörítés miatt a Clickhouse 11-szer kevesebbet használ a merevlemezen, és körülbelül 30-szor kevesebb lemezműveletet hajt végre:
MCH: – Igen, a Clickhouse lemezalrendszerrel végzett munkája nagyon hatékonyan van megvalósítva. Hatalmas SATA lemezeket használhat adatbázisokhoz, és másodpercenként több százezer soros írási sebességet érhet el. A kész rendszer támogatja a felosztást, a replikációt, és nagyon könnyen konfigurálható. Több mint elégedettek vagyunk egész éves használatával.
Az erőforrások optimalizálása érdekében telepítheti a Clickhouse-t meglévő fő adatbázisa mellé, és ezáltal sok CPU-időt és lemezműveletet takaríthat meg. A mutatók archívumát áthelyeztük a meglévő Clickhouse-fürtökbe:
A fő MySQL adatbázist annyira tehermentesítettük, hogy egy gépen egyesíthettük a Zabbix szerverrel, és elhagytuk a MySQL dedikált szerverét.
Hogyan működik a szavazás a Zabbixben?
4 hónappal ezelőtt
MM: – Nos, elfelejthetjük a bázissal kapcsolatos problémákat?
MCH: - Az biztos! Egy másik probléma, amit meg kell oldanunk, a lassú adatgyűjtés. Most mind a 15 proxyszerverünk túlterhelt SNMP-vel és lekérdezési folyamatokkal. És nincs más lehetőség, mint új és új szerverek telepítése.
MM: - Nagy. De először mondja el, hogyan működik a szavazás a Zabbixban?
MCH: – Röviden: 20 féle mérőszám létezik, és tucatnyi módja van ezek megszerzésének. A Zabbix vagy „kérés-válasz” módban gyűjthet adatokat, vagy várhat az új adatokra a „Trapper Interface”-en keresztül.
Érdemes megjegyezni, hogy az eredeti Zabbixben ez a módszer (Trapper) a leggyorsabb.
Vannak proxy szerverek a terheléselosztáshoz:
A proxy-k ugyanazokat a gyűjtési funkciókat tudják ellátni, mint a Zabbix szerver, feladatokat fogadnak tőle, és a Trapper felületén keresztül küldik el az összegyűjtött metrikákat. Ez a hivatalosan javasolt módja a terhelés elosztásának. A proxyk hasznosak a NAT-on vagy lassú csatornán keresztül működő távoli infrastruktúra figyelésére is:
MM: – Az építészettel minden világos. Meg kell nézni a forrásokat...
Pár nappal később
Az nmap fping győzelmének története
MM: – Azt hiszem, kiástam valamit.
MCH: - Mondd el!
MM: – Felfedeztem, hogy az elérhetőség ellenőrzésekor a Zabbix egyszerre legfeljebb 128 gazdagépet ellenőriz. Megpróbáltam ezt a számot 500-ra növelni, és eltávolítani a csomagok közötti intervallumot a pingben (ping) - ez megduplázta a teljesítményt. De nagyobb számokat szeretnék.
MCH: – A praxisomban időnként több ezer host elérhetőségét kell ellenőriznem, és ehhez még nem láttam nmap-nél gyorsabbat. Biztos vagyok benne, hogy ez a leggyorsabb módja. Próbáljuk ki! Jelentősen növelnünk kell a gazdagépek számát iterációnként.
MM: – Több mint ötszázat ellenőriz? 600?
MCH: - Legalább pár ezer.
MM: - RENDBEN. A legfontosabb dolog, amit el akartam mondani, az az, hogy azt tapasztaltam, hogy a legtöbb szavazás a Zabbixben szinkronban történik. Mindenképpen aszinkron módra kell váltanunk. Ekkor drámaian növelhetjük a lekérdezők által gyűjtött mérőszámok számát, különösen, ha növeljük az iterációnkénti metrikák számát.
MCH: - Nagy! És mikor?
MM: – Szokás szerint tegnap.
MCH: – Összehasonlítottuk az fping és az nmap mindkét verzióját:
Nagyszámú gazdagépen az nmap várhatóan akár ötször hatékonyabb lesz. Mivel az nmap csak a rendelkezésre állást és a válaszidőt ellenőrzi, a veszteségek számítását áthelyeztük a triggerekre, és jelentősen csökkentettük a rendelkezésre állás ellenőrzési időközeit. Azt találtuk, hogy az nmap optimális száma iterációnként körülbelül 4 ezer. Az Nmap lehetővé tette számunkra, hogy háromszorosára csökkentsük a CPU rendelkezésre állás-ellenőrzésének költségeit, és csökkentsük az intervallumot 120 másodpercről 10-re.
Szavazás optimalizálás
MM: „Aztán elkezdtünk pollereket csinálni. Elsősorban az SNMP-felderítés és az ágensek érdekeltek bennünket. A Zabbixban a lekérdezések szinkronban zajlanak, és speciális intézkedéseket tettek a rendszer hatékonyságának növelésére. Szinkron módban a gazdagép elérhetetlensége jelentős lekérdezési romlást okoz. Van egy egész állapotrendszer, vannak speciális folyamatok - az úgynevezett elérhetetlen lekérdezők, amelyek csak elérhetetlen gazdagépekkel működnek:
Ez egy kommentár, amely bemutatja az állapotmátrixot, az átmenetek rendszerének minden összetettségét, amely szükséges ahhoz, hogy a rendszer hatékony maradjon. Ezenkívül maga a szinkron lekérdezés meglehetősen lassú:
Emiatt több tucat proxyn lévő több ezer poller folyam nem tudta összegyűjteni számunkra a szükséges mennyiségű adatot. Az aszinkron implementáció nemcsak a szálak számával kapcsolatos problémákat oldotta meg, hanem jelentősen leegyszerűsítette a nem elérhető gazdagépek állapotrendszerét is, mivel bármely lekérdezési iteráció során ellenőrzött szám esetén a maximális várakozási idő 1 időtúllépés volt:
Ezenkívül módosítottuk és javítottuk az SNMP-kérések lekérdezési rendszerét. Az a tény, hogy a legtöbb ember nem tud egyszerre több SNMP-kérésre válaszolni. Ezért készítettünk egy hibrid módot, amikor ugyanazon gazdagép SNMP lekérdezése aszinkron módon történik:
Ez a teljes host csomagra vonatkozik. Ez a mód végül nem lassabb, mint egy teljesen aszinkron, mivel másfélszáz SNMP-érték lekérdezése még mindig sokkal gyorsabb, mint 1 időtúllépés.
Kísérleteink kimutatták, hogy az optimális kérések száma egy iterációban körülbelül 8 ezer SNMP lekérdezéssel. Összességében az aszinkron módra való áttérés 200-szoros, több százszoros felgyorsítását tette lehetővé számunkra.
MCH: – Az így létrejött lekérdezési optimalizálás azt mutatta, hogy nem csak az összes proxytól szabadulhatunk meg, hanem számos ellenőrzés intervallumát is csökkentjük, és a proxykra már nem lesz szükség a terhelés megosztására.
Körülbelül három hónapja
Változtassa meg az architektúrát - növelje a terhelést!
MM: - Nos, Max, ideje termelékenynek lenni? Szükségem van egy erős szerverre és egy jó mérnökre.
MCH: - Oké, tervezzük meg. Legfőbb ideje elmozdulni a másodpercenkénti 5 ezer metrika holtpontjáról.
Reggel a frissítés után
MCH: - Misha, frissítettük magunkat, de reggelre visszagurultunk... Képzeld, milyen sebességet sikerült elérnünk?
MM: – maximum 20 ezer.
MCH: - Igen, 25! Sajnos ott tartunk, ahol elkezdtük.
MM: - Miért? Csináltál valami diagnosztikát?
MCH: - Igen, persze! Itt van például egy érdekes felső:
MM: - Nézzük. Úgy látom, rengeteg szavazási szálat kipróbáltunk:
De ugyanakkor még a felére sem tudták újrahasznosítani a rendszert:
És az általános teljesítmény meglehetősen kicsi, körülbelül 4 ezer metrika másodpercenként:
Van még valami más?
MCH: – Igen, az egyik szavazó egy része:
MM: – Itt jól látható, hogy a szavazás „szemaforokra” vár. Ezek a zárak:
MCH: - Nem világos.
MM: – Nézd, ez hasonlít egy olyan helyzethez, amikor egy csomó szál olyan erőforrásokkal próbál dolgozni, amelyekkel egyszerre csak egy tud dolgozni. Ezután csak annyit tehetnek, hogy megosztják ezt az erőforrást idővel:
És az ilyen erőforrásokkal való munka teljes teljesítményét egy mag sebessége korlátozza:
A probléma megoldásának két módja van.
Frissítse a gép hardverét, váltson gyorsabb magokra:
Vagy módosítsa az architektúrát, és ezzel egyidejűleg módosítsa a terhelést:
MCH: – Egyébként a tesztgépen kevesebb magot fogunk használni, mint a harciban, de magonként 1,5-szer gyorsabbak a frekvenciájuk!
MM: - Egyértelmű? Meg kell nézni a szerver kódját.
Adatútvonal a Zabbix szerveren
MCH: – Hogy kitaláljuk, elkezdtük elemezni, hogyan történik az adatok átvitele a Zabbix szerveren belül:
Klassz kép, ugye? Nézzük végig lépésről lépésre, hogy többé-kevésbé egyértelmű legyen. Vannak olyan szálak és szolgáltatások, amelyek felelősek az adatgyűjtésért:
Az összegyűjtött metrikákat egy socketen keresztül továbbítják az előfeldolgozó menedzserhez, ahol egy sorba kerülnek:
Az „előfeldolgozó menedzser” adatokat továbbít dolgozóinak, akik végrehajtják az előfeldolgozási utasításokat, és ugyanazon a socketen keresztül küldik vissza azokat:
Ezt követően az előfeldolgozó kezelő eltárolja őket az előzmények gyorsítótárában:
Innen viszik őket a történelem-süllyesztők, akik elég sok funkciót látnak el: például triggereket számítanak ki, kitöltik az érték-gyorsítótárat, és ami a legfontosabb, mérőszámokat mentenek az előzménytárba. Általában véve a folyamat összetett és nagyon zavaros.
MM: – Az első dolog, amit láttunk, az volt, hogy a legtöbb szál versenyez az úgynevezett „konfigurációs gyorsítótárért” (az a memóriaterület, ahol az összes szerverkonfigurációt tárolják). Az adatgyűjtésért felelős szálak különösen sokat blokkolnak:
...mivel a konfiguráció nem csak a mérőszámokat tárolja a paramétereikkel együtt, hanem azokat a sorokat is, amelyekből a lekérdezők információt kapnak a következő lépésekről. Ha sok lekérdező van, és az egyik blokkolja a konfigurációt, a többiek a kérésekre várnak:
A szavazóknak nem szabad összeütközésbe kerülniük
Ezért az első dolgunk az volt, hogy a sort 4 részre osztottuk, és lehetővé tesszük, hogy a lekérdezők biztonságos körülmények között blokkolják ezeket a sorokat, ezeket a részeket egyszerre:
Ezzel megszűnt a verseny a konfigurációs gyorsítótárért, és a lekérdezők sebessége jelentősen megnőtt. De aztán szembesültünk azzal a ténnyel, hogy az előfeldolgozó menedzser elkezdte felhalmozni a feladatok sorát:
Az előfeldolgozó menedzsernek képesnek kell lennie a prioritások meghatározására
Ez olyan esetekben történt, amikor hiányzott a teljesítménye. Ezután nem tudott mást tenni, mint kéréseket gyűjteni az adatgyűjtési folyamatokból, és összeadni a pufferüket, amíg fel nem emésztette az összes memóriát és összeomlott:
A probléma megoldása érdekében hozzáadtunk egy második aljzatot, amelyet kifejezetten a dolgozóknak szántak:
Így az előfeldolgozó menedzsernek lehetősége volt priorizálni a munkáját, és ha a puffer növekszik, a feladat az eltávolítás lelassítása, lehetőséget adva a dolgozóknak, hogy ezt a puffert vegyék fel:
Aztán rájöttünk, hogy a lassulás egyik oka maguk a dolgozók, hiszen egy olyan erőforrásért versenyeztek, amely a munkájuk szempontjából teljesen lényegtelen. Ezt a problémát hibajavításként dokumentáltuk, és a Zabbix új verzióiban már megoldódott:
Növeljük az aljzatok számát - megkapjuk az eredményt
Továbbá maga az előfeldolgozó menedzser szűk keresztmetszet lett, mivel ez egy szál. Az alapsebességen nyugodott, és a maximális sebesség körülbelül 70 ezer metrika másodpercenként:
Ezért készítettünk négy, négy készlet aljzattal, munkásokat:
És ez lehetővé tette, hogy a sebességet körülbelül 130 ezer mérőszámra növeljük:
A növekedés nem-linearitása azzal magyarázható, hogy megjelent a verseny a történelem gyorsítótárért. 4 előfeldolgozó menedzser és történelemsüllyesztő versengett érte. Ekkor körülbelül 130 ezer metrikát kaptunk másodpercenként a tesztgépen, amelyet a processzor körülbelül 95%-a használt ki:
Körülbelül 2,5 hónapja
Az snmp-közösség elutasítása másfélszeresére növelte az NVP-ket
MM: – Max, új tesztautó kell! Már nem férünk bele a jelenlegibe.
MCH: - Mi van most?
MM: – Most – 130 XNUMX NVP és egy polcra kész processzor.
MCH: - Azta! Menő! Várj, két kérdésem lenne. Számításaim szerint másodpercenként 15-20 ezer metrika körül van az igényünk. Miért van szükségünk többre?
MM: – Be akarom fejezni a munkát. Szeretném látni, hogy mennyit tudunk kipréselni ebből a rendszerből.
MCH: - De…
MM: – De az üzleti életben hiábavaló.
MCH: - Ez egyértelmű. És a második kérdés: tudjuk-e önerőből, fejlesztő segítsége nélkül támogatni azt, amink van?
MM: - Nem hiszem. A konfigurációs gyorsítótár működésének megváltoztatása problémát jelent. A legtöbb szál változásait érinti, és meglehetősen nehéz fenntartani. Valószínűleg nagyon nehéz lesz fenntartani.
MCH: – Akkor valami alternatívára van szükségünk.
MM: - Van ilyen lehetőség. Áttérhetünk gyors magokra, miközben elhagyjuk az új zárrendszert. Továbbra is 60-80 ezres mérőszámú teljesítményt kapunk majd. Ugyanakkor a kód összes többi részét elhagyhatjuk. A Clickhouse és az aszinkron lekérdezés működni fog. És könnyű lesz karbantartani.
MCH: - Elképesztő! Azt javaslom, itt álljunk meg.
A szerveroldal optimalizálása után végre be tudtuk indítani az új kódot a termelésbe. Elhagytunk néhány változtatástól, és a gyors magokkal rendelkező gépre váltottunk, és minimalizáltuk a kódváltások számát. A konfigurációt is egyszerűsítettük, és lehetőség szerint kiküszöböltük a makrókat az adatelemekből, mivel ezek további zárolást vezetnek be.
Például a dokumentációban és példákban gyakran előforduló snmp-community makró elhagyása esetünkben lehetővé tette az NVP-k további körülbelül másfélszeres gyorsítását.
Két nap gyártás után
Az eseményelőzmények előugró ablakainak eltávolítása
MCH: – Misha, két napja használjuk a rendszert, és minden működik. De csak akkor, ha minden működik! A hálózat meglehetősen nagy részének átadásával terveztük a munkát, és ismét a kezünkkel ellenőriztük, hogy mi ment fel és mi nem.
MM: - Nem lehet! Mindent 10-szer ellenőriztünk. A szerver a teljes hálózati elérhetetlenséget is azonnal kezeli.
MCH: - Igen, mindent értek: szerver, adatbázis, top, austat, naplók - minden gyors... De nézzük a webes felületet, és ott van a szerveren egy processzor „a polcon” és ez:
MM: - Ez egyértelmű. Nézzük a webet. Azt találtuk, hogy egy olyan helyzetben, amikor nagyszámú aktív incidens volt, a legtöbb élő modul nagyon lassan kezdett működni:
Ennek oka az eseménytörténet előugró ablakok generálása volt, amelyek a lista minden eleméhez jönnek létre. Ezért felhagytunk ezeknek az ablakoknak a generálásával (5 sort kommentáltunk a kódban), és ez megoldotta a problémáinkat.
A widgetek betöltési ideje teljesen elérhetetlen állapotban is több percről a számunkra elfogadható 10-15 másodpercre csökkent, az előzmények pedig továbbra is megtekinthetők az időpontra kattintva:
Munka után. 2 hónapja
MCH: - Misha, elmész? Beszélnünk kell.
MM: - Nem állt szándékomban. Megint valami Zabbix-szal?
MCH: - Nem, nyugi! Csak azt akartam mondani: minden működik, köszönöm! Megittam egy sört.
A Zabbix hatékony
A Zabbix egy meglehetősen univerzális és gazdag rendszer és funkció. Használható kisméretű telepítésekhez, de az igények növekedésével optimalizálni kell. A mutatók nagy archívumának tárolásához használjon megfelelő tárolót:
- használhat beépített eszközöket az Elasticsearch-el való integráció vagy az előzmények szövegfájlokba való feltöltése formájában (a XNUMX-es verziótól elérhető);
- Kihasználhatja tapasztalatainkat és a Clickhouse-szal való integrációnkat.
A metrikák gyűjtésének sebességének drámai növelése érdekében aszinkron módszerekkel gyűjtse össze azokat, és továbbítsa a trapper interfészen keresztül a Zabbix szerverre; vagy patch segítségével aszinkronizálhatja a Zabbix pollereket.
A Zabbix C-ben van írva, és elég hatékony. Számos építészeti szűk keresztmetszet megoldása lehetővé teszi a teljesítmény további növelését és tapasztalataink szerint több mint 100 ezer metrika megszerzését egy egyprocesszoros gépen.
Ugyanaz a Zabbix tapasz
MM: – Szeretnék hozzátenni néhány pontot. A teljes aktuális jelentés, minden teszt, szám az általunk használt konfigurációhoz tartozik. Most körülbelül 20 ezer metrikát veszünk át belőle másodpercenként. Ha megpróbálja megérteni, hogy ez működik-e az Ön számára, összehasonlíthatja. A ma megbeszéltekről patch formájában felkerül a GitHubra:
A patch a következőket tartalmazza:
- teljes integráció a Clickhouse-szal (Zabbix szerver és frontend egyaránt);
- problémák megoldása az előfeldolgozó menedzserrel;
- aszinkron lekérdezés.
A javítás az összes 4-es verzióval kompatibilis, beleértve az lts-t is. Valószínűleg minimális változtatásokkal működik a 3.4-es verzión.
Köszönöm a figyelmet.
kérdések
Közönség kérdése (továbbiakban – A): – Jó napot! Kérem, mondja meg, tervez-e intenzív interakciót a Zabbix csapatával vagy velük Önnel, hogy ez ne patch legyen, hanem a Zabbix normális viselkedése?
MM: – Igen, bizonyos változtatásokat mindenképpen vállalunk. Valami történni fog, valami megmarad a foltban.
és: – Köszönöm szépen a kiváló beszámolót! Kérem, mondja meg, hogy a javítás telepítése után a Zabbix támogatása megmarad, és hogyan lehet folytatni a frissítést a magasabb verziókra? Lehetséges lesz a Zabbix frissítése a javítás után 4.2-re, 5.0-ra?
MM: - A támogatásról nem tudok mit mondani. Ha én lennék a Zabbix technikai támogatása, valószínűleg nemet mondanék, mert ez valaki más kódja. Ami a 4.2-es kódbázist illeti, az álláspontunk a következő: „Az idővel haladunk, és frissítjük magunkat a következő verziónál.” Ezért egy ideig javítást teszünk közzé a frissített verziókhoz. A jelentésben már elmondtam: a verziók változásainak száma még mindig meglehetősen kicsi. Azt hiszem, az átállás 3.4-ről 4-re körülbelül 15 percig tartott, valami megváltozott, de nem túl fontos.
és: – Tehát azt tervezi, hogy támogatja a javítást, és biztonságosan telepítheti éles üzemben, és a jövőben valamilyen módon frissítéseket kaphat?
MM: – Erősen ajánljuk. Ez sok problémát megold számunkra.
MCH: – Ezúton is szeretném felhívni a figyelmet arra, hogy azok a változtatások, amelyek nem érintik az architektúrát és nem érintik a blokkolást vagy a várakozási sorokat, modulárisak, külön modulokban vannak. Még kisebb változtatásokkal is könnyedén karbantarthatja őket.
MM: – Ha érdekelnek a részletek, akkor a „Clickhouse” az úgynevezett történelemkönyvtárat használja. Le van kötve - ez az Elastics támogatás másolata, azaz konfigurálható. A szavazás csak a szavazókat változtatja meg. Hisszük, hogy ez még sokáig működni fog.
és: - Nagyon köszönöm. Mondja, van valami dokumentáció a változtatásokról?
MM: – A dokumentáció egy folt. Nyilvánvalóan a Clickhouse bevezetésével, az új típusú pollerek bevezetésével új konfigurációs lehetőségek merülnek fel. Az utolsó dián található link rövid leírást tartalmaz a használatáról.
Az fping lecseréléséről nmap-re
és: – Hogyan valósította meg ezt végül? Tudsz konkrét példákat mondani: van pántolód és külső scripted? Mi az, hogy ilyen nagyszámú házigazdát ilyen gyorsan ellenőriznek? Hogyan bányászod ezeket a házigazdákat? Be kell őket táplálni valahogy az nmap-be, be kell szerezni valahonnan, be kell rakni, futtatni valamit?..
MM: - Menő. Nagyon helyes kérdés! A lényeg ez. Módosítottuk a könyvtárat (ICMP ping, a Zabbix része) az ICMP ellenőrzésekhez, amelyek jelzik a csomagok számát - egy (1), és a kód megpróbálja használni az nmap-et. Vagyis ez a Zabbix belső munkája, ami a pinger belső munkája lett. Ennek megfelelően nincs szükség szinkronizálásra vagy trapper használatára. Ez szándékosan történt, hogy a rendszer sértetlen maradjon, és ne kelljen két adatbázis-rendszer szinkronizálásával foglalkozni: mit kell ellenőrizni, feltölteni a polleren keresztül, és megromlott a feltöltésünk?.. Ez sokkal egyszerűbb.
és: – Proxy esetén is működik?
MM: - Igen, de nem ellenőriztük. A lekérdezési kód ugyanaz a Zabbixban és a szerveren. Működnie kellene. Még egyszer hangsúlyozom: a rendszer teljesítménye olyan, hogy nincs szükségünk proxyra.
MCH: – A helyes válasz a kérdésre: „Miért van szükség ilyen rendszerű proxyra?” Csak a NAT miatt vagy valami lassú csatornán keresztüli monitorozás miatt...
és: – És a Zabbixot használod allerátornak, ha jól értem. Vagy a grafikája (ahol az archív réteg található) átkerült egy másik rendszerre, például a Grafana-ra? Vagy nem használja ezt a funkciót?
MM: – Még egyszer hangsúlyozom: teljes integrációt értünk el. Történelmet öntünk a Clickhouse-ba, ugyanakkor megváltoztattuk a php frontendet. A Php frontend a Clickhouse-ba megy, és onnan csinálja az összes grafikát. Ugyanakkor, hogy őszinte legyek, van egy részünk, amely ugyanabból a Clickhouse-ból, ugyanazokból a Zabbix adatokból épít adatokat más grafikus megjelenítő rendszerekben.
MCH: – A „Grafan”-ban is.
Hogyan születtek a döntések az erőforrások elosztásáról?
és: – Oszd meg egy kicsit a belső konyhádból. Hogyan született meg az a döntés, hogy a termék komoly feldolgozásához forrásokat kell elkülöníteni? Ezek általában bizonyos kockázatok. És kérem, annak kapcsán, hogy támogatni fogja az új verziókat, mondja meg nekem: hogyan indokolja ezt a döntést vezetési szempontból?
MM: – Úgy látszik, nem mondtuk el jól a történelem drámáját. Olyan helyzetbe kerültünk, hogy tenni kellett valamit, és lényegében két párhuzamos csapattal mentünk:
- Az egyik egy felügyeleti rendszer elindítása új módszerekkel: a monitorozás szolgáltatásként, a nyílt forráskódú megoldások szabványos készlete, amelyeket kombinálunk, majd megpróbálunk megváltoztatni az üzleti folyamatot annak érdekében, hogy az új felügyeleti rendszerrel működjünk.
- Ugyanakkor volt egy lelkes programozónk, aki ezt csinálta (magáról). Így esett, hogy nyert.
és: – És mekkora a csapat?
MCH: - Ő előtted van.
és: – Szóval, mint mindig, szüksége van egy szenvedélyesre?
MM: - Nem tudom, mi az a szenvedélyes.
és: - Ebben az esetben úgy tűnik, te. Köszönöm szépen, szuper vagy.
MM: - Kösz.
A Zabbix javításairól
és: – Egy proxyt használó rendszernél (például egyes elosztott rendszerekben) lehetséges-e adaptálni és foltozni mondjuk a pollereket, proxykat és részben magának a Zabbix előfeldolgozóját; és interakciójuk? Lehetséges-e optimalizálni a meglévő fejlesztéseket több proxyval rendelkező rendszerre?
MM: – Úgy tudom, hogy a Zabbix szervert proxy segítségével állítják össze (a kódot lefordítják és megkapják). Ezt nem teszteltük gyártásban. Nem vagyok biztos ebben, de szerintem a proxyban nincs használva az előfeldolgozó menedzser. A proxy feladata, hogy a Zabbix-ból átvesz egy metrikát, összevonja azokat (rögzíti a konfigurációt, a helyi adatbázist is), és visszaadja a Zabbix szervernek. A szerver ezután maga végzi el az előfeldolgozást, amikor megkapja.
A proxy iránti érdeklődés érthető. Megnézzük. Ez egy érdekes téma.
és: – Az ötlet a következő volt: ha be tudod patchelni a pollereket, akkor a proxy-n is javíthatod őket, és javíthatod a szerverrel való interakciót, és az előfeldolgozót csak a szerveren adaptálhatod erre a célra.
MM: - Szerintem ez még egyszerűbb. Elveszi a kódot, alkalmaz egy javítást, majd a szükséges módon konfigurálja – proxyszervereket gyűjt össze (például ODBC-vel), és elosztja a javított kódot a rendszerek között. Ahol szükséges - gyűjtsön proxyt, ahol szükséges - egy szervert.
és: – Valószínűleg nem kell pluszban javítania a proxy átvitelt a szerverhez?
MCH: - Nem, ez szabvány.
MM: – Valójában az egyik ötlet nem hangzott el. Mindig megőriztük az egyensúlyt az ötletek robbanása és a változtatások mennyisége és a támogatás egyszerűsége között.
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com