🥇Namatay ba ang pagsubaybay? — Mabuhay ang pagsubaybay

Mula noong 2008, ang aming kumpanya ay pangunahing nakatuon sa pamamahala ng imprastraktura at suportang teknikal sa buong orasan para sa mga proyekto sa web: mayroon kaming higit sa 400 mga kliyente, na halos 15% ng Russian e-commerce. Alinsunod dito, sinusuportahan ang isang napaka-magkakaibang arkitektura. Kung may nahulog, obligado kaming ayusin ito sa loob ng 15 minuto. Ngunit upang maunawaan na ang isang aksidente ay naganap, kailangan mong subaybayan ang proyekto at tumugon sa mga insidente. Paano ito gawin?

Naniniwala ako na may problema sa pag-aayos ng maayos na sistema ng pagsubaybay. Kung walang problema, ang aking talumpati ay binubuo ng isang thesis: "Paki-install ang Prometheus + Grafana at mga plugin 1, 2, 3." Sa kasamaang palad, hindi na ito gumagana sa ganoong paraan. At ang pangunahing problema ay ang lahat ay patuloy na naniniwala sa isang bagay na umiral noong 2008, sa mga tuntunin ng mga bahagi ng software.

Tungkol sa organisasyon ng sistema ng pagsubaybay, gusto kong sabihin na... walang mga proyektong may karampatang pagsubaybay. At ang sitwasyon ay napakasama na kung may bumagsak, may panganib na hindi ito mapapansin - pagkatapos ng lahat, lahat ay sigurado na "lahat ay sinusubaybayan."
Marahil ang lahat ay sinusubaybayan. Pero paano?

Lahat tayo ay nakatagpo ng isang kuwento tulad ng sumusunod: isang partikular na devops, isang tiyak na admin ay gumagana, isang development team ang lumapit sa kanila at nagsasabing - "kami ay inilabas, ngayon ay sinusubaybayan." Subaybayan kung ano? Paano ito gumagana?

OK. Sinusubaybayan namin ang makalumang paraan. At nagbabago na ito, at lumalabas na sinusubaybayan mo ang serbisyo A, na naging serbisyo B, na nakikipag-ugnayan sa serbisyo C. Ngunit sinasabi sa iyo ng development team: "I-install ang software, dapat itong subaybayan ang lahat!"

Kaya ano ang nagbago? - Ang lahat ay nagbago!

2008 Maayos ang lahat

Mayroong ilang mga developer, isang server, isang database server. Mula rito ang lahat. Mayroon kaming ilang impormasyon, nag-install kami ng zabbix, Nagios, cacti. At pagkatapos ay nagtakda kami ng malinaw na mga alerto sa CPU, sa pagpapatakbo ng disk, at sa espasyo sa disk. Gumagawa din kami ng ilang manu-manong pagsusuri upang matiyak na tumutugon ang site at ang mga order ay dumarating sa database. At iyon lang - kami ay higit o hindi gaanong protektado.

Kung ihahambing namin ang dami ng trabaho na ginawa ng administrator noon para magbigay ng pagsubaybay, kung gayon 98% nito ay awtomatiko: dapat na maunawaan ng taong gumagawa ng pagsubaybay kung paano i-install ang Zabbix, kung paano ito i-configure at i-configure ang mga alerto. At 2% - para sa mga panlabas na pagsusuri: na ang site ay tumugon at gumagawa ng isang kahilingan sa database, na ang mga bagong order ay dumating.

2010 Lumalaki ang load

Nagsisimula kaming palakihin ang web, pagdaragdag ng isang search engine. Gusto naming tiyakin na ang katalogo ng produkto ay naglalaman ng lahat ng mga produkto. At gumagana ang paghahanap ng produkto na iyon. Na ang database ay gumagana, na ang mga order ay ginagawa, na ang site ay tumugon sa labas at tumugon mula sa dalawang server at ang user ay hindi kick out sa site habang ito ay muling binabalanse sa isa pang server, atbp. Mayroong higit pang mga entity.

Bukod dito, ang entity na nauugnay sa imprastraktura ay nananatiling pinakamalaki sa ulo ng manager. Mayroon pa ring ideya sa aking isip na ang taong gumagawa ng pagsubaybay ay ang taong mag-i-install ng zabbix at makakapag-configure nito.

Ngunit sa parehong oras, lumilitaw ang trabaho sa pagsasagawa ng mga panlabas na pagsusuri, sa paglikha ng isang hanay ng mga script ng query ng indexer sa paghahanap, isang hanay ng mga script upang suriin kung nagbabago ang paghahanap sa panahon ng proseso ng pag-index, isang hanay ng mga script na nagsusuri na ang mga kalakal ay inilipat sa serbisyo sa paghahatid, atbp. at iba pa.

