Järgmine HighLoad++ konverents toimub 6. ja 7. aprillil 2020 Peterburis Üksikasjad ja piletid . HighLoad++ Moskva 2018. Hall “Moskva”. 9. november kell 15. Teesid ja .
* Jälgimine – online ja analüüs.
* ZABBIXi platvormi põhipiirangud.
* Lahendus analüütikasalvestuse skaleerimiseks.
* ZABBIX serveri optimeerimine.
* UI optimeerimine.
* Kogemus süsteemi kasutamisel üle 40 XNUMX NVPS koormuse korral.
* Lühikesed järeldused.
Mihhail Makurov (edaspidi – MM): - Tere kõigile!
Maxim Tšernetsov (edaspidi – MCH): - Tere päevast!
MM: – Lubage mul tutvustada Maximit. Max on andekas insener, parim võrgumees, keda tean. Maxim tegeleb võrkude ja teenuste, nende arendamise ja toimimisega.
MCH: – Ja ma tahaksin teile rääkida Mihhailist. Mihhail on C-arendaja. Ta kirjutas meie ettevõttele mitu suure koormusega liikluse töötlemise lahendust. Elame ja töötame Uuralites, karmide meeste linnas Tšeljabinskis, ettevõttes Intersvyaz. Meie ettevõte pakub Interneti- ja kaabeltelevisiooniteenuseid miljonile inimesele 16 linnas.
MM: – Ja tasub öelda, et Intersvyaz on palju enamat kui lihtsalt pakkuja, see on IT-ettevõte. Enamik meie lahendusi on tehtud meie IT-osakonna poolt.
A: liiklust töötlevatest serveritest kõnekeskusesse ja mobiilirakendusse. IT-osakonnas töötab nüüd umbes 80 väga-väga mitmekülgse kompetentsiga inimest.
Zabbixist ja selle arhitektuurist
MCH: - Ja nüüd proovin püstitada isikliku rekordi ja ühe minutiga öelda, mis on Zabbix (edaspidi "Zabbix").
Zabbix positsioneerib end ettevõtte tasemel valmis seiresüsteemina. Sellel on palju funktsioone, mis muudavad elu lihtsamaks: täpsemad eskalatsioonireeglid, API integreerimiseks, hostide ja mõõdikute rühmitamiseks ja automaatseks tuvastamiseks. Zabbixil on nn skaleerimisvahendid – puhverserverid. Zabbix on avatud lähtekoodiga süsteem.
Lühidalt arhitektuurist. Võime öelda, et see koosneb kolmest komponendist:
- Server. Kirjutatud C-s. Üsna keerulise töötlemise ja teabe edastamisega lõimede vahel. Selles toimub kogu töötlemine: vastuvõtmisest kuni andmebaasi salvestamiseni.
- Kõik andmed salvestatakse andmebaasi. Zabbix toetab MySQL-i, PostreSQL-i ja Oracle'i.
- Veebiliides on kirjutatud PHP-s. Enamikus süsteemides on sellega kaasas Apache server, kuid see töötab tõhusamalt koos nginx + php-ga.
Täna räägime ühe loo meie Zabbixiga seotud ettevõtte elust...
Lugu ettevõtte Intersvyaz elust. Mis meil on ja mida me vajame?
5 või 6 kuud tagasi. Üks päev pärast tööd...
MCH: - Misha, tere! Mul on hea meel, et mul õnnestus sind tabada – vestlus käib. Jälle oli meil probleeme jälgimisega. Suure õnnetuse ajal oli kõik aeglane ja võrgu seisu kohta infot polnud. Kahjuks ei juhtu see esimest korda. Ma vajan su abi. Paneme oma monitooringu toimima igal juhul!
MM: - Aga kõigepealt sünkroniseerime. Ma pole sinna paar aastat vaadanud. Minu mäletamist mööda jätsime Nagiose maha ja läksime umbes 8 aastat tagasi Zabbixile üle. Ja nüüd tundub, et meil on 6 võimsat serverit ja kümmekond puhverserverit. Kas ma ajan midagi segamini?
MCH: - Peaaegu. 15 serverit, millest osa on virtuaalmasinad. Kõige tähtsam on see, et see ei päästaks meid hetkel, mil me seda kõige rohkem vajame. Nagu õnnetus – serverid aeglustuvad ja te ei näe midagi. Püüdsime konfiguratsiooni optimeerida, kuid see ei andnud optimaalset jõudluse kasvu.
MM: - See on selge. Vaatasid midagi, kaevasid juba diagnostikast midagi välja?
MCH: – Esimene asi, millega peate tegelema, on andmebaas. MySQL-i laaditakse pidevalt, salvestades uusi mõõdikuid ja kui Zabbix hakkab genereerima hunnikut sündmusi, läheb andmebaas sõna otseses mõttes mõneks tunniks ülekäigurajale. Rääkisin teile juba konfiguratsiooni optimeerimisest, kuid sõna otseses mõttes uuendasid nad sel aastal riistvara: serveritel on üle saja gigabaidi mälu ja kettamassiivid SSD RAID-idel – seda pole mõtet pikemas perspektiivis lineaarselt kasvatada. Mida me siis teeme?
MM: - See on selge. Üldiselt on MySQL LTP andmebaas. Ilmselt ei sobi see enam meie suuruse mõõdikute arhiivi hoidmiseks. Selgitame välja.
MCH: - Lähme!
Zabbixi ja Clickhouse'i integreerimine häkatoni tulemusena
Mõne aja pärast saime huvitavaid andmeid:
Suurema osa meie andmebaasis olevast ruumist hõivas mõõdikute arhiiv ja vähem kui 1% kasutati konfigureerimiseks, mallideks ja säteteks. Selleks ajaks olime Clickhouse’il põhinevat suurandmete lahendust opereerinud juba üle aasta. Liikumissuund oli meile selge. Meie kevadisel Hackathonil kirjutasin Zabbixi integreerimise Clickhouse'iga serveri ja kasutajaliidese jaoks. Sel ajal oli Zabbixil juba ElasticSearchi tugi ja otsustasime neid võrrelda.
Clickhouse'i ja Elasticsearchi võrdlus
MM: – Võrdluseks genereerisime sama koormuse, mida pakub Zabbixi server, ja vaatasime, kuidas süsteemid käituksid. Kirjutasime andmed 1000-realiste partiidena, kasutades CURL-i. Eeldasime, et Clickhouse on Zabbixi koormusprofiili jaoks tõhusam. Tulemused ületasid isegi meie ootusi:
Samades katsetingimustes kirjutas Clickhouse kolm korda rohkem andmeid. Samas tarbisid mõlemad süsteemid andmete lugemisel väga efektiivselt (väike ressurssi). Kuid Elastics nõudis salvestamisel palju protsessorit:
Kokkuvõttes oli Clickhouse protsessorikulu ja kiiruse poolest Elastixist oluliselt parem. Samal ajal kasutab Clickhouse andmete tihendamise tõttu kõvakettal 11 korda vähem ja teeb umbes 30 korda vähem kettatoiminguid:
MCH: - Jah, Clickhouse'i töö ketta alamsüsteemiga on rakendatud väga tõhusalt. Saate kasutada andmebaaside jaoks tohutuid SATA-kettaid ja saada kirjutuskiiruseks sadu tuhandeid ridu sekundis. Kastivalmis süsteem toetab jagamist, replikatsiooni ja seda on väga lihtne konfigureerida. Oleme aastaringse kasutamisega enam kui rahul.
Ressursside optimeerimiseks võite installida Clickhouse'i oma olemasoleva põhiandmebaasi kõrvale ja säästa seeläbi palju protsessori aega ja kettatoiminguid. Oleme viinud mõõdikute arhiivi olemasolevatesse Clickhouse klastritesse:
Me vabastasime MySQL-i põhiandmebaasi nii palju, et saime selle ühendada ühes masinas Zabbixi serveriga ja loobuda MySQL-i jaoks mõeldud serverist.
Kuidas küsitlus Zabbixis töötab?
4 kuud tagasi
MM: – Kas me võime unustada probleemid baasiga?
MCH: - See on kindel! Teine probleem, mida peame lahendama, on aeglane andmete kogumine. Nüüd on kõik meie 15 puhverserverit SNMP ja küsitlusprotsessidega üle koormatud. Ja pole muud võimalust kui uusi ja uusi servereid installida.
MM: - Suurepärane. Aga kõigepealt rääkige meile, kuidas küsitlus Zabbixis töötab?
MCH: – Lühidalt, mõõdikuid on 20 tüüpi ja nende hankimiseks tosin võimalust. Zabbix saab andmeid koguda kas režiimis "päring-vastus" või oodata uusi andmeid "Trapper Interface" kaudu.
Väärib märkimist, et algses Zabbixis on see meetod (Trapper) kiireim.
Koormuse jaotamiseks on puhverserverid:
Puhverserverid saavad täita samu kogumisfunktsioone kui Zabbixi server, võttes sellelt ülesandeid vastu ja saates kogutud mõõdikuid Trapperi liidese kaudu. See on ametlikult soovitatav viis koormuse jaotamiseks. Puhverserverid on kasulikud ka NAT-i või aeglase kanali kaudu töötava kauginfrastruktuuri jälgimiseks:
MM: – Arhitektuuriga on kõik selge. Peame vaatama allikaid...
Paar päeva hiljem
Lugu sellest, kuidas nmap fping võitis
MM: "Ma arvan, et kaevasin midagi välja."
MCH: - Ütle mulle!
MM: – Avastasin, et saadavuse kontrollimisel kontrollib Zabbix korraga maksimaalselt 128 hosti. Proovisin seda arvu suurendada 500-ni ja eemaldada nende pingist pakettidevahelise intervalli (ping) – see kahekordistas jõudlust. Aga tahaks suuremaid numbreid.
MCH: - Oma praktikas pean mõnikord kontrollima tuhandete hostide saadavust ja ma pole kunagi näinud midagi kiiremat kui nmap. Olen kindel, et see on kiireim viis. Proovime seda! Peame märkimisväärselt suurendama hostide arvu iteratsiooni kohta.
MM: – Kontrollige rohkem kui viissada? 600?
MCH: - Vähemalt paar tuhat.
MM: - OKEI. Kõige olulisem asi, mida tahtsin öelda, on see, et avastasin, et enamik küsitlusi Zabbixis tehakse sünkroonselt. Peame selle kindlasti asünkroonrežiimi muutma. Siis saame järsult suurendada küsitlejate kogutud mõõdikute arvu, eriti kui suurendame mõõdikute arvu iteratsiooni kohta.
MCH: - Suurepärane! Ja millal?
MM: – Nagu tavaliselt, eile.
MCH: - Võrdlesime fpingi ja nmapi mõlemat versiooni:
Paljude hostide puhul eeldati, et nmap on kuni viis korda tõhusam. Kuna nmap kontrollib ainult saadavust ja reageerimisaega, teisaldasime kadude arvutamise päästikutele ja vähendasime oluliselt kättesaadavuse kontrollimise intervalle. Leidsime, et nmapi jaoks on optimaalne hostide arv umbes 4 tuhat iteratsiooni kohta. Nmap võimaldas meil vähendada saadavuse kontrollimise protsessori maksumust kolm korda ja vähendada intervalli 120 sekundilt 10-le.
Küsitluse optimeerimine
MM: «Siis hakkasime polllereid tegema. Meid huvitasid peamiselt SNMP tuvastamine ja ained. Zabbixis toimub küsitlus sünkroonselt ja süsteemi efektiivsuse tõstmiseks on kasutusele võetud erimeetmed. Sünkroonrežiimis põhjustab hosti kättesaamatus küsitluse olulise halvenemise. Seal on terve olekute süsteem, on spetsiaalsed protsessid - nn kättesaamatud pollerid, mis töötavad ainult kättesaamatute hostidega:
See on kommentaar, mis näitab olekumaatriksit, kogu üleminekute süsteemi keerukust, mis on vajalik süsteemi tõhusaks püsimiseks. Lisaks on sünkroonne küsitlus ise üsna aeglane:
Seetõttu ei suutnud tuhanded küsitlusvood kümnetel puhverserveritel koguda meie jaoks vajalikku andmemahtu. Asünkroonne juurutus ei lahendanud mitte ainult lõimede arvuga seotud probleeme, vaid lihtsustas oluliselt ka kättesaamatud hostide olekusüsteemi, kuna ühes küsitlusiteratsioonis kontrollitud numbrite puhul oli maksimaalne ooteaeg 1 ajalõpp:
Lisaks muutsime ja täiustasime SNMP-päringute küsitlussüsteemi. Fakt on see, et enamik inimesi ei saa korraga vastata mitmele SNMP-päringule. Seetõttu tegime hübriidrežiimi, kui sama hosti SNMP-küsitlus toimub asünkroonselt:
Seda tehakse kogu hostide paki jaoks. See režiim ei ole lõppkokkuvõttes aeglasem kui täiesti asünkroonne, kuna pooleteise saja SNMP-väärtuse küsimine on ikka palju kiirem kui 1 ajalõpp.
Meie katsed on näidanud, et optimaalne päringute arv ühes iteratsioonis on SNMP-küsitlusega ligikaudu 8 tuhat. Kokku võimaldas asünkroonsele režiimile üleminek kiirendada küsitluse jõudlust 200 korda, mitusada korda.
MCH: – Saadud küsitluse optimeerimised näitasid, et me ei saa mitte ainult vabaneda kõigist puhverserveritest, vaid ka vähendada paljude kontrollide intervalle ning puhverservereid ei ole enam koormuse jagamiseks vaja.
Umbes kolm kuud tagasi
Muuda arhitektuuri – suurenda koormust!
MM: - Noh, Max, kas on aeg produktiivseks saada? Vajan võimsat serverit ja head inseneri.
MCH: - Olgu, planeerime seda. On viimane aeg liikuda surnud punktist 5 tuhat meetrit sekundis.
Hommik pärast uuendamist
MCH: - Misha, uuendasime end, aga hommikuks veeresime tagasi... Arvake ära, mis kiirus meil õnnestus?
MM: - maksimaalselt 20 tuhat.
MCH: - Jah, 25! Kahjuks oleme just seal, kust alustasime.
MM: - Miks? Kas tegite diagnostikat?
MCH: - Jah muidugi! Siin on näiteks huvitav top:
MM: - Vaatame. Näen, et oleme proovinud tohutul hulgal küsitluslõime:
Kuid samal ajal ei saanud nad süsteemi isegi poole võrra ringlusse võtta:
Ja üldine jõudlus on üsna väike, umbes 4 tuhat mõõdikut sekundis:
Kas on veel midagi?
MCH: – Jah, osa ühe küsitlejatest:
MM: – Siin on selgelt näha, et küsitlusprotsess ootab “semafore”. Need on lukud:
MCH: - Ebaselge.
MM: – Vaadake, see sarnaneb olukorraga, kus hunnik lõime üritab töötada ressurssidega, millega saab korraga töötada ainult üks. Siis saavad nad ainult seda ressurssi aja jooksul jagada:
Ja sellise ressursiga töötamise kogujõudlust piirab ühe tuuma kiirus:
Selle probleemi lahendamiseks on kaks võimalust.
Uuendage masina riistvara, lülituge kiirematele tuumadele:
Või muutke arhitektuuri ja muutke samal ajal koormust:
MCH: – Muide, testmasinas kasutame vähem südamikke kui lahingumasinal, kuid nende sagedus on tuuma kohta 1,5 korda kiirem!
MM: - Selge? Peate vaatama serveri koodi.
Andmete tee Zabbixi serveris
MCH: - Selle väljaselgitamiseks hakkasime analüüsima, kuidas andmeid Zabbixi serveris edastatakse:
Lahe pilt, eks? Vaatame seda samm-sammult läbi, et see oleks enam-vähem selge. Andmete kogumise eest vastutavad lõimed ja teenused:
Nad edastavad kogutud mõõdikud pistikupesa kaudu eeltöötlushaldurile, kus need salvestatakse järjekorda:
"Eeltöötluse haldur" edastab andmed oma töötajatele, kes täidavad eeltöötlusjuhiseid ja tagastavad need sama pesa kaudu tagasi:
Pärast seda salvestab eeltöötluse haldur need ajaloo vahemällu:
Sealt võtavad need ajaloo uppujad, kes täidavad päris palju funktsioone: näiteks arvutavad trigerid, täidavad väärtuste vahemälu ja mis kõige tähtsam, salvestavad mõõdikuid ajaloomällu. Üldiselt on protsess keeruline ja väga segane.
MM: – Esimene asi, mida nägime, oli see, et enamik lõime võistleb nn konfiguratsiooni vahemälu (mäluala, kuhu salvestatakse kõik serveri konfiguratsioonid) pärast. Andmete kogumise eest vastutavad lõimed blokeerivad eriti palju:
...kuna konfiguratsioon ei salvesta mitte ainult mõõdikuid koos nende parameetritega, vaid ka järjekordi, kust küsitlejad võtavad teavet selle kohta, mida edasi teha. Kui küsitlejaid on palju ja üks blokeerib konfiguratsiooni, ootavad teised päringuid:
Küsitlused ei tohiks vastuollu minna
Seetõttu jagasime esimese asjana järjekorra neljaks osaks ja lubasime küsijatel need järjekorrad, need osad korraga, ohututes tingimustes blokeerida:
See eemaldas konkurentsi konfiguratsiooni vahemälu pärast ja pollerite kiirus suurenes märkimisväärselt. Kuid siis puutusime kokku tõsiasjaga, et eeltöötleja haldur hakkas koguma järjekorda töid:
Eelprotsessori haldur peab suutma prioriseerida
See juhtus juhtudel, kui tal puudus jõudlus. Siis ei saanud ta muud teha, kui koguda taotlusi andmekogumisprotsessidest ja liita nende puhvrit, kuni see kogu mälu tarbis ja kokku jooksis:
Selle probleemi lahendamiseks lisasime teise pesa, mis oli mõeldud spetsiaalselt töötajatele:
Seega oli eeltöötlusjuhil võimalus oma tööd prioriseerida ja kui puhver kasvab, on ülesandeks eemaldamist aeglustada, andes töötajatele võimaluse seda puhvrit kasutada:
Siis avastasime, et aeglustumise üheks põhjuseks olid töötajad ise, kuna nad konkureerisid nende töö jaoks täiesti ebaolulise ressursi pärast. Dokumenteerisime selle probleemi veaparandusena ja see on Zabbixi uutes versioonides juba lahendatud:
Suurendame pistikupesade arvu - saame tulemuse
Lisaks sai kitsaskohaks eeltöötlushaldur ise, kuna see on üks lõime. See toetus põhikiirusele, andes maksimaalseks kiiruseks umbes 70 tuhat meetrit sekundis:
Seetõttu tegime neli, nelja pistikupesade komplektiga, töötajaid:
Ja see võimaldas meil suurendada kiirust umbes 130 tuhandeni:
Kasvu mittelineaarsus on seletatav asjaoluga, et ajaloo vahemälu pärast on tekkinud konkurents. Selle nimel võistles 4 eeltöötlusjuhti ja ajaloo uppujat. Sel hetkel saime testmasinas umbes 130 tuhat mõõdikut sekundis, kasutades seda umbes 95% protsessorist:
Umbes 2,5 kuud tagasi
Snmp-kogukonna keeldumine suurendas NVP-sid poolteist korda
MM: – Max, ma vajan uut prooviautot! Me ei sobi enam praegusesse.
MCH: - Mis sul praegu on?
MM: – Nüüd – 130 XNUMX NVP-d ja riiulivalmidusega protsessor.
MCH: - Vau! Lahe! Oota, mul on kaks küsimust. Minu arvutuste kohaselt on meie vajadus umbes 15-20 tuhat meetrit sekundis. Miks me rohkem vajame?
MM: "Ma tahan töö lõpetada." Tahaks näha, kui palju me suudame sellest süsteemist välja pigistada.
MCH: - Aga…
MM: "Kuid see on äri jaoks kasutu."
MCH: - See on selge. Ja teine küsimus: kas suudame seda, mis meil praegu on, toetada iseseisvalt, ilma arendaja abita?
MM: - Ma ei usu. Konfiguratsiooni vahemälu tööviisi muutmine on probleem. See mõjutab muudatusi enamikes lõimedes ja seda on üsna raske hooldada. Tõenäoliselt on seda väga raske säilitada.
MCH: "Siis vajame mingit alternatiivi."
MM: - Selline võimalus on olemas. Saame üle minna kiiretele tuumadele, samas loobudes uuest lukustussüsteemist. Saame ikkagi 60-80 tuhande mõõdiku jõudluse. Samal ajal saame jätta kogu ülejäänud koodi. Clickhouse ja asünkroonne küsitlus töötavad. Ja seda on lihtne hooldada.
MCH: - Hämmastav! Soovitan siin peatuda.
Pärast serveripoole optimeerimist saime lõpuks uue koodi tootmisse käivitada. Loobusime mõnest muudatusest, et minna üle kiirete tuumadega masinale ja minimeerida koodimuudatuste arvu. Samuti oleme konfigureerimist lihtsustanud ja võimaluse korral välistanud andmeüksustes makrod, kuna need toovad sisse täiendava lukustamise.
Näiteks dokumentatsioonis ja näidetes sageli leiduvast snmp-community makrost loobumine võimaldas meie puhul NVP-sid veelgi kiirendada umbes 1,5 korda.
Pärast kahepäevast tootmist
Juhtumiajaloo hüpikakende eemaldamine
MCH: – Misha, oleme süsteemi kasutanud kaks päeva ja kõik töötab. Aga ainult siis, kui kõik töötab! Planeerisime tööd üsna suure võrgulõigu ülekandmisega ja kontrollisime taas oma kätega, mis läks üles ja mis mitte.
MM: - Ei saa olla! Kontrollisime kõike 10 korda. Server lahendab koheselt isegi täieliku võrgu kättesaamatuse.
MCH: - Jah, ma saan kõigest aru: server, andmebaas, top, austat, logid - kõik on kiire... Kuid me vaatame veebiliidest ja serveris on protsessor "riiulis" ja see:
MM: - See on selge. Vaatame veebi. Leidsime, et olukorras, kus oli palju aktiivseid intsidente, hakkas enamik reaalajas vidinaid töötama väga aeglaselt:
Selle põhjuseks oli juhtumite ajaloo hüpikakende genereerimine, mis luuakse loendi iga üksuse jaoks. Seetõttu loobusime nende akende genereerimisest (kommenteerisime koodis 5 rida) ja see lahendas meie probleemid.
Vidinate laadimisaeg isegi siis, kui need pole täiesti saadaval, on lühenenud mitmelt minutilt meie jaoks vastuvõetavale 10-15 sekundile ja ajalugu on endiselt võimalik vaadata ajal klõpsates:
Pärast tööd. 2 kuud tagasi
MCH: - Misha, kas sa lahkud? Me peame rääkima.
MM: - Ma ei kavatsenud. Midagi jälle Zabbixiga?
MCH: - Ei, lõdvestu! Tahtsin lihtsalt öelda: kõik töötab, aitäh! Mul on õlu.
Zabbix on tõhus
Zabbix on üsna universaalne ja rikkalik süsteem ja funktsioon. Seda saab kasutada väikeste paigalduste jaoks, kuid vajaduste kasvades tuleb seda optimeerida. Suure mõõdikute arhiivi salvestamiseks kasutage sobivat salvestusruumi:
- saate kasutada sisseehitatud tööriistu Elasticsearchiga integreerimise või ajaloo tekstifailidesse üleslaadimise kujul (saadaval alates versioonist 4);
- Saate ära kasutada meie kogemusi ja integratsiooni Clickhouse'iga.
Mõõdikute kogumise kiiruse järsuks suurendamiseks koguge need asünkroonsete meetodite abil ja edastage need trapperi liidese kaudu Zabbixi serverisse; või võite kasutada plaastrit, et muuta Zabbixi pollerid asünkroonseks.
Zabbix on kirjutatud C-keeles ja on üsna tõhus. Mitmete arhitektuursete kitsaskohtade lahendamine võimaldab selle jõudlust veelgi suurendada ja meie kogemuse põhjal saada ühe protsessoriga masinal üle 100 tuhande mõõdiku.
Sama Zabbixi plaaster
MM: – Tahan lisada paar punkti. Kogu praegune aruanne, kõik testid ja numbrid on antud meie kasutatava konfiguratsiooni jaoks. Nüüd võtame sellest umbes 20 tuhat mõõdikut sekundis. Kui proovite aru saada, kas see teie jaoks töötab, saate võrrelda. Täna arutatu postitatakse GitHubisse plaastri kujul:
Plaaster sisaldab:
- täielik integratsioon Clickhouse'iga (nii Zabbixi server kui ka kasutajaliides);
- probleemide lahendamine eeltöötlusjuhiga;
- asünkroonne küsitlus.
Plaaster ühildub kõigi versioonidega 4, sealhulgas lts-iga. Tõenäoliselt töötab see minimaalsete muudatustega versioonis 3.4.
Tänan teid tähelepanu eest.
küsimused
Küsimus publikult (edaspidi – A): – Tere päevast! Palun öelge, kas teil on plaanis intensiivseks suhtlemiseks Zabbixi meeskonnaga või nemad teiega, et see ei oleks plaaster, vaid Zabbixi tavaline käitumine?
MM: – Jah, me viime kindlasti mõned muudatused sisse. Midagi juhtub, midagi jääb plaastrisse.
A: – Tänan teid väga suurepärase raporti eest! Palun öelge mulle, et pärast plaastri rakendamist jääb Zabbixi tugi alles ja kuidas jätkata värskendamist kõrgematele versioonidele? Kas Zabbixi on võimalik pärast paika panna versioonile 4.2, 5.0?
MM: – Toetuse kohta ei oska ma midagi öelda. Kui ma oleksin Zabbixi tehniline tugi, ütleksin ilmselt ei, sest see on kellegi teise kood. Mis puutub 4.2 koodibaasi, siis meie seisukoht on järgmine: "Liikume ajaga edasi ja värskendame end järgmise versiooniga." Seetõttu postitame mõnda aega värskendatud versioonide jaoks plaastrit. Ütlesin juba aruandes: versioonide muudatuste arv on endiselt üsna väike. Ma arvan, et üleminek 3.4-lt 4-le võttis meil aega umbes 15 minutit.. Midagi seal muutus, aga mitte väga oluline.
A: – Nii et plaanite oma plaastrit toetada ja saate selle ohutult tootmisse installida ja tulevikus mingil moel värskendusi saada?
MM: – Soovitame tungivalt. See lahendab meie jaoks palju probleeme.
MCH: – Taaskord juhin tähelepanu sellele, et muudatused, mis ei puuduta arhitektuuri ja ei puuduta blokeerimist ega järjekordi, on modulaarsed, need on eraldi moodulites. Isegi väikeste muudatustega saate neid üsna hõlpsalt hooldada.
MM: – Kui sind huvitavad detailid, siis “Clickhouse” kasutab nn ajaloo raamatukogu. See on lahti seotud - see on Elasticsi toe koopia, see tähendab, et see on konfigureeritav. Küsitlus muudab ainult küsitlejaid. Usume, et see toimib pikka aega.
A: - Tänud. Öelge, kas tehtud muudatuste kohta on dokumente?
MM: – Dokumentatsioon on plaaster. Ilmselgelt tekivad Clickhouse’i kasutuselevõtuga, uut tüüpi pollerite kasutuselevõtuga uued konfiguratsioonivõimalused. Viimase slaidi lingil on selle kasutamise lühike kirjeldus.
Fping-i asendamisest nmapiga
A: – Kuidas te selle lõpuks ellu viisite? Kas saate tuua konkreetseid näiteid: kas teil on rihmad ja väline skript? Mis päädib nii suure hulga hostide kiire kontrollimisega? Kuidas te neid hoste kaevandate? Kas me peame neid kuidagi nmapi söötma, kuskilt hankima, sisse panema, midagi käivitama?..
MM: - Lahe. Väga õige küsimus! Asi on selles. Muutsime teeki (ICMP ping, osa Zabbixist) ICMP kontrollide jaoks, mis näitavad pakettide arvu - üks (1) ja kood proovib kasutada nmapi. See tähendab, et see on Zabbixi sisetöö, millest on saanud pingeri sisetöö. Sellest tulenevalt pole sünkroniseerimine ega püüduri kasutamine vajalik. Seda tehti meelega, et jätta süsteem puutumata ja ei peaks tegelema kahe andmebaasisüsteemi sünkroniseerimisega: mida kontrollida, polleri kaudu üles laadida ja kas meie üleslaadimine on katki?.. Nii on palju lihtsam.
A: – Kas see töötab ka puhverserverite puhul?
MM: – Jah, aga me ei kontrollinud. Küsitluskood on nii Zabbixis kui ka serveris sama. Peaks töötama. Lubage mul veel kord rõhutada: süsteemi jõudlus on selline, et me ei vaja puhverserverit.
MCH: – Õige vastus küsimusele on: "Miks on sellise süsteemiga puhverserverit vaja?" Ainult NAT või mingi aeglase kanali kaudu jälgimise tõttu...
A: – Ja kui ma õigesti aru saan, kasutate Zabbixit alleraatorina. Või on teie graafika (kus on arhiivikiht) teisaldatud mõnda teise süsteemi, näiteks Grafanasse? Või ei kasuta te seda funktsiooni?
MM: – Rõhutan veel kord: oleme saavutanud täieliku integratsiooni. Valame Clickhouse'i ajalugu, kuid samal ajal oleme muutnud php kasutajaliidese. Php kasutajaliides läheb Clickhouse'i ja teeb sealt kogu graafika. Samas, ausalt öeldes on meil osa, mis ehitab andmeid teistesse graafilistesse kuvasüsteemidesse samast Clickhouse'ist, samadest Zabbixi andmetest.
MCH: – “Grafanis” samuti.
Kuidas tehti otsuseid ressursside jaotamise kohta?
A: - Jagage natuke oma sisemist kööki. Kuidas sündis otsus, et toote tõsiseks töötlemiseks on vaja ressursse eraldada? Need on üldiselt teatud riskid. Ja palun öelge mulle seoses sellega, et kavatsete uusi versioone toetada: kuidas see otsus juhtimis seisukohast õigustab?
MM: - Ilmselt ei rääkinud me ajaloo draamat kuigi hästi. Leidsime end olukorrast, kus tuli midagi ette võtta ja läksime sisuliselt kahe paralleelse meeskonnaga:
- Üks neist oli seiresüsteemi käivitamine, kasutades uusi meetodeid: monitooring teenusena, standardne avatud lähtekoodiga lahenduste komplekt, mida kombineerime ja proovime seejärel äriprotsessi muuta, et uue seiresüsteemiga töötada.
- Samal ajal oli meil entusiastlik programmeerija, kes tegi seda (enda kohta). Juhtus nii, et ta võitis.
A: – Ja kui suur on meeskond?
MCH: - Ta on teie ees.
A: – Niisiis, nagu alati, vajate kirglikku?
MM: – Ma ei tea, mis on kirglik.
A: - Sel juhul ilmselt sina. Tänan teid väga, olete suurepärane.
MM: - Aitäh.
Zabbixi plaastrite kohta
A: – Kas süsteemi puhul, mis kasutab puhverservereid (näiteks mõnes hajutatud süsteemis), on võimalik kohandada ja parandada näiteks pollereid, puhverservereid ja osaliselt Zabbixi eelprotsessorit; ja nende suhtlus? Kas mitme puhverserveriga süsteemi jaoks on võimalik olemasolevaid arendusi optimeerida?
MM: – Tean, et Zabbixi server on kokku pandud puhverserveri abil (kood kompileeritakse ja hangitakse). Me ei ole seda tootmises katsetanud. Ma pole selles kindel, kuid arvan, et puhverserveris ei kasutata eeltöötlushaldurit. Puhverserveri ülesanne on võtta Zabbixist mõõdikute komplekt, need liita (salvestab ka konfiguratsiooni, kohaliku andmebaasi) ja anda see tagasi Zabbixi serverisse. Server ise teostab selle vastuvõtmisel eeltöötluse.
Huvi volikirjade vastu on mõistetav. Me kontrollime seda. See on huvitav teema.
A: – Idee oli järgmine: kui saate pollereid paika panna, saate neid puhverserveris parandada ja serveriga suhtlemist parandada ning eelprotsessorit nendeks eesmärkideks kohandada ainult serveris.
MM: – Ma arvan, et see on veelgi lihtsam. Võtate koodi, rakendate paiga, seejärel seadistate selle nii, nagu vaja – kogute puhverserverid (näiteks ODBC-ga) ja levitate paigakoodi süsteemide vahel. Vajadusel koguge puhverserver, vajadusel - server.
A: – Tõenäoliselt ei pea te puhverserveri edastamist serverisse täiendavalt parandama?
MCH: – Ei, see on standardne.
MM: – Tegelikult üks ideedest ei kõlanud. Oleme alati säilitanud tasakaalu ideede plahvatusrohke ning muudatuste hulga ja toetamise lihtsuse vahel.
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com