Monitorojam Sportmaster ā€“ kā un ar ko

Par uzraudzÄ«bas sistēmas izveidi domājām produktu komandu veidoÅ”anas stadijā. Kļuva skaidrs, ka mÅ«su bizness ā€“ ekspluatācija ā€“ Å”ajās komandās neietilpst. Kāpēc ir tā, ka?

Fakts ir tāds, ka visas mÅ«su komandas ir veidotas ap atseviŔķām informācijas sistēmām, mikropakalpojumiem un frontēm, tāpēc komandas neredz visas sistēmas vispārējo stāvokli kopumā. Piemēram, viņi var nezināt, kā kāda neliela dziļā aizmugursistēmas daļa ietekmē priekŔējo galu. Viņu intereÅ”u loks ir ierobežots ar sistēmām, ar kurām viņu sistēma ir integrēta. Ja komandai un tās dienestam A nav gandrÄ«z nekādas saistÄ«bas ar servisu B, tad komandai Ŕāds serviss ir gandrÄ«z neredzams.

Monitorojam Sportmaster ā€“ kā un ar ko

MÅ«su komanda savukārt strādā ar sistēmām, kas ir ļoti cieÅ”i integrētas savā starpā: starp tām ir daudz savienojumu, Ŕī ir ļoti liela infrastruktÅ«ra. Un interneta veikala darbÄ«ba ir atkarÄ«ga no visām Ŕīm sistēmām (kuru mums, starp citu, ir milzÄ«gs skaits).

Tā nu sanāk, ka mÅ«su nodaļa nepieder nevienai komandai, bet atrodas nedaudz malā. Visā Å”ajā stāstā mÅ«su uzdevums ir vispusÄ«gi izprast, kā darbojas informācijas sistēmas, to funkcionalitāte, integrācijas, programmatÅ«ra, tÄ«kls, aparatÅ«ra un kā tas viss ir savstarpēji saistÄ«ts.

Platforma, kurā darbojas mūsu tieŔsaistes veikali, izskatās Ŕādi:

  • priekŔējais
  • vidējais birojs
  • back office

Lai kā mēs vēlētos, nenotiek tā, ka visas sistēmas darbojas nevainojami un nevainojami. Lieta atkal ir sistēmu un integrāciju skaits ā€” ar kaut ko lÄ«dzÄ«gu mÅ«sējam daži incidenti ir neizbēgami, neskatoties uz testÄ“Å”anas kvalitāti. Turklāt gan atseviŔķas sistēmas ietvaros, gan to integrācijas ziņā. Un jums ir visaptveroÅ”i jāuzrauga visas platformas stāvoklis, nevis tikai atseviŔķa tās daļa.

Ideālā gadÄ«jumā veselÄ«bas uzraudzÄ«bai visā platformā jābÅ«t automatizētai. Un mēs nonācām pie monitoringa kā Ŕī procesa neizbēgamās daļas. Sākotnēji tas tika bÅ«vēts tikai priekŔējās lÄ«nijas daļai, savukārt tÄ«kla speciālistiem, programmatÅ«ras un aparatÅ«ras administratoriem bija un joprojām ir savas slāņu uzraudzÄ«bas sistēmas. Visi Å”ie cilvēki sekoja monitoringam tikai savā lÄ«menÄ«, arÄ« nevienam nebija visaptveroÅ”as izpratnes.

Piemēram, ja virtuālā maŔīna avarē, vairumā gadÄ«jumu par to zina tikai par aparatÅ«ru un virtuālo maŔīnu atbildÄ«gais administrators. Šādos gadÄ«jumos frontes komanda redzēja paÅ”u lietojumprogrammas avārijas faktu, taču tai nebija datu par virtuālās maŔīnas avāriju. Un administrators var zināt, kas ir klients, un aptuvenu priekÅ”statu par to, kas paÅ”laik darbojas Å”ajā virtuālajā maŔīnā, ja tas ir kāds liels projekts. ViņŔ, visticamāk, nezina par mazajiem. Jebkurā gadÄ«jumā administratoram ir jāiet pie Ä«paÅ”nieka un jāpajautā, kas bija uz Ŕīs maŔīnas, kas ir jāatjauno un kas jāmaina. Un, ja kaut kas patieŔām nopietns sabojājās, viņi sāka skriet pa apli ā€“ jo neviens neredzēja sistēmu kopumā.