Tandaan: Sumulat ako ng "isang set ng mga script" nang 3 beses. Ibig sabihin, ang taong responsable sa pagsubaybay ay hindi na ang simpleng nag-i-install ng zabbix. Ito ay isang tao na nagsisimula sa coding. Ngunit wala pa ring nagbago sa isip ng koponan.

Ngunit ang mundo ay nagbabago, nagiging mas kumplikado. Isang virtualization layer at ilang bagong system ang idinagdag. Nagsisimula silang makipag-ugnayan sa isa't isa. Sino ang nagsabing "amoy microservices?" Ngunit ang bawat serbisyo ay mukhang isang website nang paisa-isa. Maaari naming buksan ito at maunawaan na nagbibigay ito ng kinakailangang impormasyon at gumagana nang mag-isa. At kung ikaw ay isang administrator na patuloy na kasangkot sa isang proyekto na umuunlad sa loob ng 5-7-10 taon, ang kaalamang ito ay naipon: isang bagong antas ang lilitaw - natanto mo ito, ang isa pang antas ay lilitaw - natanto mo ito...

Ngunit bihira ang sinumang sumasama sa isang proyekto sa loob ng 10 taon.

Resume ng Monitoringman

Ipagpalagay na nakarating ka sa isang bagong startup na agad na kumuha ng 20 developer, nagsulat ng 15 microservice, at isa kang admin na sinabihan: “Bumuo ng CI/CD. Pakiusap." Nakagawa ka ng CI/CD at bigla mong narinig: "Mahirap para sa amin na magtrabaho kasama ang produksyon sa isang "cube", nang hindi nauunawaan kung paano gagana ang application dito. Gawin kaming sandbox sa parehong "kubo".
Gumawa ka ng sandbox sa cube na ito. Kaagad nilang sasabihin sa iyo: "Gusto namin ng database ng entablado na ina-update araw-araw mula sa produksyon, upang maunawaan namin na gumagana ito sa database, ngunit sa parehong oras ay hindi masira ang database ng produksyon."

Nabubuhay ka sa lahat ng ito. Mayroong 2 linggo na natitira bago ang paglabas, sasabihin nila sa iyo: "Ngayon, subaybayan natin ang lahat ng ito..." Iyon ay. subaybayan ang imprastraktura ng cluster, subaybayan ang arkitektura ng microservice, subaybayan ang trabaho sa mga panlabas na serbisyo...

At inalis ng aking mga kasamahan ang karaniwang pamamaraan sa kanilang mga ulo at sinasabing: "Buweno, malinaw ang lahat dito! Mag-install ng program na susubaybay sa lahat ng ito.” Oo, oo: Prometheus + Grafana + mga plugin.
At idinagdag nila: "Mayroon kang dalawang linggo, siguraduhing ligtas ang lahat."

Sa maraming mga proyekto na nakikita natin, isang tao ang inilalaan para sa pagsubaybay. Isipin na gusto naming kumuha ng isang tao na magsagawa ng pagsubaybay sa loob ng 2 linggo, at sumulat kami ng isang resume para sa kanya. Anong mga kasanayan ang dapat mayroon ang taong ito, dahil sa lahat ng sinabi natin sa ngayon?

Dapat niyang maunawaan ang pagsubaybay at mga detalye ng pagpapatakbo ng imprastraktura ng bakal.
Dapat niyang maunawaan ang mga detalye ng pagsubaybay sa Kubernetes (at lahat ay gustong pumunta sa "cube", dahil maaari mong abstract mula sa lahat, itago, dahil haharapin ng admin ang iba pa) - mismo, ang imprastraktura nito, at maunawaan kung paano subaybayan ang mga application sa loob.
Dapat niyang maunawaan na ang mga serbisyo ay nakikipag-ugnayan sa isa't isa sa mga espesyal na paraan, at alam ang mga detalye kung paano nakikipag-ugnayan ang mga serbisyo sa isa't isa. Ito ay lubos na posible upang makita ang isang proyekto kung saan ang ilang mga serbisyo ay nakikipag-usap nang sabay-sabay, dahil walang ibang paraan. Halimbawa, ang backend ay dumadaan sa REST, sa pamamagitan ng gRPC sa serbisyo ng catalog, tumatanggap ng listahan ng mga produkto at ibinabalik ito. Hindi ka makapaghintay dito. At sa iba pang mga serbisyo ito ay gumagana nang asynchronously. Ilipat ang order sa delivery service, magpadala ng sulat, atbp.
Malamang nakalangoy ka na sa lahat ng ito? At lalong nataranta ang admin na kailangang subaybayan ito.
Dapat ay marunong siyang magplano at magplano ng tama - habang ang trabaho ay nagiging mas at higit pa.
Samakatuwid, dapat siyang lumikha ng isang diskarte mula sa nilikha na serbisyo upang maunawaan kung paano ito partikular na susubaybayan. Kailangan niya ng pag-unawa sa arkitektura ng proyekto at pag-unlad nito + pag-unawa sa mga teknolohiyang ginagamit sa pag-unlad.

