Seuraava HighLoad++-konferenssi järjestetään 6. ja 7 Pietarissa. Tiedot ja liput . HighLoad++ Moskova 2018. Hall “Moskova”. 9. marraskuuta klo 15. Opinnäytetyöt ja .
* Seuranta - online ja analytiikka.
* ZABBIX-alustan perusrajoitukset.
* Ratkaisu analytiikan tallennustilan skaalaamiseen.
* ZABBIX-palvelimen optimointi.
* Käyttöliittymän optimointi.
* Kokemus järjestelmän käytöstä yli 40 XNUMX NVPS:n kuormituksella.
* Lyhyet johtopäätökset.
Mihail Makurov (jäljempänä – MM): - Hei kaikki!
Maxim Chernetsov (jäljempänä - MCH): - Hyvää iltapäivää!
MM: – Haluan esitellä Maximin. Max on lahjakas insinööri, paras verkostoituja, jonka tiedän. Maxim on mukana verkostoissa ja palveluissa, niiden kehittämisessä ja toiminnassa.
MCH: – Ja haluaisin kertoa sinulle Mikhailista. Mikhail on C-kehittäjä. Hän kirjoitti yrityksellemme useita raskaan liikenteen käsittelyratkaisuja. Asumme ja työskentelemme Uralilla, kovien miesten kaupungissa Tšeljabinskissa, Intersvyaz-yhtiössä. Yrityksemme tarjoaa Internet- ja kaapelitelevisiopalveluita miljoonalle ihmiselle 16 kaupungissa.
MM: – Ja on syytä sanoa, että Intersvyaz on paljon enemmän kuin pelkkä palveluntarjoaja, se on IT-yritys. Suurin osa ratkaisuistamme on IT-osastomme valmistamia.
ja: liikennettä käsitteleviltä palvelimilta puhelinkeskukseen ja mobiilisovellukseen. IT-osastolla on nyt noin 80 henkilöä, joilla on hyvin, hyvin monipuolista osaamista.
Tietoja Zabbixista ja sen arkkitehtuurista
MCH: – Ja nyt yritän tehdä henkilökohtaisen ennätyksen ja sanoa yhdessä minuutissa, mikä Zabbix on (jäljempänä "Zabbix").
Zabbix asettuu yritystason valmiiksi valvontajärjestelmäksi. Siinä on monia ominaisuuksia, jotka helpottavat elämää: edistyneet eskalointisäännöt, API integrointiin, ryhmittelyyn ja isäntien ja mittareiden automaattiseen tunnistamiseen. Zabbixilla on niin sanotut skaalaustyökalut - välityspalvelimet. Zabbix on avoimen lähdekoodin järjestelmä.
Lyhyesti arkkitehtuurista. Voimme sanoa, että se koostuu kolmesta osasta:
- Palvelin. Kirjoitettu C. Melko monimutkaisella käsittelyllä ja tiedonsiirrolla säikeiden välillä. Kaikki käsittely tapahtuu siinä: vastaanottamisesta tietokantaan tallentamiseen.
- Kaikki tiedot tallennetaan tietokantaan. Zabbix tukee MySQL, PostreSQL ja Oracle.
- Verkkokäyttöliittymä on kirjoitettu PHP:llä. Useimmissa järjestelmissä sen mukana tulee Apache-palvelin, mutta se toimii tehokkaammin yhdessä nginx + php:n kanssa.
Tänään haluamme kertoa yhden Zabbixiin liittyvän tarinan yrityksemme elämästä...
Tarina Intersvyaz-yhtiön elämästä. Mitä meillä on ja mitä tarvitsemme?
5 tai 6 kuukautta sitten. Eräänä päivänä töiden jälkeen...
MCH: - Misha, hei! Olen iloinen, että sain sinut kiinni - keskustelu on käynnissä. Meillä oli jälleen ongelmia valvonnan kanssa. Suuren onnettomuuden aikana kaikki oli hidasta, eikä verkon tilasta ollut tietoa. Valitettavasti tämä ei ole ensimmäinen kerta, kun näin tapahtuu. Tarvitsen apuasi. Tehdään valvontamme toimivaksi kaikissa olosuhteissa!
MM: - Mutta synkronoidaan ensin. En ole katsonut siellä pariin vuoteen. Muistaakseni hylkäsimme Nagiosin ja vaihdoimme Zabbixiin noin 8 vuotta sitten. Ja nyt meillä näyttää olevan kuusi tehokasta palvelinta ja noin tusina välityspalvelinta. Olenko sekoittanut jotain?
MCH: - Melkein. 15 palvelinta, joista osa on virtuaalikoneita. Tärkeintä on, että se ei pelasta meitä sillä hetkellä, kun sitä eniten tarvitsemme. Kuten onnettomuus - palvelimet hidastuvat, etkä näe mitään. Yritimme optimoida kokoonpanon, mutta tämä ei tuottanut optimaalista suorituskyvyn kasvua.
MM: - Se on selvää. Katsoitko jotain, kaivotko jo jotain diagnostiikasta?
MCH: – Ensimmäinen asia, johon sinun on puututtava, on tietokanta. MySQL ladataan jatkuvasti ja tallentaa uusia mittareita, ja kun Zabbix alkaa tuottaa joukon tapahtumia, tietokanta menee ylikierrokselle kirjaimellisesti muutaman tunnin ajaksi. Kerroin jo konfiguraation optimoinnista, mutta kirjaimellisesti tänä vuonna he päivittivät laitteiston: palvelimissa on yli sata gigatavua muistia ja levyryhmiä SSD RAID -levyillä - ei ole mitään järkeä kasvattaa sitä lineaarisesti pitkällä aikavälillä. Mitä me teemme?
MM: - Se on selvää. Yleensä MySQL on LTP-tietokanta. Ilmeisesti se ei enää sovellu meidän kokoisen mitta-arkiston tallentamiseen. Selvitetään se.
MCH: - Katsotaanpa!
Zabbixin ja Clickhousen integrointi hackathonin tuloksena
Jonkin ajan kuluttua saimme mielenkiintoisia tietoja:
Suurin osa tietokannassamme olevasta tilasta oli metriikka-arkiston käytössä ja alle 1 % käytettiin konfigurointiin, malleihin ja asetuksiin. Olimme tuolloin käyttäneet Clickhouseen perustuvaa Big data -ratkaisua yli vuoden. Liikesuunta oli meille selvä. Kevään Hackathonissamme kirjoitin Zabbixin integroinnin Clickhousen kanssa palvelimelle ja käyttöliittymälle. Tuolloin Zabbixilla oli jo tuki ElasticSearchille, ja päätimme vertailla niitä.
Clickhousen ja Elasticsearchin vertailu
MM: – Vertailun vuoksi generoimme saman kuorman kuin Zabbix-palvelin tarjoaa ja katsoimme, miten järjestelmät käyttäytyisivät. Kirjoitimme tiedot 1000 rivin erissä käyttämällä CURL-osoitetta. Oletimme etukäteen, että Clickhouse olisi tehokkaampi kuormitusprofiilissa kuin Zabbix. Tulokset jopa ylittivät odotuksemme:
Samoissa testiolosuhteissa Clickhouse kirjoitti kolme kertaa enemmän dataa. Samanaikaisesti molemmat järjestelmät kuluttivat erittäin tehokkaasti (pieni määrä resursseja) dataa lukiessaan. Mutta Elastics vaati suuren määrän prosessoria tallennuksen aikana:
Kaiken kaikkiaan Clickhouse oli huomattavasti Elastixia parempi prosessorin kulutuksen ja nopeuden suhteen. Samaan aikaan Clickhouse käyttää tietojen pakkaamisen vuoksi 11 kertaa vähemmän kiintolevyä ja suorittaa noin 30 kertaa vähemmän levytoimintoja:
MCH: – Kyllä, Clickhousen työ levyalijärjestelmän kanssa on toteutettu erittäin tehokkaasti. Voit käyttää valtavia SATA-levyjä tietokantoihin ja saada kirjoitusnopeuksia satoja tuhansia rivejä sekunnissa. Valmis järjestelmä tukee jakamista, replikointia ja on erittäin helppo määrittää. Olemme enemmän kuin tyytyväisiä sen käyttöön ympäri vuoden.
Resurssien optimoimiseksi voit asentaa Clickhousen olemassa olevan päätietokantasi viereen ja säästää näin paljon suorittimen aikaa ja levytoimintoja. Olemme siirtäneet mittareiden arkiston olemassa oleviin Clickhouse-klustereihin:
Helpotimme MySQL-päätietokantaa niin paljon, että pystyimme yhdistämään sen yhdelle koneelle Zabbix-palvelimen kanssa ja luopumaan MySQL-palvelimesta.
Kuinka äänestys toimii Zabbixissa?
4 kuukautta sitten
MM: – No, voimmeko unohtaa tukikohdan ongelmat?
MCH: - Se on varmaa! Toinen ongelma, joka meidän on ratkaistava, on hidas tiedonkeruu. Nyt kaikki 15 välityspalvelinta ovat ylikuormitettuja SNMP- ja kyselyprosesseilla. Eikä ole muuta mahdollisuutta kuin asentaa uusia ja uusia palvelimia.
MM: - Loistava. Mutta kerro ensin meille, kuinka äänestys toimii Zabbixissa?
MCH: – Lyhyesti sanottuna mittareita on 20 tyyppiä ja tusinaa tapaa saada niitä. Zabbix voi kerätä tietoja joko "pyyntö-vastaus" -tilassa tai odottaa uusia tietoja Trapper Interfacen kautta.
On syytä huomata, että alkuperäisessä Zabbixissa tämä menetelmä (Trapper) on nopein.
Kuorman jakamiseen on välityspalvelimia:
Välityspalvelimet voivat suorittaa samoja keräystoimintoja kuin Zabbix-palvelin, vastaanottaa tehtäviä siltä ja lähettää kerätyt metriikat Trapper-rajapinnan kautta. Tämä on virallisesti suositeltu tapa jakaa kuorma. Välityspalvelimet ovat hyödyllisiä myös NAT:n tai hitaan kanavan kautta toimivan etäinfrastruktuurin valvontaan:
MM: – Arkkitehtuurissa kaikki on selvää. Pitää katsoa lähteitä...
Parin päivän päästä
Tarina siitä, kuinka nmap fping voitti
MM: "Luulen kaivanneeni jotain."
MCH: - Kerro minulle!
MM: – Huomasin, että Zabbix tarkistaa saatavuuden tarkistuksen yhteydessä enintään 128 isäntää kerrallaan. Yritin kasvattaa tätä lukua 500:aan ja poistaa pakettien välisen välin niiden pingistä (ping) - tämä kaksinkertaisti suorituskyvyn. Mutta haluaisin suurempia lukuja.
MCH: – Käytännössäni joudun joskus tarkistamaan tuhansien isäntien saatavuus, enkä ole koskaan nähnyt mitään nopeampaa kuin nmap tälle. Olen varma, että tämä on nopein tapa. Kokeillaan! Meidän on lisättävä merkittävästi isäntien määrää iteraatiota kohden.
MM: – Tarkista yli viisisataa? 600?
MCH: - Ainakin pari tuhatta.
MM: - OK. Tärkein asia, jonka halusin sanoa, on se, että huomasin, että suurin osa kyselyistä Zabbixissa tehdään synkronisesti. Meidän on ehdottomasti vaihdettava se asynkroniseen tilaan. Sitten voimme dramaattisesti lisätä pollaajien keräämien mittareiden määrää, varsinkin jos lisäämme mittareiden määrää iteraatiota kohti.
MCH: - Loistava! Ja milloin?
MM: – Kuten tavallista, eilen.
MCH: – Vertasimme molempia fping- ja nmap-versioita:
Monilla isännillä nmapin odotettiin olevan jopa viisi kertaa tehokkaampi. Koska nmap tarkistaa vain saatavuuden ja vasteajan, siirsimme häviölaskennan triggereihin ja pienensimme merkittävästi käytettävyyden tarkistusvälejä. Löysimme optimaalisen isäntien lukumäärän nmapille noin 4 tuhatta iteraatiota kohden. Nmap antoi meille mahdollisuuden vähentää prosessorin käytettävyystarkistusten kustannuksia kolme kertaa ja lyhentää aikaväliä 120 sekunnista 10:een.
Äänestyksen optimointi
MM: ”Sitten aloimme tehdä pollereita. Kiinnostuimme pääasiassa SNMP-tunnistuksesta ja -agenteista. Zabbixissa kyselyt tehdään synkronisesti ja järjestelmän tehokkuutta on lisätty erityistoimilla. Synkronisessa tilassa isännän epäkäytettävyys aiheuttaa merkittävää kyselyn heikkenemistä. On olemassa koko tilajärjestelmä, on erityisiä prosesseja - niin sanotut tavoittamattomat pollerit, jotka toimivat vain tavoittamattomien isäntien kanssa:
Tämä on kommentti, joka osoittaa tilamatriisin, siirtymäjärjestelmän kaiken monimutkaisuuden, jota tarvitaan, jotta järjestelmä pysyisi tehokkaana. Lisäksi synkroninen kysely itsessään on melko hidasta:
Tästä syystä tuhannet pollerivirrat kymmenillä välityspalvelimilla eivät pystyneet keräämään tarvittavaa datamäärää puolestamme. Asynkroninen toteutus ei ratkaissut vain säikeiden määrään liittyviä ongelmia, vaan myös yksinkertaisti merkittävästi poissaolevien isäntien tilajärjestelmää, koska minkä tahansa kyselyn aikana tarkastetulle numerolle maksimi odotusaika oli 1 aikakatkaisu:
Lisäksi muokkasimme ja paransimme SNMP-pyyntöjen kyselyjärjestelmää. Tosiasia on, että useimmat ihmiset eivät voi vastata useisiin SNMP-pyyntöihin samanaikaisesti. Siksi teimme hybriditilan, kun saman isännän SNMP-kysely tehdään asynkronisesti:
Tämä tehdään koko isäntäjoukolle. Tämä tila ei lopulta ole hitaampi kuin täysin asynkroninen, koska puolentoistasadan SNMP-arvon kysely on silti paljon nopeampaa kuin 1 aikakatkaisu.
Kokeilumme ovat osoittaneet, että optimaalinen pyyntöjen määrä yhdessä iteraatiossa on noin 8 tuhatta SNMP-kyselyllä. Kaiken kaikkiaan siirtyminen asynkroniseen tilaan antoi meille mahdollisuuden nopeuttaa kyselyn suorituskykyä 200 kertaa, useita satoja kertoja.
MCH: – Tuloksena saadut kyselyoptimoinnit osoittivat, että emme voi vain päästä eroon kaikista välityspalvelimista, vaan myös lyhentää monien tarkistusten aikavälejä, eikä valtakirjoja enää tarvita taakan jakamiseen.
Noin kolme kuukautta sitten
Muuta arkkitehtuuria - lisää kuormaa!
MM: - No, Max, onko aika olla tuottava? Tarvitsen tehokkaan palvelimen ja hyvän insinöörin.
MCH: - Okei, suunnitellaan se. On korkea aika siirtyä 5 tuhannen metriikan sekunnissa kuolleesta pisteestä.
Päivityksen jälkeinen aamu
MCH: - Misha, päivitimme itseämme, mutta aamulla rullasimme takaisin... Arvatkaa minkä nopeuden onnistuimme saavuttamaan?
MM: – enintään 20 tuhatta.
MCH: - Joo, 25! Valitettavasti olemme juuri siitä, mistä aloimme.
MM: - Miksi? Oletko tehnyt diagnostiikkaa?
MCH: - Toki! Tässä on esimerkiksi mielenkiintoinen toppi:
MM: - Katsotaan. Näen, että olemme kokeilleet valtavaa määrää äänestyssäikeitä:
Mutta samaan aikaan he eivät voineet kierrättää järjestelmää edes puoleen:
Ja kokonaissuorituskyky on melko pieni, noin 4 tuhatta mittaria sekunnissa:
Onko muuta?
MCH: – Kyllä, osa yhdestä äänestäjistä:
MM: – Tässä näkyy selvästi, että äänestysprosessi odottaa "semaforeja". Nämä ovat lukot:
MCH: - Epäselvä.
MM: – Katso, tämä on samanlainen tilanne, jossa joukko säikeitä yrittää työskennellä resurssilla, joita vain yksi voi työskennellä kerrallaan. Sitten he voivat vain jakaa tämän resurssin ajan myötä:
Ja tällaisen resurssin kanssa työskentelyn kokonaissuorituskykyä rajoittaa yhden ytimen nopeus:
On kaksi tapaa ratkaista tämä ongelma.
Päivitä koneen laitteisto, vaihda nopeampiin ytimiin:
Tai muuta arkkitehtuuria ja muuta samalla kuormaa:
MCH: – Muuten, testikoneella käytämme vähemmän ytimiä kuin taistelukoneessa, mutta ne ovat 1,5 kertaa nopeampia taajuudeltaan ydintä kohden!
MM: - Asia selvä? Sinun on katsottava palvelimen koodi.
Tietopolku Zabbix-palvelimessa
MCH: – Selvittääksemme sen, aloimme analysoida, kuinka tiedot siirretään Zabbix-palvelimen sisällä:
Siisti kuva, eikö? Käydään se läpi vaihe vaiheelta, jotta se olisi enemmän tai vähemmän selkeä. Tietojen keräämisestä vastaavat säikeet ja palvelut:
Ne välittävät kerätyt mittarit socketin kautta Preprocessor Manageriin, jossa ne tallennetaan jonoon:
"Esikäsittelypäällikkö" lähettää tiedot työntekijöilleen, jotka suorittavat esikäsittelykäskyt ja palauttavat ne takaisin saman pistorasian kautta:
Tämän jälkeen esikäsittelyn hallinta tallentaa ne historian välimuistiin:
Sieltä ne vievät historian uppoavat, jotka suorittavat melko monia toimintoja: esimerkiksi laskevat triggereitä, täyttävät arvovälimuistin ja mikä tärkeintä, tallentavat mittareita historiamuistiin. Yleensä prosessi on monimutkainen ja hyvin hämmentävä.
MM: – Ensimmäinen asia, jonka huomasimme, oli, että useimmat säikeet kilpailevat niin kutsutusta "määritysvälimuistista" (muistialue, johon kaikki palvelinkokoonpanot on tallennettu). Tietojen keräämisestä vastaavat säikeet estävät erityisen paljon:
...koska kokoonpano ei tallenna vain mittareita parametreineen, vaan myös jonoja, joista pollarit ottavat tietoa siitä, mitä tehdä seuraavaksi. Kun kyselyitä on useita ja yksi estää määrityksen, muut odottavat pyyntöjä:
Pollerien ei pitäisi olla ristiriidassa
Siksi ensimmäinen asia, jonka teimme, oli jakaa jono 4 osaan ja sallia pollaajien estää nämä jonot, nämä osat samanaikaisesti, turvallisissa olosuhteissa:
Tämä poisti kilpailun asetusvälimuistista, ja pollerien nopeus kasvoi merkittävästi. Mutta sitten kohtasimme sen tosiasian, että esikäsittelypäällikkö alkoi kerätä työjonoa:
Esikäsittelypäällikön on kyettävä priorisoimaan
Tämä tapahtui tapauksissa, joissa häneltä puuttui suorituskyky. Sitten hän ei voinut muuta kuin kerätä pyyntöjä tiedonkeruuprosesseista ja lisätä niiden puskuria, kunnes se kulutti kaiken muistin ja kaatui:
Tämän ongelman ratkaisemiseksi lisäsimme toisen pistorasian, joka oli omistettu erityisesti työntekijöille:
Esikäsittelypäälliköllä oli siis mahdollisuus priorisoida työnsä ja jos puskuri kasvaa, tehtävänä on hidastaa poistoa, jolloin työntekijöille on mahdollisuus ottaa tämä puskuri:
Sitten huomasimme, että yksi syy hidastumiseen oli työntekijöiden itsensä, koska he kilpailivat resurssista, joka oli heidän työlleen täysin merkityksetön. Dokumentoimme tämän ongelman virheenkorjauksena, ja se on jo ratkaistu uusissa Zabbix-versioissa:
Lisäämme pistorasioiden määrää - saamme tuloksen
Lisäksi itse esikäsittelijän hallinnasta tuli pullonkaula, koska se on yksi säie. Se perustui ydinnopeuteen, jolloin maksiminopeus oli noin 70 tuhatta metriä sekunnissa:
Siksi teimme neljä työntekijää neljällä pistorasiasarjalla:
Ja tämä antoi meille mahdollisuuden lisätä nopeutta noin 130 tuhanteen mittaan:
Kasvun epälineaarisuus selittyy sillä, että kilpailu historiakätköstä on ilmaantunut. 4 esikäsittelypäällikköä ja historian uppoajia kilpaili siitä. Tässä vaiheessa saimme testikoneeseen noin 130 tuhatta mittausta sekunnissa, mikä hyödynsi sitä noin 95 % prosessorista:
Noin 2,5 kuukautta sitten
Snmp-yhteisön kieltäytyminen lisäsi NVP:itä puolitoista kertaa
MM: – Max, tarvitsen uuden testiauton! Emme enää mahdu nykyiseen.
MCH: - Mitä sinulla on nyt?
MM: – Nyt – 130 XNUMX NVP:tä ja hyllyvalmis prosessori.
MCH: - Vau! Viileä! Odota, minulla on kaksi kysymystä. Laskelmieni mukaan tarpeemme on noin 15-20 tuhatta metriä sekunnissa. Miksi tarvitsemme lisää?
MM: "Haluan lopettaa työn." Haluaisin nähdä, kuinka paljon voimme puristaa irti tästä järjestelmästä.
MCH: - Mutta…
MM: "Mutta se on turhaa liiketoiminnalle."
MCH: - Se on selvää. Ja toinen kysymys: voimmeko tukea sitä, mitä meillä nyt on, itse, ilman kehittäjän apua?
MM: - En usko. Määritysvälimuistin toiminnan muuttaminen on ongelma. Se vaikuttaa muutoksiin useimmissa säikeissä ja on melko vaikea ylläpitää. Todennäköisesti sen ylläpitäminen on erittäin vaikeaa.
MCH: "Sitten tarvitsemme jonkinlaisen vaihtoehdon."
MM: – Sellainen vaihtoehto on olemassa. Voimme siirtyä nopeisiin ytimiin samalla kun hylkäämme uuden lukitusjärjestelmän. Saamme silti 60-80 tuhannen mittarin suorituskyvyn. Samalla voimme jättää kaiken muun koodin. Clickhouse ja asynkroninen äänestys toimivat. Ja se tulee olemaan helppo huoltaa.
MCH: - Hämmästyttävää! Ehdotan, että lopetamme tähän.
Palvelinpuolen optimoinnin jälkeen saimme vihdoin käynnistää uuden koodin tuotantoon. Luovuimme joistakin muutoksista ja siirryimme koneeseen, jossa on nopeat ytimet ja minimoimme koodimuutosten määrän. Olemme myös yksinkertaistaneet määritystä ja poistaneet makrot tietokohteista mahdollisuuksien mukaan, koska ne lisäävät lukitusta.
Esimerkiksi dokumentaatiossa ja esimerkeissä usein esiintyvästä snmp-yhteisömakrosta luopuminen mahdollisti tapauksessamme NVP:n nopeuttamisen edelleen noin 1,5-kertaisesti.
Kahden päivän tuotannon jälkeen
Tapahtumahistorian ponnahdusikkunoiden poistaminen
MCH: – Misha, olemme käyttäneet järjestelmää kaksi päivää ja kaikki toimii. Mutta vain kun kaikki toimii! Olimme suunnitelleet työtä melko suuren verkon segmentin siirtämiseksi ja tarkastelimme jälleen käsin, mikä meni ja mikä ei.
MM: - Ei voi olla! Tarkistimme kaiken 10 kertaa. Palvelin hoitaa jopa täydellisen verkkoon pääsyn puuttumisen välittömästi.
MCH: - Kyllä, ymmärrän kaiken: palvelin, tietokanta, top, austat, lokit - kaikki on nopeaa... Mutta katsomme verkkokäyttöliittymää ja palvelimella on "hyllyssä" prosessori ja tämä:
MM: - Se on selvää. Katsotaan nettiä. Huomasimme, että tilanteessa, jossa oli paljon aktiivisia tapahtumia, useimmat live-widgetit alkoivat toimia hyvin hitaasti:
Syynä tähän oli tapahtumahistorian ponnahdusikkunoiden luominen, jotka luodaan jokaiselle luettelon kohteelle. Siksi hylkäsimme näiden ikkunoiden luomisen (kommentoimme 5 riviä koodissa), ja tämä ratkaisi ongelmamme.
Widgetien latausaika, vaikka ne olisivat täysin poissa käytöstä, on lyhennetty useista minuuteista meille hyväksyttävään 10-15 sekuntiin, ja historiaa voi edelleen tarkastella klikkaamalla kellonaikaa:
Töiden jälkeen. 2 kuukautta sitten
MCH: - Misha, oletko lähdössä? Meidän täytyy puhua.
MM: - En aikonut. Jotain Zabbixista taas?
MCH: - Ei, rentoudu! Halusin vain sanoa: kaikki toimii, kiitos! Minulla on olut.
Zabbix on tehokas
Zabbix on melko yleinen ja rikas järjestelmä ja toiminto. Sitä voidaan käyttää pieniin asennuksiin, mutta tarpeiden kasvaessa se on optimoitava. Jos haluat tallentaa suuren mitta-arkiston, käytä sopivaa tallennustilaa:
- voit käyttää sisäänrakennettuja työkaluja integroinnin muodossa Elasticsearchiin tai historian lataamiseen tekstitiedostoihin (saatavilla versiosta XNUMX);
- Voit hyödyntää kokemustamme ja integraatiotamme Clickhousen kanssa.
Voit nopeuttaa mittareiden keräämistä dramaattisesti keräämällä ne asynkronisilla menetelmillä ja lähettämällä ne trapper-rajapinnan kautta Zabbix-palvelimelle; tai voit tehdä Zabbix-pollereista asynkronisia korjaustiedoston avulla.
Zabbix on kirjoitettu C-kielellä ja on melko tehokas. Useiden arkkitehtonisten pullonkaulojen ratkaiseminen mahdollistaa sen suorituskyvyn lisäämisen entisestään ja kokemuksemme mukaan yli 100 XNUMX mittarin saamisen yhden prosessorin koneella.
Sama Zabbix-laastari
MM: – Haluan lisätä muutaman huomautuksen. Koko nykyinen raportti, kaikki testit ja numerot on annettu käyttämällemme kokoonpanolle. Otamme nyt siitä noin 20 tuhatta mittausta sekunnissa. Jos yrität ymmärtää, toimiiko tämä sinulle, voit vertailla. Se, mistä tänään keskusteltiin, on julkaistu GitHubissa korjaustiedoston muodossa:
Laastari sisältää:
- täydellinen integrointi Clickhousen kanssa (sekä Zabbix-palvelin että käyttöliittymä);
- ongelmien ratkaiseminen esikäsittelyn johtajan kanssa;
- asynkroninen äänestys.
Korjaus on yhteensopiva kaikkien versioiden 4 kanssa, mukaan lukien lts. Todennäköisesti pienillä muutoksilla se toimii versiossa 3.4.
Kiitos huomiota.
kysymykset
Kysymys yleisöltä (jäljempänä – A): – Hyvää iltapäivää! Kerro minulle, onko sinulla suunnitelmia intensiiviseen vuorovaikutukseen Zabbix-tiimin kanssa tai heidän kanssaan, jotta tämä ei ole korjaustiedosto, vaan Zabbixin normaali käyttäytyminen?
MM: – Kyllä, osan muutoksista tulemme ehdottomasti toteuttamaan. Jotain tapahtuu, jotain jää laastariin.
ja: – Paljon kiitoksia erinomaisesta raportista! Kerro minulle, että Zabbixin tuki säilyy päivityksen asentamisen jälkeen ja kuinka jatkaa päivitystä korkeampiin versioihin? Voiko Zabbixin päivittää päivityksen jälkeen versioon 4.2, 5.0?
MM: – Tuesta en osaa sanoa mitään. Jos olisin Zabbixin tekninen tuki, sanoisin luultavasti ei, koska tämä on jonkun muun koodi. Mitä tulee 4.2-koodikantaan, kantamme on: "Muutemme ajan kanssa ja päivitämme itsemme seuraavaan versioon." Siksi julkaisemme jonkin aikaa korjaustiedoston päivitetyille versioille. Sanoin jo raportissa: versioiden muutosten määrä on vielä melko pieni. Luulen, että siirtyminen 3.4:stä 4:ään vei noin 15 minuuttia.. Jotain siinä muuttui, mutta ei kovin tärkeää.
ja: – Aiot siis tukea korjaustiedostoasi ja voit turvallisesti asentaa sen tuotantoon ja saada päivityksiä jollain tavalla tulevaisuudessa?
MM: – Suosittelemme lämpimästi. Tämä ratkaisee meille monia ongelmia.
MCH: – Haluan vielä kerran kiinnittää huomiota siihen, että muutokset, jotka eivät koske arkkitehtuuria eivätkä koske estoa tai jonoja, ovat modulaarisia, ne ovat erillisissä moduuleissa. Pienilläkin muutoksilla voit ylläpitää niitä melko helposti.
MM: – Jos olet kiinnostunut yksityiskohdista, niin “Clickhouse” käyttää ns. historiakirjastoa. Se on irrotettu - se on kopio Elastics-tuesta, eli se on konfiguroitavissa. Äänestys muuttaa vain kyselyitä. Uskomme, että tämä toimii pitkään.
ja: - Kiitos paljon. Kerro, onko tehdyistä muutoksista dokumentaatiota?
MM: – Dokumentaatio on korjaustiedosto. Ilmeisesti Clickhousen käyttöönoton ja uudentyyppisten pollereiden käyttöönoton myötä syntyy uusia konfigurointivaihtoehtoja. Viimeisen dian linkissä on lyhyt kuvaus sen käytöstä.
Tietoja fping:n korvaamisesta nmapilla
ja: – Miten lopulta toteutit tämän? Voitko antaa konkreettisia esimerkkejä: onko sinulla hihnat ja ulkoinen käsikirjoitus? Mikä päätyy tarkistamaan niin valtavan määrän isäntiä niin nopeasti? Kuinka louhit nämä isännät? Pitääkö meidän syöttää ne jotenkin nmappiin, hankkia ne jostain, laittaa ne sisään, ajaa jotain?..
MM: - Siistiä. Todella oikea kysymys! Pointti on tämä. Muokkasimme kirjastoa (ICMP ping, osa Zabbixia) ICMP-tarkistuksia varten, jotka osoittavat pakettien lukumäärän - yksi (1), ja koodi yrittää käyttää nmapia. Eli tämä on Zabbixin sisäinen työ, josta on tullut pingerin sisäinen työ. Näin ollen ei vaadita synkronointia tai trapperin käyttöä. Tämä tehtiin tarkoituksella, jotta järjestelmä jäisi koskemattomaksi eikä joutuisi käsittelemään kahden tietokantajärjestelmän synkronointia: mitä tarkistaa, ladata pollerin kautta ja onko lataus rikki?.. Tämä on paljon yksinkertaisempaa.
ja: – Toimiiko se myös välityspalvelimella?
MM: – Kyllä, mutta emme tarkistaneet. Pollauskoodi on sama sekä Zabbixissa että palvelimessa. Pitäisi toimia. Korostan vielä kerran: järjestelmän suorituskyky on sellainen, että emme tarvitse välityspalvelinta.
MCH: – Oikea vastaus kysymykseen on: "Miksi tarvitset välityspalvelimen tällaisella järjestelmällä?" Vain NAT:n tai jonkinlaisen hitaan kanavan kautta tapahtuvan valvonnan takia...
ja: – Ja käytät Zabbixia hermostona, jos ymmärrän oikein. Vai onko grafiikkasi (missä arkistokerros on) siirretty toiseen järjestelmään, kuten Grafanaan? Vai etkö käytä tätä toimintoa?
MM: – Korostan vielä kerran: olemme saavuttaneet täydellisen integraation. Kaadamme historiaa Clickhouseen, mutta samalla olemme muuttaneet php-käyttöliittymää. Php-käyttöliittymä menee Clickhouseen ja tekee kaiken grafiikan sieltä. Samaan aikaan, ollakseni rehellinen, meillä on osa, joka rakentaa tietoja muissa graafisissa näyttöjärjestelmissä samasta Clickhousesta, samoista Zabbix-tiedoista.
MCH: – Myös "Grafanissa".
Miten resurssien kohdentamiseen liittyvät päätökset tehtiin?
ja: – Jaa vähän sisäkeittiöstäsi. Miten päätettiin, että tuotteen vakavaan käsittelyyn oli kohdistettava resursseja? Nämä ovat yleensä tiettyjä riskejä. Ja kerro minulle sen tosiasian yhteydessä, että aiot tukea uusia versioita: miten tämä päätös oikeuttaa johdon näkökulmasta?
MM: – Ilmeisesti emme kertoneet kovin hyvin historian draamaa. Jouduimme tilanteeseen, jossa jotain oli tehtävä, ja menimme käytännössä kahden rinnakkaisen joukkueen kanssa:
- Yksi oli seurantajärjestelmän käynnistäminen uusilla menetelmillä: seuranta palveluna, vakiokokonaisuus avoimen lähdekoodin ratkaisuja, jotka yhdistämme ja yritämme sitten muuttaa liiketoimintaprosessia, jotta se toimisi uuden seurantajärjestelmän kanssa.
- Samaan aikaan meillä oli innokas ohjelmoija, joka teki tätä (itsestään). Niin kävi, että hän voitti.
ja: – Ja mikä on joukkueen koko?
MCH: - Hän on edessäsi.
ja: – Joten, kuten aina, tarvitset intohimoisen?
MM: – En tiedä mikä intohimo on.
ja: - Tässä tapauksessa ilmeisesti sinä. Kiitos paljon, olet mahtava.
MM: - Kiitos.
Tietoja Zabbixin korjaustiedostoista
ja: – Onko järjestelmässä, joka käyttää välityspalvelimia (esimerkiksi joissakin hajautetuissa järjestelmissä), mahdollista mukauttaa ja korjata esimerkiksi pollerit, välityspalvelimet ja osittain itse Zabbixin esiprosessori? ja heidän vuorovaikutuksensa? Onko mahdollista optimoida olemassa olevat kehitystyöt järjestelmälle, jossa on useita välityspalvelimia?
MM: – Tiedän, että Zabbix-palvelin kootaan välityspalvelimen avulla (koodi käännetään ja hankitaan). Emme ole testanneet tätä tuotannossa. En ole varma tästä, mutta mielestäni esikäsittelyn hallintaa ei käytetä välityspalvelimessa. Välityspalvelimen tehtävänä on ottaa Zabbixista joukko mittareita, yhdistää ne (se myös tallentaa konfiguraation, paikallisen tietokannan) ja antaa ne takaisin Zabbix-palvelimelle. Palvelin itse suorittaa esikäsittelyn, kun se vastaanottaa sen.
Kiinnostus valtakirjoja kohtaan on ymmärrettävää. Tarkistamme sen. Tämä on mielenkiintoinen aihe.
ja: – Ajatus oli seuraava: jos voit korjata pollereita, voit korjata ne välityspalvelimella ja paikata vuorovaikutusta palvelimen kanssa ja sovittaa esiprosessorin näihin tarkoituksiin vain palvelimella.
MM: – Minusta se on vielä yksinkertaisempaa. Otat koodin, asennat korjaustiedoston ja määrität sen sitten haluamallasi tavalla - kerää välityspalvelimet (esimerkiksi ODBC:llä) ja jaat korjatun koodin järjestelmille. Tarvittaessa - kerää välityspalvelin, tarvittaessa - palvelin.
ja: – Todennäköisesti sinun ei tarvitse korjata välityspalvelimen lähetystä palvelimelle?
MCH: - Ei, se on vakio.
MM: – Itse asiassa yksi ajatuksista ei kuulostanut. Olemme aina säilyttäneet tasapainon ideoiden räjähdysmäisen ja muutosten määrän ja tuen helppouden välillä.
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com