Galu galā Ŕādi atŔķirÄ«gi stāsti ietekmē visu frontend, lietotājus un mÅ«su galveno biznesa funkciju - pārdoÅ”anu tieÅ”saistē. Tā kā mēs neesam daļa no komandas, bet esam iesaistÄ«ti visu e-komercijas lietojumprogrammu darbÄ«bā tieÅ”saistes veikala ietvaros, mēs uzņēmāmies uzdevumu izveidot visaptveroÅ”u uzraudzÄ«bas sistēmu e-komercijas platformai.

Sistēmas struktūra un kaudze

Mēs sākām, identificējot vairākus mÅ«su sistēmu uzraudzÄ«bas slāņus, kuros mums bÅ«tu jāapkopo metrika. Un tas viss bija jāapvieno, ko mēs darÄ«jām pirmajā posmā. Tagad Å”ajā posmā mēs pabeidzam augstākās kvalitātes metrikas kolekciju visos mÅ«su slāņos, lai izveidotu korelāciju un saprastu, kā sistēmas ietekmē viena otru.

VisaptveroÅ”as uzraudzÄ«bas trÅ«kums lietojumprogrammas palaiÅ”anas sākumposmā (kopÅ” mēs sākām to veidot, kad lielākā daļa sistēmu bija ražoÅ”anā) noveda pie tā, ka mums bija ievērojams tehnisks parāds, lai izveidotu visas platformas uzraudzÄ«bu. Mēs nevarējām atļauties koncentrēties uz vienas IS monitoringa izveidi un detalizētu tās monitoringu, jo pārējās sistēmas kādu laiku paliktu bez uzraudzÄ«bas. Lai atrisinātu Å”o problēmu, mēs identificējām nepiecieÅ”amo metriku sarakstu informācijas sistēmas stāvokļa novērtÄ“Å”anai pa slāņiem un sākām to ieviest.

Tāpēc viņi nolēma ziloni ēst pa daļām.

Mūsu sistēma sastāv no:

  • aparatÅ«ra;
  • operētājsistēma;
  • programmatÅ«ra;
  • UI daļas uzraudzÄ«bas lietojumprogrammā;
  • biznesa rādÄ«tāji;
  • integrācijas lietojumprogrammas;
  • informācijas droŔība;
  • tÄ«kli;
  • satiksmes lÄ«dzsvarotājs.

Monitorojam Sportmaster ā€“ kā un ar ko

Å Ä«s sistēmas centrā ir paÅ”as uzraudzÄ«ba. Lai vispārÄ«gi izprastu visas sistēmas stāvokli, jums jāzina, kas notiek ar lietojumprogrammām visos Å”ajos slāņos un visā lietojumprogrammu komplektā.

Tātad, par kaudzi.

Monitorojam Sportmaster ā€“ kā un ar ko

Mēs izmantojam atvērtā pirmkoda programmatÅ«ru. Centrā mums ir Zabbix, ko galvenokārt izmantojam kā brÄ«dināŔanas sistēmu. Ikviens zina, ka tas ir ideāli piemērots infrastruktÅ«ras uzraudzÄ«bai. Ko tas nozÄ«mē? TieÅ”i tie zemā lÄ«meņa rādÄ«tāji, kādi ir katram uzņēmumam, kas uztur savu datu centru (un Sportmaster ir savi datu centri) - servera temperatÅ«ra, atmiņas statuss, reids, tÄ«kla ierīču metrika.

