Ang susunod na HighLoad++ conference ay gaganapin sa Abril 6 at 7, 2020 sa St. Petersburg Mga Detalye at mga tiket . HighLoad++ Moscow 2018. Hall "Moscow". Nobyembre 9, 15:00. Mga tesis at .
* Pagsubaybay - online at analytics.
* Mga pangunahing limitasyon ng platform ng ZABBIX.
* Solusyon para sa pag-scale ng imbakan ng analytics.
* Pag-optimize ng ZABBIX server.
* Pag-optimize ng UI.
* Maranasan ang pagpapatakbo ng system sa ilalim ng load ng higit sa 40k NVPS.
* Maikling konklusyon.
Mikhail Makurov (simula dito - MM): - Kamusta kayong lahat!
Maxim Chernetsov (pagkatapos nito - MCH): - Magandang hapon!
MM: – Hayaan akong ipakilala si Maxim. Si Max ay isang mahuhusay na engineer, ang pinakamahusay na networker na kilala ko. Si Maxim ay kasangkot sa mga network at serbisyo, ang kanilang pag-unlad at operasyon.
MCH: – At nais kong sabihin sa iyo ang tungkol kay Mikhail. Si Mikhail ay isang C developer. Sumulat siya ng ilang solusyon sa pagpoproseso ng trapiko na may mataas na load para sa aming kumpanya. Nakatira kami at nagtatrabaho sa mga Urals, sa lungsod ng mga mahihirap na lalaki na Chelyabinsk, sa kumpanya ng Intersvyaz. Ang aming kumpanya ay isang tagapagbigay ng mga serbisyo sa Internet at cable television para sa isang milyong tao sa 16 na lungsod.
MM: – At nararapat na sabihin na ang Intersvyaz ay higit pa sa isang provider, ito ay isang kumpanya ng IT. Karamihan sa aming mga solusyon ay ginawa ng aming departamento ng IT.
A: mula sa mga server na nagpoproseso ng trapiko hanggang sa isang call center at mobile application. Ang departamento ng IT ay mayroon na ngayong humigit-kumulang 80 katao na may napaka-magkakaibang kakayahan.
Tungkol sa Zabbix at sa arkitektura nito
MCH: – At ngayon ay susubukan kong magtakda ng isang personal na tala at sabihin sa isang minuto kung ano ang Zabbix (mula rito ay tinutukoy bilang "Zabbix").
Pinoposisyon ng Zabbix ang sarili bilang isang enterprise-level na out-of-the-box na sistema ng pagsubaybay. Marami itong feature na nagpapadali sa buhay: advanced na mga panuntunan sa pagdami, API para sa pagsasama, pagpapangkat at auto-detection ng mga host at sukatan. Ang Zabbix ay may tinatawag na mga tool sa pag-scale - mga proxy. Ang Zabbix ay isang open source system.
Maikling tungkol sa arkitektura. Masasabi nating binubuo ito ng tatlong sangkap:
- server. Nakasulat sa C. Sa halip kumplikadong pagproseso at paglilipat ng impormasyon sa pagitan ng mga thread. Ang lahat ng pagproseso ay nagaganap sa loob nito: mula sa pagtanggap hanggang sa pag-save sa database.
- Ang lahat ng data ay naka-imbak sa database. Sinusuportahan ng Zabbix ang MySQL, PostreSQL at Oracle.
- Ang web interface ay nakasulat sa PHP. Sa karamihan ng mga system ito ay may kasamang Apache server, ngunit gumagana nang mas mahusay kasama ng nginx + php.
Ngayon nais naming sabihin ang isang kuwento mula sa buhay ng aming kumpanya na may kaugnayan sa Zabbix...
Isang kwento mula sa buhay ng kumpanya ng Intersvyaz. Ano ang mayroon tayo at ano ang kailangan natin?
5 o 6 na buwan ang nakalipas. Isang araw pagkatapos ng trabaho...
MCH: - Misha, hello! Natutuwa akong nahuli kita - may usapan. Muli kaming nagkaroon ng problema sa pagsubaybay. Sa isang malaking aksidente, mabagal ang lahat at walang impormasyon tungkol sa estado ng network. Sa kasamaang palad, hindi ito ang unang pagkakataon na nangyari ito. Kailangan ko ng tulong mo. Gawin nating gumana ang ating pagsubaybay sa anumang pagkakataon!
MM: - Pero pagsabayin muna natin. Ilang taon na akong hindi tumitingin doon. Sa pagkakaalala ko, tinalikuran namin ang Nagios at lumipat sa Zabbix mga 8 taon na ang nakakaraan. At ngayon tila mayroon kaming 6 na malalakas na server at humigit-kumulang isang dosenang proxy. May nalilito ba ako?
MCH: - Halos. 15 server, ang ilan sa mga ito ay mga virtual machine. Ang pinakamahalagang bagay ay hindi ito nagliligtas sa atin sa sandaling kailangan natin ito. Tulad ng isang aksidente - bumagal ang mga server at wala kang makikita. Sinubukan naming i-optimize ang configuration, ngunit hindi ito nagbigay ng pinakamainam na pagtaas ng performance.
MM: - Ito ay malinaw. May tiningnan ka ba, may nahukay ka na ba mula sa diagnostics?
MCH: – Ang unang bagay na kailangan mong harapin ay ang database. Ang MySQL ay patuloy na nilo-load, nag-iimbak ng mga bagong sukatan, at kapag ang Zabbix ay nagsimulang bumuo ng isang grupo ng mga kaganapan, ang database ay napupunta sa overdrive nang literal ng ilang oras. Sinabi ko na sa iyo ang tungkol sa pag-optimize ng pagsasaayos, ngunit literal sa taong ito na-update nila ang hardware: ang mga server ay may higit sa isang daang gigabytes ng memorya at mga array ng disk sa mga SSD RAID - walang punto sa pagpapalaki nito nang linear sa mahabang panahon. Anong gagawin natin?
MM: - Ito ay malinaw. Sa pangkalahatan, ang MySQL ay isang LTP database. Tila, hindi na ito angkop para sa pag-imbak ng isang archive ng mga sukatan ng aming laki. Alamin natin ito.
MCH: - Tayo!
Pagsasama ng Zabbix at Clickhouse bilang resulta ng hackathon
Pagkaraan ng ilang oras nakatanggap kami ng kawili-wiling data:
Karamihan sa espasyo sa aming database ay inookupahan ng metrics archive at wala pang 1% ang ginamit para sa configuration, mga template at mga setting. Noong panahong iyon, mahigit isang taon na naming pinapatakbo ang solusyon sa Big data batay sa Clickhouse. Kitang-kita sa amin ang direksyon ng paggalaw. Sa aming Spring Hackathon, isinulat ko ang pagsasama ng Zabbix sa Clickhouse para sa server at frontend. Noong panahong iyon, mayroon nang suporta ang Zabbix para sa ElasticSearch, at nagpasya kaming ihambing ang mga ito.
Paghahambing ng Clickhouse at Elasticsearch
MM: – Para sa paghahambing, nakabuo kami ng parehong load tulad ng ibinibigay ng server ng Zabbix at tiningnan kung paano kikilos ang mga system. Sumulat kami ng data sa mga batch ng 1000 linya, gamit ang CURL. Ipinagpalagay namin nang maaga na ang Clickhouse ay magiging mas mahusay para sa profile ng pag-load na ginagawa ng Zabbix. Ang mga resulta ay lumampas pa sa aming mga inaasahan:
Sa ilalim ng parehong mga kundisyon ng pagsubok, ang Clickhouse ay sumulat ng tatlong beses na higit pang data. Kasabay nito, ang parehong mga sistema ay gumagamit ng napakahusay (isang maliit na halaga ng mga mapagkukunan) kapag nagbabasa ng data. Ngunit ang Elastics ay nangangailangan ng malaking halaga ng processor kapag nagre-record:
Sa kabuuan, ang Clickhouse ay higit na nakahihigit sa Elastix sa mga tuntunin ng pagkonsumo at bilis ng processor. Kasabay nito, dahil sa data compression, ang Clickhouse ay gumagamit ng 11 beses na mas kaunti sa hard drive at gumaganap ng humigit-kumulang 30 beses na mas kaunting mga pagpapatakbo ng disk:
MCH: – Oo, ang trabaho ng Clickhouse sa disk subsystem ay ipinatupad nang napakahusay. Maaari kang gumamit ng malalaking SATA disk para sa mga database at makakuha ng bilis ng pagsulat ng daan-daang libong linya bawat segundo. Sinusuportahan ng out-of-the-box system ang sharding, replication, at napakadaling i-configure. Kami ay higit na nasisiyahan sa paggamit nito sa buong taon.
Upang ma-optimize ang mga mapagkukunan, maaari mong i-install ang Clickhouse sa tabi ng iyong umiiral na pangunahing database at sa gayon ay makatipid ng maraming oras ng CPU at mga pagpapatakbo ng disk. Inilipat namin ang archive ng mga sukatan sa mga kasalukuyang cluster ng Clickhouse:
Pinaginhawa namin ang pangunahing database ng MySQL kaya maaari naming pagsamahin ito sa isang makina kasama ang server ng Zabbix at iwanan ang nakalaang server para sa MySQL.
Paano gumagana ang botohan sa Zabbix?
4 months ago
MM: – Well, maaari ba nating kalimutan ang tungkol sa mga problema sa base?
MCH: - Iyan ay sigurado! Ang isa pang problema na kailangan nating lutasin ay ang mabagal na pangongolekta ng data. Ngayon lahat ng aming 15 proxy server ay overloaded sa SNMP at mga proseso ng botohan. At walang paraan maliban sa pag-install ng bago at bagong mga server.
MM: - Malaki. Ngunit una, sabihin sa amin kung paano gumagana ang botohan sa Zabbix?
MCH: – Sa madaling salita, mayroong 20 uri ng mga sukatan at isang dosenang paraan upang makuha ang mga ito. Maaaring mangolekta ng data ang Zabbix sa mode na "request-response", o maghintay ng bagong data sa pamamagitan ng "Trapper Interface".
Kapansin-pansin na sa orihinal na Zabbix ang pamamaraang ito (Trapper) ay ang pinakamabilis.
Mayroong mga proxy server para sa pamamahagi ng pagkarga:
Ang mga proxy ay maaaring magsagawa ng parehong mga function ng koleksyon gaya ng Zabbix server, tumatanggap ng mga gawain mula dito at ipinapadala ang mga nakolektang sukatan sa pamamagitan ng interface ng Trapper. Ito ang opisyal na inirerekomendang paraan para ipamahagi ang load. Kapaki-pakinabang din ang mga proxy para sa pagsubaybay sa malalayong imprastraktura na tumatakbo sa pamamagitan ng NAT o isang mabagal na channel:
MM: - Ang lahat ay malinaw sa arkitektura. Kailangan nating tingnan ang mga pinagmulan...
Makalipas ang ilang araw
Ang kwento kung paano nanalo ang nmap fping
MM: "Sa tingin ko may nahukay ako."
MCH: - Sabihin mo sa akin!
MM: – Natuklasan ko na kapag tinitingnan ang availability, sinusuri ng Zabbix ang maximum na 128 host sa isang pagkakataon. Sinubukan kong taasan ang numerong ito sa 500 at alisin ang inter-packet interval sa kanilang ping (ping) - nadoble nito ang pagganap. Ngunit gusto ko ng mas malaking numero.
MCH: – Sa aking pagsasanay, minsan kailangan kong suriin ang pagkakaroon ng libu-libong mga host, at wala pa akong nakitang mas mabilis kaysa sa nmap para dito. Sigurado ako na ito ang pinakamabilis na paraan. Subukan Natin! Kailangan nating pataasin nang malaki ang bilang ng mga host sa bawat pag-ulit.
MM: – Suriin ang higit sa limang daan? 600?
MCH: - Hindi bababa sa ilang libo.
MM: - OK. Ang pinakamahalagang bagay na gusto kong sabihin ay nalaman ko na ang karamihan sa pagboto sa Zabbix ay ginagawa nang sabay-sabay. Talagang kailangan nating baguhin ito sa asynchronous mode. Pagkatapos ay maaari nating mapataas nang husto ang bilang ng mga sukatan na nakolekta ng mga poller, lalo na kung dinadagdagan natin ang bilang ng mga sukatan sa bawat pag-ulit.
MCH: - Malaki! At kailan?
MM: - Gaya ng dati, kahapon.
MCH: – Inihambing namin ang parehong mga bersyon ng fping at nmap:
Sa isang malaking bilang ng mga host, ang nmap ay inaasahang magiging hanggang limang beses na mas epektibo. Dahil sinusuri lamang ng nmap ang availability at oras ng pagtugon, inilipat namin ang pagkalkula ng mga pagkalugi sa mga trigger at makabuluhang binawasan ang mga agwat ng pagsusuri sa availability. Nalaman namin na ang pinakamainam na bilang ng mga host para sa nmap ay nasa 4 na libo bawat pag-ulit. Pinahintulutan kami ng Nmap na bawasan ang halaga ng CPU ng mga pagsusuri sa availability ng tatlong beses at bawasan ang pagitan mula 120 segundo hanggang 10.
Pag-optimize ng botohan
MM: "Pagkatapos ay nagsimula kaming gumawa ng mga poller. Pangunahing interesado kami sa SNMP detection at mga ahente. Sa Zabbix, ang botohan ay ginagawa nang sabay-sabay at ang mga espesyal na hakbang ay ginawa upang mapataas ang kahusayan ng system. Sa synchronous mode, ang hindi available na host ay nagdudulot ng makabuluhang pagkasira ng botohan. Mayroong isang buong sistema ng mga estado, may mga espesyal na proseso - ang tinatawag na hindi maabot na mga poller, na gumagana lamang sa mga hindi maabot na host:
Ito ay isang komentaryo na nagpapakita ng state matrix, ang lahat ng pagiging kumplikado ng sistema ng mga transition na kinakailangan upang ang system ay manatiling epektibo. Bilang karagdagan, ang kasabay na pagboto mismo ay medyo mabagal:
Kaya naman ang libu-libong poller stream sa dose-dosenang proxy ay hindi makakolekta ng kinakailangang dami ng data para sa amin. Nalutas ng asynchronous na pagpapatupad hindi lamang ang mga problema sa bilang ng mga thread, ngunit makabuluhang pinasimple din ang sistema ng estado ng mga hindi available na host, dahil para sa anumang numero na nasuri sa isang pag-ulit ng botohan, ang maximum na oras ng paghihintay ay 1 timeout:
Bukod pa rito, binago at pinahusay namin ang sistema ng botohan para sa mga kahilingan sa SNMP. Ang katotohanan ay ang karamihan sa mga tao ay hindi maaaring tumugon sa maramihang mga kahilingan sa SNMP sa parehong oras. Samakatuwid, gumawa kami ng hybrid mode, kapag ang SNMP polling ng parehong host ay tapos na asynchronously:
Ginagawa ito para sa buong pack ng mga host. Ang mode na ito sa huli ay hindi mas mabagal kaysa sa ganap na asynchronous, dahil ang pagboto ng isa at kalahating daang halaga ng SNMP ay mas mabilis pa rin kaysa sa 1 timeout.
Ipinakita ng aming mga eksperimento na ang pinakamainam na bilang ng mga kahilingan sa isang pag-ulit ay humigit-kumulang 8 libo na may SNMP polling. Sa kabuuan, pinayagan kami ng paglipat sa asynchronous mode na pabilisin ang pagganap ng botohan nang 200 beses, ilang daang beses.
MCH: – Ang mga resultang pag-optimize ng botohan ay nagpakita na hindi lang natin maaalis ang lahat ng mga proxy, ngunit mababawasan din ang mga agwat para sa maraming mga pagsusuri, at hindi na kakailanganin ang mga proxy bilang isang paraan upang ibahagi ang load.
Mga tatlong buwan na ang nakalipas
Baguhin ang arkitektura - dagdagan ang pagkarga!
MM: - Well, Max, oras na ba para maging produktibo? Kailangan ko ng isang malakas na server at isang mahusay na engineer.
MCH: - Okay, planuhin natin ito. Oras na para lumipat mula sa dead point na 5 thousand metrics per second.
Umaga pagkatapos ng pag-upgrade
MCH: - Misha, nag-update kami sa aming sarili, ngunit sa umaga kami ay gumulong pabalik ... Hulaan kung ano ang bilis na nagawa naming makamit?
MM: – 20 thousand maximum.
MCH: - Oo, 25! Sa kasamaang palad, kami ay tama kung saan kami nagsimula.
MM: - Bakit? Nagpatakbo ka ba ng anumang mga diagnostic?
MCH: - Oo ba! Narito, halimbawa, ay isang kawili-wiling tuktok:
MM: - Manood tayo. Nakikita ko na sinubukan namin ang isang malaking bilang ng mga thread ng botohan:
Ngunit sa parehong oras ay hindi nila mai-recycle ang system kahit sa kalahati:
At ang pangkalahatang pagganap ay medyo maliit, mga 4 na libong sukatan bawat segundo:
may iba pa ba?
MCH: – Oo, bakas ng isa sa mga poller:
MM: – Dito mo malinaw na makikita na ang proseso ng botohan ay naghihintay para sa mga "semaphore". Ito ang mga kandado:
MCH: - Hindi maliwanag.
MM: – Tingnan mo, ito ay katulad ng isang sitwasyon kung saan ang isang bungkos ng mga thread ay sumusubok na gumana sa mga mapagkukunan na isa lamang ang maaaring gumana sa isang pagkakataon. Pagkatapos ang magagawa lang nila ay ibahagi ang mapagkukunang ito sa paglipas ng panahon:
At ang kabuuang pagganap ng pagtatrabaho sa naturang mapagkukunan ay limitado sa bilis ng isang core:
Mayroong dalawang paraan upang malutas ang problemang ito.
I-upgrade ang hardware ng makina, lumipat sa mas mabilis na mga core:
O baguhin ang arkitektura at sa parehong oras baguhin ang pagkarga:
MCH: – Sa pamamagitan ng paraan, sa test machine gagamit kami ng mas kaunting mga core kaysa sa isang labanan, ngunit ang mga ito ay 1,5 beses na mas mabilis sa dalas sa bawat core!
MM: - Maliwanag? Kailangan mong tingnan ang server code.
Data path sa Zabbix server
MCH: – Upang malaman ito, sinimulan naming pag-aralan kung paano inililipat ang data sa loob ng server ng Zabbix:
Cool na larawan, tama ba? Halina't hakbang-hakbang upang gawin itong mas malinaw. May mga thread at serbisyo na responsable para sa pagkolekta ng data:
Ipinapadala nila ang mga nakolektang sukatan sa pamamagitan ng isang socket sa tagapamahala ng Preprocessor, kung saan naka-save ang mga ito sa isang queue:
Ang "tagapamahala ng preprocessor" ay nagpapadala ng data sa mga manggagawa nito, na nagsasagawa ng mga tagubilin sa preprocessing at ibinalik ang mga ito sa parehong socket:
Pagkatapos nito, iniimbak sila ng tagapamahala ng preprocessor sa cache ng kasaysayan:
Mula doon ay kinukuha sila ng mga history sinkers, na gumaganap ng napakaraming function: halimbawa, pagkalkula ng mga trigger, pagpuno sa value cache at, higit sa lahat, pag-save ng mga sukatan sa history storage. Sa pangkalahatan, ang proseso ay kumplikado at napaka-nakalilito.
MM: – Ang unang bagay na nakita namin ay ang karamihan sa mga thread ay nakikipagkumpitensya para sa tinatawag na "configuration cache" (ang lugar ng memorya kung saan naka-imbak ang lahat ng mga configuration ng server). Ang mga thread na responsable sa pagkolekta ng data ay gumagawa lalo na ng maraming pagharang:
...dahil ang configuration ay nag-iimbak hindi lamang ng mga sukatan kasama ng kanilang mga parameter, kundi pati na rin ang mga pila kung saan kumukuha ang mga poller ng impormasyon tungkol sa kung ano ang susunod na gagawin. Kapag maraming poller at hinarangan ng isa ang configuration, ang iba ay naghihintay ng mga kahilingan:
Hindi dapat magkasalungat ang mga poller
Samakatuwid, ang unang bagay na ginawa namin ay hatiin ang pila sa 4 na bahagi at payagan ang mga poller na harangan ang mga pila na ito, ang mga bahaging ito nang sabay-sabay, sa ilalim ng ligtas na mga kondisyon:
Inalis nito ang kumpetisyon para sa cache ng pagsasaayos, at ang bilis ng mga poller ay tumaas nang malaki. Ngunit pagkatapos ay nakatagpo namin ang katotohanan na ang tagapamahala ng preprocessor ay nagsimulang makaipon ng isang pila ng mga trabaho:
Ang tagapamahala ng preprocessor ay dapat na makapag-prioritize
Nangyari ito sa mga kaso kung saan kulang siya sa pagganap. Pagkatapos ang tanging magagawa niya ay mag-ipon ng mga kahilingan mula sa mga proseso ng pagkolekta ng data at idagdag ang kanilang buffer hanggang sa maubos nito ang lahat ng memorya at nag-crash:
Upang malutas ang problemang ito, nagdagdag kami ng pangalawang socket na partikular na nakatuon sa mga manggagawa:
Kaya, nagkaroon ng pagkakataon ang tagapamahala ng preprocessor na unahin ang trabaho nito at, kung lumaki ang buffer, ang gawain ay pabagalin ang pag-alis, na nagbibigay ng pagkakataon sa mga manggagawa na kunin ang buffer na ito:
Pagkatapos ay natuklasan namin na ang isa sa mga dahilan ng pagbagal ay ang mga manggagawa mismo, dahil nakikipagkumpitensya sila para sa isang mapagkukunan na ganap na hindi mahalaga para sa kanilang trabaho. Naidokumento namin ang problemang ito bilang isang pag-aayos ng bug, at nalutas na ito sa mga bagong bersyon ng Zabbix:
Pinapataas namin ang bilang ng mga socket - nakuha namin ang resulta
Dagdag pa, ang tagapamahala ng preprocessor mismo ay naging isang bottleneck, dahil ito ay isang thread. Ito ay nakasalalay sa pangunahing bilis, na nagbibigay ng pinakamataas na bilis na humigit-kumulang 70 libong sukatan bawat segundo:
Samakatuwid, gumawa kami ng apat, na may apat na hanay ng mga socket, mga manggagawa:
At nagbigay-daan ito sa amin na pataasin ang bilis sa humigit-kumulang 130 libong sukatan:
Ang non-linearity ng paglago ay ipinaliwanag sa pamamagitan ng katotohanan na ang kumpetisyon para sa cache ng kasaysayan ay lumitaw. 4 na preprocessor manager at history sinkers ang nagpaligsahan para dito. Sa puntong ito, nakakatanggap kami ng humigit-kumulang 130 libong sukatan bawat segundo sa test machine, na ginagamit ito ng humigit-kumulang 95% ng processor:
Mga 2,5 buwan na ang nakalipas
Ang pagtanggi mula sa snmp-community ay tumaas ng isa at kalahating beses ang mga NVP
MM: – Max, kailangan ko ng bagong test car! Hindi na tayo magkasya sa kasalukuyan.
MCH: - Ano ang mayroon ka ngayon?
MM: – Ngayon – 130k NVP at isang shelf-ready na processor.
MCH: - Wow! Malamig! Teka, may dalawang tanong ako. Ayon sa aking mga kalkulasyon, ang aming pangangailangan ay nasa 15-20 thousand metrics per second. Bakit kailangan pa natin?
MM: "Gusto kong tapusin ang trabaho." Gusto kong makita kung magkano ang maaari nating maipit sa sistemang ito.
MCH: - Ngunit…
MM: "Ngunit ito ay walang silbi para sa negosyo."
MCH: - Ito ay malinaw. At ang pangalawang tanong: maaari ba nating suportahan kung ano ang mayroon tayo ngayon sa ating sarili, nang walang tulong ng isang developer?
MM: - Hindi ko iniisip. Ang pagbabago kung paano gumagana ang configuration cache ay isang problema. Nakakaapekto ito sa mga pagbabago sa karamihan ng mga thread at medyo mahirap mapanatili. Malamang, napakahirap na mapanatili ito.
MCH: "Kung gayon kailangan namin ng ilang uri ng alternatibo."
MM: - Mayroong ganoong opsyon. Maaari tayong lumipat sa mabilis na mga core, habang iniiwan ang bagong locking system. Makakakuha pa rin tayo ng performance na 60-80 thousand metrics. Kasabay nito, maaari nating iwanan ang lahat ng natitirang code. Gagana ang Clickhouse at asynchronous na botohan. At ito ay magiging madali upang mapanatili.
MCH: - Kamangha-manghang! I suggest na tumigil na tayo dito.
Matapos i-optimize ang panig ng server, sa wakas ay nailunsad namin ang bagong code sa produksyon. Inabandona namin ang ilan sa mga pagbabago sa pabor ng paglipat sa isang makina na may mabilis na mga core at pagliit ng bilang ng mga pagbabago sa code. Pinasimple rin namin ang configuration at inalis ang mga macro sa mga item ng data kung saan posible, habang ipinapasok ng mga ito ang karagdagang pag-lock.
Halimbawa, ang pag-abandona sa snmp-community macro, na kadalasang makikita sa dokumentasyon at mga halimbawa, sa aming kaso, naging posible na pabilisin ang mga NVP nang humigit-kumulang 1,5 beses.
Pagkatapos ng dalawang araw sa produksyon
Inaalis ang mga pop-up ng history ng insidente
MCH: – Misha, dalawang araw na naming ginagamit ang system, at gumagana ang lahat. Ngunit kapag gumagana ang lahat! Kami ay nagplano ng trabaho sa paglipat ng isang medyo malaking bahagi ng network, at muli naming sinuri gamit ang aming mga kamay kung ano ang tumaas at kung ano ang hindi.
MM: - Hindi pwede! Sinuri namin ang lahat ng 10 beses. Pinangangasiwaan ng server ang kahit na kumpletong kawalan ng available na network kaagad.
MCH: - Oo, naiintindihan ko ang lahat: server, database, tuktok, austat, log - lahat ay mabilis... Ngunit tinitingnan namin ang web interface, at mayroong isang processor "sa istante" sa server at ito:
MM: - Ito ay malinaw. Panoorin natin ang web. Nalaman namin na sa mga sitwasyon kung saan maraming aktibong insidente, ang karamihan sa mga live na widget ay nagsimulang gumana nang napakabagal:
Ang dahilan nito ay ang pagbuo ng mga pop-up ng history ng insidente na nabuo para sa bawat item sa listahan. Samakatuwid, inabandona namin ang pagbuo ng mga window na ito (nagkomento ng 5 linya sa code), at nalutas nito ang aming mga problema.
Ang oras ng paglo-load para sa mga widget, kahit na ganap na hindi magagamit, ay nabawasan mula sa ilang minuto hanggang sa katanggap-tanggap na 10-15 segundo para sa amin, at ang kasaysayan ay maaari pa ring tingnan sa pamamagitan ng pag-click sa oras:
Pagkatapos ng trabaho. 2 buwan ang nakalipas
MCH: - Misha, aalis ka na ba? Kailangan nating mag-usap.
MM: - Hindi ko sinasadya. May kay Zabbix na naman?
MCH: - Hindi, magpahinga! Gusto ko lang sabihin: gumagana ang lahat, salamat! May dala akong beer.
Ang Zabbix ay mahusay
Ang Zabbix ay isang medyo unibersal at mayamang sistema at pag-andar. Maaari itong magamit para sa mga maliliit na pag-install sa labas ng kahon, ngunit habang lumalaki ang mga pangangailangan, kailangan itong i-optimize. Upang mag-imbak ng malaking archive ng mga sukatan, gumamit ng angkop na storage:
- maaari kang gumamit ng mga built-in na tool sa anyo ng pagsasama sa Elasticsearch o pag-upload ng kasaysayan sa mga text file (magagamit mula sa bersyon 4);
- Maaari mong samantalahin ang aming karanasan at pagsasama sa Clickhouse.
Upang kapansin-pansing mapataas ang bilis ng pagkolekta ng mga sukatan, kolektahin ang mga ito gamit ang mga asynchronous na pamamaraan at ipadala ang mga ito sa pamamagitan ng interface ng trapper sa server ng Zabbix; o maaari kang gumamit ng patch upang gawing asynchronous ang mga poller ng Zabbix.
Ang Zabbix ay nakasulat sa C at medyo mahusay. Ang paglutas ng ilang mga bottleneck sa arkitektura ay nagbibigay-daan sa iyo upang higit pang pataasin ang pagganap nito at, sa aming karanasan, makakuha ng higit sa 100 libong sukatan sa isang single-processor machine.
Ang parehong patch ng Zabbix
MM: – Gusto kong magdagdag ng ilang puntos. Ang buong kasalukuyang ulat, lahat ng pagsubok, numero ay ibinigay para sa configuration na ginagamit namin. Kami ngayon ay kumukuha ng humigit-kumulang 20 libong sukatan bawat segundo mula rito. Kung sinusubukan mong maunawaan kung ito ay gagana para sa iyo, maaari mong ihambing. Ang tinalakay ngayon ay nai-post sa GitHub sa anyo ng isang patch:
Kasama sa patch ang:
- buong pagsasama sa Clickhouse (parehong Zabbix server at frontend);
- paglutas ng mga problema sa tagapamahala ng preprocessor;
- asynchronous na botohan.
Ang patch ay katugma sa lahat ng bersyon 4, kabilang ang lts. Malamang, na may kaunting pagbabago ay gagana ito sa bersyon 3.4.
Salamat sa iyo para sa iyong pansin.
mga katanungan
Tanong mula sa madla (simula dito – A): – Magandang hapon! Mangyaring sabihin sa akin, mayroon ka bang mga plano para sa masinsinang pakikipag-ugnayan sa koponan ng Zabbix o sa kanila sa iyo, upang hindi ito isang patch, ngunit normal na pag-uugali ng Zabbix?
MM: – Oo, tiyak na gagawin namin ang ilan sa mga pagbabago. May mangyayari, may mananatili sa patch.
A: – Maraming salamat sa napakahusay na ulat! Mangyaring sabihin sa akin, pagkatapos ilapat ang patch, ang suporta mula sa Zabbix ay mananatili at kung paano magpatuloy sa pag-update sa mas mataas na mga bersyon? Posible bang i-update ang Zabbix pagkatapos ng iyong patch sa 4.2, 5.0?
MM: - Wala akong masasabi tungkol sa suporta. Kung ako ay teknikal na suporta ng Zabbix, malamang na sabihin kong hindi, dahil ito ay code ng ibang tao. Tulad ng para sa 4.2 codebase, ang aming posisyon ay: "Kami ay lilipat sa oras, at i-update namin ang aming sarili sa susunod na bersyon." Samakatuwid, sa loob ng ilang panahon ay magpo-post kami ng patch para sa mga na-update na bersyon. Sinabi ko na sa ulat: ang bilang ng mga pagbabago sa mga bersyon ay medyo maliit pa rin. Sa tingin ko ang paglipat mula sa 3.4 hanggang 4 ay tumagal ng halos 15 minuto. May nagbago doon, ngunit hindi masyadong mahalaga.
A: – Kaya plano mong suportahan ang iyong patch at maaari mong ligtas na mai-install ito sa produksyon at makatanggap ng mga update sa ilang paraan sa hinaharap?
MM: – Lubos naming inirerekomenda ito. Malulutas nito ang maraming problema para sa atin.
MCH: - Muli, nais kong bigyang pansin ang katotohanan na ang mga pagbabago na hindi nauugnay sa arkitektura at hindi tungkol sa pagharang o pila ay modular, ang mga ito ay nasa magkahiwalay na mga module. Kahit na may mga maliliit na pagbabago maaari mong mapanatili ang mga ito nang madali.
MM: – Kung interesado ka sa mga detalye, ginagamit ng “Clickhouse” ang tinatawag na history library. Ito ay hindi nakatali - ito ay isang kopya ng suporta ng Elastics, iyon ay, ito ay maaaring i-configure. Ang botohan ay nagbabago lamang ng mga poller. Naniniwala kami na ito ay gagana sa mahabang panahon.
A: - Maraming salamat. Sabihin mo sa akin, mayroon bang anumang dokumentasyon ng mga pagbabagong ginawa?
MM: – Ang dokumentasyon ay isang patch. Malinaw, sa pagpapakilala ng Clickhouse, sa pagpapakilala ng mga bagong uri ng mga poller, lumitaw ang mga bagong opsyon sa pagsasaayos. Ang link mula sa huling slide ay may maikling paglalarawan kung paano ito gamitin.
Tungkol sa pagpapalit ng fping ng nmap
A: – Paano mo ito ipinatupad sa wakas? Maaari ka bang magbigay ng mga partikular na halimbawa: mayroon ka bang mga strapper at isang panlabas na script? Ano ang nagtatapos sa pagsusuri ng napakaraming host nang napakabilis? Paano mo mamimina ang mga host na ito? Kailangan ba natin silang pakainin sa nmap kahit papaano, kunin sila sa kung saan, ilagay, patakbuhin ang isang bagay?..
MM: - Malamig. Isang napakatamang tanong! Ang punto ay ito. Binago namin ang library (ICMP ping, bahagi ng Zabbix) para sa ICMP checks, na nagpapahiwatig ng bilang ng mga packet - isa (1), at sinusubukan ng code na gumamit ng nmap. Iyon ay, ito ang panloob na gawain ng Zabbix, na naging panloob na gawain ng pinger. Alinsunod dito, hindi kinakailangan ang pag-synchronize o paggamit ng isang trapper. Ito ay sadyang ginawa upang iwanang buo ang system at hindi na kailangang harapin ang pag-synchronize ng dalawang database system: ano ang susuriin, i-upload sa pamamagitan ng poller, at sira ba ang ating upload?.. Mas simple ito.
A: – Gumagana rin ba ito para sa mga proxy?
MM: - Oo, ngunit hindi namin nasuri. Ang code ng botohan ay pareho sa Zabbix at sa server. Dapat na gumana. Hayaan akong bigyang-diin muli: ang pagganap ng system ay tulad na hindi namin kailangan ng isang proxy.
MCH: – Ang tamang sagot sa tanong ay: “Bakit kailangan mo ng proxy na may ganoong sistema?” Dahil lamang sa NAT o pagsubaybay sa isang uri ng mabagal na channel...
A: – At ginagamit mo ang Zabbix bilang isang allertor, kung naiintindihan ko nang tama. O inilipat ang iyong mga graphics (kung saan ang archive layer) sa ibang system, gaya ng Grafana? O hindi mo ba ginagamit ang pagpapaandar na ito?
MM: – Muli kong idiin: nakamit natin ang kumpletong pagsasama. Ibinubuhos namin ang kasaysayan sa Clickhouse, ngunit kasabay nito ay binago namin ang php frontend. Ang Php frontend ay napupunta sa Clickhouse at ginagawa ang lahat ng mga graphics mula doon. Sa parehong oras, sa totoo lang, mayroon kaming bahagi na bumubuo ng data sa iba pang mga graphic na display system mula sa parehong Clickhouse, mula sa parehong data ng Zabbix.
MCH: – Sa “Grafan” din.
Paano ginawa ang mga desisyon tungkol sa paglalaan ng mga mapagkukunan?
A: – Ibahagi ang kaunti sa iyong panloob na kusina. Paano ginawa ang desisyon na kinakailangang maglaan ng mga mapagkukunan para sa seryosong pagproseso ng produkto? Ito ay, sa pangkalahatan, ilang mga panganib. At mangyaring sabihin sa akin, sa konteksto ng katotohanan na susuportahan mo ang mga bagong bersyon: paano nabibigyang katwiran ang desisyong ito mula sa pananaw ng pamamahala?
MM: - Tila, hindi namin nasabi nang maayos ang drama ng kasaysayan. Natagpuan namin ang aming sarili sa isang sitwasyon kung saan may kailangang gawin, at talagang sumama kami sa dalawang magkatulad na koponan:
- Ang isa ay naglulunsad ng isang sistema ng pagsubaybay gamit ang mga bagong pamamaraan: pagsubaybay bilang isang serbisyo, isang karaniwang hanay ng mga open source na solusyon na pinagsama namin at pagkatapos ay subukang baguhin ang proseso ng negosyo upang gumana sa bagong sistema ng pagsubaybay.
- Kasabay nito, mayroon kaming isang masigasig na programmer na gumagawa nito (tungkol sa kanyang sarili). Nagkataon na nanalo siya.
A: – At ano ang laki ng pangkat?
MCH: - Siya ay nasa harap mo.
A: - Kaya, tulad ng dati, kailangan mo ng isang madamdamin?
MM: - Hindi ko alam kung ano ang passionary.
A: - Sa kasong ito, tila, ikaw. Maraming salamat, ang galing mo.
MM: - Salamat.
Tungkol sa mga patch para sa Zabbix
A: – Para sa isang system na gumagamit ng mga proxy (halimbawa, sa ilang mga distributed system), posible bang mag-adapt at mag-patch, halimbawa, mga poller, proxy at bahagyang ang preprocessor ng Zabbix mismo; at ang kanilang pakikipag-ugnayan? Posible bang i-optimize ang mga kasalukuyang development para sa isang system na may maraming proxy?
MM: – Alam ko na ang server ng Zabbix ay binuo gamit ang isang proxy (ang code ay pinagsama-sama at nakuha). Hindi pa namin ito nasubukan sa produksyon. Hindi ako sigurado tungkol dito, ngunit sa palagay ko ang tagapamahala ng preprocessor ay hindi ginagamit sa proxy. Ang gawain ng proxy ay kumuha ng isang hanay ng mga sukatan mula sa Zabbix, pagsamahin ang mga ito (itinatala din nito ang pagsasaayos, ang lokal na database) at ibalik ito sa server ng Zabbix. Ang server mismo ang gagawa ng preprocessing kapag natanggap ito.
Ang interes sa mga proxy ay naiintindihan. Susuriin namin ito. Ito ay isang kawili-wiling paksa.
A: – Ang ideya ay ito: kung maaari mong i-patch ang mga poller, maaari mong i-patch ang mga ito sa proxy at i-patch ang pakikipag-ugnayan sa server, at iakma ang preprocessor para sa mga layuning ito lamang sa server.
MM: - Sa tingin ko ito ay mas simple. Kukunin mo ang code, maglapat ng patch, pagkatapos ay i-configure ito sa paraang kailangan mo - mangolekta ng mga proxy server (halimbawa, kasama ang ODBC) at ipamahagi ang naka-patch na code sa mga system. Kung kinakailangan - mangolekta ng isang proxy, kung kinakailangan - isang server.
A: – Malamang, hindi mo na kailangang i-patch ang proxy transmission sa server bilang karagdagan?
MCH: - Hindi, ito ay pamantayan.
MM: - Sa katunayan, ang isa sa mga ideya ay hindi tunog. Palagi kaming nagpapanatili ng balanse sa pagitan ng pagsabog ng mga ideya at ang dami ng mga pagbabago at kadalian ng suporta.
Ilang ad 🙂
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com