Ngayon, bilang karagdagan sa monolithic code, ang aming proyekto ay may kasamang dose-dosenang mga microservice. Ang bawat isa sa kanila ay nangangailangan na subaybayan. Ang paggawa nito sa ganoong sukat gamit ang mga inhinyero ng DevOps ay may problema. Bumuo kami ng isang monitoring system na gumagana bilang isang serbisyo para sa mga developer. Maaari silang independiyenteng magsulat ng mga sukatan sa sistema ng pagsubaybay, gamitin ang mga ito, bumuo ng mga dashboard batay sa mga ito, at mag-attach ng mga alerto sa kanila na ma-trigger kapag naabot ang mga halaga ng threshold. Para sa mga inhinyero ng DevOps, imprastraktura at dokumentasyon lamang.
Ang post na ito ay isang transcript ng aking talumpati sa aming sa RIT++. Maraming tao ang humiling sa amin na gumawa ng mga tekstong bersyon ng mga ulat mula doon. Kung ikaw ay nasa kumperensya o nanood ng video, wala kang makikitang bago. At lahat ng iba pa - maligayang pagdating sa pusa. Sasabihin ko sa iyo kung paano kami nakarating sa ganoong sistema, kung paano ito gumagana at kung paano namin ito pinaplanong i-update.
Ang nakaraan: mga scheme at plano
Paano tayo nakarating sa kasalukuyang sistema ng pagsubaybay? Upang masagot ang tanong na ito, kailangan mong pumunta sa 2015. Ganito ang hitsura noon:
Mayroon kaming humigit-kumulang 24 na node na responsable sa pagsubaybay. Mayroong isang buong pakete ng iba't ibang mga korona, script, daemon na kahit papaano ay sinusubaybayan ang isang bagay, nagpapadala ng mga mensahe, at gumaganap ng mga function. Naisip namin na habang lumayo kami, hindi gaanong mabubuhay ang ganoong sistema. Walang punto sa pagbuo nito: ito ay masyadong masalimuot.
Napagpasyahan naming piliin ang mga elemento ng pagsubaybay na aming pananatilihin at bubuo, at ang mga aabandonahin namin. Mayroong 19 sa kanila. Tanging mga graphite, aggregator at Grafana bilang dashboard ang natitira. Ngunit ano ang magiging hitsura ng bagong sistema? Ganito:
Mayroon kaming imbakan ng mga sukatan: ito ay mga graphite, na ibabatay sa mga mabibilis na SSD drive, ito ang ilang partikular na aggregator para sa mga sukatan. Susunod - Grafana para sa pagpapakita ng mga dashboard at Moira para sa pag-alerto. Nais din naming bumuo ng isang sistema para sa paghahanap ng mga anomalya.
Pamantayan: Pagsubaybay 2.0
Ito ang hitsura ng mga plano noong 2015. Ngunit kailangan nating ihanda hindi lamang ang imprastraktura at ang serbisyo mismo, kundi pati na rin ang dokumentasyon para dito. Nakabuo kami ng corporate standard para sa aming sarili, na tinatawag naming monitoring 2.0. Ano ang mga kinakailangan para sa sistema?
- patuloy na kakayahang magamit;
- agwat ng imbakan ng mga sukatan = 10 segundo;
- nakabalangkas na imbakan ng mga sukatan at dashboard;
- SLA > 99,99%
- koleksyon ng mga sukatan ng kaganapan sa pamamagitan ng UDP (!).
Kailangan namin ng UDP dahil mayroon kaming malaking daloy ng trapiko at mga kaganapan na bumubuo ng mga sukatan. Kung isusulat mo silang lahat sa graphite nang sabay-sabay, babagsak ang storage. Pinili din namin ang mga prefix sa unang antas para sa lahat ng sukatan.
Ang bawat isa sa mga prefix ay may ilang pag-aari. May mga sukatan para sa mga server, network, container, mapagkukunan, application, at iba pa. Naipatupad na ang malinaw, mahigpit, na-type na pag-filter, kung saan tinatanggap namin ang mga sukatan sa unang antas at ibinababa na lang ang iba. Ganito namin pinlano ang sistemang ito noong 2015. Ano ang nasa kasalukuyan?
Kasalukuyan: diagram ng pakikipag-ugnayan ng mga bahagi ng pagsubaybay
Una sa lahat, sinusubaybayan namin ang mga application: ang aming PHP code, mga application at microservice - sa madaling salita, lahat ng isinulat ng aming mga developer. Ang lahat ng mga application ay nagpapadala ng mga sukatan sa pamamagitan ng UDP sa Brubeck aggregator (statsd, muling isinulat sa C). Ito ay naging pinakamabilis sa mga synthetic na pagsubok. At ipinapadala nito ang pinagsama-samang sukatan sa Graphite sa pamamagitan ng TCP.
Mayroon itong uri ng mga sukatan na tinatawag na mga timer. Ito ay isang napaka-maginhawang bagay. Halimbawa, para sa bawat koneksyon ng user sa serbisyo, magpapadala ka ng sukatan na may oras ng pagtugon sa Brubeck. Isang milyong tugon ang pumasok, ngunit ang aggregator ay nagbalik lamang ng 10 sukatan. Nasa iyo ang bilang ng mga taong dumating, ang maximum, minimum at average na oras ng pagtugon, ang median at 4 na porsyento. Pagkatapos ang data ay inilipat sa Graphite at nakikita namin ang lahat ng ito nang live.
Mayroon din kaming pagsasama-sama para sa mga sukatan sa hardware, software, mga sukatan ng system at ang aming lumang sistema ng pagsubaybay sa Munin (nagtrabaho ito para sa amin hanggang 2015). Kinokolekta namin ang lahat ng ito sa pamamagitan ng CollectD daemon ng C (mayroon itong isang buong bungkos ng iba't ibang mga plugin na nakapaloob dito, maaari nitong i-poll ang lahat ng mga mapagkukunan ng host system kung saan ito naka-install, tukuyin lamang sa pagsasaayos kung saan isusulat ang data) at isulat ang data sa Graphite sa pamamagitan nito. Sinusuportahan din nito ang mga plugin ng python at mga script ng shell, para makapagsulat ka ng sarili mong mga custom na solusyon: Kokolektahin ng CollectD ang data na ito mula sa isang lokal o malayong host (ipagpalagay na Curl) at ipadala ito sa Graphite.
Pagkatapos ay ipinapadala namin ang lahat ng sukatan na aming nakolekta sa Carbon-c-relay. Ito ang solusyon sa Carbon Relay mula sa Graphite, na binago sa C. Ito ay isang router na kinokolekta ang lahat ng sukatan na ipinapadala namin mula sa aming mga aggregator at dinadala ang mga ito sa mga node. Gayundin sa yugto ng pagruruta, sinusuri nito ang bisa ng mga sukatan. Una, dapat silang tumutugma sa prefix scheme na ipinakita ko kanina at, pangalawa, wasto ang mga ito para sa grapayt. Kung hindi ay babagsak sila.
Pagkatapos ay ipinapadala ng Carbon-c-relay ang mga sukatan sa kumpol ng Graphite. Gumagamit kami ng Carbon-cache, na muling isinulat sa Go, bilang pangunahing storage ng mga sukatan. Ang Go-carbon, dahil sa multithreading nito, ay higit na nakahihigit sa Carbon-cache. Tumatanggap ito ng data at isinusulat ito sa mga disk gamit ang whisper package (standard, nakasulat sa python). Upang mabasa ang data mula sa aming mga storage, ginagamit namin ang Graphite API. Ito ay mas mabilis kaysa sa karaniwang Graphite WEB. Ano ang susunod na mangyayari sa data?
Pumunta sila sa Grafana. Ginagamit namin ang aming mga graphite cluster bilang pangunahing pinagmumulan ng data, at mayroon kaming Grafana bilang isang web interface para sa pagpapakita ng mga sukatan at pagbuo ng mga dashboard. Para sa bawat isa sa kanilang mga serbisyo, gumagawa ang mga developer ng sarili nilang dashboard. Pagkatapos ay bumuo sila ng mga graph batay sa kanila, na nagpapakita ng mga sukatan na kanilang isinusulat mula sa kanilang mga application. Bilang karagdagan sa Grafana, mayroon din kaming SLAM. Isa itong demonyong python na kinakalkula ang SLA batay sa data mula sa graphite. Tulad ng nasabi ko na, mayroon kaming ilang dosenang microservice, bawat isa ay may sariling mga kinakailangan. Gamit ang SLAM, pumupunta kami sa dokumentasyon at ihahambing ito sa kung ano ang nasa Graphite at ihahambing kung gaano kahusay ang pagtutugma ng mga kinakailangan sa pagkakaroon ng aming mga serbisyo.
Pumunta pa tayo: alerto. Ito ay inayos gamit ang isang malakas na sistema - Moira. Ito ay independyente dahil mayroon itong sariling Graphite sa ilalim ng talukbong. Binuo ng mga lalaki mula sa SKB "Kontur", nakasulat sa python at Go, ganap na open source. Natatanggap ni Moira ang parehong daloy na napupunta sa mga graphite. Kung sa ilang kadahilanan ay namatay ang iyong storage, gagana pa rin ang iyong pag-alerto.
Nag-deploy kami ng Moira sa Kubernetes; gumagamit ito ng isang kumpol ng mga server ng Redis bilang pangunahing database. Ang resulta ay isang fault-tolerant system. Inihahambing nito ang stream ng mga sukatan sa listahan ng mga nag-trigger: kung walang mga pagbanggit dito, ibababa nito ang sukatan. Kaya nagagawa nitong mag-digest ng mga gigabyte ng mga sukatan kada minuto.
Nag-attach din kami ng corporate LDAP dito, sa tulong kung saan ang bawat user ng corporate system ay makakagawa ng mga notification para sa kanilang sarili batay sa mga umiiral na (o bagong likhang) trigger. Dahil naglalaman ang Moira ng Graphite, sinusuportahan nito ang lahat ng mga tampok nito. Kaya kunin mo muna ang linya at kopyahin ito sa Grafana. Tingnan kung paano ipinapakita ang data sa mga graph. At pagkatapos ay kunin mo ang parehong linya at kopyahin ito sa Moira. Isabit mo ito nang may mga limitasyon at makakuha ng alerto sa output. Para magawa ang lahat ng ito, hindi mo kailangan ng anumang partikular na kaalaman. Maaaring mag-alerto si Moira sa pamamagitan ng SMS, email, Jira, Slack... Sinusuportahan din nito ang pagpapatupad ng mga custom na script. Kapag may naganap na trigger sa kanya, at naka-subscribe siya sa isang custom na script o binary, pinapatakbo niya ito at ipinapadala ang JSON sa stdin para sa binary na ito. Alinsunod dito, dapat itong i-parse ng iyong programa. Nasa sa iyo kung ano ang gagawin mo sa JSON na ito. Kung gusto mo, ipadala ito sa Telegram, kung gusto mo, buksan ang mga gawain sa Jira, gawin ang kahit ano.
Ginagamit din namin ang aming sariling pag-unlad para sa pag-alerto - Imagotag. Iniangkop namin ang panel, na karaniwang ginagamit para sa mga electronic na tag ng presyo sa mga tindahan, upang umangkop sa aming mga pangangailangan. Nagdala kami ng mga trigger mula kay Moira dito. Ipinapahiwatig nito kung anong estado sila at kung kailan sila naganap. Ang ilan sa mga taong nag-develop ay inabandona ang mga abiso sa Slack at nag-email sa pabor sa panel na ito.
Well, dahil progresibong kumpanya kami, sinusubaybayan din namin ang mga Kubernetes sa sistemang ito. Isinama namin ito sa system gamit ang Heapster, na na-install namin sa cluster, nangongolekta ito ng data at ipinapadala ito sa Graphite. Bilang resulta, ganito ang hitsura ng diagram:
Mga Bahagi ng Pagsubaybay
Narito ang isang listahan ng mga link sa mga sangkap na ginamit namin para sa gawaing ito. Lahat sila ay open source.
Grapayt:
- go-carbon:
- bulong:
- graphite-api:
Carbon-c-relay:
Brubeck:
Nakolekta:
Moira:
Grafana:
Heapster:
statistics
At narito ang ilang numero tungkol sa kung paano gumagana ang system para sa amin.
Aggregator (brubeck)
Bilang ng mga sukatan: ~300/seg
Interval para sa pagpapadala ng mga sukatan sa Graphite: 30 sec
Paggamit ng mapagkukunan ng server: ~ 6% CPU (pinag-uusapan natin ang tungkol sa mga ganap na server); ~ 1Gb RAM; ~3 Mbps LAN
Graphite (go-carbon)
Bilang ng mga sukatan: ~ 1 / min
Interval ng pag-update ng mga sukatan: 30 seg
Scheme ng storage ng mga sukatan: 30sec 35d, 5min 90d, 10min 365d (nagbibigay sa iyo ng pag-unawa sa kung ano ang nangyayari sa serbisyo sa loob ng mahabang panahon)
Paggamit ng mapagkukunan ng server: ~10% CPU; ~ 20Gb RAM; ~30 Mbps LAN
Kakayahang umangkop
Talagang pinahahalagahan namin sa Avito ang flexibility sa aming serbisyo sa pagsubaybay. Bakit ba talaga siya naging ganito? Una, ang mga bahagi nito ay mapagpapalit: ang mga bahagi mismo at ang kanilang mga bersyon. Pangalawa, supportability. Dahil ang buong proyekto ay open source, maaari mong i-edit ang code sa iyong sarili, gumawa ng mga pagbabago, at ipatupad ang mga function na hindi available sa labas ng kahon. Medyo karaniwang mga stack ang ginagamit, pangunahin ang Go at Python, kaya ito ay ginagawa nang simple.
Narito ang isang halimbawa ng isang tunay na problema. Ang isang sukatan sa Graphite ay isang file. May pangalan ito. Pangalan ng file = pangalan ng sukatan. At may paraan para makarating doon. Ang mga pangalan ng file sa Linux ay limitado sa 255 character. At mayroon kaming (bilang "mga panloob na customer") na mga lalaki mula sa departamento ng database. Sinasabi nila sa amin: "Gusto naming subaybayan ang aming mga query sa SQL. At hindi sila 255 character, ngunit 8 MB bawat isa. Gusto naming ipakita ang mga ito sa Grafana, tingnan ang mga parameter para sa kahilingang ito, at mas mabuti pa, gusto naming makita ang tuktok ng mga naturang kahilingan. Magiging mahusay kung ito ay ipinapakita sa real time. Ito ay talagang cool na ilagay ang mga ito sa alerto.
Ang halimbawang SQL query ay kinuha bilang isang halimbawa mula sa
Nag-set up kami ng Redis server at ginagamit ang aming Collectd plugins, na pumupunta sa Postgres at kinukuha ang lahat ng data mula doon, na nagpapadala ng mga sukatan sa Graphite. Ngunit pinapalitan namin ng mga hash ang pangalan ng sukatan. Sabay-sabay naming ipinapadala ang parehong hash sa Redis bilang isang susi, at ang buong query sa SQL bilang isang halaga. Ang kailangan lang nating gawin ay tiyakin na maaaring pumunta si Grafana sa Redis at kunin ang impormasyong ito. Binubuksan namin ang Graphite API dahil... ito ang pangunahing interface para sa pakikipag-ugnayan ng lahat ng mga bahagi ng pagsubaybay na may grapayt, at nagpasok kami ng isang bagong function doon na tinatawag na aliasByHash() - mula sa Grafana nakuha namin ang pangalan ng sukatan, at ginagamit ito sa isang kahilingan sa Redis bilang isang susi, sa sagot na nakukuha namin ang halaga ng susi, na aming "SQL query" " Kaya, ipinakita namin sa Grafana ang isang pagpapakita ng isang SQL query, na sa teorya ay imposibleng ipakita doon, kasama ang mga istatistika dito (mga tawag, mga hilera, total_time, ...).
Mga resulta ng
Kakayahang magamit Ang aming serbisyo sa pagsubaybay ay magagamit 24/7 mula sa anumang aplikasyon at anumang code. Kung mayroon kang access sa mga pasilidad ng imbakan, maaari kang sumulat ng data sa serbisyo. Ang wika ay hindi mahalaga, ang mga desisyon ay hindi mahalaga. Kailangan mo lang malaman kung paano magbukas ng socket, maglagay ng metric doon at isara ang socket.
Pagiging maaasahan. Ang lahat ng mga bahagi ay fault-tolerant at mahusay na pinangangasiwaan ang aming mga load.
Mababang hadlang sa pagpasok. Upang magamit ang sistemang ito, hindi mo kailangang matuto ng mga programming language at query sa Grafana. Buksan lang ang iyong application, magpasok ng socket dito na magpapadala ng mga sukatan sa Graphite, isara ito, buksan ang Grafana, gumawa ng mga dashboard doon at tingnan ang gawi ng iyong mga sukatan, pagtanggap ng mga notification sa pamamagitan ng Moira.
Pagsasarili. Magagawa mo ang lahat ng ito sa iyong sarili, nang walang tulong ng mga inhinyero ng DevOps. At ito ay isang kalamangan, dahil maaari mong subaybayan ang iyong proyekto sa ngayon, hindi mo kailangang hilingin sa sinuman - upang simulan ang trabaho o gumawa ng mga pagbabago.
Ano ang pakay natin?
Ang lahat ng nakalista sa ibaba ay hindi lamang abstract na mga kaisipan, ngunit isang bagay na kung saan hindi bababa sa mga unang hakbang ay ginawa.
- Detektor ng anomalya. Nais naming lumikha ng isang serbisyo na pupunta sa aming mga imbakan ng Graphite at suriin ang bawat sukatan gamit ang iba't ibang mga algorithm. Mayroon nang mga algorithm na gusto nating tingnan, mayroong data, alam natin kung paano ito gagawin.
- Metadata. Marami tayong serbisyo, nagbabago sila sa paglipas ng panahon, tulad ng mga taong nagtatrabaho sa kanila. Ang patuloy na pagpapanatili ng manu-manong dokumentasyon ay hindi isang opsyon. Iyon ang dahilan kung bakit kami ngayon ay naglalagay ng metadata sa aming mga microservice. Nakasaad dito kung sino ang bumuo nito, ang mga wikang nakikipag-ugnayan dito, mga kinakailangan sa SLA, kung saan at kanino dapat ipadala ang mga abiso. Kapag nagde-deploy ng isang serbisyo, ang lahat ng data ng entity ay ginawa nang hiwalay. Bilang resulta, makakakuha ka ng dalawang link - isa sa mga nag-trigger, ang isa sa mga dashboard sa Grafana.
- Pagsubaybay sa bawat tahanan. Naniniwala kami na ang lahat ng mga developer ay dapat gumamit ng ganoong sistema. Sa kasong ito, palagi mong nauunawaan kung nasaan ang iyong trapiko, kung ano ang nangyayari dito, kung saan ito bumabagsak, kung saan ang mga kahinaan nito. Kung, halimbawa, may dumating at nag-crash sa iyong serbisyo, malalaman mo ang tungkol dito hindi sa isang tawag mula sa manager, ngunit mula sa isang alerto, at maaari mong agad na buksan ang pinakabagong mga log at makita kung ano ang nangyari doon.
- Mataas na pagganap. Ang aming proyekto ay patuloy na lumalaki, at ngayon ito ay nagpoproseso ng humigit-kumulang 2 mga halaga ng sukatan kada minuto. Isang taon na ang nakalilipas, ang figure na ito ay 000. At ang paglago ay nagpapatuloy, at nangangahulugan ito na pagkatapos ng ilang oras Graphite (bulong) ay magsisimulang mabigat na i-load ang disk subsystem. Tulad ng sinabi ko na, ang sistema ng pagsubaybay na ito ay lubos na pangkalahatan dahil sa pagpapalitan ng mga bahagi. May nagpapanatili at patuloy na nagpapalawak ng kanilang imprastraktura partikular para sa Graphite, ngunit nagpasya kaming pumunta sa ibang ruta: gamitin bilang isang imbakan para sa aming mga sukatan. Ang paglipat na ito ay halos kumpleto na, at sa lalong madaling panahon sasabihin ko sa iyo nang mas detalyado kung paano ito ginawa: kung anong mga paghihirap ang nagkaroon at kung paano sila nalampasan, kung paano napunta ang proseso ng paglipat, ilalarawan ko ang mga bahagi na pinili bilang umiiral at ang kanilang mga pagsasaayos.
Salamat sa iyong atensyon! Itanong ang iyong mga katanungan sa paksa, susubukan kong sagutin dito o sa mga sumusunod na post. Marahil ay may nakaranas ng pagbuo ng katulad na sistema ng pagsubaybay o paglipat sa Clickhouse sa isang katulad na sitwasyon - ibahagi ito sa mga komento.
Pinagmulan: www.habr.com