HighLoad++, Mihail Makurov, Maxim Černetsov (Intersvyaz): Zabbix, 100kNVPS ühel serveril

Järgmine HighLoad++ konverents toimub 6. ja 7. aprillil 2020 Peterburis. Üksikasjad ja piletid linki pidi. HighLoad++ Moskvas 2018. Saal "Moskva". 9. november, 15:00. Teesid ja esitlus.

* Jälgimine - reaalajas ja analüütika.
* ZABBIXi platvormi põhipiirangud.
* Lahendus analüütilise salvestamise skaleerimiseks.
* ZABBIXi serveri optimeerimine.
* UI optimeerimine.
* Kogemus süsteemi kasutamisest üle 40k NVPS koormuse korral.
* Lühidalt järeldused.

Mikhail Makurov (edasi – MM): – Kõigile tere!

Maksim Tšernecov (edasi – MT): – Tere päevast!

MM: – Lubage mul tutvustada Maksimit. Maksim on andekas insener, parim võrguspetsialist, keda ma tunnen. Maksim tegeleb võrkude ja teenuste arendamise ja haldamisega.

MT: – Ja ma sooviksin rääkida Mihhailist. Mihhail on C keele arendaja. Ta on meie ettevõtte jaoks kirjutanud mitmeid kõrgkoormusega lahendusi liikluse töötlemiseks. Me elame ja töötame Uuralites, karmide meeste linnas Tšeljabinski, firmas "Intersvyaz". Meie ettevõte on interneti- ja kaabeltelevisiooniteenuste pakkuja miljonile inimesele 16 linnas.

MM: – Ja tuleks mainida, et "Intersvyaz" on palju enamat kui lihtsalt teenusepakkuja, see on IT-ettevõte. Enamik meie lahendustest on loodud meie IT-osakonna jõududega.

A: serveritest, mis töötlevad liiklust, kuni kõnekeskuse ja mobiilirakenduseni. IT-osakonnas on hetkel umbes 80 inimest, kellel on väga ja väga erinevad oskused.

Zabbixist ja selle arhitektuurist

MT: – Nüüd proovin ma seada isiklikku rekordit ja minutiga seletada, mis on Zabbix (edasi – "Zabbix").

"Zabbix" positsioneerib end ettevõtte tasandi "lahtiselt" jälgimissüsteemina. Sellest leiate palju elu lihtsustavaid funktsioone: arenenud eskalatsiooni reeglid, API integreerimiseks, hostide ja mõõdikute rühmitamine ning automaatne avastamine. "Zabbix"is on nn skaleerimise tööriistad - proksid. "Zabbix" on avatud lähtekoodiga süsteem.

Lühidalt arhitektuurist. Selle võib jagada kolmeks komponendiks:

• Server. Kirjutatud C keeles. Piisavalt keeruka infovoogude töötlemise ja edastamisega. Kõik töötlemine toimub seal: andmete vastuvõtmisest andmebaasi salvestamiseni.
• Kõik andmed salvestatakse andmebaasis. "Zabbix" toetab MySQL, PostgreSQL ja Oracle.
• Veebiliides on kirjutatud PHP-s. Suuremas osas süsteemidest tuleb see koos Apache serveriga, kuid töötab efektiivsemalt koos nginx + php-iga.

Täna tahaksime jagada ühte meie ettevõtte elu lugu, mis on seotud "Zabbixiga"...

Lugu ettevõttest "Intersside". Mida meil on ja mida on vaja?

5 või 6 kuud tagasi. Ühel õhtul pärast tööd...

MT: – Miša, tere! Tore, et suutsin sind kinni püüda – mul on juttu. Meil olid jälle probleemid jälgimisega. Suure avarii ajal kõik seisis ja ei olnud mingit teavet võrgu seisundi kohta. Kahjuks on see juba mitte esmakordselt. Mul on vaja sinu abi. Teeme nii, et meie jälgimine töötaks igasugustes oludes!

MM: – Aga kõigepealt sünkroniseerime end. Ma pole sinna paar aastat vaatamas käinud. Kui ma õigesti mäletan, loobusime Nagiosest ja läksime "Zabbixile" umbes 8 aastat tagasi. Ja praegu on meil näiliselt 6 võimsat serverit ja paar tosinat proksi. Kas ma segan midagi?

