La sekva HighLoad++-konferenco okazos la 6-an kaj 7-an de aprilo 2020 en Sankt-Peterburgo Detaloj kaj biletoj . HighLoad++ Moskvo 2018. Salono "Moskvo". 9-a de novembro, 15:00. Tezoj kaj .
* Monitorado - interreta kaj analitiko.
* Bazaj limigoj de la platformo ZABBIX.
* Solvo por grimpi analizan stokadon.
* Optimumigo de la servilo ZABBIX.
* Optimumigo de UI.
* Spertu funkciigante la sistemon sub ŝarĝoj de pli ol 40k NVPS.
* Mallongaj konkludoj.
Miĥail Makurov (ĉi-poste - MM): - Saluton al ĉiuj!
Maxim Chernetsov (ĉi-poste - MCH): - Bonan posttagmezon!
MM: – Mi prezentu Maksim. Max estas talenta inĝeniero, la plej bona retumanto, kiun mi konas. Maxim estas implikita en retoj kaj servoj, ilia evoluo kaj funkciado.
MCH: – Kaj mi ŝatus rakonti al vi pri Miĥail. Mikhail estas C-programisto. Li skribis plurajn altŝarĝajn trafikajn prilaborajn solvojn por nia kompanio. Ni loĝas kaj laboras en Uralo, en la urbo de malmolaj viroj Ĉeljabinsk, en la kompanio Intersvyaz. Nia kompanio estas provizanto de interretaj kaj kablotelevidaj servoj por unu miliono da homoj en 16 urboj.
MM: – Kaj indas diri, ke Intersvyaz estas multe pli ol nur provizanto, ĝi estas IT-kompanio. Plej multaj el niaj solvoj estas faritaj de nia IT-sekcio.
A: de serviloj pritraktantaj trafikon al vokcentro kaj movebla aplikaĵo. La IT-sekcio nun havas ĉirkaŭ 80 homojn kun tre, tre diversaj kompetentecoj.
Pri Zabbix kaj ĝia arkitekturo
MCH: – Kaj nun mi provos starigi personan rekordon kaj diri en unu minuto kio estas Zabbix (ĉi-poste nomata "Zabbix").
Zabbix poziciigas sin kiel entrepren-nivelan eksterordinaran monitoradsistemon. Ĝi havas multajn funkciojn, kiuj faciligas la vivon: altnivelaj reguloj de eskalado, API por integriĝo, grupiĝo kaj aŭtomata detekto de gastigantoj kaj metrikoj. Zabbix havas tiel nomatajn skalajn ilojn - prokurojn. Zabbix estas malfermkoda sistemo.
Mallonge pri arkitekturo. Ni povas diri, ke ĝi konsistas el tri komponantoj:
- Servilo. Skribita en C. Kun sufiĉe kompleksa prilaborado kaj translokigo de informoj inter fadenoj. Ĉiu prilaborado okazas en ĝi: de ricevado ĝis konservado al la datumbazo.
- Ĉiuj datumoj estas konservitaj en la datumbazo. Zabbix subtenas MySQL, PostreSQL kaj Oracle.
- La retinterfaco estas skribita en PHP. En plej multaj sistemoj ĝi venas kun Apache-servilo, sed funkcias pli efike kombine kun nginx + php.
Hodiaŭ ni ŝatus rakonti unu rakonton el la vivo de nia kompanio rilata al Zabbix...
Rakonto el la vivo de la kompanio Intersvyaz. Kion ni havas kaj kion ni bezonas?
antaŭ 5 aŭ 6 monatoj. Unu tagon post laboro...
MCH: - Miŝa, saluton! Mi ĝojas, ke mi sukcesis kapti vin - estas konversacio. Ni denove havis problemojn kun monitorado. Dum grava akcidento, ĉio estis malrapida kaj ne estis informoj pri la stato de la reto. Bedaŭrinde, ĉi tio ne estas la unua fojo, ke tio okazas. Mi bezonas vian helpon. Ni funkciu nian monitoradon en ajna cirkonstanco!
MM: - Sed ni unue sinkronigu. Mi ne rigardis tien dum kelkaj jaroj. Kiom mi memoras, ni forlasis Nagios kaj ŝanĝis al Zabbix antaŭ ĉirkaŭ 8 jaroj. Kaj nun ni ŝajnas havi 6 potencajn servilojn kaj proksimume dekduon da prokuriloj. Ĉu mi konfuzas ion?
MCH: - Preskaŭ. 15 serviloj, kelkaj el kiuj estas virtualaj maŝinoj. La plej grava afero estas, ke ĝi ne savas nin en la momento, kiam ni plej bezonas ĝin. Kiel akcidento - la serviloj malrapidiĝas kaj vi nenion povas vidi. Ni provis optimumigi la agordon, sed ĉi tio ne disponigis la optimuman rendimenton pliiĝon.
MM: - Estas klare. Ĉu vi rigardis ion, ĉu vi jam elfosis ion el la diagnozo?
MCH: – La unua afero, kiun vi devas trakti, estas la datumbazo. MySQL estas konstante ŝarĝita, stokante novajn metrikojn, kaj kiam Zabbix komencas generi amason da eventoj, la datumbazo iras en trorapidumon dum laŭvorte kelkaj horoj. Mi jam rakontis al vi pri optimumigo de la agordo, sed laŭvorte ĉi-jare ili ĝisdatigis la aparataron: la serviloj havas pli ol cent gigabajtojn da memoro kaj disko-tabeloj sur SSD RAID-oj - ne utilas linie kreskigi ĝin longtempe. Kion ni faru?
MM: - Estas klare. Ĝenerale, MySQL estas LTP-datumbazo. Ŝajne, ĝi ne plu taŭgas por konservi arkivon de metrikoj de nia grandeco. Ni eltrovu ĝin.
MCH: - Ni!
Integriĝo de Zabbix kaj Clickhouse kiel rezulto de la hakatono
Post iom da tempo ni ricevis interesajn datumojn:
Plejparto de la spaco en nia datumbazo estis okupita de la metrika arkivo kaj malpli ol 1% estis uzata por agordo, ŝablonoj kaj agordoj. Antaŭ tiu tempo, ni funkciis la Granda datuma solvo bazita sur Clickhouse dum pli ol jaro. La direkto de movado estis evidenta al ni. Ĉe nia printempa Hackathon, mi skribis la integriĝon de Zabbix kun Clickhouse por la servilo kaj fasado. Tiutempe, Zabbix jam havis subtenon por ElasticSearch, kaj ni decidis kompari ilin.
Komparo de Clickhouse kaj Elasticsearch
MM: – Por komparo, ni generis la saman ŝarĝon kiel la servilo Zabbix provizas kaj rigardis kiel la sistemoj kondutus. Ni skribis datumojn en aroj de 1000 linioj, uzante CURL. Ni anticipe supozis, ke Clickhouse estus pli efika por la ŝarĝa profilo, kiun Zabbix faras. La rezultoj eĉ superis niajn atendojn:
Sub la samaj testkondiĉoj, Clickhouse skribis trioble pli da datumoj. Samtempe, ambaŭ sistemoj konsumis tre efike (malgranda kvanto da rimedoj) dum legado de datumoj. Sed Elastiko postulis grandan kvanton da procesoro dum registrado:
Entute, Clickhouse estis signife pli alta ol Elastix koncerne procesoran konsumon kaj rapidecon. Samtempe, pro datumkunpremado, Clickhouse uzas 11 fojojn malpli sur la malmola disko kaj faras proksimume 30 fojojn malpli da diskoperacioj:
MCH: - Jes, la laboro de Clickhouse kun la disksubsistemo estas efektivigita tre efike. Vi povas uzi grandegajn SATA-diskojn por datumbazoj kaj akiri skribrapidojn de centoj da miloj da linioj sekundo. La senfina sistemo subtenas sharding, reproduktadon, kaj estas tre facile agordi. Ni estas pli ol kontentaj pri ĝia uzo dum la tuta jaro.
Por optimumigi rimedojn, vi povas instali Clickhouse apud via ekzistanta ĉefa datumbazo kaj tiel ŝpari multe da CPU-tempo kaj diskoperacioj. Ni movis la arkivon de metrikoj al ekzistantaj Clickhouse-aretoj:
Ni malpezigis la ĉefan MySQL-datumbazon tiom multe, ke ni povis kombini ĝin sur unu maŝino kun la Zabbix-servilo kaj forlasi la dediĉitan servilon por MySQL.
Kiel funkcias balotado en Zabbix?
4 monatoj
MM: – Nu, ĉu ni povas forgesi pri la problemoj kun la bazo?
MCH: - Tiu certas! Alia problemo, kiun ni devas solvi, estas malrapida kolekto de datumoj. Nun ĉiuj niaj 15 prokuraj serviloj estas troŝarĝitaj per SNMP kaj balotprocezoj. Kaj estas neniu maniero krom instali novajn kaj novajn servilojn.
MM: - Bonege. Sed unue, diru al ni kiel funkcias balotado en Zabbix?
MCH: – Mallonge, estas 20 specoj de metrikoj kaj dekduo manieroj akiri ilin. Zabbix povas kolekti datumojn aŭ en la "peto-responda" reĝimo, aŭ atendi novajn datumojn per la "Trapper Interface".
Rimarkindas, ke en la originala Zabbix ĉi tiu metodo (Trapper) estas la plej rapida.
Estas prokurserviloj por ŝarĝa distribuo:
Prokuriloj povas plenumi la samajn kolektofunkciojn kiel la Zabbix-servilo, ricevante taskojn de ĝi kaj sendante la kolektitajn metrikojn tra la Trapper-interfaco. Ĉi tiu estas la oficiale rekomendita maniero distribui la ŝarĝon. Prokuriloj ankaŭ estas utilaj por monitorado de malproksima infrastrukturo funkcianta per NAT aŭ malrapida kanalo:
MM: – Ĉio estas klara kun arkitekturo. Ni devas rigardi la fontojn...
Kelkajn tagojn poste
La rakonto pri kiel nmap fping venkis
MM: "Mi pensas, ke mi elfosis ion."
MCH: - Diru al mi!
MM: – Mi malkovris, ke kontrolante haveblecon, Zabbix kontrolas maksimume 128 gastigantojn samtempe. Mi provis pliigi ĉi tiun nombron al 500 kaj forigi la inter-pakatan intervalon en ilia ping (ping) - tio duobligis la rendimenton. Sed mi ŝatus pli grandajn nombrojn.
MCH: – En mia praktiko, mi foje devas kontroli la haveblecon de miloj da gastigantoj, kaj mi neniam vidis ion pli rapide ol nmap por ĉi tio. Mi certas, ke ĉi tio estas la plej rapida maniero. Ni provu ĝin! Ni devas signife pliigi la nombron da gastigantoj per ripeto.
MM: – Kontroli pli ol kvincent? 600?
MCH: - Almenaŭ du miloj.
MM: - BONE. La plej grava afero, kiun mi volis diri, estas, ke mi trovis, ke la plej multaj balotadoj en Zabbix estas sinkrone. Ni certe devas ŝanĝi ĝin al nesinkrona reĝimo. Tiam ni povas draste pliigi la nombron da metrikoj kolektitaj de balotantoj, precipe se ni pliigas la nombron da metrikoj per ripeto.
MCH: - Bonege! Kaj kiam?
MM: – Kiel kutime, hieraŭ.
MCH: - Ni komparis ambaŭ versiojn de fping kaj nmap:
Sur granda nombro da gastigantoj, nmap estis atendita esti ĝis kvinoble pli efika. Ĉar nmap nur kontrolas haveblecon kaj respondtempon, ni movis la kalkulon de perdoj al ellasiloj kaj signife reduktis la havebleckontrolajn intervalojn. Ni trovis, ke la optimuma nombro da gastigantoj por nmap estas ĉirkaŭ 4 mil per ripeto. Nmap permesis al ni redukti la CPU-koston de haveblecaj kontroloj je tri fojojn kaj redukti la intervalon de 120 sekundoj al 10.
Optimumigo de balotado
MM: “Tiam ni komencis fari enketistojn. Ni ĉefe interesiĝis pri SNMP-detekto kaj agentoj. En Zabbix, balotado estas farita sinkrone kaj specialaj iniciatoj estis prenitaj por pliigi la efikecon de la sistemo. En sinkrona reĝimo, gastiga malhavebleco kaŭzas signifan balotan degeneron. Estas tuta sistemo de ŝtatoj, ekzistas specialaj procezoj - la tiel nomataj neatingeblaj enketistoj, kiuj funkcias nur kun neatingeblaj gastigantoj:
Ĉi tio estas komento kiu montras la ŝtatmatricon, la tutan kompleksecon de la sistemo de transiroj kiuj estas postulataj por ke la sistemo restu efika. Krome, sinkrona balotado mem estas sufiĉe malrapida:
Tial miloj da enketfluoj sur dekoj da prokuriloj ne povis kolekti la bezonatan kvanton da datumoj por ni. La nesinkrona efektivigo solvis ne nur la problemojn pri la nombro da fadenoj, sed ankaŭ signife simpligis la ŝtatan sistemon de nedisponeblaj gastigantoj, ĉar por iu ajn nombro kontrolita en unu balota ripeto, la maksimuma atendotempo estis 1 tempoforigo:
Aldone, ni modifis kaj plibonigis la balotsistemon por SNMP-petoj. Fakte, plej multaj homoj ne povas respondi al pluraj SNMP-petoj samtempe. Tial, ni faris hibridan reĝimon, kiam SNMP-sondado de la sama gastiganto estas farita nesinkrone:
Ĉi tio estas farita por la tuta pako da gastigantoj. Ĉi tiu reĝimo finfine ne estas pli malrapida ol tute nesinkrona, ĉar balotado de cent kaj duono da SNMP-valoroj daŭre estas multe pli rapida ol 1-tempo.
Niaj eksperimentoj montris, ke la optimuma nombro da petoj en unu ripeto estas proksimume 8 mil kun SNMP-sondado. Entute, la transiro al nesinkrona reĝimo permesis al ni akceli balotan rendimenton je 200 fojojn, plurcent fojojn.
MCH: – La rezultaj balotaj optimumoj montris, ke ni povas ne nur forigi ĉiujn prokurojn, sed ankaŭ redukti la intervalojn por multaj kontroloj, kaj prokuriloj ne plu estos bezonataj kiel maniero dividi la ŝarĝon.
Antaŭ ĉirkaŭ tri monatoj
Ŝanĝu la arkitekturon - pliigu la ŝarĝon!
MM: - Nu, Maks, ĉu estas tempo produktiĝi? Mi bezonas potencan servilon kaj bonan inĝenieron.
MCH: - Bone, ni planu ĝin. Jam estas tempo movi de la morta punkto de 5 mil metrikoj por sekundo.
Matene post la ĝisdatigo
MCH: - Miŝa, ni ĝisdatigis nin, sed antaŭ la mateno ni retroiris... Divenu, kian rapidecon ni sukcesis atingi?
MM: – 20 mil maksimume.
MCH: - Jes, 25! Bedaŭrinde, ni estas ĝuste kie ni komencis.
MM: - Kial? Ĉu vi faris iun diagnozon?
MCH: - Jes certa! Jen, ekzemple, interesa supro:
MM: - Ni rigardu. Mi vidas, ke ni provis grandegan nombron da balotfadenoj:
Sed samtempe ili ne povis recikli la sistemon eĉ je duono:
Kaj la ĝenerala rendimento estas sufiĉe malgranda, ĉirkaŭ 4 mil metrikoj por sekundo:
Ĉu estas io alia?
MCH: – Jes, spuro de unu el la enketistoj:
MM: – Ĉi tie vi povas klare vidi, ke la balotprocezo atendas "semaforojn". Ĉi tiuj estas la seruroj:
MCH: - Neklara.
MM: – Rigardu, ĉi tio similas al situacio, kie amaso da fadenoj provas labori kun rimedoj, kun kiuj nur unu povas labori samtempe. Tiam ĉio, kion ili povas fari, estas dividi ĉi tiun rimedon laŭlonge de la tempo:
Kaj la totala agado labori kun tia rimedo estas limigita de la rapideco de unu kerno:
Estas du manieroj solvi ĉi tiun problemon.
Ĝisdatigu la aparataron de la maŝino, ŝanĝu al pli rapidaj kernoj:
Aŭ ŝanĝu la arkitekturon kaj samtempe ŝanĝu la ŝarĝon:
MCH: – Cetere, ĉe la testmaŝino ni uzos malpli da kernoj ol ĉe la batala, sed ili estas 1,5 fojojn pli rapidaj laŭ frekvenco po kerno!
MM: - Klara? Vi devas rigardi la servilan kodon.
Datuma vojo en Zabbix-servilo
MCH: – Por eltrovi ĝin, ni komencis analizi kiel datumoj estas transdonitaj en la Zabbix-servilo:
Mirinda bildo, ĉu ne? Ni trarigardu ĝin paŝon post paŝo por pli-malpli klara. Estas fadenoj kaj servoj respondecaj pri kolektado de datumoj:
Ili transdonas la kolektitajn metrikojn per ingo al la Preprocesor-manaĝero, kie ili estas konservitaj en atendovico:
La "antaŭprocesora administranto" transdonas datumojn al siaj laboristoj, kiuj plenumas antaŭprilaborajn instrukciojn kaj resendas ilin tra la sama ingo:
Post tio, la antaŭprocesora administranto konservas ilin en la historia kaŝmemoro:
De tie ili estas prenitaj de historiaj sinkers, kiuj plenumas sufiĉe multajn funkciojn: ekzemple kalkuli ellasilon, plenigi la valorkaŝmemoron kaj, plej grave, ŝpari metrikojn en la historia stokado. Ĝenerale, la procezo estas kompleksa kaj tre konfuza.
MM: – La unua afero, kiun ni vidis, estis, ke la plej multaj fadenoj konkuras por la tiel nomata "agorda kaŝmemoro" (la memorareo kie ĉiuj servilaj agordoj estas stokitaj). Fadenoj respondecaj pri kolektado de datumoj faras precipe multe da blokado:
...ĉar la agordo stokas ne nur metrikojn kun siaj parametroj, sed ankaŭ vostojn de kiuj balotantoj prenas informojn pri tio, kion fari poste. Kiam estas multaj enketistoj kaj unu blokas la agordon, la aliaj atendas petojn:
Enketistoj ne devus konflikti
Tial, la unua afero, kiun ni faris, estis dividi la vicon en 4 partojn kaj permesi al balotantoj bloki ĉi tiujn vicojn, tiujn partojn samtempe, en sekuraj kondiĉoj:
Tio forigis konkuradon pri la agorda kaŝmemoro, kaj la rapideco de balotantoj pliiĝis signife. Sed tiam ni renkontis la fakton, ke la antaŭprocesora administranto komencis amasigi vicon da laborpostenoj:
Antaŭprocesora administranto devas povi prioritati
Ĉi tio okazis en kazoj kie mankis al li efikeco. Tiam ĉio, kion li povis fari, estis amasigi petojn de datumkolektaj procezoj kaj aldoni ilian bufron ĝis ĝi konsumis la tutan memoron kaj kraŝis:
Por solvi ĉi tiun problemon, ni aldonis duan ingon, kiu estis dediĉita specife al laboristoj:
Tiel, la administranto de antaŭprocesoro havis la ŝancon prioritati sian laboron kaj, se la bufro kreskas, la tasko estas malrapidigi la forigon, donante al laboristoj la ŝancon preni ĉi tiun bufron:
Tiam ni malkovris, ke unu el la kialoj de la malrapidiĝo estis la laboristoj mem, ĉar ili konkuris por rimedo tute negrava por ilia laboro. Ni dokumentis ĉi tiun problemon kiel korekton, kaj ĝi jam estis solvita en novaj versioj de Zabbix:
Ni pliigas la nombron da ingoj - ni ricevas la rezulton
Plue, la antaŭprocesora administranto mem iĝis proplemkolo, ĉar ĝi estas unu fadeno. Ĝi ripozis sur la kernrapideco, donante maksimuman rapidecon de proksimume 70 mil metrikoj je sekundo:
Tial ni faris kvar, kun kvar aroj da ingoj, laboristoj:
Kaj ĉi tio permesis al ni pliigi la rapidecon al proksimume 130 mil metrikoj:
La nelineareco de kresko estas klarigita per la fakto, ke konkurenco por la historia kaŝmemoro aperis. 4 antaŭprocesormanaĝeroj kaj historia sinkers konkuris pri ĝi. Je ĉi tiu punkto, ni ricevis proksimume 130 mil metrikojn je sekundo sur la testa maŝino, uzante ĝin ĉirkaŭ 95% de la procesoro:
Antaŭ ĉirkaŭ 2,5 monatoj
Rifuzo de snmp-komunumo pliigis NVP-ojn je unu kaj duono fojojn
MM: – Maks, mi bezonas novan testaŭton! Ni ne plu taŭgas en la nunan.
MCH: - Kion vi havas nun?
MM: – Nun – 130k NVP-oj kaj breto-preta procesoro.
MCH: - Ŭaŭ! Mirinda! Atendu, mi havas du demandojn. Laŭ miaj kalkuloj, nia bezono estas ĉirkaŭ 15-20 mil metrikoj por sekundo. Kial ni bezonas pli?
MM: "Mi volas fini la laboron." Mi ŝatus vidi kiom ni povas elpremi el ĉi tiu sistemo.
MCH: - Sed…
MM: "Sed ĝi estas senutila por komerco."
MCH: - Estas klare. Kaj la dua demando: ĉu ni povas subteni tion, kion ni nun havas memstare, sen la helpo de programisto?
MM: - Mi ne pensas. Ŝanĝi kiel funkcias la agorda kaŝmemoro estas problemo. Ĝi influas ŝanĝojn en la plej multaj fadenoj kaj estas sufiĉe malfacile konservi. Plej verŝajne, estos tre malfacile konservi ĝin.
MCH: "Do ni bezonas ian alternativon."
MM: - Estas tia opcio. Ni povas ŝanĝi al rapidaj kernoj, dum ni forlasas la novan ŝlosan sistemon. Ni ankoraŭ ricevos rendimenton de 60-80 mil metrikoj. Samtempe, ni povas lasi la tutan reston de la kodo. Clickhouse kaj nesinkrona balotado funkcios. Kaj ĝi estos facile konservi.
MCH: - Mirinda! Mi proponas, ke ni haltu ĉi tie.
Post optimumigo de la servila flanko, ni finfine povis lanĉi la novan kodon en produktadon. Ni forlasis kelkajn el la ŝanĝoj en favoro de ŝanĝi al maŝino kun rapidaj kernoj kaj minimumigi la nombron da kodaj ŝanĝoj. Ni ankaŭ simpligis la agordon kaj forigis makroojn en datumeroj kie eble, ĉar ili enkondukas plian ŝlosadon.
Ekzemple, forlasi la snmp-komunuman makroon, kiu ofte troviĝas en dokumentado kaj ekzemploj, en nia kazo ebligis plirapidigi NVP-ojn ĉirkaŭ 1,5 fojojn.
Post du tagoj en produktado
Forigo de okazaĵhistoriaj ŝprucfenestroj
MCH: – Miŝa, ni uzas la sistemon dum du tagoj, kaj ĉio funkcias. Sed nur kiam ĉio funkcias! Ni planis laboron kun la translokigo de sufiĉe granda segmento de la reto, kaj ni denove kontrolis per niaj manoj kio iris kaj kio ne.
MM: - Ne povas esti! Ni kontrolis ĉion 10 fojojn. La servilo traktas eĉ kompletan retan nehaveblecon tuj.
MCH: - Jes, mi komprenas ĉion: servilo, datumbazo, supro, aŭstat, protokoloj - ĉio estas rapida... Sed ni rigardas la retinterfacon, kaj estas procesoro "en la breto" sur la servilo kaj ĉi tio:
MM: - Estas klare. Ni rigardu la retejon. Ni trovis, ke en situacio kie estis granda nombro da aktivaj okazaĵoj, la plej multaj vivaj fenestraĵoj komencis funkcii tre malrapide:
La kialo de tio estis la generacio de okazaĵhistoriaj ŝprucfenestroj, kiuj estas generitaj por ĉiu ero en la listo. Tial ni forlasis la generacion de ĉi tiuj fenestroj (komentis 5 liniojn en la kodo), kaj ĉi tio solvis niajn problemojn.
La ŝarĝotempo por fenestraĵoj, eĉ kiam tute nedisponebla, estis reduktita de kelkaj minutoj al la akcepteblaj 10-15 sekundoj por ni, kaj la historio ankoraŭ povas esti vidita klakante sur la tempo:
Post laboro. antaŭ 2 monatoj
MCH: - Miŝa, ĉu vi foriras? Ni devas paroli.
MM: - Mi ne intencis. Ĉu io kun Zabbix denove?
MCH: - Ne, malstreĉu! Mi volis nur diri: ĉio funkcias, dankon! Mi havas bieron.
Zabbix estas efika
Zabbix estas sufiĉe universala kaj riĉa sistemo kaj funkcio. Ĝi povas esti uzata por malgrandaj instalaĵoj el la skatolo, sed kiam bezonoj kreskas, ĝi devas esti optimumigita. Por konservi grandan arkivon de metrikoj, uzu taŭgan stokadon:
- vi povas uzi enkonstruitajn ilojn en formo de integriĝo kun Elasticsearch aŭ alŝuto de historio al tekstaj dosieroj (havebla de versio 4);
- Vi povas utiligi nian sperton kaj integriĝon kun Clickhouse.
Por draste pliigi la rapidecon de kolektado de metrikoj, kolektu ilin uzante nesinkronajn metodojn kaj elsendu ilin tra la kaptilinterfaco al la servilo Zabbix; aŭ vi povas uzi diakilon por fari Zabbix-enketistojn nesinkronajn.
Zabbix estas skribita en C kaj estas sufiĉe efika. Solvi plurajn arkitekturajn botelojn permesas vin pligrandigi ĝian rendimenton kaj, laŭ nia sperto, akiri pli ol 100 mil metrikojn sur unu-procesora maŝino.
La sama Zabbix-peceto
MM: – Mi volas aldoni kelkajn punktojn. La tuta aktuala raporto, ĉiuj testoj, nombroj estas donitaj por la agordo, kiun ni uzas. Ni nun prenas proksimume 20 mil metrikojn por sekundo de ĝi. Se vi provas kompreni ĉu ĉi tio funkcios por vi, vi povas kompari. Kio estis diskutita hodiaŭ estas afiŝita sur GitHub en formo de flikaĵo:
La diakilo inkluzivas:
- plena integriĝo kun Clickhouse (kaj Zabbix-servilo kaj fasado);
- solvante problemojn kun la antaŭprocesora administranto;
- nesinkrona balotado.
La flikaĵo kongruas kun ĉiuj versioj 4, inkluzive de lts. Plej verŝajne, kun minimumaj ŝanĝoj ĝi funkcios en versio 3.4.
Dankon pro via atento.
Viaj demandoj
Demando de la publiko (ĉi-poste – A): – Bonan posttagmezon! Bonvolu diri al mi, ĉu vi havas planojn por intensa interago kun la Zabbix-teamo aŭ kun ili kun vi, por ke ĉi tio ne estu flikaĵo, sed normala konduto de Zabbix?
MM: – Jes, ni certe faros kelkajn el la ŝanĝoj. Io okazos, io restos en la diakilo.
A: – Koran dankon pro la bonega raporto! Bonvolu diri al mi, post apliki la flikilon, subteno de Zabbix restos kaj kiel daŭrigi ĝisdatigon al pli altaj versioj? Ĉu eblos ĝisdatigi Zabbix post via flikaĵo al 4.2, 5.0?
MM: – Mi povas nenion diri pri subteno. Se mi estus teknika subteno de Zabbix, mi verŝajne dirus ne, ĉar ĉi tio estas la kodo de iu alia. Koncerne la kodbazon 4.2, nia pozicio estas: "Ni moviĝos kun la tempo, kaj ni ĝisdatigos nin pri la sekva versio." Tial, dum iom da tempo ni afiŝos flikaĵon por ĝisdatigitaj versioj. Mi jam diris en la raporto: la nombro de ŝanĝoj kun versioj estas ankoraŭ sufiĉe malgranda. Mi pensas, ke la transiro de 3.4 al 4 prenis nin ĉirkaŭ 15 minutojn.Io ŝanĝiĝis tie, sed ne tre grava.
A: – Do vi planas subteni vian flikilon kaj vi povas sekure instali ĝin en produktado kaj ricevi ĝisdatigojn iel estonte?
MM: – Ni forte rekomendas ĝin. Ĉi tio solvas multajn problemojn por ni.
MCH: – Denove mi ŝatus atentigi pri tio, ke la ŝanĝoj, kiuj ne koncernas la arkitekturon kaj ne koncernas blokadon aŭ vicojn, estas modulaj, ili estas en apartaj moduloj. Eĉ kun etaj ŝanĝoj vi povas konservi ilin sufiĉe facile.
MM: – Se vi interesiĝas pri la detaloj, tiam "Clickhouse" uzas la tiel nomatan historian bibliotekon. Ĝi estas malligita - ĝi estas kopio de la Elastics-subteno, tio estas, ĝi estas agordebla. Sondado nur ŝanĝas balotantojn. Ni kredas, ke ĉi tio funkcios dum longa tempo.
A: - Multaj dankoj. Diru al mi, ĉu ekzistas dokumentado pri la ŝanĝoj faritaj?
MM: – Dokumentado estas flikaĵo. Evidente, kun la enkonduko de Clickhouse, kun la enkonduko de novaj specoj de enketiloj, aperas novaj agordaj elektoj. La ligilo de la lasta diapozitivo havas mallongan priskribon pri kiel uzi ĝin.
Pri anstataŭigo de fping per nmap
A: – Kiel vi finfine efektivigis ĉi tion? Ĉu vi povas doni specifajn ekzemplojn: ĉu vi havas rimenojn kaj eksteran skripton? Kio finas kontroli tian grandegan nombron da gastigantoj tiel rapide? Kiel vi minigas ĉi tiujn gastigantojn? Ĉu ni bezonas nutri ilin al nmap iel, akiri ilin de ie, enmeti ilin, ruli ion?...
MM: - Bone. Tre ĝusta demando! La punkto estas ĉi tio. Ni modifis la bibliotekon (ICMP ping, parto de Zabbix) por ICMP-kontroloj, kiuj indikas la nombron da pakaĵoj - unu (1), kaj la kodo provas uzi nmap. Tio estas, ĉi tio estas la interna laboro de Zabbix, kiu fariĝis la interna laboro de la pinger. Sekve, neniu sinkronigo aŭ uzo de kaptilo estas postulata. Ĉi tio estis farita intence por lasi la sistemon sendifekta kaj ne devi trakti la sinkronigon de du datumbazaj sistemoj: kion kontroli, alŝuti per la enketilo, kaj ĉu nia alŝuto estas rompita?.. Ĉi tio estas multe pli simpla.
A: – Ĉu ĝi funkcias ankaŭ por prokuriloj?
MM: – Jes, sed ni ne kontrolis. La voĉdona kodo estas la sama en kaj Zabbix kaj la servilo. Devus funkcii. Mi emfazu denove: la agado de la sistemo estas tia, ke ni ne bezonas prokurilon.
MCH: – La ĝusta respondo al la demando estas: "Kial vi bezonas prokurilon kun tia sistemo?" Nur pro NAT aŭ monitorado per ia malrapida kanalo...
A: – Kaj vi uzas Zabbix kiel alergilon, se mi bone komprenas. Aŭ ĉu viaj grafikaĵoj (kie estas la arkiva tavolo) translokiĝis al alia sistemo, kiel Grafana? Aŭ ĉu vi ne uzas ĉi tiun funkcion?
MM: – Mi ankoraŭfoje emfazos: ni atingis kompletan integriĝon. Ni verŝas historion en Clickhouse, sed samtempe ni ŝanĝis la php-interfadon. La Php fasado iras al Clickhouse kaj faras ĉiujn grafikaĵojn de tie. Samtempe, por esti honesta, ni havas parton, kiu konstruas datumojn en aliaj grafikaj ekransistemoj de la sama Clickhouse, de la sama Zabbix-datumoj.
MCH: – Ankaŭ en “Grafan”.
Kiel estis faritaj decidoj pri la asigno de rimedoj?
A: – Kunhavigu iom de via interna kuirejo. Kiel estis la decido, ke necesas asigni rimedojn por serioza prilaborado de la produkto? Ĉi tiuj estas, ĝenerale, certaj riskoj. Kaj bonvolu diri al mi, en la kunteksto de tio, ke vi subtenos novajn versiojn: kiel tiu ĉi decido pravigas el administra vidpunkto?
MM: – Ŝajne, ni ne tre bone rakontis la dramon de la historio. Ni trovis nin en situacio kie io devis esti farita, kaj ni esence iris kun du paralelaj teamoj:
- Unu estis lanĉi monitoran sistemon uzante novajn metodojn: monitorado kiel servo, norma aro de malfermfontaj solvoj, kiujn ni kombinas kaj poste provas ŝanĝi la komercan procezon por labori kun la nova monitora sistemo.
- Samtempe, ni havis entuziasman programiston, kiu faris tion (pri si mem). Okazis, ke li venkis.
A: – Kaj kia estas la grandeco de la teamo?
MCH: - Ŝi estas antaŭ vi.
A: – Do, kiel ĉiam, vi bezonas pasiulon?
MM: – Mi ne scias, kio estas pasiulo.
A: - En ĉi tiu kazo, ŝajne, vi. Koran dankon, vi estas bonega.
MM: - Dankon.
Pri flikoj por Zabbix
A: – Por sistemo, kiu uzas prokurojn (ekzemple, en iuj distribuitaj sistemoj), ĉu eblas adapti kaj fliki, ekzemple, enketistojn, prokurojn kaj parte la antaŭprocesilon de Zabbix mem; kaj ilia interago? Ĉu eblas optimumigi ekzistantajn evoluojn por sistemo kun multoblaj prokuriloj?
MM: – Mi scias, ke la servilo Zabbix estas kunmetita per prokurilo (la kodo estas kompilita kaj akirita). Ni ne testis ĉi tion en produktado. Mi ne certas pri tio, sed mi pensas, ke la antaŭprocesora administranto ne estas uzata en la prokurilo. La tasko de la prokurilo estas preni aron da metrikoj de Zabbix, kunfandi ilin (ĝi ankaŭ registras la agordon, la lokan datumbazon) kaj redoni ĝin al la Zabbix-servilo. La servilo mem tiam faros la antaŭtraktadon kiam ĝi ricevos ĝin.
La intereso pri prokuroj estas komprenebla. Ni kontrolos ĝin. Ĉi tio estas interesa temo.
A: – La ideo estis jena: se vi povas fliki enketistojn, vi povas fliki ilin sur la prokurilo kaj fliki la interagon kun la servilo, kaj adapti la antaŭprocesilon por ĉi tiuj celoj nur sur la servilo.
MM: – Mi pensas, ke ĝi estas eĉ pli simpla. Vi prenas la kodon, aplikas flikaĵon, tiam agordu ĝin kiel vi bezonas - kolektu prokurservilojn (ekzemple, kun ODBC) kaj distribuu la flikitan kodon tra sistemoj. Kie necese - kolektu prokurilon, kie necese - servilon.
A: – Plej verŝajne, vi ne devos fliki la prokuran transdonon al la servilo aldone?
MCH: - Ne, ĝi estas norma.
MM: – Fakte, unu el la ideoj ne sonis. Ni ĉiam konservis ekvilibron inter la eksplodo de ideoj kaj la kvanto de ŝanĝoj kaj facileco de subteno.
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com