Tandaan natin ang isang ganap na normal na kaso: ang ilang mga serbisyo ay nasa PHP, ang ilang mga serbisyo ay nasa Go, ang ilang mga serbisyo ay nasa JS. Kahit papaano ay nakikipagtulungan sila sa isa't isa. Dito nagmula ang terminong "microservice": napakaraming indibidwal na system na hindi maintindihan ng mga developer ang proyekto sa kabuuan. Isang bahagi ng koponan ang nagsusulat ng mga serbisyo sa JS na gumagana nang mag-isa at hindi alam kung paano gumagana ang natitirang bahagi ng system. Ang kabilang bahagi ay nagsusulat ng mga serbisyo sa Python at hindi nakakasagabal sa kung paano gumagana ang ibang mga serbisyo; sila ay nakahiwalay sa kanilang sariling lugar. Ang pangatlo ay ang pagsulat ng mga serbisyo sa PHP o iba pa.
Ang lahat ng 20 tao na ito ay nahahati sa 15 na serbisyo, at mayroon lamang isang admin na dapat maunawaan ang lahat ng ito. Tumigil ka! hinati lang namin ang system sa 15 microservices dahil 20 tao ang hindi nakakaintindi sa buong system.

Pero kailangan subaybayan kahit papaano...

Ano ang resulta? Bilang isang resulta, mayroong isang tao na nag-iisip ng lahat ng bagay na hindi maintindihan ng buong koponan ng mga developer, at sa parehong oras ay dapat din niyang malaman at magawa ang aming ipinahiwatig sa itaas - imprastraktura ng hardware, imprastraktura ng Kubernetes, atbp.

Ano ang masasabi ko... Houston, may mga problema tayo.

Ang pagsubaybay sa isang modernong proyekto ng software ay isang proyekto ng software mismo

Mula sa maling paniniwala na ang pagsubaybay ay software, nagkakaroon kami ng paniniwala sa mga himala. Ngunit ang mga himala, sayang, ay hindi mangyayari. Hindi mo mai-install ang zabbix at asahan na gagana ang lahat. Walang punto sa pag-install ng Grafana at umaasa na magiging ok ang lahat. Karamihan sa mga oras ay gugugol sa pag-aayos ng mga pagsusuri ng pagpapatakbo ng mga serbisyo at ang kanilang pakikipag-ugnayan sa isa't isa, pagsuri kung paano gumagana ang mga panlabas na sistema. Sa katunayan, 90% ng oras ay gugugol hindi sa pagsulat ng mga script, ngunit sa pagbuo ng software. At dapat itong hawakan ng isang pangkat na nakakaunawa sa gawain ng proyekto.
Kung sa sitwasyong ito ang isang tao ay itinapon sa pagsubaybay, kung gayon ang sakuna ay mangyayari. Alin ang nangyayari sa lahat ng dako.

Halimbawa, mayroong ilang mga serbisyo na nakikipag-ugnayan sa isa't isa sa pamamagitan ng Kafka. Dumating ang order, nagpadala kami ng mensahe tungkol sa order kay Kafka. Mayroong isang serbisyo na nakikinig sa impormasyon tungkol sa order at nagpapadala ng mga kalakal. Mayroong isang serbisyo na nakikinig sa impormasyon tungkol sa order at nagpapadala ng liham sa gumagamit. At pagkatapos ay lumilitaw ang isang grupo ng higit pang mga serbisyo, at nagsisimula kaming malito.