Esam integrējuÅ”i Zabbix ar Telegram Messenger un Microsoft Teams, kuras aktÄ«vi izmanto komandās. Zabbix aptver faktiskā tÄ«kla slāni, aparatÅ«ru un dažas programmatÅ«ras, taču tā nav panaceja. Mēs bagātinām Å”os datus no dažiem citiem pakalpojumiem. Piemēram, aparatÅ«ras lÄ«menÄ« mēs, izmantojot API, tieÅ”i izveidojam savienojumu ar mÅ«su virtualizācijas sistēmu un apkopojam datus.

Kas vēl. Papildus Zabbix mēs izmantojam Prometheus, kas ļauj pārraudzÄ«t metriku dinamiskas vides lietojumprogrammā. Tas nozÄ«mē, ka mēs varam saņemt lietojumprogrammu metriku, izmantojot HTTP galapunktu, un neuztraucamies par to, kuras metrikas tajā jāielādē un kuras nē. Pamatojoties uz Å”iem datiem, var izstrādāt analÄ«tiskos vaicājumus.

Datu avoti citiem slāņiem, piemēram, biznesa metrika, ir sadalīti trīs komponentos.

Pirmkārt, tās ir ārējās biznesa sistēmas, Google Analytics, mēs apkopojam metriku no žurnāliem. No tiem mēs iegÅ«stam datus par aktÄ«vajiem lietotājiem, reklāmguvumiem un visu pārējo, kas saistÄ«ts ar biznesu. Otrkārt, Ŕī ir lietotāja interfeisa uzraudzÄ«bas sistēma. Tas bÅ«tu jāapraksta sÄ«kāk.

Kādreiz mēs sākām ar manuālo testÄ“Å”anu, un tā pārauga automātiskās funkcionalitātes un integrācijas testos. No tā mēs veicām uzraudzÄ«bu, atstājot tikai galveno funkcionalitāti, un paļāvāmies uz marÄ·ieriem, kas ir pēc iespējas stabilāki un laika gaitā bieži nemainās.

Jaunā komandas struktÅ«ra nozÄ«mē, ka visas lietojumprogrammu darbÄ«bas attiecas tikai uz produktu komandām, tāpēc mēs pārtraucām veikt tikai testÄ“Å”anu. Tā vietā mēs izveidojām lietotāja interfeisa uzraudzÄ«bu no testiem, kas rakstÄ«ti Java, Selenium un Jenkins valodā (izmantota kā sistēma atskaiÅ”u palaiÅ”anai un Ä£enerÄ“Å”anai).

Mums bija daudz testu, bet beigās nolēmām doties uz galveno ceļu, augstākā lÄ«meņa metriku. Un, ja mums ir daudz Ä«paÅ”u testu, bÅ«s grÅ«ti atjaunināt datus. Katrs nākamais laidiens bÅ«tiski sabojās visu sistēmu, un viss, ko mēs darÄ«sim, ir to salabot. Tāpēc mēs koncentrējāmies uz ļoti fundamentālām lietām, kas reti mainās, un tikai uzraugām tās.

Visbeidzot, treÅ”kārt, datu avots ir centralizēta reÄ£istrÄ“Å”anas sistēma. Mēs izmantojam Elastic Stack žurnāliem, un pēc tam mēs varam ievilkt Å”os datus mÅ«su uzraudzÄ«bas sistēmā biznesa metrikai. Papildus tam mums ir savs pārraudzÄ«bas API pakalpojums, kas rakstÄ«ts Python, kas vaicā jebkuru pakalpojumu, izmantojot API, un apkopo datus no tiem Zabbix.

Vēl viens neaizstājams monitoringa atribÅ«ts ir vizualizācija. MÅ«su pamatā ir Grafana. Tas izceļas citu vizualizācijas sistēmu vidÅ« ar to, ka ļauj informācijas panelÄ« vizualizēt dažādu datu avotu metriku. Mēs varam apkopot augstākā lÄ«meņa metriku tieÅ”saistes veikalam, piemēram, pasÅ«tÄ«jumu skaitu, kas veikti pēdējā stundā no DBVS, veiktspējas metriku operētājsistēmai, kurā darbojas Å”is tieÅ”saistes veikals no Zabbix, un metriku par Ŕīs lietojumprogrammas gadÄ«jumiem. no Prometeja. Un tas viss bÅ«s vienā informācijas panelÄ«. Skaidrs un pieejams.

