Järgmine HighLoad++ konverents toimub 6. ja 7. aprillil 2020 Peterburis. Üksikasjad ja piletid. . HighLoad++ Moskva 2018. Saal «Moskva». 9. november, 15:00. Teesid ja .
* Jälgimine — online ja analüüs.
* ZABBIX platvormi peamised piirangud.
* Lahendus analüüsihoiustamise skaleerimiseks.
* ZABBIX serveri optimeerimine.
* UI optimeerimine.
* Süsteemi kasutamise kogemus üle 40k NVPS koormuste juures.
* Lühidalt järeldused.
Mihhail Makurov (edaspidi – MM): – Tere kõigile!
Maksim Tšernecov (edaspidi – MT): – Tere päevast!
MM: – Lubage mul esitleda Maksi. Maks on andekas insener, parim võrgutegija, keda ma tean. Maksim tegeleb võrkude ja teenustega, nende arendamise ja kasutamisega.
MT: – Ja mina sooviksin rääkida Mihhailist. Mihhail on C programmeerija. Ta on kirjutanud mitmeid väga koormatud lahendusi meie ettevõtte liikluse töötlemiseks. Me elame ja töötame Uuralites, karmide meestega Chelyabinskis, ettevõttes «Intersvyaz». Meie ettevõte on interneti- ja kaabeltelevisiooniteenuste pakkuja miljonile inimesele 16 linnas.
MM: – Ja tuleb öelda, et «Intersvyaz» on palju enamat kui lihtsalt teenusepakkuja, see on IT-ettevõte. Enamik meie lahendustest on loodud meie IT-osakonna poolt.
A: serveritest, mis töötlevad liiklust, kuni kõnekeskkonna ja mobiilirakenduse. IT-osakonnas on praegu umbes 80 inimest, kellel on väga erinevad oskused.
Zabbixist ja selle arhitektuurist
MT: – Ja nüüd püüan ma seada isiklikku rekordit ja ühe minutiga öelda, mis asi on Zabbix (edaspidi – «Zabbix»).
«Zabbix» positsioneerib end ettevõtte tasemel monitoorimissüsteemina „karbist välja“. Sellel on palju elu lihtsustavaid funktsioone: arenenud eskaleerimisreeglid, API integratsiooniks, hostide ja mõõdikute rühmitamine ja automaatne avastamine. «Zabbixis» on nii öelda skaleerimisvahendid – proksi. «Zabbix» on avatud lähtekoodiga süsteem.
Lühidalt arhitektuurist. Võib öelda, et see koosneb kolmest komponendist:
- Server. Kirjutatud C-s. Piisavalt keeruka andmetöötluse ja edastamisega voogude vahel. Kogu töötlemine toimub seal: andmete vastuvõtmisest kuni andmebaasi salvestamiseni.
- Kõik andmed salvestatakse andmebaasi. «Zabbix» toetab MySQL, PostgreSQL ja Oracle.
- Veebiliides on kirjutatud PHP-s. Enamikus süsteemides kaasneb Apache serveriga, kuid töötab tõhusamalt koos nginx + php-ga.
Täna soovime jagada ühe loo meie ettevõtte elust, mis seondub 'Zabbixiga'...
Lugu ettevõtte 'Intersvyaz' elust. Mida me omame ja mida on vaja?
5 või 6 kuud tagasi. Ühel õhtul pärast tööd...
MT: – Misha, tere! Hea meel, et suutsin sind kinni püüda – mul on jutt. Meil olid taas probleemid jälgimisega. Suure õnnetuse ajal kõik seisis ja ega mingit teavet võrgu seisundi kohta polnud. Kahjuks kordub see juba mitte esmakordselt. Mul on sinu abi vaja. Teeme nii, et meie jälgimine toimiks igas olukorras!
MM: – Aga alustame esmalt sünkroonimist. Ma pole sinna juba paar aastat vaadanud. Kui ma õigesti mäletan, siis loobusime Nagiosest ja läksime 8 aastat tagasi 'Zabbixile'. Ja praegu tundub, et meil on 6 võimsat serverit ja umbes tosin proksi. Ma ei aja asju segamini, eks?
MT: – Peaaegu. 15 serverit, millest osa on virtuaalmasinad. Kõige olulisem on see, et see ei päästa meid siis, kui seda kõige rohkem vajame. Nagu avarii - serverid hakkavad aeglustuma ja mitte midagi ei ole näha. Proovisime konfiguratsiooni optimeerida, kuid see ei toonud soovitud jõudlust.
MM: – Selge. Kas midagi uurisite, midagi olete diagnostikast leidnud?
MT: – Esimene asi, millega tegelema peame, on just andmebaas. MySQL on niigi pidevalt koormatud, salvestades uusi mõõdikuid, ja kui "Zabbix" hakkab genereerima hulgaliselt sündmusi, siis andmebaas kukub endasse sõna otseses mõttes mitmeks tunniks. Konfiguratsiooni optimeerimise kohta olen sulle juba rääkinud, aga just sel aastal uuendasime riistvara: serverites on üle saja giga mälu ja SSD RAID-iga diskimassiivid - edaspidi ei ole mõtet seda lineaarselt kasvatada. Mida teeme?
MM: – Selge. Üldiselt, MySQL on LTP-andmebaas. Tundub, et see ei sobi enam meie mõõdikute arhiivi salvestamiseks. Hakkame asja uurima.
MT: – Hakkame!
Zabbixi ja Clickhouse'i integreerimine hackathon'i tulemusena
Mõne aja pärast saime huvitavaid andmeid:
Enamik ruumi meie andmebaasis oli hõivatud mõõdikute arhiiviga ja vähem kui 1% kasutati konfiguratsiooni, mallide ja seadistuste jaoks. Sel hetkel olime juba üle aasta töötanud Big Data lahenduse kallal, mis põhines Clickhouse'il. Meie tegevussuund oli selge. Meie kevadisel "Hackathonil" kirjutasin integratsiooni "Zabbix" ja "Clickhouse" vahel serveri ja esiosa jaoks. Toona toetati "Zabbixis" juba ElasticSearch'i, ja me otsustasime neid võrrelda.
Clickhouse'i ja Elasticsearch'i võrdlus
MM: – Võrdluseks genereerisime koormust, mis oli sama, mida tagas "Zabbix"-server, ja vaatasime, kuidas süsteemid käituvad. Kirjutasime andmeid partiidesse 1000 rida, kasutasime CURL-i. Me oletame ette, et "Clickhouse" on selle koormusprofiili jaoks, mida "Zabbix" loob, tõhusam. Tulemused ületasid isegi meie ootusi:
Samades tingimustes testides kirjutas "Clickhouse" kolm korda rohkem andmeid. Samas kasutasid mõlemad süsteemid andmete lugemisel väga efektiivselt (vähem ressursse). Kuid "Elasticsearch" vajab kirjutamisel suurt hulka protsessori ressursse:
Kokkuvõttes ületas ClickHouse oluliselt Elastixi protsessori ja kiirusnõudeid. Samuti, andmete kokkusurumise tõttu kasutab ClickHouse kõvakettal 11 korda vähem ruumi ja teostab umbes 30 korda vähem kõvakettatehteid.
MT: – Jah, ClickHouse'i töökorraldus kõvakettasüsteemiga on väga efektiivne. Selle alla saab kasutada suuri SATA-kettasid ja saavutada kirjutamiskiirus sadu tuhandeid ridu sekundis. Süsteem toetab "kastist välja" jagamist, replikatsiooni ja on seadistamisel väga lihtne. Oleme oma aasta jooksul selle kasutamisega rohkem kui rahul.
Resursside optimeerimiseks on võimalik paigaldada ClickHouse olemasoleva peamise andmebaasi kõrvale, säilitades sellega tohutult protsessorivõimet ja kõvakettatehteid. Oleme arhiiveeritud mõõdikud olemasolevatesse ClickHouse klastritesse.
Oleme peamise MySQL-andmebaasi nii palju koormanud, et saime selle ühendada ühel masinal Zabbix-serveriga ja loobuda eraldatud serverist MySQL jaoks.
Kuidas polling Zabbix'is töötab?
4 kuud tagasi
MM: – Noh, kas andmebaasi probleemidest võib juba unustada?
MT: – See, that's right! Another issue we need to tackle is the slow data collection. Now all our 15 proxy servers are overloaded with SNMP and polling processes. And there's no choice but to keep adding new servers.
MM: – Great. But first, tell me how polling works in 'Zabbix'?
MT: – To put it briefly, there are 20 types of metrics and a dozen ways to gather them. 'Zabbix' can collect data either in a 'request-response' mode or wait for new data via the 'Trapper Interface'.
It's worth noting that in the original 'Zabbix', this method (Trapper) is the fastest.
There are proxy servers for load distribution:
Proxies can perform the same collection functions as the 'Zabbix' server, receiving tasks from it and sending collected metrics through the Trapper interface. This is the officially recommended method for load distribution. Proxies are also useful for monitoring remote infrastructure operating through NAT or a slow connection:
MM: – The architecture is clear. We need to look at the source code…
A couple of days later
The tale of how nmap fping triumphed
MM: – Looks like I've dug something up.
MT: – Spill the beans!
MM: – Olen avastanud, et «Zabbix» kontrollib kergesti juurdepääsetavust korraga maksimaalselt 128 hosti. Proovisin seda arvu tõsta 500-ni ja eemaldasin nende pingist vahepkgendi, mis kahekordistas jõudlust. Aga tahaksin veelgi suuremaid numbreid.
MT: – Oma praktikas pean vahel kontrollima tuhandete hostide juurdepääsetavust ning ma pole leidnud midagi kiiremat kui nmap. Olen kindel, et see on kõige kiirem viis. Proovime seda! Peame oluliselt suurendama hostide arvu ühe iteratsiooni jooksul.
MM: – Kontrollida üle viiesaja? 600?
MT: – Vähemalt paar tuhat.
MM: – Okei. Kõige olulisem, mida tahtsin öelda: olen leidnud, et enamus pollingust «Zabbixis» on tehtud sünkroonselt. Peame kindlasti selle asünkroonsesse režiimi ümber tegema. Siis suudame oluliselt suurendada jälgijate kogutud mõõdikute arvu, eriti kui me kasume mõõdikute arvu ühe iteratsiooni jooksul.
MT: – Lahe! Ja millal?
MM: – Nagu tavaliselt, eile.
MT: – Võrdlesime mõlemaid versioone fping ja nmap:
Paljude hostide puhul oli nmap oodatult kuni viis korda efektiivsem. Kuna nmap kontrollib ainult ligipääsetavust ja reageerimisaega, oleme kaotuste arvestuse lisanud käivitustele ning oluliselt lühendanud ligipääsetavuse kontrollimise vahemaid. Nmapi optimaalseks hostide arvuks ühes iteratsioonis leidsime umbes 4000. Nmap võimaldas meil kolm korda vähendada CPU kulu ligipääsetavuse testimisele ning lühendada intervalli 120 sekundilt 10 sekundile.
Pollimise optimeerimine
MM: – Seejärel tegelesime pollijatega. Eelkõige oli meid huvitanud SNMP ja agentide kaaperdamine. "Zabbixis" on pollimine tehtud sünkroonselt ja on võetud erilisi meetmeid, et suurendada süsteemi efektiivsust. Sünkroonses režiimis põhjustab hostide puudumine oluliseks pollimise halvenemise. On olemas terve hulk olekute süsteeme ja spetsiaalsed protsessid - nn unreachable-pollijad, mis töötavad ainult puuduvate hostidega:
See on kommentaar, mis demonstreerib olekute maatriksit, kogu süsteemi üleminekute keerukust, mis on vajalik efektiivsuse säilitamiseks. Lisaks on sünkroonne pollimine iseenesest piisavalt aeglane:
Seetõttu ei suutnud tuhanded pollerite vood kümne proxiga meile vajalikku andmemahu kogumist sooritada. Asünkroonne teostus lahendas mitte ainult voogude arvu probleemid, vaid lihtsustas oluliselt ka mitteolemasolevate hostide olekusüsteemi, kuna ühes polling'i iteratsioonis kontrollitavate elementide arvust hoolimata oli maksimaalne ooteaeg 1 timeout:
Lisaks modifitseerisime ja täiendame SNMP-pollingu süsteemi. Asi on selles, et enamus ei saa korraga mitmele SNMP-päringule vastata. Seetõttu tegime hübriidrežiimi, kus sama hosti SNMP-polling toimub asünkroonselt:
See toimub kogu hostide rühma jaoks. Selline režiim ei ole lõpuks aeglasem kui täiesti asünkroonne, kuna poolesaja SNMP-väärtuse küsimine on ikkagi palju kiirem kui 1 timeout.
Meie katsed näitasid, et optimaalne päringute arv ühes iteratsioonis on umbes 8000 SNMP-pollingu puhul. Kokkuvõttes võimaldas üleminek asünkroonsesse režiimi kiirusel enerji 200 korda, mõnesaja korra võrra.
MT: – Saadud optimeerimised pingetulemused näitavad, et me saame mitte ainult kõrvaldada kõik proksid, vaid ka vähendada paljude kontrollide intervalle, ning proksid ei ole enam vajalikud koormuse jaotamiseks.
Umbes kolm kuud tagasi
Muuda arhitektuuri – suurenda koormust!
MM: – Niisiis, Max, kas oleme valmistunud tootmisse minema? Mul on vaja võimsat serverit ja head inseneri.
MT: – Hästi, plaanime. On aeg liikuda edasi 5000 mõõtmise sekundisse.
Hommik pärast uuendust
MT: – Misha, me värskendasime, kuid hommikuks oli kõik tagasi... Arva, millise kiiruseni me jõudsime?
MM: – Umbes 20 tuhat maksimaalselt.
MT: – Aha, 25! Kahjuks oleme seal, kus alustasime.
MM: – Miks see nii on? Kas tehti mingi diagnostika?
MT: – Jah, loomulikult! Vaata, näiteks huvitav top:
MM: – Vaata, kui palju proovitud pingevooge on:
Kuid me ei suutnud isegi süsteemi poolestki kasutada:
Ja kogutootlikkus on üsna madal, umbes 4000 mõõtmist sekundis:
Kas on veel midagi?
MT: – Jah, ühe polleri strace:
MM: – Siit on selgelt näha, et pingetöötlus ootab 'semaforeid'. Need on blokeeringud:
MT: – Ei saa aru.
MM: – Vaata, see tundub nagu olukord, kus hulk lõime püüab töötada ressursiga, millega saab samal ajal töötada ainult üks. Niisiis, kõik, mida nad saavad teha, on jagada seda ressursi ajaliselt:
Ja sellise ressursi kogutootlikkus on piiratud ühe tuuma kiirusena:
See probleem on võimalik lahendada kahel viisil.
Uuendage masina riistvara, liikudes kiirematele tuumadele:
Või muutke arhitektuuri ja samal ajal – koormust:
MT: – Muide, testmasinas kasutame vähem tuumasid kui tootmismasinas, kuid need on tuumade sageduses 1,5 korda kiirem!
MM: – Selge? Peame vaatama serveri koodi.
Andmete teekond Zabbix-serveris
MT: – Arusaamiseks hakkasime analüüsima, kuidas andmed edastatakse «Zabbix»-serveris:
Lahe pilt, eks? Käime selle üle samm-sammult, et enam-vähem selgeks saada. On lõime ja teenuseid, mis on vastutavad andmete kogumise eest:
Kogutud mõõdikud edastatakse nad soketi kaudu Preprocessor managerisse, kus need salvestatakse järjekorda:
Preprotsessorihaldur edastab andmed oma töötlejatele, kes täidavad eeltöötlusjuhiseid ja saadavad need tagasi läbi sama pesa:
Pärast seda salvestab preprotsessorihaldur need ajaloo vahemällu:
Sealt võtavad need andmed ajaloo sünkroniseerijad, mis täidavad üsna palju funktsioone: näiteks triggerite arvutamine, väärtuste vahemälu täitmine ja mis kõige tähtsam, mõõdikute salvestamine ajaloo hoidlas. Ühesõnaga, protsess on keeruline ja üsna segane.
MM: – Esimene asi, mida me nägime, oli, et enamik vooge konkureerib nn "konfiguratsiooni vahemälu" pärast (mälutsoon, kus säilitatakse kõik serveri konfiguratsioonid). Eriti palju lukustusi teevad vood, mis vastutavad andmete lugemise eest:
…sest konfiguratsioonis säilitatakse mitte ainult mõõdikud nende parameetritega, vaid ka järjekorrad, millest pollerid võtavad teavet selle kohta, mida nad peavad edasi tegema. Kui pollereid on palju ja üks lukustab konfiguratsiooni, peavad teised ootama päringute saama:
Pollerid ei tohi konfliktida
Seetõttu jagasime järjekorra neljaks osaks ja lubasime polleritel samaaegselt need osad turvalistes tingimustes blokeerida:
See kõrvaldas konkurentsi konfiguratsioonikese eest ning pollerite töökiirus kasvas märgatavalt. Kuid siis seisis meil silmitsi olukord, kus eeltöötleja haldur hakkas järjekorde üles kuhjama:
Eeltöötleja haldur peab suutma seada prioriteete.
See juhtus siis, kui tal oli jõudlusest puudu. Siis oli ainus, mida ta suudab teha, koguda andmekogumisprotsessidelt päringuid ja koguda neid puhvrit, kuni ta kasutas kogu mäluruumi ning kukkus kokku:
Selle probleemi lahendamiseks lisasime teise pesa, mis oli eraldatud spetsiaalselt tööprotsesside jaoks:
Nii sai eeltöötleja haldur võimaluse seada oma töö prioriteedid ning puhvri kasvamisel vähendada ülesandeid, andes workeritele võimaluse see puhver ära võtta:
Seejärel avastasime, et üheks pidurdavaks teguriks olid töötajad ise, kuna nad konkureerisid täiesti ebaolulise ressursi pärast. Me lahendasime selle probleemi veaparandusega, ning uutes "Zabbixi" versioonides on see juba lahendatud:
Suurendame pistikute arvu – saame tulemuse
Järgmine kitsaskoht oli eelprotsessori haldur, kuna see on üheks keeruline. See takerdus tuuma kiirusse, pakkudes maksimaalset kiirus umbes 70 tuhat mõõtmist sekundis:
Seega tegime nelja rakendusega nelja pistikut, töötajat:
Ja see võimaldas kiirus suurendada umbes 130 tuhande mõõtmiseni:
Mitte-lineaarne kasv on seletatav asjaoluga, et ajaloost tekkis konkurents. Selle nimel konkureeris neli eelprotsessori haldurit ja ajaloosüntilised. Selleks ajaks saime testmasinas umbes 130 tuhat mõõtmist sekundis, kasutades seda umbes 95% võrra protsessorist:
Umbes 2,5 kuud tagasi
SNMP-kogukonnast loobumine suurendas NVPsid pooleteise korra võrra
MM: – Max, mul on vaja uut testmasinat! Me ei mahu enam praegusesse.
MT: – Mis seal praegu on?
MM: – Praegu on – 130k NVPs ja protsessor "riiulil".
MT: – Vau! Lahe! Oota, mul on kaks küsimust. Minu arvutuste kohaselt on meie vajadus umbes 15-20 tuhat mõõtmist sekundis. Miks me vajame rohkem?
MM: – Tahaks asja lõpuni viia. Tahaks teada, kui palju me suudame sellest süsteemist välja pigistada.
MT: – Aga…
MM: – Aga see on äri jaoks kasutu.
MT: – Selge. Ja teine küsimus: kas me saame selle, mis meil praegu on, iseseisvalt toetada, ilma arendaja abita?
MM: – Ma ei arva nii. Konfiguratsioonide vahemäluga töötamise muutmine on probleem. See puudutab enamikku vooge ja on piisavalt keeruline hooldada. Tõenäoliselt on selle toetamine väga raske.
MT: – Siis vajame mingit alternatiivi.
MM: – On selline variant. Me saame üle minna kiiretele tuumadele, loobudes selle uue lukustussüsteemi kasutamisest. Me saavutame ikkagi 60-80 tuhat mõõtmist. Samuti saame jätta kogu ülejäänud koodi. 'ClickHouse', asünkroonne polling töötavad. Ja seda on lihtne hooldada.
MT: – Suurepärane! Pakun, et lõpetame sellega.
Pärast serverioptimeerimist saime lõpuks käivitada uue koodi tootmises. Me loobusime osast muudatustest, et liikuda kiirete tuumadega masinale ja vähendada koodimuudatuste arvu. Samuti lihtsustasime konfiguratsiooni ja võimaluse korral loobusime makrodest andmeelementides, kuna need toovad kaasa täiendavaid blokeeringuid.
Näiteks loobumine dokumentatsioonis ja näidetes sageli esinevast makrost snmp-community kiirendas meie NVP-sid ligikaudu 1,5 korda.
Pärast kahte päeva tootmises
Küljest eemaldame sündmuste ajaloovihked
MT: – Misha, me oleme kaks päeva süsteemi kasutanud ja kõik töötab. Kuid ainult siis, kui kõik töötab! Meil olid plaanilised tööd, kus kandisime üle piisavalt suure võrgu segmendi, ja me kontrollisime jälle käsitsi, mis on üles ja mis mitte.
MM: – See ei saa olla tõsi! Me kontrollisime kõik 10 korda. Server töötleb isegi täielikku võrgu puudumist hetkega.
MT: – Jah, ma saan aru: server, andmebaas, top, austat, logid – kõik on kiire... Kuid meie vaatame veebiliidest, ja seal on serveri protsessor „riivas“ ja see:
MM: – Selge. Vaatame veebilehte. Oleme avastanud, et olukordades, kus oli palju aktiivseid sündmusi, hakkasid enamik operatiivseid vidinaid väga aeglaselt töötama:
Selle põhjuseks oli hüpikakende genereerimine sündmuste ajalooga, mis genereeritakse iga loendi elemendi jaoks. Seetõttu loobusime nende akende genereerimisest (kommenteerisime 5 rida koodist välja) ja see lahendas meie probleemid.
Vidinate laadimisaeg isegi täieliku kättesaamatuse korral vähenes mitmest minutist meie jaoks vastuvõetavate 10–15 sekundi piirini, ja ajalugu on endiselt vaadatav aja klikkimisega:
Pärast tööd. 2 kuud tagasi
MT: – Misha, lahkud? On juttu.
MM: – Ei plaaninud. Kas jälle midagi «Zabbixiga»?
MT: – Ei, rahune! Ma tahtsin lihtsalt öelda: kõik töötab, aitäh! Minu arvelt õlu.
Zabbix on efektiivne
«Zabbix» on piisavalt universaalne ja rikkaliku süsteemiga ning funktsiooniga. Seda saab hästi kasutada väikeste installatsioonide jaoks "karbist välja", kuid vajaduste suurenedes tuleb seda optimeerida. Suure arhiivi mõõdikute salvestamiseks kasutage sobivat salvestusruumi:
- võite kasutada sisseehitatud vahendeid, nagu integreerimine 'Elasticsearch'iga või ajaloo eksportimine tekstifailidesse (saadaval alates neljandast versioonist);
- võite kasutada meie kogemust ja integreerimist 'ClickHouse'iga.
Metrika kogumise kiirusetõstmiseks koguge neid asünkroonselt ja edastage need trapperi liidese kaudu 'Zabbix' serverisse; või võite kasutada 'Zabbixi' enda pollerite asünkroonsuse plaastrit.
'Zabbix' on kirjutatud C keeles ja on piisavalt efektiivne. Siiski, mõned kitsad arhitektuurilised kohad võimaldavad veelgi suurendada selle jõudlust ja meie kogemuse kohaselt saab üheprotsessori masinal saada üle 100 000 mõõtme.
See Zabbixi plaastriteema
MM: – Ma tahan lisada paar punkti. Kogu praegune ettekande, kõik testid ja numbrid on esitatud selle konfiguratsiooni jaoks, mida meie kasutame. Selle pealt võtame praegu umbes 20 000 mõõtme sekundis. Kui te üritate mõista, kas see töötab teil – võite võrrelda. See, millest täna rääkisime, on saadaval GitHubis plaastreina:
Plaaster sisaldab:
- täielik integreeritus «ClickHouse'iga» (nii «Zabbix» serverite kui ka frontendiga);
- probleemide lahendamine eeltöötluse halduriga;
- asünkroonne polling.
Päis on ühilduv kõigi 4. versiooniga, sealhulgas lts. Tõenäoliselt töötab see minimaalsete muudatustega ka 3.4 versioonis.
Aitäh tähelepanu eest.
Küsimused
Küsimus publikust (edasi – A): – Tere! Palun ütle, kas teil on plaane aktiivseks koostööks Zabbixi meeskonnaga või neil teie omaga, et see ei oleks lihtsalt päis, vaid Zabbixi normaalse käitumise kujundamine?
MM: – Jah, osa muudatusi me kindlasti kinnitame. Midagi jääb ellu, midagi jääb päisesse.
A: – Aitäh palju suurepärase ettekande eest! Palun öelge, kas pärast päise rakendamist jääb Zabbixi toetus alles ja kuidas edasi kõrgemate versioonide peale uuendada? Kas on võimalus uuendada Zabbixi teie päise järel versioonidele 4.2, 5.0?
MM: – Toetuse kohta ei oska ma öelda. Kui ma oleksin «Zabbixi» tehniline tugi, siis ilmselt ütleksin ei, sest see on kellegi teise kood. Mis puudutab koodibaasi 4.2, siis meie seisukoht on selline: «Me lähme ajaga kaasas ja uuendame ise järgmisele versioonile». Seega mõnda aega avaldame me patši uuendatud versioonide jaoks. Olen juba oma ettekandes öelnud: muudatuste hulk versioonide vahel on praegu piisavalt väike. Arvan, et üleminek versioonilt 3.4 versioonile 4 võttis meil umbes 15 minutit. Seal midagi muutus, kuid mitte väga olulist.
A: – Kas te kavatsete oma patši toetada ja kas seda võib julgelt tootmises kasutada, saades tulevikus värskendusi mingil moel?
MM: – Me soovitame seda kategooriliselt. See lahendab meile väga palju probleeme.
MT: – Tahtsin veel kord rõhutada, et muudatused, mis ei puuduta arhitektuuri ega blokeeringuid, järjekordi – need on moodulilised, need on eraldi moodulites. Isegi väikeste muudatuste korral on neid piisavalt lihtne toetada.
MM: – Kui üksikasjad huvitavad, siis «ClickHouse» kasutab nn ajalugu raamatukogu. See on lahtiseotud – see on «Elasticsearchi» toe koopia, mis tähendab, et see on konfiguratsiooniliselt muudetav. Polling muudab ainult pollereid. Me arvame, et see töötab kaua.
A: – Suur aitäh. Ja kas on olemas mingit dokumentatsiooni tehtud muudatuste kohta?
MM: – Dokumentatsioon on patch. Ilmselt seoses «ClickHouse’i» kasutuselevõtuga, uute pollertüüpide tekke tõttu tekivad uued konfiguratsioonivõimalused. Viimase slaidi lingilt leiate lühikese kirjelduse, kuidas sellega töötada.
fping asendamisest nmap'iga
A: – Kuidas te seda lõpuks realiseerisite? Võite tuua konkreetsed näited: kas teil on strappereid ja väline skript? Mis lõpuks kontrollib nii kiiresti nii suure hulga hoste? Kuidas te neid hoste hankite? Peab nmap'ile need kuidagi sisestama, millestki saama, panema, midagi käivitama?
MM: – Lahe. Väga õige küsimus! Asi on selles, et me kohandasime raamatukogu (ICMP-ping, osa "Zabbixist") ICMP-kontrollide jaoks, mille puhul on pakettide arv - üks (1), ja kood püüab kasutada nmap'i. See tähendab, et see on "Zabbixi" sisemine töö, mis on muutunud pingeriikimiseks. Seega ei ole vajalik sünkroneerimist või trapperi kasutamist. See tehti teadlikult, et süsteemi terviklikkust säilitada ning mitte süveneda kahe süsteemi andmebaaside sünkroneerimisele: mida kontrollida, andmete üleslaadimine polleri kaudu, ja kas meie üleslaadimine on katki?.. See on palju lihtsam.
A: – Kas see töötab ka proksi jaoks?
MM: – Jah, aga me ei ole testinud. Pollimise kood nii "Zabbixis" kui ka serveris on ühtne. Peaks töötama. Tõestan veel kord: süsteemi jõudlus on selline, et me ei vaja proksi.
MT: – Õige vastus küsimusele on: "Miks teil on sellise süsteemi puhul proksi?" Ainult NAT'i pärast või kui monitorida läbi aeglase kanali…
A: – Te kasutate "Zabbixit" nagu alarmisüsteemi, kui ma õigesti aru sain. Kas või graafikud (kus on arhiivi kiht) on üle viidud teise süsteemi, nagu Grafana? Või te ei kasuta seda funktsionaalsust?
MM: – Kordaks rõhutan: oleme teinud täieliku integreerimise. Me voolame ajaloo «Clickhouse'i», kuid samal ajal muutsime php-frontend'i. Php-frontend pääseb «Clickhouse'i» juurde ja kõik diagrammid tehakse sealt. Ausalt öeldes on meil osa, mis loob samast «Clickhouse'ist», samadest «Zabbixi» andmetest teistes graafikute süsteemides.
MT: – Sealhulgas «Grafanas».
Kuidas langetati otsus ja ressursi eraldamine?
A: – Jagage natuke oma ideed. Kuidas langetati otsus, et on vaja eraldada ressursid toote tõsiselt ümber töötamiseks? See on tõepoolest teatud risk. Ja palun öelge kontekstis, et te kavatsete toetada uusi versioone: kuidas seda otsust haldamise seisukohalt õigustatakse?
MM: – Tundub, et ajalugu ei ole me väga hästi jutustanud. Olime olukorras, kus midagi pidi tegema, ja läksime põhimõtteliselt kaht paralleelset teed pidi:
- Üks oli hõivatud monitoorsüsteemi käivitamisega uutel meetoditel: monitooring teenusena, standardsete avatud lahenduste komplekt, mida me kombineerime ja seejärel püüame äriprotsessi muuta, et töötada uue monitooringusüsteemiga.
- Samas oli meil entusiast-programmeerija, kes sellega tegelema hakkas (enda kohta). Nii juhtus, et ta võitis.
A: – Mis on meeskonna suurus?
MT: – See on teie ees.
A: – Kas nagu ikka on vajalik kirglik inimene?
MM: – Ma ei tea, mis asi on kirglik inimene.
A: – Antud juhul olete see ilmselt teie. Suur aitäh, te olete ägedad.
MM: – Aitäh.
Patchide kohta Zabbixis
A: – Kas lahendust, mis kasutab proksi (näiteks mõnedes jaotatud süsteemides), on võimalik kohandada ja patcheerida, ütleme, pollereid, proksi ja osaliselt Zabbixi eelprotsessorit; ja nende omavahelist suhtlust? Kas olemasolevaid lahendusi on võimalik optimeerida mitme proksi süsteemi jaoks?
MM: – Tean, et 'Zabbix' server koostatakse kaudu proksi (koostatakse ja saadakse kood). Me ei ole seda tootmises kontrollinud. Ma ei ole sellest kindel, kuid mulle tundub, et etteprotsessorihaldurit ei kasutata proksi puhul. Proksi ülesanne on võtta Zabbixist meetrikate kogum, neid töödelda (ta salvestab ka konfigureerimise, kohalikku andmebaasi) ja anda tagasi Zabbix serverile. Edasi töötleb server, kui see saab.
Proksiga seotud huvi on arusaadav. Me kontrollime seda. See on huvitav teema.
A: – Idee oli selline: kui on võimalik patšida pollereid, saab neid patšida ka proksis ja patšida serveriga suhtlemist, ning etteprotsessorit nende eesmärkide jaoks kohandada ainult serveris.
MM: – Ma arvan, et kõik on isegi lihtsam. Te võtate koodi, rakendate patši, konfigureerite siis nii, nagu vajate – kogute proksi servereid (näiteks ODBC kaudu) ja patšitud koodi jagate süsteemide vahel. Kus vaja – kogute proksi, kus vaja – server.
A: – Täiendavalt ei pea proksi ja serveri vaheline edastus ilmselt patšima?
MT: – Ei, see on standardne.
MM: – Üks idee jäi tegelikult kõlama. Oleme alati hoidnud tasakaalu ideede voo ja muudatuste arvu ning hoolduse lihtsuse vahel.
Veidi reklaami 🙂
Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. , ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).
Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas
Allikas: habr.com