At kung ibibigay mo rin ito sa admin at mga developer sa yugto kung kailan may maikling oras na natitira bago ang paglabas, kakailanganin ng tao na maunawaan ang buong protocol na ito. Yung. Ang isang proyekto ng sukat na ito ay tumatagal ng isang malaking halaga ng oras, at ito ay dapat na isasaalang-alang sa pagbuo ng system.
Ngunit madalas, lalo na sa mga startup, nakikita natin kung paano ipinagpaliban ang pagsubaybay hanggang sa ibang pagkakataon. “Ngayon ay gagawa tayo ng Proof of Concept, ilulunsad natin ito, hayaang mahulog - handa tayong magsakripisyo. At pagkatapos ay susubaybayan namin ang lahat. Kapag (o kung) nagsimulang kumita ang proyekto, gusto ng negosyo na magdagdag ng higit pang mga tampok - dahil nagsimula na itong gumana, kaya kailangan pa itong ilunsad! At ikaw ay nasa punto kung saan kailangan mo munang subaybayan ang lahat ng nakaraan, na hindi tumatagal ng 1% ng oras, ngunit higit pa. At siya nga pala, kakailanganin ng mga developer para sa pagsubaybay, at mas madaling hayaan silang magtrabaho sa mga bagong feature. Bilang isang resulta, ang mga bagong tampok ay nakasulat, ang lahat ay nagiging screwed up, at ikaw ay nasa isang walang katapusang deadlock.

Kaya kung paano subaybayan ang isang proyekto simula sa simula, at ano ang gagawin kung nakakuha ka ng isang proyekto na kailangang subaybayan, ngunit hindi mo alam kung saan magsisimula?

Una, kailangan mong magplano.

Lyrical digression: kadalasan nagsisimula sila sa pagsubaybay sa imprastraktura. Halimbawa, mayroon kaming Kubernetes. Magsimula tayo sa pamamagitan ng pag-install ng Prometheus sa Grafana, pag-install ng mga plugin para sa pagsubaybay sa "cube". Hindi lamang ang mga developer, kundi pati na rin ang mga administrator ay may kapus-palad na kasanayan ng: "I-install namin ang plugin na ito, ngunit malamang na alam ng plugin kung paano ito gawin." Gusto ng mga tao na magsimula sa simple at prangka, sa halip na sa mahahalagang aksyon. At madali ang pagsubaybay sa imprastraktura.

Una, magpasya kung ano at kung paano mo gustong subaybayan, at pagkatapos ay pumili ng isang tool, dahil ang ibang mga tao ay hindi makapag-isip para sa iyo. At dapat sila? Ang ibang mga tao ay nag-isip sa kanilang sarili, tungkol sa isang unibersal na sistema - o hindi nag-isip nang lahat noong isinulat ang plugin na ito. At dahil lamang sa ang plugin na ito ay may 5 libong mga gumagamit ay hindi nangangahulugan na ito ay may anumang gamit. Marahil ikaw ay magiging ika-5001 dahil lang mayroon nang 5000 na tao doon noon.

Kung sisimulan mong subaybayan ang imprastraktura at ang backend ng iyong application ay hihinto sa pagtugon, mawawalan ng koneksyon ang lahat ng user sa mobile application. May lalabas na error. Lalapit sila sa iyo at sasabihing "Hindi gumagana ang application, anong ginagawa mo dito?" - "Kami ay sinusubaybayan." — “Paano mo susubaybayan kung hindi mo nakikitang hindi gumagana ang application?!”

Naniniwala ako na kailangan mong simulan ang pagsubaybay nang eksakto mula sa entry point ng user. Kung hindi nakikita ng user na gumagana ang application, iyon lang, ito ay isang pagkabigo. At ang sistema ng pagsubaybay ay dapat na babala muna tungkol dito.
At saka lang natin masusubaybayan ang imprastraktura. O gawin ito sa parallel. Mas madali sa imprastraktura - dito na lang natin mai-install ang zabbix.
At ngayon kailangan mong pumunta sa mga ugat ng application upang maunawaan kung saan hindi gumagana ang mga bagay.

Ang aking pangunahing ideya ay ang pagsubaybay ay dapat na kaayon ng proseso ng pag-unlad. Kung abalahin mo ang monitoring team para sa iba pang mga gawain (paglikha ng CI/CD, sandboxing, muling pag-aayos ng imprastraktura), magsisimulang mahuli ang pagsubaybay at maaaring hindi ka na makahabol sa pag-unlad (o maaga o huli, kakailanganin mong ihinto ito).

Lahat sa pamamagitan ng mga antas

Ito ay kung paano ko nakikita ang organisasyon ng isang sistema ng pagsubaybay.

1) Antas ng aplikasyon:

pagsubaybay sa lohika ng negosyo ng aplikasyon;
pagsubaybay sa mga sukatan ng kalusugan ng mga serbisyo;
pagsubaybay sa integrasyon.

2) Antas ng imprastraktura:

pagsubaybay sa antas ng orkestrasyon;
pagsubaybay sa software ng system;
pagsubaybay sa antas ng bakal.

3) Muli ang antas ng aplikasyon - ngunit bilang isang produkto ng engineering:

pagkolekta at pagsubaybay sa mga log ng aplikasyon;
APM;
pagsubaybay.