AtļauÅ”os atzÄ«mēt par droŔību ā€“ Å”obrÄ«d tiek pabeigta sistēmas izveide, kuru vēlāk integrēsim ar globālo uzraudzÄ«bas sistēmu. Manuprāt, galvenās problēmas, ar kurām saskaras e-komercija informācijas droŔības jomā, ir saistÄ«tas ar botiem, parsētājiem un brutālu spēku. Mums tas ir jāseko lÄ«dzi, jo tas viss var kritiski ietekmēt gan mÅ«su lietojumprogrammu darbÄ«bu, gan mÅ«su reputāciju no biznesa viedokļa. Un ar izvēlēto kaudzi mēs veiksmÄ«gi risinām Å”os uzdevumus.

Vēl viens svarÄ«gs punkts ir tas, ka uzklāŔanas slāni montē Prometheus. ViņŔ pats arÄ« ir integrēts ar Zabbix. Un mums ir arÄ« vietnes ātrums, pakalpojums, kas ļauj skatÄ«t tādus parametrus kā mÅ«su lapas ielādes ātrums, vājās vietas, lapas renderÄ“Å”ana, skriptu ielāde utt., tas ir arÄ« integrēts API. Tātad mÅ«su rādÄ«tāji tiek apkopoti Zabbix, un attiecÄ«gi mēs arÄ« brÄ«dinām no turienes. Visi brÄ«dinājumi paÅ”laik tiek sÅ«tÄ«ti uz galvenajām sÅ«tÄ«Å”anas metodēm (pagaidām tas ir e-pasts un telegramma, nesen ir pievienota arÄ« MS Teams). Ir plānots jaunināt brÄ«dinājumus lÄ«dz tādam stāvoklim, ka viedie robotprogrammatÅ«ra darbojas kā pakalpojums un nodroÅ”ina uzraudzÄ«bas informāciju visām ieinteresētajām produktu komandām.

Mums metrika ir svarÄ«ga ne tikai atseviŔķām informācijas sistēmām, bet arÄ« vispārÄ«ga metrika visai infrastruktÅ«rai, ko izmanto lietojumprogrammas: fizisko serveru kopas, uz kurām darbojas virtuālās maŔīnas, trafika balansētāji, tÄ«kla slodzes balansētāji, pats tÄ«kls, sakaru kanālu izmantoÅ”ana. . Plus metrika mÅ«su paÅ”u datu centriem (mums ir vairāki, un infrastruktÅ«ra ir diezgan liela).

Monitorojam Sportmaster ā€“ kā un ar ko

MÅ«su uzraudzÄ«bas sistēmas priekÅ”rocÄ«bas ir tādas, ka ar tās palÄ«dzÄ«bu mēs redzam visu sistēmu veselÄ«bas stāvokli un varam novērtēt to ietekmi viena uz otru un uz kopējiem resursiem. Un galu galā tas ļauj mums iesaistÄ«ties resursu plānoÅ”anā, kas arÄ« ir mÅ«su atbildÄ«ba. Pārvaldām serveru resursus - e-komercijas baseinu, nododam un noņemam jaunas iekārtas, iegādājamies papildus jaunas iekārtas, veicam resursu izmantoÅ”anas auditu u.c. Katru gadu komandas plāno jaunus projektus, izstrādā savas sistēmas, un mums ir svarÄ«gi nodroÅ”ināt tās ar resursiem.

