Ne filluam tĂ« mendojmĂ« pĂ«r krijimin e njĂ« sistemi monitorimi nĂ« fazĂ«n e formimit tĂ« grupeve produktive. U bĂ« e qartĂ« se aktiviteti ynĂ« â operimi â nuk bĂ«nte aspak pjesĂ« e kĂ«tyre grupeve. Pse ndodhi kĂ«shtu?
ĂĂ«shtja Ă«shtĂ« se tĂ« gjitha grupet tona janĂ« ndĂ«rtuar rreth sistemeve tĂ« veçanta informacioni, mikro shĂ«rbimeve dhe front-end, prandaj ekipi nuk e sheh gjendjen e shĂ«ndetit tĂ« gjithĂ« sistemit si njĂ« tĂ«rĂ«si. PĂ«r shembull, ata mund tĂ« mos dinĂ« se si njĂ« pjesĂ« e vogĂ«l nĂ« backend e ndikon pjesĂ«n front-end. Rrethi i interesave tĂ« tyre kufizohet me sistemet me tĂ« cilat Ă«shtĂ« integruar sistemi i tyre. NĂ«se ekipi dhe shĂ«rbimi A nd almost nuk janĂ« tĂ« lidhur me shĂ«rbimin B, atĂ«herĂ« njĂ« shĂ«rbim i tillĂ« pĂ«r ekipin Ă«shtĂ« pothuajse i padukshĂ«m.
Ekipi ynĂ«, nga ana tjetĂ«r, punon me sisteme qĂ« janĂ« shumĂ« tĂ« integruara me njĂ«ra-tjetrĂ«n: ka shumĂ« lidhje mes tyre, Ă«shtĂ« njĂ« infrastrukturĂ« e madhe. Dhe nga tĂ« gjithĂ« kĂ«to sisteme (pĂ«r tâu thĂ«nĂ«, kemi njĂ« numĂ«r tĂ« madh), varet funksionimi i dyqanit online.
Kështu që del se departamenti ynë nuk i përket asnjë ekipi, por është paksa në anë. Në të gjithë këtë histori, detyra jonë është të kuptojmë në mënyrë gjithëpërfshirëse si funksionojnë sistemet informative, funksionaliteti i tyre, integrimet, softueri, rrjeta, hardueri dhe se si e gjithë kjo lidhet me njëra-tjetrën.
Platforma, në të cilën funksionojnë dyqanet tona online, duket kështu:
- front
- middle-office
- back-office
Sa do qĂ« tĂ« dĂ«shirojmĂ«, nuk ka asnjĂ« rast ku tĂ« gjitha sistemet tĂ« funksionojnĂ« pa probleme dhe nĂ« mĂ«nyrĂ« perfekte. ĂĂ«shtja Ă«shtĂ«, pĂ«rsĂ«ri, nĂ« numrin e sistemeve dhe integrimeve - nĂ« rastin tonĂ«, ndodhin incidente tĂ« tilla, pavarĂ«sisht cilĂ«sisĂ« sĂ« testimit. Kjo ndodh si brenda njĂ« sistemi tĂ« veçantĂ«, ashtu edhe nĂ« aspektin e integrimeve tĂ« tyre. ĂshtĂ« e nevojshme tĂ« ndjekim gjendjen e gjithĂ« platformĂ«s nĂ« mĂ«nyrĂ« gjithĂ«pĂ«rfshirĂ«se, e jo njĂ« pjese tĂ« saj.
Idealisht, monitorimi i shëndetit të gjithë platformës duhet automatizuar. Dhe ne arritëm te monitorimi si një pjesë e pashmangshme e këtij procesi. Fillimisht, ai u ndërtua vetëm për pjesën front-end, ndërkohë që ekzistojnë sisteme monitorimi nga shtresa për administratorët e rrjetit, softuerit dhe harduerit. Të gjithë këta njerëz e ndoqën monitorimin vetëm në nivelin e tyre, askush nuk kishte një kuptim gjithëpërfshirës.
PĂ«r shembull, nĂ«se njĂ« makinĂ« virtuale bie, nĂ« shumicĂ«n e rasteve, vetĂ«m administratori qĂ« Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r harduerin dhe makinĂ«n virtuale e di kĂ«tĂ«. Ekipi i front-end-it nĂ« kĂ«to raste sheh vetĂ«m faktin e rĂ«nies sĂ« aplikacionit, por nuk kishte tĂ« dhĂ«na pĂ«r rĂ«nien e makinĂ«s virtuale. NdĂ«rsa administratori mund tĂ« dijĂ« se kush Ă«shtĂ« klienti dhe tĂ« ketĂ« njĂ« ide se çfarĂ« po ndodh nĂ« kĂ«tĂ« makinĂ« virtuale, me kusht qĂ« tĂ« jetĂ« njĂ« projekt i madh. NĂ«se Ă«shtĂ« i vogĂ«l, ndoshta nuk e di. NĂ« çdo rast, administratori duhet tĂ« shkojĂ« te pronari dhe tĂ« pyesĂ« se çfarĂ« kishte nĂ« kĂ«tĂ« makinĂ«, se çfarĂ« duhet tĂ« rikuperohet dhe se çfarĂ« duhet ndĂ«rruar. Dhe nĂ«se kishte njĂ« problem mĂ« serioz, fillonte njĂ« kĂ«rkim paniku â sepse askush nuk e shihte sistemin si njĂ« tĂ«rĂ«si.
NĂ« fund tĂ« fundit, kĂ«to tregime tĂ« shpĂ«rndara ndikojnĂ« nĂ« tĂ« gjithĂ« front-end-in, nĂ« pĂ«rdoruesit dhe funksionin tonĂ« kryesor tĂ« biznesit â shitjet online. Tani qĂ« ne nuk jemi pjesĂ« e ekipeve dhe merremi me operimin e tĂ« gjitha aplikacioneve e-commerce brenda dyqanit online, morĂ«m pĂ«rsipĂ«r detyrĂ«n pĂ«r tĂ« krijuar njĂ« sistem kompleks monitorimi pĂ«r platformĂ«n e-commerce.
Struktura e sistemit dhe stek
Filluam duke ndarë disa nivele monitorimi për sistemet tona, përmes të cilave do të na duhej të mbledhim metrika. Dhe gjithçka duhej të ndërmerrej, gjë që e bëmë në fazën e parë. Tani për këtë fazë ne po përmirësojmë mbledhjen sa më cilësore të metricave në të gjitha nivelet tona, për të ndërtuar korelacionin dhe për të kuptuar si sistemet ndikojnë njëra-tjetrën.
Mungesa e një monitorimi të kompleks në fazat e hershme të nisjes së aplikacioneve (pasi filluam ta ndërtojmë atë, kur shumica e sistemeve ishin në funksion) çoi në një borxh teknik të konsiderueshëm për konfigurimin e monitorimit të gjithë platformës. Nuk mund të fokusoheshim në konfigurimin e monitorimit për një sistem të vetëm dhe ta zhvillonim në detaje, pasi sistemet e tjera do të mbeteshin pa monitorim për një periudhë të caktuar. Për të adresuar këtë çështje, ne identifikuam një listë të metricave më të nevojshme për vlerësimin e gjendjes së sistemit informatik sipas niveleve dhe filluam ta implementonim atë.
Prandaj, vendosëm ta hamë elefantin me pjesë.
Sistemi ynë përbëhet nga:
- hardueri;
- sistemi operativ;
- softueri;
- Pjesët e UI në aplikacionin e monitorimit;
- metrikat e biznesit;
- aplikacionet e integrimit;
- siguria informative;
- rrjetet;
- balancuesi i trafikut.
Qendra e këtij sistemi është pikërisht monitorimi. Për të kuptuar gjendjen e përgjithshme të sistemit, është e rëndësishme të dimë se çfarë po ndodh me aplikacionet në të gjitha këto nivele dhe në përmasat e të gjitha aplikacioneve.
Kështu, për stek.
Ne pĂ«rdorim softuer me burim tĂ« hapur. NĂ« qendĂ«r kemi Zabbix-in, tĂ« cilin e pĂ«rdorim kryesisht si sistem alarmimi. TĂ« gjithĂ« e dinĂ« se ai Ă«shtĂ« ideal pĂ«r monitorimin e infrastrukturĂ«s. ĂfarĂ« nĂ«nkuptohet kĂ«tu? PikĂ«risht ato metrika tĂ« nivelit tĂ« ulĂ«t qĂ« ka çdo kompani qĂ« ka qendrĂ«n e vet tĂ« tĂ« dhĂ«nave (dhe Sportmaster ka qendrat e veta) â temperatura e serverit, gjendja e memories, RAID-it, metrikat e pajisjeve tĂ« rrjetit.
Ne integrojmë Zabbix-in me mesazherin Telegram dhe Microsoft Teams, të cilat përdoren aktivisht në ekipet. Zabbix mbulon nivelin e rrjetit aktual, harduerit dhe pjesërisht softuerit, por kjo nuk është një zgjidhje universale. Ne pasurojmë këto të dhëna nga disa shërbime të tjera. Për shembull, në nivelin e harduerit ne lidhemi drejtpërdrejt përmes API-së në sistemin tonë të virtualizimit dhe marrim të dhëna.
ĂfarĂ« tjetĂ«r. PĂ«rveç Zabbix-it, ne pĂ«rdorim Prometheus-in, i cili lejon monitorimin e metrikave nĂ« aplikacionin e mjedisit dinamik. Pra, ne mund tĂ« marrim metrikat e aplikacionit pĂ«rmes endpoint-it HTTP dhe tĂ« mos shqetĂ«sohemi pĂ«r ato metrika qĂ« duhet tĂ« ngarkojmĂ« nĂ« tĂ« dhe ato qĂ« jo. NĂ« bazĂ« tĂ« kĂ«tyre tĂ« dhĂ«nave, mund tĂ« zhvillojmĂ« kĂ«rkesa analitike.
Burimet e të dhënave për nivelet e tjera, për shembull, metrikat e biznesit, ndahen në tri komponentë.
Së pari, këto janë sistemet e biznesit të jashtëm, Google Analytics, ne mbledhim metrika nga log-et. Nga ato marrim të dhëna për përdoruesit aktivë, konvertimin dhe gjithçka tjetër që lidhet me biznesin. Së dyti, është sistemi i monitorimit të UI. Për këtë do të flasim më në detaje.
Dikur ne filluam me testimin manual dhe ky proces u zhvillua në testet automatike për funksionalitetin dhe integrimet. Nga kjo ne krijuam monitorimin, duke lënë vetëm funksionalitetin kryesor dhe duke u ndërlidhur me treguesit, të cilët janë sa më të qëndrueshëm dhe nuk ndryshojnë shpesh me kalimin e kohës.
Struktura e re e ekipeve nënkupton që të gjitha aktivitetet në lidhje me aplikacionet janë të përqendruara në ekipet produktore, prandaj ne kemi ndaluar të angazhohemi me testimin e pastër. Në vend të kësaj, ne kemi krijuar një monitorim UI, të shkruar në Java, Selenium dhe Jenkins (përdoret si sistem për nisjen dhe gjenerimin e raporteve).
Kishim shumĂ« teste, por nĂ« fund vendosĂ«m tĂ« fokusoheshim nĂ« mĂ« tĂ« rĂ«ndĂ«sishmen, njĂ« metrikĂ« mbi nivelin. Dhe nĂ«se kemi shumĂ« teste specifike, do tĂ« ishte e vĂ«shtirĂ« tĂ« ruanim tĂ« dhĂ«nat nĂ« pĂ«rditĂ«sim. Ădo lĂ«shim i mĂ«passhĂ«m do tĂ« thyejĂ« ndjeshĂ«m tĂ«rĂ« sistemin, dhe ne do tĂ« merreshim vetĂ«m me riparimin e tij. Prandaj, ne kemi treguar interes pĂ«r gjĂ«ra themelore, qĂ« ndryshojnĂ« rrallĂ«, dhe monitorojmĂ« vetĂ«m ato.
Së fundmi, siç e përmenda, burimi i të dhënave është një sistem centralizues i regjistrimit. Për regjistrimet përdorim Elastic Stack, dhe më pas mund t'i transferojmë këto të dhëna në sistemin tonë të monitorimit të metrikave biznesore. Përveç kësaj, funksionon shërbimi ynë Monitoring API, i shkruar në Python, i cili pyet përmes API të gjitha shërbimet dhe merr të dhëna për to në Zabbix.
Një atribut tjetër i pazëvendësueshëm i monitorimit është vizualizimi. Kjo e fundit ndihmon të ndërtojmë në bazë të Grafana. Ndër sistemet e tjera të vizualizimit, ajo veçohet për faktin se në dashboard mund të vizualizojmë metrika nga burime të ndryshme të të dhënave. Mund të mbledhim metrika mbi nivelin e internet dyqanit, për shembull, numrin e porosive të kryera gjatë orës së fundit nga baza e të dhënave, metrika të performancës së OS-së mbi të cilën funksionon ky internet dyqani nga Zabbix, dhe metrika të instancave të këtij aplikacioni nga Prometheus. Të gjitha këto do të jenë në një dashboard. Qartë dhe në dispozitë.
Dua tĂ« theksoj nĂ« lidhje me sigurinĂ« â tani jemi duke pĂ«rmirĂ«suar sistemin, tĂ« cilin pĂ«rfundimisht do ta integrojmĂ« me sistemin global tĂ« monitorimit. Sipas mendimit tim, problemet kryesore me tĂ« cilat pĂ«rballet e-commerce nĂ« fushĂ«n e sigurisĂ« informative janĂ« tĂ« lidhura me robotĂ«t, parserĂ«t dhe brute force. KĂ«to duhet tĂ« monitorohen, sepse ato mund tĂ« kenĂ« njĂ« ndikim kritik nĂ« funksionimin e aplikacioneve tona, si dhe nĂ« reputacionin tonĂ« nga pikĂ«pamja e biznesit. Dhe me stack-un e zgjedhur, ne i mbulojmĂ« kĂ«to detyra me sukses.
Një moment tjetër i rëndësishëm është niveli i aplikacioneve që mblidhet nga Prometheus. Ai është gjithashtu i integruar me Zabbix. Po ashtu kemi sitespeed, një shërbim që na lejon të shikojmë parametrat si shpejtësia e ngarkimit të faqeve tona, pengesat, renderimi i faqeve, ngarkimi i skripteve dhe të tjera, gjithashtu është i integruar përmes API. Pra, metrikat mblidhen në Zabbix dhe alarmin e kemi gjithashtu nga aty. Të gjitha alarmin deri tani shkojnë përmes metodave kryesore të dërgimit (deri tani janë email dhe telegram, po ashtu kemi lidhur kohët e fundit MS Teams). Në planet tona është të zhvillojmë alarmin në një gjendje ku robotët e mençur funksionojnë si shërbim dhe ofrojnë informacion mbi monitorimin për të gjithë ekipet produktive që kërkojnë.
Për ne janë të rëndësishme metrikat jo vetëm të sistemeve të informacionit të veçanta, por edhe metrikat e përgjithshme për gjithë infrastrukturën që aplikacionet përdorin: grupe serverësh fizikë, mbi të cilat funksionojnë makinat virtuale, balancuesit e trafikut, balancuesit e ngarkesës në rrjet, vetë rrjeti, shfrytëzimi i kanaleve të komunikimit. Plus metrikat për qendrat tona të të dhënave (ne kemi disa dhe infrastruktura është mjaft e madhe).
Avantazhi i sistemit tonĂ« tĂ« monitorimit Ă«shtĂ« se me ndihmĂ«n e tij ne shohim gjendjen e funksionimit tĂ« tĂ« gjitha sistemeve, mund tĂ« vlerĂ«sojmĂ« ndikimin e tyre mbi njĂ«ri-tjetrin dhe mbi burimet e pĂ«rgjithshme. Dhe nĂ« fund tĂ« fundit, ajo na lejon tĂ« merremi me planifikimin e burimeve, qĂ« gjithashtu bĂ«n pjesĂ« nĂ« pĂ«rgjegjĂ«sinĂ« tonĂ«. Ne menaxhojmĂ« burimet e serverĂ«ve â njĂ« grup brenda e-commerce, nxjerrim nga pĂ«rdorimi pajisje tĂ« reja, blejmĂ« tĂ« tjera, bĂ«jmĂ« auditimin e shfrytĂ«zimit tĂ« burimeve dhe tĂ« tjera. Ădo vit ekipet planifikojnĂ« projekte tĂ« reja, zhvillojnĂ« sistemet e tyre, dhe na nevojitet qĂ« t'u sigurojmĂ« atyre burime.
Dhe me ndihmën e metrikave ne shohim tendencën e konsumit të burimeve nga sistemet tona të informacionit. Dhe tashmë mbi këtë bazë mund të planifikojmë diçka. Në nivelin e virtualizimit ne mbledhim të dhëna dhe shohim informacionin mbi numrin e burimeve të disponueshme sipas qendrave të të dhënave. Dhe brenda qendrës së të dhënave shihet gjithashtu shfrytëzimi dhe shpërndarja reale, konsumimi i burimeve. Ndërkohë si me serverët standalone, ashtu edhe me makinat virtuale dhe grupet e serverëve fizikë, mbi të cilat këto makina virtuale funksionojnë me ritëm të shkëlqyer.
Perspektivat
Tani është kernel i sistemit në përgjithësi i gatshëm, por ka shumë aspekte mbi të cilat duhet të punojmë ende. Të paktën, ky është shtresa e sigurisë së informacionit, por është e rëndësishme gjithashtu të arrijmë në rrjet, të zhvillojmë alerturnin dhe të zgjidhim çështjen e korelacionit. Ne kemi shumë shtresa dhe sisteme; në çdo shtresë ka shumë metrika. Kështu, kemi një matryoshka në shkallë të matryoshkes.
Detyra jonë është të krijojmë alertra të sakta në fund. Për shembull, nëse ndodh një problem me pjesën harduerike, përsëri, me makinën virtuale, dhe aty kishte një aplikacion të rëndësishëm, dhe shërbimi nuk ishte rezervuar. Ne do të kuptojmë që makina virtuale ka vdekur. Pastaj do të alertojë metrikat e biznesit: përdoruesit janë zhdukur, nuk ka konvertime, UI në ndërfaqe është i paaksesueshëm, gjithashtu edhe softueri dhe shërbimet kanë vdekur.
Me një situatë të tillë, ne do të marrim spam nga alertrat, dhe kjo nuk përputhet me standardet e një sistemi monitorimi të saktë. Ngrihet çështja e korelacionit. Prandaj, në mënyrë ideale, sistemi ynë i monitorimit duhet të thotë: "Djem, makina fizike ka vdekur, dhe së bashku me të këtë aplikacion dhe këto metrika", me ndihmën e një alertri, në vend që të na mbushin me njëqind alertra. Ai duhet të raportojë për gjërat kryesore - për shkakun, i cili ndihmon në shpejtësinë e zgjidhjes së problemit përmes lokalizimit të tij.
Sistemi ynĂ« i njoftimit dhe pĂ«rpunimi i alertrave Ă«shtĂ« ndĂ«rtuar rreth njĂ« shĂ«rbimi tĂ« linjĂ«s sĂ« nxehtĂ« 24/7. TĂ« gjitha alertrat qĂ« konsiderohen si tĂ« domosdoshme dhe janĂ« pĂ«rfshirĂ« nĂ« listĂ«n e kontrollit, dĂ«rgohen atje. Ădo alertr duhet patjetĂ«r tĂ« ketĂ« njĂ« pĂ«rshkrim: çfarĂ« ka ndodhur, çfarĂ« do tĂ« thotĂ« kjo, çfarĂ« ndikon. Dhe gjithashtu njĂ« lidhje me panelin e kontrollit dhe njĂ« udhĂ«zim pĂ«r atĂ« qĂ« duhet tĂ« bĂ«jmĂ« nĂ« kĂ«tĂ« rast.
Këto janë të gjitha kërkesat për ndërtimin e alertrave. Situata mund të zhvillohet në dy drejtime - ose problemi ekziston dhe duhet zgjidhur, ose ka ndodhur një defekt në sistemin e monitorimit. Por në çdo rast, duhet të shkojmë dhe të kuptojmë.
Në mesatare, tani na bien rreth njëqind alertra në ditë, kjo është duke marrë parasysh se korelacioni i alertrave ende nuk është konfiguruar siç duhet. Dhe nëse është e nevojshme të kryhen punë teknike, dhe ne ndalojmë diçka me forcë, numri i ndonjëherë rritet shumë herë.
Përveç monitorimit të sistemeve që ne përdorim dhe mbledhjes së metrikeve që ne e shohim si të rëndësishme, sistemi i monitorimit lejon mbledhjen e të dhënave për ekipet produkti. Ato mund të ndikojnë në përbërjen e metrikeve brenda sistemeve informative që monitorohen nga ne.
Kolegët tanë mund të vijnë dhe të kërkojnë të shtojnë ndonjë metrikë që do të jetë e dobishme si për ne, ashtu edhe për ekipin. Ose, p.sh., ekipi mund të mos ketë mjaftueshëm metrika bazë që kemi, ata duhet të ndjekin diçka specifike. Në Grafana, krijojmë hapësira për secilin ekip dhe ofrojmë të drejta administratori. Po ashtu, nëse ekipi ka nevojë për dashboarde dhe ata vetë nuk mund / nuk dinë si ta bëjnë këtë, ne i ndihmojmë.
Duke qenë se ne jemi jashtë rrjedhës së krijimit të vlerave të ekipit, lëshimeve dhe planifikimit, gradualisht po arrijmë në përfundimin se lëshimet e të gjithë sistemeve janë pa pengesa dhe mund të dalin çdo ditë, pa u marrë parasysh me ne. Dhe është e rëndësishme të ndjekim këto lëshime, sepse potencialisht ato mund të ndikojnë në funksionimin e aplikacionit dhe të shqetësojnë diçka, që është kritike. Për menaxhimin e lëshimeve ne përdorim Bamboo, nga ku marrim të dhënat përmes API dhe mund të shohim se cilat lëshime janë bërë në cilat sisteme informative dhe statusin e tyre. Dhe më e rëndësishmja - në cilin kohë. Ne vendosim markat për lëshimet në metrike kritike kryesore, që vizualisht është shumë treguese në rast problemesh.
Kështu, ne mund të shohim korrelacionin midis lëshimeve të reja dhe problemeve që dalin. Ideja kryesore është të kuptojmë se si funksionon sistemi në të gjitha nivelet, të lokalizojmë shpejt problemin dhe ta korrigjojmë po aq shpejt. Sepse shpesh ndodh që më shumë kohë shpenzohet për të gjetur shkakun, sesa për të zgjidhur problemin.
Dhe për këtë drejtim në të ardhmen ne duam të fokusohemi në proaktivitetin. Ideali do të ishte të mësojmë paraprakisht për një problem në ardhje, e jo pas faktit, për të marrë masa parandaluese, jo për ta zgjidhur atë. Ndonjëherë ndodhin alarmet false të sistemit të monitorimit, si për shkak të gabimeve njerëzore, ashtu edhe për shkak të ndryshimeve në aplikacion. Ne po punojmë për këtë, e po e përmirësojmë sistemin dhe përpiqemi që para çdo manipulimi me sistemin e monitorimit të paralajmërojmë përdoruesit që e përdorin atë së bashku me ne, ose të kryejmë këto aktivitete në kohë teknike.
Pra, sistemi u aktivizua dhe funksionon me sukses që nga fillimi i pranverës... dhe tregon një fitim të vërtetë. Sigurisht, kjo nuk është versioni përfundimtar, ne do të implementojmë shumë shërbime të tjera të dobishme. Por pikërisht tani, me një numër të madh integrimesh dhe aplikacionesh, pa automatizimin e monitorimit, në të vërtetë nuk mund të kalojmë.
NĂ«se ju gjithashtu monitoroni projekte tĂ« mĂ«dha me njĂ« sasi serioze integrimesh â shkruani nĂ« komentet, çfarĂ« zgjidhjeje kĂ«rkuese keni gjetur pĂ«r kĂ«tĂ«.
Burimi: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish