Naisipan naming gumawa ng monitoring system sa yugto ng pagbuo ng mga team ng produkto. Naging malinaw na ang aming negosyo - pagsasamantala - ay hindi nabibilang sa mga pangkat na ito. Bakit ganon?
Ang katotohanan ay ang lahat ng aming mga koponan ay binuo sa paligid ng mga indibidwal na sistema ng impormasyon, mga microservice at mga harapan, kaya hindi nakikita ng mga koponan ang pangkalahatang kalusugan ng buong sistema sa kabuuan. Halimbawa, maaaring hindi nila alam kung paano nakakaapekto ang ilang maliit na bahagi sa deep backend sa front end. Ang kanilang saklaw ng interes ay limitado sa mga sistema kung saan isinama ang kanilang sistema. Kung ang isang koponan at ang serbisyo nito A ay halos walang koneksyon sa serbisyo B, kung gayon ang gayong serbisyo ay halos hindi nakikita ng koponan.
Ang aming koponan, sa turn, ay gumagana sa mga system na napakalakas na pinagsama sa isa't isa: maraming koneksyon sa pagitan nila, ito ay isang napakalaking imprastraktura. At ang pagpapatakbo ng online na tindahan ay nakasalalay sa lahat ng mga sistemang ito (kung saan mayroon kami, sa pamamagitan ng paraan, isang malaking bilang).
Kaya lumalabas na ang aming departamento ay hindi nabibilang sa anumang koponan, ngunit matatagpuan nang kaunti sa gilid. Sa buong kwentong ito, ang aming gawain ay komprehensibong maunawaan kung paano gumagana ang mga sistema ng impormasyon, ang kanilang paggana, mga pagsasama, software, network, hardware, at kung paano konektado ang lahat ng ito sa isa't isa.
Ang platform kung saan tumatakbo ang aming mga online na tindahan ay ganito ang hitsura:
- harap
- Gitnang opisina
- back office
Gaano man natin gusto, hindi mangyayari na gumagana nang maayos at walang kamali-mali ang lahat ng system. Ang punto, muli, ay ang bilang ng mga system at pagsasama - sa isang bagay na tulad ng sa amin, ang ilang mga insidente ay hindi maiiwasan, sa kabila ng kalidad ng pagsubok. Bukod dito, pareho sa loob ng isang hiwalay na sistema at sa mga tuntunin ng kanilang pagsasama. At kailangan mong subaybayan ang estado ng buong platform nang komprehensibo, at hindi ang anumang indibidwal na bahagi nito.
Sa isip, dapat na awtomatiko ang pagsubaybay sa kalusugan sa buong platform. At dumating kami sa pagsubaybay bilang isang hindi maiiwasang bahagi ng prosesong ito. Sa una, ito ay binuo lamang para sa front-line na bahagi, habang ang mga network specialist, software at hardware administrator ay mayroon at mayroon pa ring sariling layer-by-layer monitoring system. Ang lahat ng mga taong ito ay sumunod sa pagsubaybay lamang sa kanilang sariling antas; walang sinuman ang may komprehensibong pang-unawa.
Halimbawa, kung nag-crash ang isang virtual machine, sa karamihan ng mga kaso, ang administrator lang na responsable para sa hardware at ang virtual machine ang nakakaalam nito. Sa ganitong mga kaso, nakita ng frontline team ang mismong katotohanan ng pag-crash ng application, ngunit wala itong data tungkol sa pag-crash ng virtual machine. At maaaring malaman ng administrator kung sino ang customer at magkaroon ng magaspang na ideya kung ano ang kasalukuyang tumatakbo sa virtual machine na ito, sa kondisyon na ito ay isang uri ng malaking proyekto. Malamang na hindi niya alam ang tungkol sa mga maliliit. Sa anumang kaso, ang administrator ay kailangang pumunta sa may-ari at tanungin kung ano ang nasa makina na ito, kung ano ang kailangang ibalik at kung ano ang kailangang baguhin. At kung may nangyaring seryoso, nagsimula silang tumakbo nang paikot-ikot - dahil walang nakakita sa sistema sa kabuuan.
Sa huli, ang mga ganitong magkakaibang kwento ay nakakaapekto sa buong frontend, mga user at aming pangunahing function ng negosyo - mga online na benta. Dahil hindi kami bahagi ng isang team, ngunit nakikibahagi sa pagpapatakbo ng lahat ng application ng ecommerce bilang bahagi ng isang online na tindahan, ginawa namin ang gawain ng paglikha ng isang komprehensibong sistema ng pagsubaybay para sa platform ng ecommerce.
Istraktura at stack ng system
Nagsimula kami sa pamamagitan ng pagtukoy ng ilang mga layer ng pagsubaybay para sa aming mga system, kung saan kakailanganin naming mangolekta ng mga sukatan. At ang lahat ng ito ay kailangang pagsamahin, na kung ano ang ginawa namin sa unang yugto. Ngayon sa yugtong ito, tinatapos namin ang pinakamataas na kalidad na koleksyon ng mga sukatan sa lahat ng aming mga layer upang makabuo ng ugnayan at maunawaan kung paano naiimpluwensyahan ng mga system ang isa't isa.
Ang kakulangan ng komprehensibong pagsubaybay sa mga unang yugto ng paglulunsad ng application (mula noong sinimulan namin itong buuin noong karamihan sa mga system ay nasa produksyon) na humantong sa katotohanan na mayroon kaming malaking teknikal na utang upang i-set up ang pagsubaybay sa buong platform. Hindi namin kayang mag-focus sa pag-set up ng pagsubaybay para sa isang IS at pag-aayos ng pagsubaybay para dito nang detalyado, dahil ang iba pang mga system ay maiiwan nang walang pagsubaybay nang ilang panahon. Upang malutas ang problemang ito, natukoy namin ang isang listahan ng mga pinaka-kinakailangang sukatan para sa pagtatasa ng estado ng sistema ng impormasyon sa pamamagitan ng layer at nagsimulang ipatupad ito.
Samakatuwid, nagpasya silang kainin ang elepante sa ilang bahagi.
Ang aming sistema ay binubuo ng:
- hardware;
- operating system;
- software;
- Mga bahagi ng UI sa application ng pagsubaybay;
- mga sukatan ng negosyo;
- mga aplikasyon ng pagsasama;
- seguridad ng impormasyon;
- mga network;
- tagabalanse ng trapiko.
Sa gitna ng sistemang ito ay ang pagsubaybay mismo. Upang pangkalahatang maunawaan ang estado ng buong system, kailangan mong malaman kung ano ang nangyayari sa mga application sa lahat ng mga layer na ito at sa buong hanay ng mga application.
Kaya, tungkol sa stack.
Gumagamit kami ng open source software. Sa gitna mayroon kaming Zabbix, na pangunahing ginagamit namin bilang isang sistema ng pag-aalerto. Alam ng lahat na ito ay perpekto para sa pagsubaybay sa imprastraktura. Ano ang ibig sabihin nito? Eksakto sa mga mababang antas na sukatan na mayroon ang bawat kumpanya na nagpapanatili ng sarili nitong data center (at ang Sportmaster ay may sariling mga data center) - temperatura ng server, katayuan ng memorya, pagsalakay, mga sukatan ng device sa network.
Isinama namin ang Zabbix sa Telegram messenger at Microsoft Teams, na aktibong ginagamit sa mga team. Sinasaklaw ng Zabbix ang layer ng aktwal na network, hardware at ilang software, ngunit hindi ito isang panlunas sa lahat. Pinayaman namin ang data na ito mula sa ilang iba pang serbisyo. Halimbawa, sa antas ng hardware, direktang kumonekta kami sa pamamagitan ng API sa aming virtualization system at nangongolekta ng data.
Ano pa. Bilang karagdagan sa Zabbix, ginagamit namin ang Prometheus, na nagbibigay-daan sa amin na subaybayan ang mga sukatan sa isang dynamic na application sa kapaligiran. Ibig sabihin, makakatanggap kami ng mga sukatan ng application sa pamamagitan ng isang HTTP endpoint at huwag mag-alala tungkol sa kung aling mga sukatan ang ilo-load dito at kung alin ang hindi. Batay sa data na ito, maaaring bumuo ng mga analytical na query.
Ang mga mapagkukunan ng data para sa iba pang mga layer, halimbawa, mga sukatan ng negosyo, ay nahahati sa tatlong bahagi.
Una, ito ay mga panlabas na sistema ng negosyo, Google Analytics, kinokolekta namin ang mga sukatan mula sa mga log. Mula sa kanila nakakakuha kami ng data sa mga aktibong user, conversion at lahat ng iba pang nauugnay sa negosyo. Pangalawa, ito ay isang UI monitoring system. Dapat itong ilarawan nang mas detalyado.
Noong unang panahon nagsimula kami sa manu-manong pagsubok at ito ay lumago sa mga awtomatikong pagsubok ng pag-andar at pagsasama. Mula dito ginawa namin ang pagsubaybay, na iniiwan lamang ang pangunahing pag-andar, at umasa sa mga marker na stable hangga't maaari at hindi madalas na nagbabago sa paglipas ng panahon.
Ang bagong istraktura ng koponan ay nangangahulugan na ang lahat ng mga aktibidad sa aplikasyon ay nakakulong sa mga pangkat ng produkto, kaya huminto kami sa paggawa ng purong pagsubok. Sa halip, gumawa kami ng pagsubaybay sa UI mula sa mga pagsubok, na nakasulat sa Java, Selenium at Jenkins (ginamit bilang isang sistema para sa paglulunsad at pagbuo ng mga ulat).
Marami kaming pagsubok, ngunit sa huli ay nagpasya kaming pumunta sa pangunahing kalsada, ang pinakamataas na antas ng sukatan. At kung marami tayong partikular na pagsubok, magiging mahirap na panatilihing napapanahon ang data. Ang bawat kasunod na release ay makabuluhang masira ang buong system, at ang gagawin lang namin ay ayusin ito. Samakatuwid, nakatuon kami sa mga napakapangunahing bagay na bihirang magbago, at sinusubaybayan lang namin ang mga ito.
Panghuli, pangatlo, ang data source ay isang sentralisadong sistema ng pag-log. Gumagamit kami ng Elastic Stack para sa mga log, at pagkatapos ay maaari naming kunin ang data na ito sa aming monitoring system para sa mga sukatan ng negosyo. Bilang karagdagan sa lahat ng ito, mayroon kaming sariling serbisyo ng Monitoring API, na nakasulat sa Python, na nagtatanong ng anumang mga serbisyo sa pamamagitan ng API at nangongolekta ng data mula sa mga ito sa Zabbix.
Ang isa pang kailangang-kailangan na katangian ng pagsubaybay ay visualization. Ang sa amin ay batay sa Grafana. Namumukod-tangi ito sa iba pang visualization system dahil pinapayagan ka nitong makita ang mga sukatan mula sa iba't ibang data source sa dashboard. Maaari kaming mangolekta ng pinakamataas na antas ng sukatan para sa isang online na tindahan, halimbawa, ang bilang ng mga order na inilagay sa huling oras mula sa DBMS, mga sukatan ng pagganap para sa OS kung saan tumatakbo ang online na tindahan na ito mula sa Zabbix, at mga sukatan para sa mga pagkakataon ng application na ito. mula sa Prometheus. At lahat ng ito ay nasa isang dashboard. Malinaw at naa-access.
Hayaan akong tandaan ang tungkol sa seguridad - kasalukuyan naming tinatapos ang system, na sa kalaunan ay isasama namin sa pandaigdigang sistema ng pagsubaybay. Sa aking opinyon, ang mga pangunahing problema na kinakaharap ng e-commerce sa larangan ng seguridad ng impormasyon ay nauugnay sa mga bot, parser at brute force. Kailangan nating bantayan ito, dahil lahat ng ito ay maaaring kritikal na makaapekto sa pagpapatakbo ng ating mga aplikasyon at sa ating reputasyon mula sa pananaw ng negosyo. At sa napiling salansan ay matagumpay nating nasasakop ang mga gawaing ito.
Ang isa pang mahalagang punto ay ang application layer ay binuo ng Prometheus. Siya mismo ay isinama din sa Zabbix. At mayroon din kaming sitespeed, isang serbisyo na nagbibigay-daan sa amin upang tingnan ang mga parameter tulad ng bilis ng paglo-load ng aming pahina, mga bottleneck, pag-render ng pahina, pag-load ng mga script, atbp., ito ay isinama rin ng API. Kaya ang aming mga sukatan ay kinokolekta sa Zabbix, at nang naaayon, alerto din kami mula doon. Ang lahat ng mga alerto ay kasalukuyang ipinadala sa mga pangunahing paraan ng pagpapadala (sa ngayon ito ay email at telegrama, kamakailan lamang ay konektado ang MS Teams). May mga planong i-upgrade ang pag-aalerto sa ganoong estado na gumagana ang mga smart bot bilang isang serbisyo at nagbibigay ng impormasyon sa pagsubaybay sa lahat ng interesadong pangkat ng produkto.
Para sa amin, ang mga sukatan ay mahalaga hindi lamang para sa mga indibidwal na sistema ng impormasyon, kundi pati na rin ang mga pangkalahatang sukatan para sa buong imprastraktura na ginagamit ng mga application: mga kumpol ng mga pisikal na server kung saan tumatakbo ang mga virtual machine, mga traffic balancer, Network Load Balancers, ang network mismo, ang paggamit ng mga channel ng komunikasyon . Dagdag pa ang mga sukatan para sa sarili naming mga data center (mayroon kaming ilan sa mga ito at medyo malaki ang imprastraktura).
Ang mga bentahe ng aming sistema ng pagsubaybay ay na sa tulong nito ay nakikita namin ang katayuan sa kalusugan ng lahat ng mga sistema at maaaring masuri ang kanilang epekto sa isa't isa at sa mga pinagsasaluhang mapagkukunan. At sa huli, pinapayagan tayo nitong makisali sa pagpaplano ng mapagkukunan, na responsibilidad din natin. Pinamamahalaan namin ang mga mapagkukunan ng server - isang pool sa loob ng e-commerce, komisyon at pag-decommission ng mga bagong kagamitan, pagbili ng karagdagang bagong kagamitan, nagsasagawa ng pag-audit ng paggamit ng mapagkukunan, atbp. Taun-taon, nagpaplano ang mga koponan ng mga bagong proyekto, bumuo ng kanilang mga sistema, at mahalaga para sa amin na bigyan sila ng mga mapagkukunan.
At sa tulong ng mga sukatan, nakikita namin ang takbo sa pagkonsumo ng mapagkukunan ng aming mga sistema ng impormasyon. At batay sa kanila maaari tayong magplano ng isang bagay. Sa antas ng virtualization, kinokolekta namin ang data at nakikita namin ang impormasyon sa magagamit na dami ng mga mapagkukunan ng data center. At nasa loob na ng data center makikita mo ang pag-recycle, ang aktwal na pamamahagi, at pagkonsumo ng mga mapagkukunan. Bukod dito, kapwa may mga standalone na server at virtual machine at kumpol ng mga pisikal na server kung saan ang lahat ng virtual machine na ito ay umiikot nang husto.
Prospect
Ngayon ay handa na ang core ng system sa kabuuan, ngunit marami pa ring bagay na kailangan pang pagsikapan. Sa pinakamababa, ito ay isang layer ng seguridad ng impormasyon, ngunit mahalaga din na maabot ang network, bumuo ng pag-alerto at lutasin ang isyu ng ugnayan. Marami kaming mga layer at system, at sa bawat layer ay marami pang sukatan. Ito ay lumalabas na isang matryoshka sa antas ng isang matryoshka.
Ang aming gawain ay sa huli ay gumawa ng mga tamang alerto. Halimbawa, kung may problema sa hardware, muli, sa isang virtual machine, at mayroong isang mahalagang application, at ang serbisyo ay hindi na-back up sa anumang paraan. Nalaman namin na ang virtual machine ay namatay. Pagkatapos ay aalertuhan ka ng mga sukatan ng negosyo: nawala ang mga user sa isang lugar, walang conversion, hindi available ang UI sa interface, namatay din ang software at mga serbisyo.
Sa sitwasyong ito, makakatanggap kami ng spam mula sa mga alerto, at hindi na ito umaangkop sa format ng wastong sistema ng pagsubaybay. Ang tanong ng ugnayan ay lumitaw. Samakatuwid, mas mabuti, ang aming sistema ng pagsubaybay ay dapat sabihin: "Guys, ang iyong pisikal na makina ay namatay, at kasama nito ang application na ito at ang mga sukatan na ito," sa tulong ng isang alerto, sa halip ng galit na pagbomba sa amin ng isang daang alerto. Dapat itong iulat ang pangunahing bagay - ang dahilan, na tumutulong upang mabilis na maalis ang problema dahil sa lokalisasyon nito.
Ang aming sistema ng abiso at pagproseso ng alerto ay binuo sa paligid ng isang XNUMX na oras na serbisyo sa hotline. Ang lahat ng mga alerto na itinuturing na dapat na mayroon at kasama sa checklist ay ipinadala doon. Ang bawat alerto ay dapat may isang paglalarawan: kung ano ang nangyari, kung ano talaga ang ibig sabihin nito, kung ano ang naaapektuhan nito. At isang link din sa dashboard at mga tagubilin sa kung ano ang gagawin sa kasong ito.
Ito ay tungkol sa lahat ng mga kinakailangan para sa pagbuo ng isang alerto. Pagkatapos ang sitwasyon ay maaaring umunlad sa dalawang direksyon - maaaring may problema at kailangang lutasin, o nagkaroon ng pagkabigo sa sistema ng pagsubaybay. Ngunit sa anumang kaso, kailangan mong pumunta at alamin ito.
Sa karaniwan, nakakatanggap na kami ngayon ng humigit-kumulang isang daang mga alerto bawat araw, na isinasaalang-alang ang katotohanan na ang ugnayan ng mga alerto ay hindi pa maayos na na-configure. At kung kailangan nating magsagawa ng teknikal na gawain, at pilit nating pinapatay ang isang bagay, ang kanilang bilang ay tumataas nang malaki.
Bilang karagdagan sa pagsubaybay sa mga system na aming pinapatakbo at pagkolekta ng mga sukatan na itinuturing na mahalaga sa aming panig, pinapayagan kami ng sistema ng pagsubaybay na mangolekta ng data para sa mga pangkat ng produkto. Maaari nilang maimpluwensyahan ang komposisyon ng mga sukatan sa loob ng mga sistema ng impormasyon na aming sinusubaybayan.
Maaaring dumating ang aming kasamahan at hilingin na magdagdag ng ilang sukatan na magiging kapaki-pakinabang para sa amin at sa koponan. O, halimbawa, maaaring hindi sapat ang team sa mga pangunahing sukatan na mayroon kami; kailangan nilang subaybayan ang ilang partikular na sukatan. Sa Grafana, gumagawa kami ng puwang para sa bawat koponan at nagbibigay ng mga karapatan ng admin. Gayundin, kung ang isang koponan ay nangangailangan ng mga dashboard, ngunit sila mismo ay hindi/hindi alam kung paano ito gagawin, tinutulungan namin sila.
Dahil tayo ay nasa labas ng daloy ng paggawa ng halaga ng team, ang kanilang mga release at pagpaplano, unti-unti tayong nagkakaroon ng konklusyon na ang mga release ng lahat ng system ay walang putol at maaaring ilunsad araw-araw nang walang pakikipag-ugnayan sa amin. At mahalaga para sa amin na subaybayan ang mga release na ito, dahil posibleng makaapekto ang mga ito sa pagpapatakbo ng application at masira ang isang bagay, at kritikal ito. Upang pamahalaan ang mga release, ginagamit namin ang Bamboo, kung saan kami tumatanggap ng data sa pamamagitan ng API at makikita kung aling mga release ang inilabas kung saan ang mga information system at ang kanilang status. At ang pinakamahalagang bagay ay kung anong oras. Ipinapatong namin ang mga marker ng paglabas sa mga pangunahing kritikal na sukatan, na kung saan ay nakikitang napaka-indicative sa kaso ng mga problema.
Sa ganitong paraan makikita natin ang ugnayan sa pagitan ng mga bagong release at mga umuusbong na problema. Ang pangunahing ideya ay upang maunawaan kung paano gumagana ang system sa lahat ng mga layer, mabilis na i-localize ang problema at ayusin ito nang mabilis. Pagkatapos ng lahat, madalas na nangyayari na ang pinakamaraming oras ay hindi paglutas ng problema, ngunit paghahanap para sa dahilan.
At sa lugar na ito sa hinaharap gusto naming tumuon sa proactivity. Sa isip, gusto kong malaman ang tungkol sa isang paparating na problema nang maaga, at hindi pagkatapos ng katotohanan, upang maiwasan ko ito sa halip na malutas ito. Minsan nangyayari ang mga maling alarma ng sistema ng pagsubaybay, kapwa dahil sa pagkakamali ng tao at dahil sa mga pagbabago sa application. At ginagawa namin ito, i-debug ito, at sinusubukang bigyan ng babala ang mga user na gumagamit nito sa amin tungkol dito bago ang anumang pagmamanipula ng sistema ng pagsubaybay , o isagawa ang mga aktibidad na ito sa teknikal na window.
Kaya, ang sistema ay inilunsad at matagumpay na gumagana mula noong simula ng tagsibol... at nagpapakita ng tunay na kita. Siyempre, hindi ito ang huling bersyon nito; ipapakilala namin ang maraming mas kapaki-pakinabang na feature. Ngunit sa ngayon, sa napakaraming pagsasama at aplikasyon, talagang hindi maiiwasan ang pagsubaybay sa automation.
Kung sinusubaybayan mo rin ang mga malalaking proyekto na may malaking bilang ng mga pagsasama, isulat sa mga komento kung anong pilak na bala ang nakita mo para dito.
Pinagmulan: www.habr.com