4) Alerto:

organisasyon ng isang sistema ng babala;
organisasyon ng isang sistema ng tungkulin;
organisasyon ng isang "base ng kaalaman" at daloy ng trabaho para sa pagproseso ng insidente.

Mahalagang: nakakakuha tayo sa alerto hindi pagkatapos, ngunit kaagad! Hindi na kailangang ilunsad ang pagsubaybay at "sa anumang paraan mamaya" alamin kung sino ang makakatanggap ng mga alerto. Pagkatapos ng lahat, ano ang gawain ng pagsubaybay: upang maunawaan kung saan sa system ang isang bagay ay gumagana nang mali, at upang ipaalam sa mga tamang tao ang tungkol dito. Kung iiwan mo ito hanggang sa huli, malalaman ng mga tamang tao na may nangyayaring mali sa pamamagitan lamang ng pagtawag na "walang gumagana para sa amin."

Application Layer - Pagsubaybay sa Logic ng Negosyo

Dito pinag-uusapan natin ang pagsuri sa mismong katotohanan na gumagana ang application para sa user.

Ang antas na ito ay dapat gawin sa yugto ng pag-unlad. Halimbawa, mayroon kaming conditional na Prometheus: papunta ito sa server na gumagawa ng mga tseke, kinukuha ang endpoint, at ang endpoint ay pupunta at sinusuri ang API.

Kapag madalas na hinihiling na subaybayan ang home page upang matiyak na gumagana ang site, ang mga programmer ay nagbibigay ng hawakan na maaaring hilahin sa tuwing kailangan nilang tiyakin na gumagana ang API. At ang mga programmer sa sandaling ito ay kumukuha pa rin at sumulat ng /api/test/helloworld
Ang tanging paraan upang matiyak na gumagana ang lahat? - Hindi!

Ang paggawa ng mga naturang pagsusuri ay mahalagang gawain ng mga developer. Ang mga pagsubok sa yunit ay dapat isulat ng mga programmer na sumulat ng code. Dahil kung i-leak mo ito sa admin, "Dude, narito ang isang listahan ng mga protocol ng API para sa lahat ng 25 function, mangyaring subaybayan ang lahat!" - walang gagana.
Kung magpi-print ka ng "hello world", walang makakaalam na dapat at gumagana ang API. Ang bawat pagbabago sa API ay dapat humantong sa isang pagbabago sa mga pagsusuri.
Kung mayroon ka nang ganoong problema, ihinto ang mga tampok at maglaan ng mga developer na magsusulat ng mga pagsusuring ito, o tanggapin ang mga pagkalugi, tanggapin na walang sinusuri at mabibigo.

Mga Teknikal na Tip:

Siguraduhing ayusin ang isang panlabas na server upang ayusin ang mga pagsusuri - dapat mong tiyakin na ang iyong proyekto ay naa-access sa labas ng mundo.
Ayusin ang mga pagsusuri sa buong API protocol, hindi lang sa mga indibidwal na endpoint.
Gumawa ng prometheus-endpoint na may mga resulta ng pagsubok.

Application layer - pagsubaybay sa mga sukatan ng kalusugan

Ngayon ay pinag-uusapan natin ang tungkol sa panlabas na sukatan ng kalusugan ng mga serbisyo.

Napagpasyahan namin na subaybayan namin ang lahat ng "mga hawakan" ng application gamit ang mga panlabas na pagsusuri, na tinatawag namin mula sa isang panlabas na sistema ng pagsubaybay. Ngunit ito ang "mga hawakan" na "nakikita" ng gumagamit. Gusto naming makatiyak na gumagana ang aming mga serbisyo. Narito ang kuwento ay mas mahusay: K8s ay may mga pagsusuri sa kalusugan, upang hindi bababa sa "kubo" mismo ay maaaring kumbinsido na ang serbisyo ay gumagana. Ngunit kalahati ng mga tseke na nakita ko ay ang parehong naka-print na "hello world". Yung. Kaya isang beses siyang humila pagkatapos ng deployment, sumagot siya na maayos ang lahat - iyon lang. At ang serbisyo, kung nagbibigay ito ng sarili nitong API, ay may malaking bilang ng mga entry point para sa parehong API, na kailangan ding subaybayan, dahil gusto naming malaman na gumagana ito. At sinusubaybayan na namin ito sa loob.

Paano ito maipapatupad nang tama sa teknikal na paraan: ang bawat serbisyo ay naglalantad ng isang endpoint tungkol sa kasalukuyang pagganap nito, at sa mga graph ng Grafana (o anumang iba pang aplikasyon) makikita namin ang katayuan ng lahat ng mga serbisyo.

Ang bawat pagbabago sa API ay dapat humantong sa isang pagbabago sa mga pagsusuri.
Gumawa kaagad ng bagong serbisyo gamit ang mga sukatan sa kalusugan.
Maaaring pumunta ang isang admin sa mga developer at magtanong ng “idagdag ako ng ilang feature para maunawaan ko ang lahat at magdagdag ng impormasyon tungkol dito sa aking monitoring system.” Ngunit karaniwang sinasagot ng mga developer, "Hindi kami magdaragdag ng anuman dalawang linggo bago ang paglabas."
Ipaalam sa mga development manager na magkakaroon ng mga ganitong pagkalugi, ipaalam din sa pamamahala ng mga development manager. Dahil kapag bumagsak ang lahat, may tatawag pa rin at hihingi na subaybayan ang "patuloy na bumabagsak na serbisyo" (c)
Sa pamamagitan ng paraan, maglaan ng mga developer upang magsulat ng mga plugin para sa Grafana - ito ay magiging isang magandang tulong para sa mga admin.

Application Layer - Pagmamanman ng Pagsasama

Ang pagsubaybay sa pagsasama ay nakatuon sa pagsubaybay sa mga komunikasyon sa pagitan ng mga sistemang kritikal sa negosyo.

Halimbawa, mayroong 15 serbisyo na nakikipag-ugnayan sa isa't isa. Ang mga ito ay hindi na magkahiwalay na mga site. Yung. hindi namin maaaring kunin ang serbisyo nang mag-isa, kunin ang /helloworld at maunawaan na tumatakbo ang serbisyo. Dahil ang serbisyo sa web ng pag-order ay dapat magpadala ng impormasyon tungkol sa order sa bus - mula sa bus, dapat matanggap ng serbisyo ng bodega ang mensaheng ito at magtrabaho kasama nito nang higit pa. At ang serbisyo sa pamamahagi ng email ay dapat na iproseso ito kahit papaano, atbp.

Alinsunod dito, hindi namin maintindihan, na sinusundo ang bawat indibidwal na serbisyo, na gumagana ang lahat. Dahil mayroon kaming isang tiyak na bus kung saan lahat ay nakikipag-usap at nakikipag-ugnayan.
Samakatuwid, dapat markahan ng yugtong ito ang yugto ng mga serbisyo sa pagsubok para sa pakikipag-ugnayan sa iba pang mga serbisyo. Imposibleng ayusin ang pagsubaybay sa komunikasyon sa pamamagitan ng pagsubaybay sa broker ng mensahe. Kung mayroong isang serbisyo na nag-iisyu ng data at isang serbisyo na tumatanggap nito, kapag sinusubaybayan ang broker ay makikita lamang namin ang data na lumilipad mula sa gilid patungo sa gilid. Kahit na kahit papaano ay nagawa naming subaybayan ang interaksyon ng data na ito sa loob - na ang isang partikular na producer ay nag-post ng data, may nagbabasa nito, ang daloy na ito ay patuloy na napupunta sa Kafka - hindi pa rin ito magbibigay sa amin ng impormasyon kung ang isang serbisyo ay nagpadala ng mensahe sa isang bersyon , ngunit hindi inaasahan ng ibang serbisyo ang bersyong ito at nilaktawan ito. Hindi namin malalaman ang tungkol dito, dahil sasabihin sa amin ng mga serbisyo na gumagana ang lahat.

Ano ang inirerekomenda kong gawin:

Para sa magkakasabay na komunikasyon: ang endpoint ay gumagawa ng mga kahilingan sa mga kaugnay na serbisyo. Yung. kinukuha namin ang endpoint na ito, kumukuha ng script sa loob ng serbisyo, na pupunta sa lahat ng punto at nagsasabing "Maaari kong hilahin doon, at hilahin doon, maaari kong hilahin doon..."
Para sa asynchronous na komunikasyon: mga papasok na mensahe - sinusuri ng endpoint ang bus para sa mga pansubok na mensahe at ipinapakita ang katayuan sa pagpoproseso.
Para sa asynchronous na komunikasyon: mga papalabas na mensahe - ang endpoint ay nagpapadala ng mga pansubok na mensahe sa bus.

Gaya ng karaniwang nangyayari: mayroon kaming serbisyong naghahatid ng data sa bus. Pumunta kami sa serbisyong ito at hinihiling sa iyo na sabihin sa amin ang tungkol sa kalusugan ng pagsasama nito. At kung ang serbisyo ay kailangang gumawa ng isang mensahe sa isang lugar pa (WebApp), gagawa ito ng pagsubok na mensahe. At kung kami ay nagpapatakbo ng isang serbisyo sa bahagi ng OrderProcessing, ito ay unang nagpo-post kung ano ang maaari nitong i-post na independyente, at kung mayroong ilang mga umaasa na bagay, pagkatapos ay nagbabasa ito ng isang set ng mga pansubok na mensahe mula sa bus, nauunawaan na maaari nitong iproseso ang mga ito, iulat ito at , kung kinakailangan, i-post ang mga ito nang higit pa, at tungkol dito sabi niya - lahat ay ok, buhay ako.

Kadalasan ay naririnig natin ang tanong na "paano natin masusubok ito sa data ng labanan?" Halimbawa, pinag-uusapan natin ang parehong serbisyo sa pag-order. Ang order ay nagpapadala ng mga mensahe sa bodega kung saan ang mga kalakal ay isinulat: hindi namin ito masubukan sa data ng labanan, dahil "ang aking mga kalakal ay mapapawi!" Solusyon: Planuhin ang buong pagsubok na ito sa simula. Mayroon ka ring mga unit test na gumagawa ng mga pangungutya. Kaya, gawin ito sa mas malalim na antas kung saan mayroon kang channel ng komunikasyon na hindi nakakasira sa pagpapatakbo ng negosyo.

Antas ng imprastraktura

Ang pagsubaybay sa imprastraktura ay isang bagay na matagal nang itinuturing na pagsubaybay mismo.

Ang pagsubaybay sa imprastraktura ay maaari at dapat na ilunsad bilang isang hiwalay na proseso.
Hindi ka dapat magsimula sa pagsubaybay sa imprastraktura sa isang tumatakbong proyekto, kahit na gusto mo talaga. Ito ay isang sakit para sa lahat ng devops. "Una, susubaybayan ko ang kumpol, susubaybayan ko ang imprastraktura" - i.e. Una, susubaybayan nito kung ano ang nasa ibaba, ngunit hindi papasok sa application. Dahil ang application ay isang bagay na hindi maintindihan para sa mga devops. Na-leak ito sa kanya, at hindi niya maintindihan kung paano ito gumagana. Ngunit naiintindihan niya ang imprastraktura at nagsisimula dito. Ngunit hindi - kailangan mo munang subaybayan ang application.
Huwag lumampas sa bilang ng mga alerto. Isinasaalang-alang ang pagiging kumplikado ng mga modernong system, ang mga alerto ay patuloy na lumilipad, at kailangan mong mamuhay nang may ganitong grupo ng mga alerto. At ang on-call na tao, nang tumingin sa isang daan sa mga susunod na alerto, ay magpapasya na "Ayoko nang isipin ito." Ang mga alerto ay dapat lamang mag-abiso tungkol sa mga kritikal na bagay.

Antas ng aplikasyon bilang isang yunit ng negosyo

Pangunahing puntos:

ELK. Ito ang pamantayan ng industriya. Kung sa ilang kadahilanan ay hindi ka nagsasama-sama ng mga log, simulan ang paggawa nito kaagad.
APM. Mga panlabas na APM bilang isang paraan upang mabilis na isara ang pagsubaybay sa application (NewRelic, BlackFire, Datadog). Maaari mong pansamantalang i-install ang bagay na ito upang kahit paano ay maunawaan kung ano ang nangyayari sa iyo.
Pagsubaybay. Sa dose-dosenang mga microservice, kailangan mong subaybayan ang lahat, dahil ang kahilingan ay hindi na nabubuhay nang mag-isa. Napakahirap idagdag sa ibang pagkakataon, kaya mas mahusay na agad na mag-iskedyul ng pagsubaybay sa pag-unlad - ito ang gawain at utility ng mga developer. Kung hindi mo pa ito ipinatupad, ipatupad ito! Tingnan ang Jaeger/Zipkin

Nag-aalerto