MT: – Peaaegu. 15 serverit, millest osa on virtuaalmasinad. Peamine probleem on see, et see ei aita meid siis, kui meil seda kõige rohkem vaja on. Iga avarii korral serverid seisavad ja midagi ei paista. Oleme proovinud konfiguratsiooni optimeerida, kuid see ei anna optimaalset jõudluse kasvu.

MM: – Selge. Kas oled midagi vaadanud, kas on midagi diagnoosimise käigus välja kaevatud?

MT: – Esimene probleem, millega kokku puutume, on just andmebaas. MySQL on pidevalt koormatud uute metrikate salvestamisega, ja kui "Zabbix" hakkab genereerima hulgaliselt sündmusi, läheb andmebaas täiesti kinni tavaliselt paariks tunniks. Konfiguratsiooni optimeerimisest rääkisin juba, kuid just sel aastal värskendasime riistvara: serverites on üle saja gigabaidi mälust ja SSD RAID-ide ketasmassiivid – ei ole mõtet seda edasi lineaarselt kasvatada. Mida teeme?

MM: – Selge. Üldiselt on MySQL LTP-andmebaas. Tundub, et see ei sobi enam meie suurte metrikate arhiivi hoidmiseks. Hakka uurima.

MT: – Hakkame!

Zabbixi ja Clickhouse'i integreerimine hackathoni lõpptulemusena

Mõne aja pärast saime huvitavaid andmeid:

Enamik ruumi meie andmebaasis oli hõivatud metrikate arhiiviga ning vähem kui 1% kasutati konfiguratsiooni, malli ja seadistuste jaoks. Sel ajal olime juba üle aasta kasutanud Big Data lahendust Clickhouse'i baasil. Meie suund oli ilmne. Meie kevadisest „Hakatonist” kirjutasin integraatsiooni „Zabbixi” ja „Clickhouse'i” jaoks serverile ja frontendile. Tol ajal oli „Zabbixis” juba toetatud ElasticSearch ja otsustasime neid võrrelda.

Clickhouse'i ja Elasticsearchi võrdlus

MM: – Võrdlemiseks genereerisime koormust, mis oli sama, nagu tagab „Zabbixi” server, ja vaatasime, kuidas süsteemid käituvad. Kirjutasime andmeid partiidena 1000 rida, kasutasime CURLi. Oletasime eelnevalt, et „Clickhouse” on selle koormusprofiili jaoks efektiivsem. Tulemused ületasid isegi meie ootusi:

Katses samaalustes tingimustes kirjutas „Clickhouse” kolm korda rohkem andmeid. Samas kasutasid mõlemad süsteemid andmete lugemisel väga efektiivselt (vähenenud ressursside hulga). Kuid kirjutamise ajal vajas „Elasticsearch” suures koguses protsessorit:

Kokkuvõttes ületas „Clickhouse” märkimisväärselt „Elasticsearchi” protsessorite kasutuse ja kiirusest. Samuti kasutab „Clickhouse” andmete tihendamise abil 11 korda vähem ruumi kõvakettal ning teeb umbes 30 korda vähem kettatehinguid:

MT: – Jah, „Clickhouse'i” kettaseadmega töötamine on väga efektiivselt realiseeritud. Andmebaaside jaoks saab kasutada suuri SATA-ketasid ja saavutada kirjutamiskiirus sadu tuhandeid ridu sekundis. Süsteem toetab „karbist väljas” šardimist, replikatsiooni ja on väga lihtsalt seadistatav. Oleme rohkem kui rahul selle kasutamisega aasta jooksul.

Ressursside optimeerimiseks saab „Clickhouse'i” paigaldada olemasoleva põhiandmebaasi vahetusse lähedusse ja sellega säästa palju protsessorite aega ja kettatehinguid. Oleme viinud metrikate arhiivi juba olemasolevatele „Clickhouse'i” klastritele:

Oleme peamise MySQL andmebaasi nii kergelt koormust vähendanud, et saime selle ühendada ühel masinal „Zabbixi” serveriga ja loobuda eraldi serverist MySQL jaoks.

Kuidas toimib polling Zabbixis?

4 kuud tagasi

MM: – Noh, kas andmebaasi probleemidest võib nüüd unustada?

MT: – See on kindel! Teine ülesanne, mille peame lahendama, on aeglane andmete kogumine. Nüüd on kõik meie 15 proksiserverit üle koormatud SNMP protsesside ja polling'uga. Ja ei ole muud võimalust, kui lihtsalt uute serverite seadistamine.

MM: – Suurepärane. Aga räägi esmalt, kuidas toimub polling 'Zabbix'is?

MT: – Lühidalt öeldes on olemas 20 tüüpi mõõdikuid ja kümme erinevat viisi nende hankimiseks. 'Zabbix' saab koguda andmeid kas "päring - vastus" režiimis või oodata uusi andmeid "Trapperi liidese" kaudu.

Tasub märkida, et originaalses 'Zabbix'is on see meetod (Trapper) kõige kiirem.

On olemas proksiserverid koormuse jagamiseks:

Proksid saavad täita samu andmete kogumise funktsioone nagu 'Zabbix' server, saades sellest ülesandeid ja saadetedes kogutud mõõdikud just läbi Trapperi liidese. See on ametlikult soovitatud koormuse jaotamise meetod. Samuti on proksid kasulikud kaug-infrastruktuuri jälgimiseks, mis töötab läbi NAT või aeglase kanali:

MM: – Arhitektuur on arusaadav. Tuleb vaadata lähtekoodi...

Mõni päev hiljem

Lugu sellest, kuidas nmap ja fping võitsid

MM: – Tundub, et ma leidsin midagi.

MT: – Räägi!

MM: – Otsides kättesaadavust avastasin, et 'Zabbix' kontrollib korraga maksimaalselt 128 hosti. Proovisin seda arvu suurendada 500-le ja eemaldasin nende pingeni (ping) vahe - see kahekordistas jõudlust. Aga tahaksin suuremaid numbreid.

MT: – Oma praktikas pean mõnikord kontrollima tuhandeid hoste ning ma ei ole leidnud midagi kiiremat kui nmap. Olen kindel, et see on kõige kiirem meetod. Proovime seda! Peame märkimisväärselt suurendama hostide arvu ühe iteratsiooni jooksul.

MM: – Kontrollida rohkem kui viissada? 600?

MT: – Vähemalt paar tuhat.

MM: – Okei. Kõige tähtsam, mida tahtsin öelda: leidsin, et enamik polling'ust 'Zabbix'is on tehtud sünkroonselt. Peame selle kindlasti ümber töötama asünkroonseks. Siis saame dramaatiliselt suurendada mõõdikute arvu, mida pollingud koguvad, eriti kui suurendame mõõdikute arvu ühe iteratsiooni kohta.

MT: – Suurepärane! Ja millal?

MM: – Nagu tavaliselt, eile.

MT: – Võrdlesime mõlemaid versioone fping ja nmap:

Paljude hostide puhul oli nmap ootuspäraselt kuni viis korda tõhusam. Kuna nmap kontrollib ainult ligipääsetavust ja reaktsiooniaega, viisin kaotuste arvestamise triggereisse ja lühendasin märgatavalt ligipääsetavuse kontrollimise intervalli. Optimaalseks hostide arvuks nmap'i jaoks leidsime umbes 4000 ühe iteratsiooni kohta. Nmap võimaldas meil kolm korda vähendada CPU koormust ligipääsetavuse kontrollimiseks ja lühendada intervalli 120 sekundilt 10 sekundile.

Pollimise optimeerimine

MM: – Siis tegelesime polleritega. Peamiselt huvitavad meid SNMP kogumid ja agendid. „Zabbix’is” on pollimine tehtud sünkroonselt ning on rakendatud erilisi meetmeid süsteemi efektiivsuse suurendamiseks. Sünkroonses režiimis põhjustab hostide ligipääsetamatuse oluliselt pollimise halvenemist. Eksisteerib terviklik olekute süsteem, seal on erilised protsessid – nn unreachable-pollereid, mis töötavad ainult ligipääsmatute hostidega:

See on kommentaar, mis demonstreerib olekute maatriksit ja kogu süsteemi üleminekute keerukust, mis on vajalik süsteemi efektiivsena hoidmiseks. Lisaks on sünkroonne pollimine piisavalt aeglane:

Seetõttu ei suutnud tuhanded pollerite lõimed kümnel pöördumisel koguda meile vajalikku andmemassi. Asünkroonne realiseerimine lahendas mitte ainult lõimede arvu probleemid, vaid lihtsustas oluliselt ligipääsematute hostide olekute süsteemi, kuna ühes pollimise iteratsioonis kontrollitava arvu juures oli maksimaalne ootamise aeg 1 aegumine:

Lisaks modifitseerisime ja täiustasime SNMP päringute pollimise süsteemi. Asi on selles, et enamus ei suuda vastata mitmele SNMP päringule korraga. Seetõttu tegime hübriidrežiimi, kus ühe ja sama hosti SNMP pollimine toimub asünkroonselt:

See kehtib kogu hostide partii kohta. Selline režiim ei ole lõpuks aeglasem kui täielikult asünkroonne, kuna poolteist sadat SNMP väärtuse küsitlemine on ikkagi oluliselt kiirem kui 1 aegumine.

Meie eksperimendid näitasid, et optimaalseks päringute arvuks ühes iteratsioonis on umbes 8000 SNMP pollimise puhul. Kokkuvõttes võimaldas üleminek asünkroonsesse režiimi kiirendada pollimise jõudlust 200 korda, mitusada korda.

MT: – Saadud pollingu optimeerimised näitasid, et saame mitte ainult loobuda kõigist proksidest, vaid ka vähendada paljude kontrollide intervallide pikkust, ning proksid ei ole enam vajalikud koormuse jaotamise meetodina.

Umbes kolm kuud tagasi

Muuda arhitektuuri – suurenda koormust!

MM: – Noh, Max, kas on aeg tootmisse minna? Mul on vaja võimsat serverit ja head inseneri.

MT: – Hästi, plaanime. On aeg liikuda edasi 5000 meetrika sekundis.

Hommik pärast uuendust

MT: – Misha, me uuendasime, kuid hommikuks said tagasi tagasi… Arva, millise kiiruseni me jõudsime?

MM: – Tuhat 20 maksimaalselt.

MT: – Aha, 25! Kahjuks oleme seal, kus alustasime.

MM: – Miks nii? Kas tehti mingi diagnostika?

MT: – Jah, loomulikult! Vaata, siin on näiteks huvitav top:

MM: – Vaata, ma näen, et oleme proovinud tohutult palju pollingu teemasid:

Aga samas ei suutnud me süsteemi isegi poole võrra ära kasutada:

Ja kogu tootlikkus on piisavalt väike, umbes 4000 meetrika sekundis:

Kas on midagi veel?

MT: – Jah, ühe polleri strace:

MM: – Siit on selgelt näha, et pollingu protsess ootab "semaforeid". Need on lukud:

MT: – Ebaselge.

MM: – Vaata, see näeb välja nagu olukord, kus hulk teemasid üritab töötada ressursiga, millega saab samal ajal töötada vaid üks inimene. Siis saavad nad seda ressurssi ainult ajaliselt jagada:

Ja sellise ressursiga töötamise kogutootlikkus on piiratud ühe tuuma kiiruseta:

Tõsta selline probleem on võimalik kahte moodi.

Uuendada masina riistvara, minna kiirematele tuumadele:

Või muuta arhitektuuri ja samal ajal – koormust:

MT: – Muide, testmasinas kasutame vähem tuumasid kui tootmises, kuid need on tuumade sageduse järgi 1,5 korda kiiremad!

MM: – Selge? Peame vaatama serveri koodi.

Andmete tee Zabbix serveris

MT: – Probleemi mõistmiseks hakkasime analüüsima, kuidas andmed Zabbix serveris edastatakse:

Lahe pilt, eks? Läheme seda samm-sammult uurima, et veidi selgemaks saada. Andmete kogumise eest vastutavad voolud ja teenused:

Kogutud meetrikad edastatakse socketi kaudu ettevalmistajate haldurile, kus need salvestatakse järjekorda:

Ettevalmistajate haldur edastab andmed oma töötajatele, kes täidavad ettevalmistamisjuhised ja edastavad need tagasi sama socketi kaudu:

Pärast seda salvestab eelprotsessorihaldur need ajaloosirde vahemälu.

Sealt võtavad need andmesünkroniseerijad, kes täidavad mitmeid ülesandeid: näiteks trigerite arvutamine, väärtuste vahemälu täitmine ja, mis kõige tähtsam, meetrite salvestamine ajaloos. Üldiselt on protsess keeruline ja üsna segane.

MM: – Esimene asi, mida me nägime, oli see, et enamus vooge konkureerib nn "konfiguratsiooni vahemälu" pärast (mäluala, kus hoitakse kõik serveri konfiguratsioonid). Eriti palju lukustusi teevad vood, mis vastutavad andmete väljavõtmise eest:

…sest konfiguratsioonis hoitakse mitte ainult meetmeid koos nende parameetritega, vaid ka järjekordi, millest pollijad võtavad teavet selle kohta, mida nad edasi tegema peavad. Kui pollijaid on palju ja üks lukustab konfiguratsiooni, peavad teised ootama päringute tegemist:

Pollijad ei tohiks konfliktida

Seetõttu esimene asi, mida me tegime, oli jagada järjekord neljaks osaks ja lubada pollijatel ohututes tingimustes neid järjekordi, neid osi samal ajal lukustada:

See kaotas konkurentsi konfiguratsiooni vahemälu pärast ja pollijate töökiirus suurenes märkimisväärselt. Kuid seejärel seisime silmitsi probleemiga, et eelprotsessorihaldur hakkas ülesandejärjekorda koguma:

Eelprotsessorihaldur peab olema suuteline prioriteete seadma

See juhtus juhtudel, kui tal puudus jõudlus. Siis sai ta ainult koguda päringuid andmete kogumise protsessidelt ja hoida neid vahemikus, kuni see võttis kogu mälu ja kukkus kokku:

Selle probleemi lahendamiseks lisasime teise pistiku, mis oli spetsiaalselt eraldatud töötajatele:

Nii sai eelprotsessorihaldur võimaluse oma tööd prioriseerida ja juhul, kui puhversalv suurenes, suudab ta peatada andmete väljavõtmise, andes töötajatele võimaluse see puhversalv ära võtta:

Seejärel avastasime, et üks aeglustumise põhjuseid olid töötajad ise, kuna nad konkureerisid täiesti nende töö jaoks ebaolulise ressursiga. Selle probleemi lahendasime bogi-parandusega, ja uutes "Zabbixi" versioonides on see juba lahendatud:

Suurendame pistikute arvu – saavutame tulemuse

Seejärel sai eelprotsessorihaldur kitsaskohaks, kuna see on ühe vooga. Ta piirab südamiku kiirus, andes maksimaalse kiirus umbes 70 tuhat meetrit sekundis:

Seetõttu tegime neli erinevat töötlusseadet nelja pistikuga,

Ja see võimaldas kiirusel tõusta umbes 130 000 metrikani:

Mittejooneline kasv on tingitud konkurentsist ajaloo vahemälu pärast. Selle eest võitlesid neli eeltöötlus-juhti ja ajaloosünkroniseerijad. Selleks ajaks saime testmasinas umbes 130 000 metrikat sekundis, kasutades umbes 95% protsessorist:

Umbes 2,5 kuud tagasi

SNMP-kogukonnast loobumine tõstis NVP-sid pooleteise korra võrra

MM: – Max, mul on vaja uut testmasinat! Praegu ei mahu me enam sisse.

MT: – Mis seal praegu on?

MM: – Praegu – 130k NVP-d ja protsessor "seisab".

MT: – Vau! Kift! Oota, mul on kaks küsimust. Minu arvutuste kohaselt on meie vajadus umbes 15-20 tuhat metrikat sekundis. Miks me vajame rohkem?

MM: – Tahaksime asja lõpuni viia. Tahaks teada, kui palju me suudame sellest süsteemist välja pigistada.

MT: – Aga...

MM: – Aga see on ettevõtte jaoks kasutuskõlbmatu.

MT: – Selge. Ja teine küsimus: kas seda, mis meil praegu on, saame me iseseisvalt toetada, ilma arendaja abita?

MM: – Ma ei arva. Konfiguratsioonivahendi töö muutmine on probleem. See puudutab enamikke vooge ja on piisavalt keeruline hooldada. Tõenäoliselt on selle hooldamine väga keeruline.

MT: – Siis on vaja mõnda alternatiivi.

MM: – On selline variant. Saame minna kiiremate tuumade peale ja loobuda uue lukustussüsteemi kasutamisest. Saame ikkagi 60-80 tuhat metrikat. Samuti saame hoida kogu muu koodi. "ClickHouse", asünkroonne pollimine jääb tööle. Ja seda on kerge hooldada.

MT: – Suurepärane! Pakun, et peame siin peatuma.

Pärast serveripoolse optimiseerimist suutsime lõpuks uut koodi tootmisse viia. Me loobusime osast muudatustest kiiremate tuumade masinale ülemineku ja koodimuudatuste arvu minimoimise kasuks. Lihtsustasime ka konfiguratsiooni ning lõime võimalusel makrosid andmeelementides, kuna need on täiendavate lukustuste allikaks.

Näiteks loobumine sageli esinevast SNMP-kogukonna makrost meie dokumentatsioonis ja näidetes võimaldas NVP-sid kiirusel veel 1,5 korda kiirendada.

Pärast kahte päeva tootmises

Eemaldame hädaolukordade ajaloo hüpikaknad

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 planeeritud tööd, kus viidi üle piisavalt suur võrgu segment, ja me kontrollisime käsitsi, mis töötab ja mis mitte.

MM: – Ei saa olla! Me kontrollisime kõike 10 korda. Server töötleb isegi täieliku võrgu mittesaatvust hetkega.

MT: – Ma saan aru: server, andmebaas, top, austat, logid – kõik on kiire… Aga me vaatame veebiliidest, ja seal on serveri protsessor 'puhkusel' ning see:

MM: – Arusaadav. Vaatame veebiliidest. Me avastasime, et olukordades, kus oli suur hulk aktiivseid intsidente, hakkas enamik operatiivseid vidinaid töötama väga aeglaselt:

Selle põhjuseks oli hüpikakende genereerimine intsidentide ajalooga, mis genereeritakse iga nimekirjas oleva elemendi jaoks. Seetõttu loobusime nende akende genereerimisest (kommenteerisime 5 rida koodi) ja see lahendas meie probleemid.

Vidinate laadimisaeg isegi täieliku mittesaatvuse korral vähenes mõnest minutist meie jaoks vastuvõetavatesse 10-15 sekundisse, ja ajalugu on endiselt võimalik vaadata aja peale klikkides:

Pärast tööd. 2 kuud tagasi

MT: – Misha, lahkud? On juttu.

MM: – Ei plaaninud. Jälle midagi 'Zabbixi' käes?

MT: – Ei, rahune maha! Tahtsin lihtsalt öelda: kõik töötab, aitäh! Minu arvelt õlu.

Zabbix on efektiivne

'Zabbix' on piisavalt mitmekülgne ja rikkaliku süsteemi ning funktsiooniga. Seda võib täiesti kasutada väikeste installeerimiste jaoks 'kastist välja', kuid vajaduste kasvades on seda vaja optimeerida. Suure arhiivi metrikate hoidmiseks kasutage sobivat salvestust:

• võite kasutada sisseehitatud vahendeid nagu 'Elasticsearch' integratsioon või ajaloo eksportimine tekstifailidesse (saadaval neljandast versioonist);
• võite kasutada meie kogemusi ja integratsiooni 'ClickHouse'iga.

Metrikate kogumise kiirusel radikaalseks suurenemiseks koguge neid asünkroonsete meetodite abil ja edastage need trapperi liidese kaudu 'Zabbixi' serverisse; või võite kasutada patši 'Zabbix'i pollerite asünkroonsuse jaoks.

«Zabbix» on kirjutatud C keeles ja on üsna efektiivne. Teatud kitsaskohtade arhitektuur võimaldab selle jõudlust veelgi suurendada ja meie kogemuse kohaselt saab ühe protsessoriga masinal üle 100 000 mõõdiku.

See on Zabbixi patš.

MM: – Soovin lisada paar punkti. Kõik praegused ettekanded, testid ja numbrid on esitatud selle konfiguratsiooni kohta, mida meie kasutame. Meie süsteem suudab praegu koguda umbes 20 000 mõõdikut sekundis. Kui üritate mõista, kas see toimib teie jaoks – saate võrrelda. Seda, millest täna rääkisime, on saadaval GitHubis patšina: github.com/miklert/zabbix

Patš sisaldab:

• täielikku integreerimist «ClickHouse'iga» (nii «Zabbixi» serverite kui ka frontendi jaoks);
• probleemide lahendamine eelprotsessorihalduriga;
• asünkroonne polling.

Patš on ühilduv kogu 4.0 versiooniga, sealhulgas lts-iga. Tõenäoliselt toimib see väikeste muudatustega ka versioonis 3.4.

Aitäh tähelepanu eest.

Küsimused

Küsimus publikust (edaspidi – K): – Tere päevast! Palun öelge, kas teil on plaanis tihe koostöö Zabbixi meeskonnaga või ka nende poolt teiega, et see ei oleks lihtsalt patš, vaid Zabbixi normaalne käitumine?

MM: – Jah, me kindlasti salvestame osa muudatusi. Midagi jääb siiski patši sisse.

A: – Suur tänu suurepärase ettekande eest! Palun öelge, kas pärast patši rakendamist jääb Zabbixi tugi alles ja kuidas edasi uute versioonide peale uuendada? Kas on võimalik uuendada Zabbixi teie patši 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 tegemist on võõra koodiga. Mis puudutab koodibaasi 4.2, siis meie seisukoht on selline: „Me kavatseme ajaga kaasas käia ja uuendada järgmisele versioonile”. Seega avaldame mõne aja jooksul patši uuendatud versioonidele. Olen juba ettekandes öelnud: muudatuste arv versioonide vahel on küllaltki väike. Arvan, et üleminek 3.4-lt 4.0-le võttis aega umbes 15 minutit. Seal on midagi muutunud, aga see ei ole oluliselt tähtis.

A: – Ehk kavatsete toetada oma patši ja seda on ohutu rakendada tootmisse, saades hiljem uuendusi?

MM: – Me soovitame seda kategooriliselt. See lahendab meie jaoks väga palju probleeme.

MT: – Veel tahan uuesti rõhutada, et muudatused, mis ei puuduta arhitektuuri ega blokeeringut ega järjekordi – need on moodulised, need on eraldi moodulites. Isegi iseseisvalt, isegi väikeste muudatuste korral, on neid suhteliselt lihtne hallata.

MM: – Kui huvi pakuvad detailid, siis "ClickHouse" kasutab nn ajaloo raamatukogu. See on lahtiseotatud – see on "Elasticsearchi" toe koopia, st seda saab konfigureerida. Pollimine muudab ainult pollereid. Usume, et see töötab kaua.

A: – Aitäh palju. Kas oskate öelda, kas on olemas mingit dokumentatsiooni tehtud muudatuste kohta?

MM: – Dokumentatsioon on patch. Ilmselgelt, koos "ClickHouse'i" kasutuselevõtuga, uute pollerite tüüpide kasutuselevõtuga ilmnevad uued konfigureerimisvõimalused. Viimase slaidi lingil on lühike kirjeldus, kuidas sellega töötada.

Fpingi asendamine nmapiga

A: – Kuidas te selle lõppkokkuvõttes ellu viisite? Võite anda konkreetsed näited: kas teil on strapid ja väline skript? Mis kontrollib nii kiiresti nii suurt hulka hoste? Kuidas te need hostid hankite? Kas nmap peab neid kuidagi toitma, saama kuskilt, panema, midagi käivitama?

MM: – Lahe. Väga hea küsimus! Sisu on selline. Muutsime raamatukogu (ICMP-ping, osa "Zabbixi" süsteemist) ICMP-kontrollide jaoks, kus on määratud pakettide arv – üks (1), ja kood proovib kasutada nmapi. See tähendab, et see on "Zabbixi" sisemine töö, see on saanud pingija sisemiseks tööks. Seega ei ole mingit sünkroonimist ega trapperi kasutamist vajalik. See tehti teadlikult, et süsteem jääks terviklikuks ja ei peaks tegelema kahe baas-süsteemi sünkroonimisega: mida kontrollida, laadida polleri kaudu, ja kas our laadimine ei ole rikki läinud? See on palju lihtsam.

A: – Kas see töötab ka proksi jaoks?

MM: – Jah, aga me ei ole seda kontrollinud. Pollimise kood on nii "Zabbixis" kui ka serveris ühesugune. Peaks töötama. Veel kord rõhutan: süsteemi jõudlus on selline, et me ei vaja proksi.

MT: – Õige vastus küsimusele on: "Miks teil sellise süsteemi juures proksi on?" Ainult NAT'i tõttu või jälgida mõne aeglase kanali kaudu?

A: – Kas te kasutate "Zabbixit" ärevusnäitaja (alert) rollis, kui ma õigesti aru sain. Või on teie graafikud (kus on arhiivikiht) läinud teise süsteemi, nagu Grafana? Või te ei kasuta seda funktsiooni?

MM: – Ma rõhutan veel kord: me oleme teinud täieliku integreerimise. Me edastame ajaloo "ClickHouse'i", kuid samal ajal muutsime php-frontendi. Php-frontend jõuab "ClickHouse'i" ja kõiki diagramme tehakse sealt. Peale selle, kui aus olla, meil on osa, mis koostab samast "ClickHouse'ist", samadest Zabbixi andmetest andmeid teiste graafiliste kuvamiste süsteemide jaoks.

MT: – Sealhulgas "Grafana's".

Kuidas tehti otsus ja ressursside eraldamine?

A: – Jagage natuke sisemist kööki. Kuidas tehti otsus, et tuleb eraldada ressursse toote tõsiseks ümberkujundamiseks? See on üldiselt teatud riskid. Ja palun öelge kontekstis, et kavatsete toetada uusi versioone: kuidas see otsus juhimise seisukohalt õigustatakse?

MM: – Tundub, et ajaloost ei ole me väga hästi rääkinud. Me sattusime olukorda, kus midagi tuli teha, ja läksime tegelikult kahe paralleelse meeskonnaga:

• Üks tegeles uute meetodite põhjal jälgimise süsteemi käivitamisega: jälgimine kui teenus, standardne komplekt avatud lähtekoodiga lahendusi, mida me kombineerime ja püüame siis muuta äri protsessi, et töötada uue jälgimissüsteemiga.
• Samas oli meil entusiast-programmeerija, kes sellega tegeles (iseendast). Nii juhtus, et tema võitis.

A: – Ja kui suur on meeskond?

MT: – Ta on teie ees.

A: – Kas nagu alati on vajalik kirglik inimene?

MM: – Ma ei tea, mis on kirglik inimene.

A: – Antud juhul ilmselt te. Suur tänu, te olete toredad.

MM: – Aitäh.

Patchide kohta Zabbixile

A: – Kas on võimalik teie lahendust kohandada ja patchida, ütleme, pollereid, proksi ja osaliselt Zabbixi enda eeltöötlejat; ja nende koostööd? Kas praeguseid arenguid on võimalik optimeerida mitmete proksidega süsteemi jaoks?

MM: – Ma tean, et Zabbixi server koostatakse proksi abil (kompilleeritakse ja saadakse kood). Me ei ole seda tootmises kontrollinud. Ma ei ole selles kindel, aga minu arvates ei kasutata proksi puhul eeltöötlejat. Proksi ülesanne on võtta komplekt mõõdikuid Zabbixilt, neid koguda (see salvestab ka konfiguratsiooni, kohaliku andmebaasi) ja anda tagasi Zabbixi serverile. Eeltöötlemise teeb siis server, kui ta selle kätte saab.

Huvi proksi vastu on arusaadav. Kontrollime seda. See on huvitav teema.

A: – Idee oli selline: kui saab patšida pollereid, saab neid patšida prokside jaoks ja kohandada serveri jaoks eeltöötlust.

MM: – Arvan, et asi on isegi lihtsam. Te võtate koodi, rakendate patši, konfigureerite selle endale sobivaks – koostate proksiserverid (näiteks ODBC abil) ja jagate patšitud koodi süsteemidesse. Kus on vaja – panete kokku proksid, kus on vaja – serveri.

A: – Täiendavat proksi edastamise patšimist serverile ei tule ilmselt teha?

MT: – Ei, see on standardselt.

MM: – Tegelikult ei kõlanud ükski ideedest. Oleme alati hoidnud tasakaalu ideede plahvatuse ja muudatuste arvu, hooldatavuse lihtsuse vahel.

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. Pilve VPS arendajatele alates $4.99, ainulaadne entry-level serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas jagada serverit õigesti? (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).

Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest Kuidas luua ettevõtte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?

Allikas: habr.com