Un ar metrikas palÄ«dzÄ«bu mēs redzam mÅ«su informācijas sistēmu resursu patēriņa tendenci. Un, pamatojoties uz tiem, mēs varam kaut ko plānot. Virtualizācijas lÄ«menÄ« mēs apkopojam datus un redzam informāciju par pieejamo resursu apjomu pa datu centriem. Un jau datu centrā varat redzēt resursu pārstrādi, faktisko sadali un patēriņu. Turklāt gan ar atseviŔķiem serveriem, gan virtuālajām maŔīnām un fizisko serveru kopām, kurās visas Ŕīs virtuālās maŔīnas enerÄ£iski griežas.

Perspektīvas

Tagad mums ir gatavs sistēmas kodols kopumā, taču vēl ir daudz lietu, pie kurām vēl jāpiestrādā. Tas ir vismaz informācijas droŔības slānis, taču ir svarÄ«gi arÄ« sasniegt tÄ«klu, izstrādāt brÄ«dinājumus un atrisināt korelācijas problēmu. Mums ir daudz slāņu un sistēmu, un katrā slānÄ« ir daudz vairāk metrikas. Izrādās, ka tā ir matrjoÅ”ka lÄ«dz matrjoÅ”kai.

MÅ«su uzdevums ir sniegt pareizos brÄ«dinājumus. Piemēram, ja radās problēma ar aparatÅ«ru, atkal ar virtuālo maŔīnu un bija svarÄ«ga lietojumprogramma, un pakalpojums netika dublēts nekādā veidā. Mēs uzzinām, ka virtuālā maŔīna ir mirusi. Tad biznesa metrika jÅ«s brÄ«dinās: lietotāji ir kaut kur pazuduÅ”i, konvertÄ“Å”ana nenotiek, interfeisa lietotāja interfeiss nav pieejams, programmatÅ«ra un pakalpojumi arÄ« ir miruÅ”i.

Šādā situācijā mēs saņemsim surogātpastu no brÄ«dinājumiem, un tas vairs neatbilst pareizas uzraudzÄ«bas sistēmas formātam. Rodas korelācijas jautājums. Tāpēc ideālā gadÄ«jumā mÅ«su uzraudzÄ«bas sistēmai vajadzētu teikt: ā€œPuiÅ”i, jÅ«su fiziskā maŔīna ir nomira un lÄ«dz ar to arÄ« Ŕī lietojumprogramma un Å”ie rādÄ«tāji,ā€ ar viena brÄ«dinājuma palÄ«dzÄ«bu, tā vietā, lai nikni bombardētu mÅ«s ar simts brÄ«dinājumiem. Tam vajadzētu ziņot par galveno - cēloni, kas palÄ«dz ātri novērst problēmu tās lokalizācijas dēļ.

MÅ«su paziņojumu sistēma un brÄ«dinājumu apstrāde ir balstÄ«ta uz diennakts palÄ«dzÄ«bas tālruņa pakalpojumu. Tur tiek nosÅ«tÄ«ti visi brÄ«dinājumi, kas tiek uzskatÄ«ti par obligātiem un ir iekļauti kontrolsarakstā. Katram brÄ«dinājumam ir jābÅ«t aprakstam: kas noticis, ko tas patiesÄ«bā nozÄ«mē, ko tas ietekmē. Un arÄ« saite uz informācijas paneli un instrukcijas, kā rÄ«koties Å”ajā gadÄ«jumā.

Tas viss attiecas uz brÄ«dinājuma izveides prasÄ«bām. Tad situācija var attÄ«stÄ«ties divos virzienos ā€“ vai nu ir problēma un tā ir jārisina, vai arÄ« notikusi kļūme monitoringa sistēmā. Bet jebkurā gadÄ«jumā jums ir jāiet un jāizdomā.

Vidēji tagad mēs saņemam aptuveni simts brÄ«dinājumu dienā, ņemot vērā to, ka brÄ«dinājumu korelācija vēl nav pareizi konfigurēta. Un, ja mums ir nepiecieÅ”ams veikt tehniskos darbus, un mēs kaut ko piespiedu kārtā izslēdzam, to skaits ievērojami palielinās.

Papildus mÅ«su darbināmo sistēmu uzraudzÄ«bai un metriku apkopoÅ”anai, kas tiek uzskatÄ«ta par svarÄ«gu no mÅ«su puses, uzraudzÄ«bas sistēma ļauj mums vākt datus produktu komandām. Tie var ietekmēt metriku sastāvu mÅ«su uzraugāmajās informācijas sistēmās.

MÅ«su kolēģis var atnākt un lÅ«gt pievienot kādu metriku, kas noderēs gan mums, gan komandai. Vai, piemēram, komandai var nebÅ«t pietiekami daudz pamata metrikas, kas mums ir; viņiem ir jāizseko daži konkrēti rādÄ«tāji. Programmā Grafana mēs izveidojam vietu katrai komandai un pieŔķiram administratora tiesÄ«bas. Tāpat, ja komandai ir nepiecieÅ”ami informācijas paneļi, bet viņi paÅ”i nevar/nezina, kā to izdarÄ«t, mēs palÄ«dzam.

Tā kā mēs esam ārpus komandas vērtÄ«bas radÄ«Å”anas, to izlaiÅ”anas un plānoÅ”anas plÅ«smas, mēs pakāpeniski nonākam pie secinājuma, ka visu sistēmu laidieni ir nevainojami un tos var izlaist katru dienu bez saskaņoÅ”anas ar mums. Un mums ir svarÄ«gi uzraudzÄ«t Å”os laidienus, jo tie var ietekmēt lietojumprogrammas darbÄ«bu un kaut ko sabojāt, un tas ir ļoti svarÄ«gi. Lai pārvaldÄ«tu izlaidumus, mēs izmantojam Bamboo, no kurienes mēs saņemam datus caur API un varam redzēt, kuri laidieni kādās informācijas sistēmās ir izlaisti un to statuss. Un pats galvenais, kurā laikā. Mēs uzliekam izlaiÅ”anas marÄ·ierus galvenajām kritiskajām metrikām, kas ir vizuāli ļoti indikatÄ«vs problēmu gadÄ«jumā.

Tādā veidā mēs varam redzēt korelāciju starp jauniem izdevumiem un jaunām problēmām. Galvenā ideja ir saprast, kā sistēma darbojas visos slāņos, ātri lokalizēt problēmu un tikpat ātri to novērst. Galu galā bieži gadās, ka visvairāk laika aizņem nevis problēmas risināŔana, bet gan cēloņa meklÄ“Å”ana.

Un Å”ajā jomā nākotnē mēs vēlamies koncentrēties uz proaktivitāti. Ideālā gadÄ«jumā es vēlētos uzzināt par problēmas tuvoÅ”anos iepriekÅ”, nevis pēc fakta, lai varētu to novērst, nevis atrisināt. Dažkārt rodas viltus trauksmes no pārraudzÄ«bas sistēmas gan cilvēcisku kļūdu, gan lietojumprogrammas izmaiņu dēļ. Mēs pie tā strādājam, atkļūdojam un cenÅ”amies brÄ«dināt lietotājus, kuri to izmanto kopā ar mums, pirms jebkādām manipulācijām ar uzraudzÄ«bas sistēmu. , vai veikt Ŕīs darbÄ«bas tehniskajā logā.

Tātad sistēma ir iedarbināta un veiksmÄ«gi darbojas kopÅ” pavasara sākuma... un rāda ļoti reālu peļņu. Protams, Ŕī nav tā galÄ«gā versija; mēs ieviesÄ«sim vēl daudzas noderÄ«gas funkcijas. Taču Å”obrÄ«d, kad ir tik daudz integrāciju un lietojumprogrammu, uzraudzÄ«bas automatizācija patieŔām ir neizbēgama.

Ja arī uzraugāt lielus projektus ar ievērojamu skaitu integrāciju, rakstiet komentāros, kādu sudraba lodi tam atradāt.

Avots: www.habr.com

Pievieno komentāru