Organisasyon ng isang sistema ng abiso: sa mga kondisyon ng pagsubaybay sa isang grupo ng mga bagay, dapat mayroong isang pinag-isang sistema para sa pagpapadala ng mga abiso. Maaari ka sa Grafana. Sa Kanluran, lahat ay gumagamit ng PagerDuty. Ang mga alerto ay dapat na malinaw (hal. kung saan sila nanggaling...). At ipinapayong kontrolin na ang mga abiso ay natatanggap sa lahat
Organisasyon ng isang sistema ng tungkulin: hindi dapat magpadala ng mga alerto sa lahat (alinman sa lahat ay magre-react sa karamihan, o walang magre-react). Kailangan ding maging oncall ang mga developer: siguraduhing tukuyin ang mga lugar ng responsibilidad, gumawa ng malinaw na mga tagubilin at isulat dito kung sino ang eksaktong tatawag sa Lunes at Miyerkules, at kung sino ang tatawagan sa Martes at Biyernes (kung hindi, hindi sila tatawag sa sinuman kahit na sa kaganapan ng isang malaking problema - matatakot silang gisingin ka o abalahin : karaniwang ayaw ng mga tao na tumawag at gisingin ang ibang tao, lalo na sa gabi). At ipaliwanag na ang paghingi ng tulong ay hindi isang tagapagpahiwatig ng kawalan ng kakayahan ("Humihingi ako ng tulong, ibig sabihin ako ay isang masamang manggagawa"), hikayatin ang mga kahilingan para sa tulong.
Organisasyon ng isang "base ng kaalaman" at daloy ng trabaho para sa pagpoproseso ng insidente: para sa bawat seryosong insidente, dapat magplano ng post-mortem, at bilang pansamantalang panukala, dapat na itala ang mga aksyon na magresolba sa insidente. At gawin itong isang kasanayan na ang paulit-ulit na mga alerto ay isang kasalanan; kailangan nilang ayusin sa code o infrastructure work.

Salansan ng teknolohiya

Isipin natin na ang aming stack ay ang mga sumusunod:

pangongolekta ng data - Prometheus + Grafana;
pagtatasa ng log - ELK;
para sa APM o Tracing - Jaeger (Zipkin).

Ang pagpili ng mga opsyon ay hindi kritikal. Dahil kung sa simula ay naiintindihan mo kung paano subaybayan ang system at nagsulat ng isang plano, pagkatapos ay magsisimula kang pumili ng mga tool upang umangkop sa iyong mga kinakailangan. Ang tanong ay kung ano ang pinili mong subaybayan sa unang lugar. Dahil marahil ang tool na pinili mo sa simula ay hindi angkop sa iyong mga kinakailangan.

Ilang teknikal na punto na nakikita ko saanman kamakailan:

Si Prometheus ay itinutulak sa loob ng Kubernetes - sino ang nakaisip nito?! Kung nag-crash ang iyong cluster, ano ang iyong gagawin? Kung mayroon kang isang kumplikadong kumpol sa loob, dapat mayroong ilang uri ng sistema ng pagsubaybay sa loob ng kumpol, at ang iba sa labas, na mangongolekta ng data mula sa loob ng kumpol.

Sa loob ng cluster kinokolekta namin ang mga log at lahat ng iba pa. Ngunit ang sistema ng pagsubaybay ay dapat nasa labas. Kadalasan, sa isang kumpol kung saan may naka-install na Promtheus sa loob, mayroon ding mga system na nagsasagawa ng mga panlabas na pagsusuri sa pagpapatakbo ng site. Paano kung ang iyong mga koneksyon sa labas ng mundo ay bumaba at ang application ay hindi gumagana? Lumalabas na maayos ang lahat sa loob, ngunit hindi nito pinapadali ang mga bagay para sa mga user.

Natuklasan

Ang pagsubaybay sa pag-unlad ay hindi ang pag-install ng mga kagamitan, ngunit ang pagbuo ng isang produkto ng software. 98% ng pagsubaybay ngayon ay coding. Pag-coding sa mga serbisyo, pag-coding ng mga panlabas na pagsusuri, pagsuri sa mga panlabas na serbisyo, at iyon lang.
Huwag sayangin ang oras ng iyong mga developer sa pagsubaybay: maaari itong tumagal ng hanggang 30% ng kanilang trabaho, ngunit sulit ito.
Mga devops, huwag mag-alala na hindi mo masusubaybayan ang isang bagay, dahil ang ilang mga bagay ay ganap na naiibang paraan ng pag-iisip. Ikaw ay hindi isang programmer, at ang pagsubaybay sa trabaho ay eksaktong kanilang trabaho.
Kung ang proyekto ay tumatakbo na at hindi sinusubaybayan (at ikaw ay isang tagapamahala), maglaan ng mga mapagkukunan para sa pagsubaybay.
Kung ang produkto ay nasa produksyon na, at ikaw ay isang devops na sinabihan na "i-set up ang pagsubaybay" - subukang ipaliwanag sa pamamahala kung ano ang isinulat ko tungkol sa lahat ng ito.

Ito ay isang pinahabang bersyon ng ulat sa kumperensya ng Saint Highload++.

Kung interesado ka sa aking mga ideya at iniisip tungkol dito at mga kaugnay na paksa, dito mo magagawa basahin ang channel 🙂

Pinagmulan: www.habr.com

Patay na ba ang pagsubaybay? — Mabuhay ang pagsubaybay