Ne menduam të krijonim një sistem monitorimi në fazën e formimit të ekipeve të produktit. U bë e qartë se biznesi ynë - shfrytëzimi - nuk bie në këto ekipe. Pse eshte ajo?
Fakti është se të gjitha ekipet tona janë ndërtuar rreth sistemeve individuale të informacionit, mikroshërbimeve dhe fronteve, kështu që ekipet nuk e shohin shëndetin e përgjithshëm të të gjithë sistemit në tërësi. Për shembull, ata mund të mos e dinë se si një pjesë e vogël në pjesën e pasme të thellë ndikon në pjesën e përparme. Shtrirja e tyre e interesit është e kufizuar në sistemet me të cilat sistemi i tyre është i integruar. Nëse një ekip dhe shërbimi i tij A nuk kanë pothuajse asnjë lidhje me shërbimin B, atëherë një shërbim i tillë është pothuajse i padukshëm për ekipin.
Ekipi ynë, nga ana tjetër, punon me sisteme që janë shumë të integruara me njëri-tjetrin: ka shumë lidhje mes tyre, kjo është një infrastrukturë shumë e madhe. Dhe funksionimi i dyqanit në internet varet nga të gjitha këto sisteme (nga të cilat ne kemi, nga rruga, një numër të madh).
Pra, rezulton se departamenti ynë nuk i përket asnjë ekipi, por ndodhet pak më anash. Në të gjithë këtë histori, detyra jonë është të kuptojmë në mënyrë gjithëpërfshirëse se si funksionojnë sistemet e informacionit, funksionalitetin e tyre, integrimet, softuerin, rrjetin, harduerin dhe se si e gjithë kjo lidhet me njëra-tjetrën.
Platforma në të cilën funksionojnë dyqanet tona online duket si kjo:
- front
- zyra e mesme
- zyra prapa
Pavarësisht se sa do të donim, nuk ndodh që të gjitha sistemet të funksionojnë pa probleme dhe pa të meta. Çështja, përsëri, është numri i sistemeve dhe integrimeve - me diçka si e jona, disa incidente janë të pashmangshme, pavarësisht cilësisë së testimit. Për më tepër, si brenda një sistemi të veçantë, ashtu edhe në aspektin e integrimit të tyre. Dhe ju duhet të monitoroni gjendjen e të gjithë platformës në mënyrë gjithëpërfshirëse, dhe jo vetëm të ndonjë pjese individuale të saj.
Në mënyrë ideale, monitorimi shëndetësor në të gjithë platformën duhet të jetë i automatizuar. Dhe kemi ardhur te monitorimi si pjesë e pashmangshme e këtij procesi. Fillimisht, ai u ndërtua vetëm për pjesën e përparme, ndërsa specialistët e rrjetit, administratorët e softuerit dhe harduerit kishin dhe kanë sistemet e tyre të monitorimit shtresë pas shtrese. Të gjithë këta persona e ndoqën monitorimin vetëm në nivelin e tyre, as askush nuk kishte një mirëkuptim të plotë.
Për shembull, nëse një makinë virtuale rrëzohet, në shumicën e rasteve vetëm administratori përgjegjës për harduerin dhe makinën virtuale di për të. Në raste të tilla, ekipi i vijës së parë pa vetë faktin e rrëzimit të aplikacionit, por nuk kishte të dhëna për rrëzimin e makinës virtuale. Dhe administratori mund të dijë se kush është klienti dhe të ketë një ide të përafërt se çfarë po funksionon aktualisht në këtë makinë virtuale, me kusht që të jetë një lloj projekti i madh. Me shumë mundësi ai nuk di për të vegjlit. Në çdo rast, administratori duhet të shkojë te pronari dhe të pyesë se çfarë ishte në këtë makinë, çfarë duhet të restaurohet dhe çfarë duhet ndryshuar. Dhe nëse diçka vërtet serioze prishej, ata filluan të vrapojnë në rrathë - sepse askush nuk e shihte sistemin në tërësi.
Në fund të fundit, histori të tilla të ndryshme ndikojnë në të gjithë frontin, përdoruesit dhe funksionin tonë kryesor të biznesit - shitjet në internet. Duke qenë se nuk jemi pjesë e një ekipi, por jemi të angazhuar në funksionimin e të gjitha aplikacioneve të e-commerce si pjesë e një dyqani online, morëm përsipër detyrën e krijimit të një sistemi gjithëpërfshirës monitorimi për platformën e tregtisë elektronike.
Struktura dhe staku i sistemit
Ne filluam duke identifikuar disa shtresa monitorimi për sistemet tona, brenda të cilave do të na duhej të mblidhnim metrikë. Dhe e gjithë kjo duhej të kombinohej, gjë që bëmë në fazën e parë. Tani në këtë fazë ne po finalizojmë koleksionin me cilësi më të lartë të metrikës në të gjitha shtresat tona në mënyrë që të ndërtojmë një korrelacion dhe të kuptojmë se si sistemet ndikojnë në njëri-tjetrin.
Mungesa e monitorimit gjithëpërfshirës në fazat fillestare të lançimit të aplikacionit (që kur filluam ta ndërtonim kur shumica e sistemeve ishin në prodhim) çoi në faktin se kishim borxhe të konsiderueshme teknike për të vendosur monitorimin e të gjithë platformës. Ne nuk mund të përballonim të fokusoheshim në vendosjen e monitorimit për një IS dhe të punonim monitorimin për të në detaje, pasi pjesa tjetër e sistemeve do të mbetej pa monitorim për ca kohë. Për të zgjidhur këtë problem, ne identifikuam një listë të metrikave më të nevojshme për vlerësimin e gjendjes së sistemit të informacionit sipas shtresës dhe filluam ta zbatojmë atë.
Prandaj, ata vendosën ta hanë elefantin pjesë-pjesë.
Sistemi ynë përbëhet nga:
- harduer;
- sistemi operativ;
- softuer;
- Pjesët e UI në aplikacionin e monitorimit;
- matjet e biznesit;
- aplikacionet e integrimit;
- siguria e informacionit;
- rrjete;
- balancues i trafikut.
Në qendër të këtij sistemi është vetë monitorimi. Për të kuptuar përgjithësisht gjendjen e të gjithë sistemit, duhet të dini se çfarë po ndodh me aplikacionet në të gjitha këto shtresa dhe në të gjithë grupin e aplikacioneve.
Pra, në lidhje me pirgun.
Ne përdorim softuer me kod të hapur. Në qendër kemi Zabbix, të cilin e përdorim kryesisht si një sistem alarmi. Të gjithë e dinë se është ideale për monitorimin e infrastrukturës. Çfarë do të thotë kjo? Pikërisht ato metrikë të nivelit të ulët që ka çdo kompani që mban qendrën e saj të të dhënave (dhe Sportmaster ka qendrat e veta të të dhënave) - temperatura e serverit, statusi i kujtesës, bastisja, metrikat e pajisjes së rrjetit.
Ne kemi integruar Zabbix me mesazherin Telegram dhe Microsoft Teams, të cilat përdoren në mënyrë aktive në ekipe. Zabbix mbulon shtresën e rrjetit aktual, harduerin dhe disa softuer, por nuk është një ilaç. Ne i pasurojmë këto të dhëna nga disa shërbime të tjera. Për shembull, në nivelin e harduerit, ne lidhemi drejtpërdrejt nëpërmjet API me sistemin tonë të virtualizimit dhe mbledhim të dhëna.
Çfarë tjetër. Përveç Zabbix, ne përdorim Prometheus, i cili na lejon të monitorojmë metrikat në një aplikacion mjedisor dinamik. Kjo do të thotë, ne mund të marrim matjet e aplikacionit përmes një pike fundore HTTP dhe të mos shqetësohemi se cilat metrika të ngarkojmë në të dhe cilat jo. Bazuar në këto të dhëna, mund të zhvillohen pyetje analitike.
Burimet e të dhënave për shtresat e tjera, për shembull, metrikat e biznesit, ndahen në tre komponentë.
Së pari, këto janë sisteme të jashtme të biznesit, Google Analytics, ne mbledhim metrikë nga regjistrat. Prej tyre marrim të dhëna për përdoruesit aktivë, konvertimet dhe gjithçka tjetër që lidhet me biznesin. Së dyti, ky është një sistem monitorimi UI. Duhet të përshkruhet më në detaje.
Njëherë e një kohë filluam me testimin manual dhe ai u shndërrua në teste automatike të funksionalitetit dhe integrimeve. Nga kjo bëmë monitorim, duke lënë vetëm funksionalitetin kryesor dhe u mbështetëm në shënues që janë sa më të qëndrueshëm dhe nuk ndryshojnë shpesh me kalimin e kohës.
Struktura e re e ekipit do të thotë që të gjitha aktivitetet e aplikimit janë të kufizuara në ekipet e produkteve, kështu që ne ndaluam së bëri testime të pastra. Në vend të kësaj, ne bëmë monitorimin e UI nga testet, të shkruara në Java, Selenium dhe Jenkins (përdorur si një sistem për lëshimin dhe gjenerimin e raporteve).
Kemi bërë shumë prova, por në fund vendosëm të shkonim në rrugën kryesore, metrikën e nivelit të lartë. Dhe nëse kemi shumë teste specifike, do të jetë e vështirë të mbajmë të dhënat të përditësuara. Çdo lëshim i mëpasshëm do të thyejë ndjeshëm të gjithë sistemin dhe gjithçka që do të bëjmë është ta rregullojmë atë. Prandaj, ne u fokusuam në gjëra shumë thelbësore që rrallë ndryshojnë dhe ne vetëm i monitorojmë ato.
Së fundi, së treti, burimi i të dhënave është një sistem i centralizuar i prerjeve. Ne përdorim Elastic Stack për regjistrat dhe më pas mund t'i tërheqim këto të dhëna në sistemin tonë të monitorimit për matjet e biznesit. Përveç gjithë kësaj, ne kemi shërbimin tonë të Monitorimit API, të shkruar në Python, i cili kërkon çdo shërbim nëpërmjet API dhe mbledh të dhëna prej tyre në Zabbix.
Një atribut tjetër i domosdoshëm i monitorimit është vizualizimi. E jona është e bazuar në Grafana. Ai dallohet midis sistemeve të tjera të vizualizimit në atë që ju lejon të vizualizoni metrikat nga burime të ndryshme të të dhënave në panelin e kontrollit. Ne mund të mbledhim matjet e nivelit të lartë për një dyqan në internet, për shembull, numrin e porosive të bëra në orën e fundit nga DBMS, matjet e performancës për sistemin operativ në të cilin funksionon ky dyqan online nga Zabbix dhe metrikë për shembuj të këtij aplikacioni nga Prometeu. Dhe e gjithë kjo do të jetë në një pult. E qartë dhe e arritshme.
Më lejoni të shënoj për sigurinë - aktualisht jemi duke e finalizuar sistemin, të cilin më vonë do ta integrojmë me sistemin global të monitorimit. Për mendimin tim, problemet kryesore me të cilat përballet e-commerce në fushën e sigurisë së informacionit lidhen me robotët, analizuesit dhe forcën brutale. Ne duhet t'i kushtojmë vëmendje kësaj, sepse e gjithë kjo mund të ndikojë në mënyrë kritike si në funksionimin e aplikacioneve tona ashtu edhe në reputacionin tonë nga pikëpamja e biznesit. Dhe me pirgun e zgjedhur ne i mbulojmë me sukses këto detyra.
Një pikë tjetër e rëndësishme është se shtresa e aplikimit është montuar nga Prometheus. Ai vetë është gjithashtu i integruar me Zabbix. Dhe ne kemi gjithashtu shpejtësinë e faqes, një shërbim që na lejon të shikojmë parametra të tillë si shpejtësia e ngarkimit të faqes sonë, pikat e ngushta, interpretimi i faqeve, ngarkimi i skripteve, etj., është gjithashtu i integruar API. Pra, metrikat tona janë mbledhur në Zabbix, dhe në përputhje me rrethanat, ne gjithashtu sinjalizojmë nga atje. Të gjitha sinjalizimet dërgohen aktualisht në metodat kryesore të dërgimit (për momentin është email dhe telegram, MS Teams gjithashtu është lidhur së fundmi). Ka plane për të përmirësuar sinjalizimin në një gjendje të tillë që robotët inteligjentë të punojnë si shërbim dhe të ofrojnë informacion monitorimi për të gjitha ekipet e produkteve të interesuara.
Për ne, metrikat janë të rëndësishme jo vetëm për sistemet individuale të informacionit, por edhe metrikat e përgjithshme për të gjithë infrastrukturën që përdorin aplikacionet: grupet e serverëve fizikë në të cilët funksionojnë makinat virtuale, balancuesit e trafikut, Balancuesit e ngarkesës së rrjetit, vetë rrjeti, përdorimi i kanaleve të komunikimit. . Metrikë plus për qendrat tona të të dhënave (ne kemi disa prej tyre dhe infrastruktura është mjaft e madhe).
Përparësitë e sistemit tonë të monitorimit janë se me ndihmën e tij ne shohim gjendjen shëndetësore të të gjitha sistemeve dhe mund të vlerësojmë ndikimin e tyre tek njëri-tjetri dhe tek burimet e përbashkëta. Dhe në fund, na lejon të përfshihemi në planifikimin e burimeve, që është gjithashtu përgjegjësia jonë. Ne menaxhojmë burimet e serverit - një grup brenda tregtisë elektronike, komisionim dhe çmontim pajisje të reja, blejmë pajisje të reja shtesë, kryejmë një auditim të përdorimit të burimeve, etj. Çdo vit, ekipet planifikojnë projekte të reja, zhvillojnë sistemet e tyre dhe është e rëndësishme për ne t'u ofrojmë burime.
Dhe me ndihmën e metrikës, ne shohim tendencën në konsumin e burimeve nga sistemet tona të informacionit. Dhe në bazë të tyre ne mund të planifikojmë diçka. Në nivelin e virtualizimit, ne mbledhim të dhëna dhe shohim informacione për sasinë e disponueshme të burimeve nga qendra e të dhënave. Dhe tashmë brenda qendrës së të dhënave ju mund të shihni riciklimin, shpërndarjen aktuale dhe konsumin e burimeve. Për më tepër, si me serverë të pavarur, ashtu edhe me makina virtuale dhe grupime të serverëve fizikë në të cilët të gjitha këto makina virtuale po rrotullohen fuqishëm.
Perspektivat
Tani kemi gati thelbin e sistemit në tërësi, por ka ende shumë gjëra për të cilat duhet të punohet. Në minimum, kjo është një shtresë e sigurisë së informacionit, por është gjithashtu e rëndësishme të arrihet rrjeti, të zhvillohet alarmi dhe të zgjidhet çështja e korrelacionit. Ne kemi shumë shtresa dhe sisteme, dhe në secilën shtresë ka shumë më tepër metrikë. Rezulton të jetë një matryoshka në shkallën e një matryoshka.
Detyra jonë është që në fund të bëjmë sinjalizimet e duhura. Për shembull, nëse kishte një problem me harduerin, përsëri, me një makinë virtuale, dhe kishte një aplikacion të rëndësishëm dhe shërbimi nuk u kopjua në asnjë mënyrë. Zbulojmë se makina virtuale ka vdekur. Atëherë matjet e biznesit do t'ju paralajmërojnë: përdoruesit janë zhdukur diku, nuk ka konvertim, ndërfaqja e përdoruesit në ndërfaqe nuk është e disponueshme, softueri dhe shërbimet gjithashtu kanë vdekur.
Në këtë situatë, ne do të marrim spam nga sinjalizimet dhe kjo nuk përshtatet më në formatin e një sistemi të duhur monitorimi. Shtrohet pyetja e korrelacionit. Prandaj, në mënyrë ideale, sistemi ynë i monitorimit duhet të thotë: "Djema, makina juaj fizike ka vdekur dhe bashkë me të ky aplikacion dhe këto metrikë", me ndihmën e një alarmi, në vend që të na bombardojë furishëm me njëqind alarme. Ai duhet të raportojë gjënë kryesore - shkakun, i cili ndihmon në eliminimin e shpejtë të problemit për shkak të lokalizimit të tij.
Sistemi ynë i njoftimeve dhe përpunimi i sinjalizimeve është ndërtuar rreth një shërbimi të linjës telefonike XNUMX-orëshe. Të gjitha sinjalizimet që konsiderohen të domosdoshme dhe janë të përfshira në listën e kontrollit dërgohen atje. Çdo alarm duhet të ketë një përshkrim: çfarë ka ndodhur, çfarë do të thotë në të vërtetë, çfarë ndikon. Dhe gjithashtu një lidhje me pultin dhe udhëzimet se çfarë të bëni në këtë rast.
Kjo ka të bëjë me kërkesat për ndërtimin e një alarmi. Atëherë situata mund të zhvillohet në dy drejtime - ose ka një problem dhe duhet zgjidhur, ose ka pasur një dështim në sistemin e monitorimit. Por në çdo rast, duhet të shkoni dhe ta kuptoni.
Mesatarisht, tani marrim rreth njëqind sinjalizime në ditë, duke marrë parasysh faktin se korrelacioni i sinjalizimeve ende nuk është konfiguruar siç duhet. Dhe nëse na duhet të kryejmë punë teknike dhe e fikim me forcë diçka, numri i tyre rritet ndjeshëm.
Përveç monitorimit të sistemeve që ne operojmë dhe mbledhjes së matjeve që konsiderohen të rëndësishme nga ana jonë, sistemi i monitorimit na lejon të mbledhim të dhëna për ekipet e produkteve. Ato mund të ndikojnë në përbërjen e metrikës brenda sistemeve të informacionit që ne monitorojmë.
Kolegu ynë mund të vijë dhe të kërkojë të shtojë disa metrikë që do të jenë të dobishme si për ne ashtu edhe për ekipin. Ose, për shembull, ekipi mund të mos ketë mjaftueshëm metrikat bazë që ne kemi; ata duhet të gjurmojnë disa të veçanta. Në Grafana, ne krijojmë një hapësirë për çdo ekip dhe japim të drejta administratori. Gjithashtu, nëse një ekipi ka nevojë për panele kontrolli, por ata vetë nuk mund/nuk dinë ta bëjnë këtë, ne i ndihmojmë.
Meqenëse jemi jashtë rrjedhës së krijimit të vlerës së ekipit, lëshimeve dhe planifikimit të tyre, gradualisht po arrijmë në përfundimin se publikimet e të gjitha sistemeve janë të njëtrajtshme dhe mund të shpërndahen çdo ditë pa koordinim me ne. Dhe është e rëndësishme për ne që të monitorojmë këto lëshime, sepse ato mund të ndikojnë potencialisht në funksionimin e aplikacionit dhe të prishin diçka, dhe kjo është kritike. Për të menaxhuar publikimet, ne përdorim Bamboo, nga ku marrim të dhëna nëpërmjet API dhe mund të shohim se cilat versione janë lëshuar në cilat sisteme informacioni dhe statusin e tyre. Dhe gjëja më e rëndësishme është se në cilën orë. Ne mbivendosim shënuesit e lëshimit në metrikat kryesore kritike, gjë që është vizualisht shumë tregues në rast problemesh.
Në këtë mënyrë ne mund të shohim korrelacionin midis publikimeve të reja dhe problemeve të shfaqura. Ideja kryesore është të kuptoni se si funksionon sistemi në të gjitha shtresat, të lokalizoni shpejt problemin dhe ta rregulloni atë po aq shpejt. Në fund të fundit, shpesh ndodh që ajo që merr më shumë kohë nuk është zgjidhja e problemit, por kërkimi i shkakut.
Dhe në këtë fushë në të ardhmen duam të fokusohemi në proaktivitet. Idealisht, do të doja të dija për një problem që po afrohet paraprakisht, dhe jo pas faktit, në mënyrë që ta parandaloj atë në vend që ta zgjidh. Ndonjëherë ndodhin alarme të rreme të sistemit të monitorimit, si për shkak të gabimit njerëzor ashtu edhe për shkak të ndryshimeve në aplikacion. Dhe ne punojmë për këtë, e korrigjojmë atë dhe përpiqemi të paralajmërojmë përdoruesit që e përdorin atë me ne për këtë përpara çdo manipulimi të sistemit të monitorimit , ose kryeni këto aktivitete në dritaren teknike.
Pra, sistemi ka nisur dhe funksionon me sukses që në fillim të pranverës...dhe po shfaq fitime shumë reale. Sigurisht, ky nuk është versioni i tij përfundimtar; ne do të prezantojmë shumë veçori të tjera të dobishme. Por tani, me kaq shumë integrime dhe aplikacione, automatizimi i monitorimit është vërtet i pashmangshëm.
Nëse monitoroni gjithashtu projekte të mëdha me një numër të konsiderueshëm integrimesh, shkruani në komente se çfarë plumbi argjendi keni gjetur për këtë.
Burimi: www.habr.com