Ne kemi filluar të mendojmë për krijimin e një sistemi monitorimi gjatë formimit të ekipeve të produktit. U bë e qartë se puna jonë - operimi - nuk përfshihet në këto ekipe. Pse ndodh kështu?
Kjo ndodh sepse të gjitha ekipet tona janë ndërtuar rreth sistemeve të veçanta informacioni, mikroshërbimeve dhe fronteve, prandaj gjendja e përgjithshme shëndetësore e sistemit si një tërësi nuk është e dukshme për ekipet. Për shembull, ata mund të mos dinë se si një pjesë e vogël në backend të thellë ndikon në pjesën e frontit. Rrethi i interesave të tyre kufizohet me sistemet me të cilat është integruar sistemi i tyre. Nëse ekipi dhe shërbimi i tij A nuk janë të lidhur pothuajse fare me shërbimin B, atëherë ky shërbim është pothuajse i padukshëm për ekipin.
Ekipi ynë, nga ana tjetër, punon me sisteme që janë shumë të integruara me njëra-tjetrën: midis tyre ekzistojnë shumë lidhje, kjo është një infrastrukthrë mjaft e madhe. Dhe nga të gjitha këto sisteme (të cilat, për të thënë të drejtën, janë një numër i madh), varet funksionimi i dyqanit online.
Pra sa është, që departamenti ynë nuk i përket asnjë ekipi, por ndodhet paksa në anë. Në tërë këtë histori, detyra jonë është të kuptojmë në mënyrë të plotë se si funksionojnë sistemet informative, funksionalitetet e tyre, integrimet, softueri, rrjeti, hardueri, dhe si lidhen të gjitha këto me njëra-tjetrën.
Platforma, në të cilën funksionojnë dyqanet tona në internet, duket kështu:
- front
- middle-office
- back-office
Sa do qĂ« tĂ« donim, nuk ka asnjĂ« rast qĂ« tĂ« gjitha sistemet tĂ« funksionojnĂ« pa probleme dhe pa gabime. Problemi, sĂ«rish, Ă«shtĂ« numri i sistemeve dhe integrimeve â nĂ« situatĂ«n tonĂ«, ndodhin disa incidente tĂ« papĂ«rshtatshme, pavarĂ«sisht cilĂ«sisĂ« sĂ« testimit. KĂ«shtu, ndodhin si brenda njĂ« sistemi tĂ« veçantĂ«, ashtu edhe nĂ« lidhje me integrimin e tyre. ĂshtĂ« e nevojshme tĂ« monitorohet gjendja e gjithĂ« platformĂ«s nĂ« mĂ«nyrĂ« komplekse, dhe jo vetĂ«m njĂ« pjese tĂ« saj tĂ« veçantĂ«.
Në idealin e saj, monitorimi i shëndetit të gjithë platformës duhet të automatizohet. Dhe ne arritëm te monitorimi si një pjesë e paevitueshme e këtij procesi. Fillimisht, ai u ndërtua vetëm për pjesën e parë, ndërsa sistemet tona të monitorimit në nivele ishin dhe janë ende të pranishme tek rrjetistët, administratorët e softuerit dhe të harduerit. Të gjithë këta individë e ndiqnin monitorimin vetëm në nivelin e tyre, pa pasur një kuptim kompleks të situatës.
PĂ«r shembull, nĂ«se njĂ« makinĂ« virtuale ka rĂ«nĂ«, nĂ« shumicĂ«n e rasteve, pĂ«r kĂ«tĂ« e di vetĂ«m administratori qĂ« Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r harduerin dhe makinĂ«n virtuale. Ekipi i front-end nĂ« raste tĂ« tilla sheh vetĂ«m faktin e rĂ«nies sĂ« aplikacionit, por nuk ka tĂ« dhĂ«na pĂ«r rĂ«nien e makinĂ«s virtuale. NdĂ«rsa administratori mund tĂ« di se kush Ă«shtĂ« klienti dhe tĂ« ketĂ« njĂ« ide tĂ« pĂ«rafĂ«rt se çfarĂ« po funksionon aktualisht nĂ« kĂ«tĂ« makinĂ« virtuale, nĂ« rast se Ă«shtĂ« njĂ« projekt i madh. PĂ«r projektet e vogla, nuk do tĂ« dijĂ« ndoshta asgjĂ«. NĂ« çdo rast, administratori duhet tĂ« shkojĂ« te pronari, tĂ« pyesĂ« se çfarĂ« kishte nĂ« kĂ«tĂ« makinĂ«, çfarĂ« duhet tĂ« rikuperohet dhe çfarĂ« duhet ndryshuar. Dhe nĂ«se diçka ishte prishur shumĂ« seriozisht, fillonte njĂ« shĂ«titje rreth e rrotull â sepse askush nuk e kishte parĂ« sistemin nĂ« tĂ«rĂ«si.
NĂ« fund tĂ« fundit, kĂ«to histori tĂ« ndara ndikon nĂ« tĂ«rĂ« front-end-in, te pĂ«rdoruesit dhe funksionin tonĂ« kryesor tĂ« biznesit â shitjet nĂ« internet. Duke qenĂ« se ne nuk jemi pjesĂ« e ekipeve dhe merremi me operimin e tĂ« gjitha aplikacioneve ecommerce brenda dyqanit online, e kemi marrĂ« detyrĂ«n pĂ«r tĂ« krijuar njĂ« sistem tĂ«rĂ«sor monitorimi pĂ«r platformĂ«n ecommerce.
Struktura e sistemit dhe stoku
Ne filluam duke identifikuar disa nivele monitorimi për sistemet tona, nëpërmjet të cilave na nevojitet të mbledhim metrika. Dhe e gjithë kjo duhej të ishte e bashkuar, që arritëm ta realizojmë në fazën e parë. Tani, në këtë fazë, po punojmë për të siguruar mbledhjen sa më cilësore të metrikeve në të gjitha nivelet tona, për të ndërtuar korelacion dhe për të kuptuar se si sistemet ndikojnë njëra-tjetrën.
Mungesa e monitorimit të gjithanshëm në fazat e para të lançimit të aplikacioneve (sepse filluam ta ndërtojmë atë kur pjesa më e madhe e sistemeve ishte në përdorim) solli në krijimin e një borxhi të konsiderueshëm teknik lidhur me konfigurimin e monitorimit të gjithë platformës. Nuk mund të përqendroheshim në konfigurimin e monitorimit për një informacion të caktuar dhe ta zhvillojmë atë në detaje, pasi sistemet e tjera do të mbeteshin një kohë pa monitorim. Për të zgjidhur këtë problem, ne përcaktuam një listë të metrikeve më të nevojshme për vlerësimin e gjendjes së informacionit sipas niveleve dhe filluam ta implementojmë atë.
Prandaj, vendosëm ta kalojmë njëherë një copë nga elefanti.
Sistemi ynë përbëhet nga:
- hardware;
- sistemi operativ;
- software;
- Elementet UI në aplikacionin e monitorimit;
- metrikat e biznesit;
- aplikacione integrimi;
- siguria informative;
- rrjetet;
- balancuesi i trafikut.
Qendra e këtij sistemi është monitorimi për vete. Për të kuptuar gjendjen e përgjithshme të të gjithë sistemit, është e nevojshme të dimë se çfarë po ndodh me aplikacionet në të gjitha këto nivele dhe në kontekstin e gjithë shumllojshmërisë së aplikacioneve.
Kështu, për sa i përket stek.
PĂ«rdorim softuer me burim tĂ« hapur. NĂ« qendĂ«r kemi Zabbix, tĂ« cilin e pĂ«rdorim kryesisht si sistem alertrimi. TĂ« gjithĂ«ve u Ă«shtĂ« e njohur se ai Ă«shtĂ« perfekt pĂ«r monitorimin e infrastrukturĂ«s. ĂfarĂ« do tĂ« thotĂ« kjo? JanĂ« pikĂ«risht ato metrika tĂ« nivelit tĂ« ulĂ«t qĂ« ka çdo kompani qĂ« ka qendrĂ«n e saj tĂ« tĂ« dhĂ«nave (dhe Sportmaster ka qendrat e veta tĂ« tĂ« dhĂ«nave) - temperatura e serverĂ«ve, gjendja e memories, RAID-it, metrikat e pajisjeve tĂ« rrjetit.
Ne kemi integruar Zabbix me mesazherin Telegram dhe Microsoft Teams, të përdorura aktivisht në ekipe. Zabbix pokriva nivelin e rrjetit aktual, harduerit dhe pjesërisht të softuerit, por nuk është panacea. Ne e pasurojmë këtë informacion nga disa shërbime të tjera. Për shembull, në nivelin e harduerit, ne lidhim drejtpërdrejt përmes API në sistemin tonë të virtualizimit dhe marrim të dhëna.
ĂfarĂ« tjetĂ«r. PĂ«rveç Zabbix, ne pĂ«rdorim Prometheus, i cili lejon monitorimin e metrikave nĂ« aplikacione tĂ« mjedisit dinamik. KĂ«shtu, ne mund tĂ« marrim metrika tĂ« aplikacionit pĂ«rmes HTTP endpoint dhe tĂ« mos shqetĂ«sohemi pĂ«r ata qĂ« duhet t'i ngarkojmĂ« nĂ« tĂ«, dhe ata qĂ« jo. NĂ« bazĂ« tĂ« kĂ«tyre tĂ« dhĂ«nave, mund tĂ« pĂ«rpunojmĂ« kĂ«rkesat analitike.
Burimet e të dhënave për shtresat e tjera, për shembull, metrikat biznesore, ndahen në tri përbërës.
Së pari, janë sistemet e jashtme të biznesit, Google Analytics, nga të cilat mbledhim metrikat nga log-et. Nga to, ne marrim të dhëna për përdoruesit aktivë, konversionet dhe gjithçka tjetër të lidhur me biznesin. Së dyti, është sistemi i monitorimit të UI. Për këtë duhet të flasim më në detaje.
Njëherë ne kemi filluar me testimin manual dhe e kemi zhvilluar në teste automatike për funksionalitetin dhe integrimet. Nga kjo, ne kemi krijuar monitorimin, duke lënë vetëm funksionalitetin kryesor dhe duke u lidhur me shenjat që janë sa më të qëndrueshme dhe që nuk ndryshojnë shpesh me kalimin e kohës.
Struktura e re e ekipeve parashikon që të gjitha aktivitetet në aplikacione të mbyllen brenda ekipeve produktive, prandaj ne kurrë nuk merremi më me testimin e pastër. Në vend të kësaj, ne kemi bërë monitorim UI, të shkruar në Java, Selenium dhe Jenkins (i përdorur si sistem për ekzekutimin dhe krijimin e raporteve).
Ne kishim shumĂ« teste, por pĂ«rfundimisht vendosĂ«m tĂ« dalim nĂ« rrugĂ«n kryesore, metrikat e nivelit tĂ« lartĂ«. Dhe nĂ«se do tĂ« kesh shumĂ« teste specifike, do tĂ« ishte e vĂ«shtirĂ« tĂ« mbaje tĂ« dhĂ«nat aktuale. Ădo lĂ«shim i mĂ«passhĂ«m do tĂ« prishte ndjeshĂ«m tĂ« gjithĂ« sistemin, dhe ne vetĂ«m do tĂ« merreshim me riparimin e tij. Prandaj, ne u lidhĂ«m vetĂ«m me gjĂ«rat thelbĂ«sore, qĂ« ndryshojnĂ« rrallĂ« dhe monitorojmĂ« vetĂ«m ato.
Së fundi, në tretin vend, burimi i të dhënave është një sistem i centralizuar i regjistrimit. Për log-et përdorim Elastic Stack, dhe më pas mund t'i sjellim këto të dhëna në sistemin tonë të monitorimit të metricave të biznesit. Përveç gjithçkaje tjetër, funksionon edhe shërbimi ynë Monitoring API, i shkruar në Python, i cili pyet përmes API çdo shërbim dhe merr të dhënat nga ata në Zabbix.
Një tjetër atribut i paçmuar i monitorimit është vizualizimi. Kjo realizohet mbi bazën e Grafana-s. Ndër sistemet e tjera të vizualizimit, ajo dallohet për faktin se në dashboard mund të vizualizosh metrika nga burime të ndryshme të dhënash. Mund të mbledhim metrika në nivel të lartë të një dyqani online, për shembull, numrin e porosive të bëra në orën e fundit nga DBMS, metrika të performancës së OS-së mbi të cilën është aktivizuar ky dyqan online nga Zabbix, dhe metrika të instancave të kësaj aplikacioni nga Prometheus. Dhe e gjithë kjo do të jetë në një dashboard. E qartë dhe e qasshme.
Dua tĂ« flas pĂ«r sigurinĂ« â pĂ«r momentin po pĂ«rfundojmĂ« njĂ« sistem qĂ« mĂ« vonĂ« do ta integrojmĂ« me njĂ« sistem global tĂ« monitorimit. Sipas mendimit tim, problemet kryesore me tĂ« cilat pĂ«rballet e-commerce nĂ« fushĂ«n e sigurisĂ« informative lidhen me robotĂ«t, parserĂ«t dhe brute force. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« monitorohet kjo, sepse gjithçka mund tĂ« ndikojĂ« ndjeshĂ«m si nĂ« funksionimin e aplikacioneve tona, ashtu edhe nĂ« reputacionin e biznesit. Me stack-un e zgjedhur, i mbulojmĂ« me sukses kĂ«to sfida.
Një pikë tjetër e rëndësishme është se niveli i aplikacioneve mblidhet nga Prometheus. Ai gjithashtu është i integruar me Zabbix. Po ashtu, kemi sitespeed, një shërbim që na lejon të shohim parametra të tillë si shpejtësia e ngarkesës së faqes tonë, ngushticat, vizualizimi i faqes, ngarkimi i skripteve dhe të tjera, gjithashtu i integruar përmes API. Kështu që metrikat mblidhen në Zabbix, dhe ne gjithashtu alertojmë nga aty. Të gjitha alarmin dergohen përmes mënyrave kryesore të dërgimit (për momentin, këto janë email dhe telegram, dhe së fundmi kemi lidhur gjithashtu MS Teams). Në planet tona është përmirësimi i alertimit deri në një gjendje ku robotët inteligjentë do të punojnë si shërbim dhe do të ofrojnë informacion mbi monitorimin për të gjitha ekipet produktive që janë të interesuara.
Për ne janë të rëndësishme metrikat jo vetëm të sistemeve informacioni të veçuara, por edhe metrikat e përgjithshme për të gjithë infrastrukturën që aplikacionet përdorin: klasterët serverëve fizikë, mbi të cilët funksionojnë virtualkat, balancuesit e trafikut, Network Load Balancer-at, vetë rrjeti, përdorimi i kanaleve të komunikimit. Përveç kësaj, metrikat për qendrat tona të të dhënave (kemi disa dhe infrastruktura është mjaft e madhe).
Avantazhet e sistemit tonĂ« tĂ« monitorimit janĂ« 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Ă«rbashkĂ«ta. Dhe nĂ« fund, ajo na lejon tĂ« merremi me planifikimin e burimeve, qĂ« gjithashtu Ă«shtĂ« pjesĂ« e pĂ«rgjegjĂ«sisĂ« sonĂ«. Ne menaxhojmĂ« burimet serverike - njĂ« basen brenda e-commerce, futim-dalim nga pĂ«rdorimi pajisje tĂ« reja, blejmĂ« tĂ« reja, kryejmĂ« auditimin e riciklimit tĂ« burimeve dhe tĂ« tjera. Ădo vit ekipet planifikojnĂ« projekte tĂ« reja, zhvillojnĂ« sistemet e tyre, dhe Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r ne tĂ« sigurojmĂ« burime pĂ«r to.
Dhe me ndihmën e metrikave ne shohim tendencën e konsumit të burimeve nga sistemet tona informuese. Dhe bazuar në to, mund të planifikojmë diçka. Në nivelin e virtualizimit grumbullojmë të dhëna dhe shohim informacionin në lidhje me sasinë e burimeve të disponueshme në mënyrë të ndarë për qendrat e të dhënave. Dhe brenda qendrës së të dhënave shikohet si riciklimi ashtu edhe shpërndarja faktike, konsumimi i burimeve. Kjo ndodh si me serverët standalone ashtu edhe me makinat virtuale dhe klasteret e serverëve fizikë, mbi të cilat të gjitha këto virtuale funksionojnë lehtësisht.
Perspektivat
Tani kemi një sistem të gatshëm në përgjithësi, por ka ende disa çështje mbi të cilat duhet të punojmë. Të paktën kjo përfshin layers e sigurisë informative, ndërsa është gjithashtu e rëndësishme të arrijmë në rrjet, të zhvillojmë alarmet dhe të zgjidhim çështjen e korrelacionit. Kemi shumë nivele dhe sisteme, dhe në çdo nivel ka gjithashtu shumë metrika. Kështu krijohet një matryoshka në shkallën e matryoshkës.
Detyra jonë është në fund të fundit për të krijuar alarmet e duhura. Për shembull, nëse ka ndodhur një problem me komponentin hardware, gjithashtu me makinat virtuale, ku kishte një aplikacion të rëndësishëm dhe shërbimi nuk ishte ashtu siç duhej. Ne do të zbulojmë se makina virtuale ka vdekur. Më pas, do të alarmojmë metrikat e biznesit: përdoruesit janë humbur diku, nuk ka konversion, UI në ndërfaqe nuk është i aksesueshëm, gjithashtu programet dhe shërbimet kanë vdekur.
Me kĂ«to rrethana, do tĂ« marrim spam nga alarmet, dhe kjo nuk pĂ«rputhet me formatin e duhur tĂ« njĂ« sistemi monitorimi. Lind pyetja e korelacionit. Prandaj, nĂ« mĂ«nyrĂ« ideale, sistemi ynĂ« i monitorimit duhet tĂ« thotĂ«: "Djem, makina fizike vdiq, dhe me tĂ« shkuan kjo aplikacion dhe kĂ«to metrika", me njĂ« alarm tĂ« vetĂ«m nĂ« vend qĂ« tĂ« na bombardohet me njĂ«qind alarmet. Ai duhet tĂ« raportojĂ« tĂ« rĂ«ndĂ«sishmen â shkakun, qĂ« ndihmon nĂ« pĂ«rshpejtimin e zgjidhjes sĂ« problemit pĂ«rmes lokalizimit tĂ« tij.
Sistemi ynĂ« i njoftimeve dhe pĂ«rpunimi i alarmet janĂ« ndĂ«rtuar nĂ« rrethin e shĂ«rbimit telefonik tĂ« nxehtĂ« njĂ«zet e katĂ«r orĂ«. TĂ« gjitha alarmet qĂ« ne i konsiderojmĂ« si njĂ« domosdoshmĂ«ri dhe pĂ«rfshihen nĂ« listĂ«n e kontrollit, dĂ«rgohen atje. Ădo alarm duhet tĂ« ketĂ« patjetĂ«r njĂ« pĂ«rshkrim: çfarĂ« ndodhi, çfarĂ« do tĂ« thotĂ«, pĂ«r çfarĂ« ndikon. Dhe gjithashtu njĂ« lidhje pĂ«r panelin e kontrollit dhe njĂ« udhĂ«zim se çfarĂ« duhet tĂ« bĂ«jmĂ« nĂ« kĂ«tĂ« rast.
KĂ«to janĂ« tĂ« gjitha kĂ«rkesat pĂ«r ndĂ«rtimin e alarmimit. Situata mĂ« pas mund tĂ« zhvillohet nĂ« dy drejtime â ose ka njĂ« problem dhe duhet tĂ« zgjidhet, ose ka ndodhur njĂ« dĂ«shtim nĂ« sistemin e monitorimit. Por nĂ« çdo rast, duhet tĂ« shkojmĂ« dhe tĂ« hetojmĂ«.
Në mesatare, tani na bien rreth njëqind alerte në ditë, duke marrë parasysh se korelacioni i alerteve ende nuk është konfiguruar siç duhet. Dhe nëse duhet të kryhen punë teknike, dhe ne disablokojmë diçka me forcë, numri i tyre rritet shumëfish.
Përveç monitorimit të sistemeve që ne operojmë dhe mbledhjes së metrikave, të cilat në anën tonë përbëjnë informacion të rëndësishëm, sistemi i monitorimit lejon mbledhjen e të dhënave për ekipet e produktit. Ato mund të ndikojnë në përmbajtjen e metrikave brenda sistemeve informative që monitorohen nga ne.
Kolegu ynë mund të vijë dhe të kërkojë të shtohet ndonjë metrikë, e cila do të jetë e dobishme si për ne, ashtu edhe për ekipin. Ose, për shembull, ekipi mund të mos jetë i kënaqur me metrikat bazë që kemi, ata mund të duan të ndjekin ndonjë specifike. Në Grafana krijojmë një hapësirë për çdo ekip dhe ofrojmë të drejtat e adminit. Po ashtu, nëse ekipi ka nevojë për panelë, por ata vetë nuk mund/din si ta bëjnë këtë, ne i ndihmojmë.
Duke jemi jashtĂ« fluxit tĂ« krijimit tĂ« vlerave tĂ« ekipit, publikimeve tĂ« tyre dhe planifikimit, po arrijmĂ« gradualisht nĂ« njĂ« situatĂ« ku tĂ« gjitha publikimet e sistemeve janĂ« pa ndĂ«rprerje dhe mund tĂ« lĂ«shohen çdo ditĂ«, pa u koordinuar me ne. ĂshtĂ« e rĂ«ndĂ«sishme pĂ«r ne qĂ« tĂ« ndjekim kĂ«to publikime, pasi ato potencialisht mund tĂ« ndikojnĂ« nĂ« funksionimin e aplikacionit dhe tĂ« shkaktojnĂ« ndonjĂ« problem, gjĂ« qĂ« Ă«shtĂ« kritike. PĂ«r menaxhimin e publikimeve pĂ«rdorim Bamboo, nga ku marrim tĂ« dhĂ«na pĂ«rmes API-t dhe mund tĂ« shohim se cilat publikime kanĂ« dalĂ« nĂ« cilat sisteme informacioni dhe statusin e tyre. Dhe mĂ« e rĂ«ndĂ«sishmja â nĂ« çfarĂ« kohe. Ne vendosim tregues pĂ«r publikimet nĂ« metrikat tona kryesore, qĂ« vizualisht janĂ« shumĂ« treguese nĂ« rast tĂ« problemeve.
Kështu, ne mund ta shohim korrelacionin mes publikimeve të reja dhe problemeve që shfaqen. Ideja kryesore është të kuptojmë se si funksionon sistemi në të gjitha nivelet, të lokalizojmë shpejt problemin dhe ta riparojmë po ashtu shpejt. Sepse shpesh ndodh që më shumë kohë shkon për të gjetur shkakun, sesa për të zgjidhur problemin.
Në këtë drejtim, në të ardhmen do të dëshirojmë të fokusojmë mbi proaktivitetin. Ideali do të ishte të dijmë paraprakisht për një problem që po afron, e jo pas faktit, për të parandaluar atë, jo për ta zgjidhur. Ndonjëherë ndodhin alarmime të rreme nga sistemi i monitorimit, si për shkak të gabimeve njerëzore, ashtu edhe për shkak të ndryshimeve në aplikacion. Po punojmë mbi këtë, duke e rregulluar, dhe përpiqemi që para çdo manipulimi me sistemin e monitorimit të paralajmërojmë përdoruesit që e përdorin atë me ne, ose të kryejmë këto aktivitete në një dritare teknike.
Pra, sistemi është lançuar dhe funksionon me sukses që nga fillimi i pranverës⊠dhe tregon një fitim të dukshëm. Sigurisht, kjo nuk është versioni përfundimtar, ne do të integrojmë shumë funksionalitete të tjera. Por në këtë moment, me kaq shumë integrime dhe aplikacione, pa automatizimin e monitorimit, në fakt, nuk mund të kalojmë.
NĂ«se ju gjithashtu monitoroni projekte tĂ« mĂ«dha me njĂ« numĂ«r serioz integrimesh â shkruani nĂ« komentet se çfarĂ« zgjidhje tĂ« shkĂ«lqyer keni gjetur pĂ«r kĂ«tĂ«.
Burimi: habr.com
