Përshëndetje të gjithëve!
Kompania jonë është e angazhuar në zhvillimin e softuerit dhe mbështetjen teknike të mëvonshme. Mbështetja teknike kërkon jo vetëm ndreqjen e gabimeve, por monitorimin e performancës së aplikacioneve tona.
Për shembull, nëse një nga shërbimet ka dështuar, atëherë duhet ta regjistroni automatikisht këtë problem dhe të filloni ta zgjidhni atë, në vend që të prisni thirrje nga përdoruesit e pakënaqur në mbështetjen teknike.
Ne kemi një kompani të vogël, nuk kemi burime për të studiuar dhe mbajtur ndonjë zgjidhje komplekse për monitorimin e aplikacioneve, na duhej të gjenim një zgjidhje të thjeshtë dhe efektive.
Strategjia e monitorimit
Nuk është e lehtë të kontrollosh funksionalitetin e një aplikacioni, kjo detyrë është jo e parëndësishme, madje mund të thuhet krijuese. Është veçanërisht e vështirë të verifikohet një sistem kompleks me shumë lidhje.
Si mund të hani një elefant? Vetëm në pjesë! Ne e përdorim këtë qasje për të monitoruar aplikacionet.
Thelbi i strategjisë sonë të monitorimit:
Ndani aplikacionin tuaj në komponentë.
Krijoni kontrolle kontrolli për secilin komponent.
Një komponent konsiderohet të jetë në gjendje të mirë nëse të gjitha kontrollet e tij të kontrollit kryhen pa gabime. Një aplikacion konsiderohet i shëndetshëm nëse të gjithë përbërësit e tij janë funksionalë.
Kështu, çdo sistem mund të përfaqësohet si një pemë e komponentëve. Komponentët kompleksë ndahen në më të thjeshtë. Komponentët e thjeshtë kanë kontrolle.
Standardet nuk kanë për qëllim të kryejnë testime funksionale, ato nuk janë teste njësi. Kontrollet e kontrollit duhet të kontrollojnë se si ndihet komponenti në momentin aktual në kohë, nëse ka të gjitha burimet e nevojshme për funksionimin e tij dhe nëse ka ndonjë problem.
Nuk ka mrekulli, shumica e kontrolleve do të duhet të zhvillohen në mënyrë të pavarur. Por mos kini frikë, sepse në shumicën e rasteve një kontroll kërkon 5-10 rreshta kodi, por ju mund të zbatoni çdo logjikë dhe do të kuptoni qartë se si funksionon kontrolli.
Sistemi i monitorimit
Le të themi se e kemi ndarë aplikacionin në komponentë, kemi dalë dhe kemi zbatuar kontrolle për secilin komponent, por çfarë të bëjmë me rezultatet e këtyre kontrolleve? Si e dimë nëse një kontroll dështoi?
Do të na duhet një sistem monitorimi. Ajo do të kryejë detyrat e mëposhtme:
- Merrni rezultatet e testit dhe përdorni ato për të përcaktuar statusin e komponentëve.
Vizualisht, kjo duket si nënvizimi i pemës përbërëse. Komponentët funksionalë bëhen të gjelbër, ata problematikë bëhen të kuq. - Kryeni kontrolle të përgjithshme jashtë kutisë.
Sistemi i monitorimit mund të kryejë vetë disa kontrolle. Pse të rishpikni timonin, le t'i përdorim ato. Për shembull, mund të kontrolloni nëse një faqe uebsajti po hapet ose serveri po bën ping. - Dërgoni njoftime për problemet tek palët e interesuara.
- Vizualizimi i të dhënave të monitorimit, sigurimi i raporteve, grafikëve dhe statistikave.
Përshkrim i shkurtër i sistemit ASMO
Është më mirë të shpjegohet me një shembull. Le të shohim se si është organizuar monitorimi i performancës së sistemit ASMO.
ASMO është një sistem i automatizuar i mbështetjes meteorologjike. Sistemi i ndihmon specialistët e shërbimit rrugor të kuptojnë se ku dhe kur është e nevojshme të trajtohet rruga me materiale ngrirëse. Sistemi mbledh të dhëna nga pikat e kontrollit rrugor. Një pikë kontrolli rrugor është një vend në rrugë ku janë instaluar pajisjet: një stacion meteorologjik, një videokamerë, etj. Për të parashikuar situata të rrezikshme, sistemi merr parashikimet e motit nga burime të jashtme.
Pra, përbërja e sistemit është mjaft tipike: faqe interneti, agjent, pajisje. Le të fillojmë monitorimin.
Ndarja e sistemit në komponentë
Komponentët e mëposhtëm mund të dallohen në sistemin ASMO:
1. Llogari personale
Ky është një aplikacion në internet. Së paku, duhet të kontrolloni nëse aplikacioni është i disponueshëm në internet.
2. Baza e të dhënave
Baza e të dhënave ruan të dhënat që janë të rëndësishme për raportimin dhe ju duhet të siguroheni që kopjet rezervë të bazës së të dhënave janë krijuar me sukses.
3. Serveri
Me server nënkuptojmë harduerin në të cilin funksionojnë aplikacionet. Është e nevojshme të kontrolloni statusin e HDD, RAM, CPU.
4. Agjent
Ky është një shërbim Windows që kryen shumë detyra të ndryshme sipas një orari. Së paku, duhet të kontrolloni nëse shërbimi po funksionon.
5. Detyra e agjentit
Nuk mjafton vetëm të dish që një agjent po punon. Një agjent mund të punojë, por të mos kryejë detyrat e caktuara. Le të ndajmë komponentin e agjentit në detyra dhe të kontrollojmë nëse çdo detyrë agjenti funksionon me sukses.
6. Pikat e kontrollit rrugor (kontejneri i të gjitha MPC-ve)
Ka shumë pika kontrolli rrugor, kështu që le të kombinojmë të gjitha MPC-të në një komponent. Kjo do ta bëjë më të përshtatshëm leximin e të dhënave të monitorimit. Kur shikoni statusin e komponentit "sistemi ASMO", do të jetë menjëherë e qartë se ku janë problemet: në aplikacione, harduer ose në sistemin e kontrollit maksimal.
7. Pika e kontrollit rrugor (një kufi maksimal)
Ne do ta konsiderojmë këtë komponent si të përdorshëm nëse të gjitha pajisjet në këtë MPC janë të përdorshme.
8. Pajisja
Kjo është një videokamerë ose stacion moti që është instaluar në kufirin maksimal të përqendrimit. Është e nevojshme të kontrolloni nëse pajisja po funksionon siç duhet.
Në sistemin e monitorimit, pema përbërëse do të duket kështu:
Monitorimi i aplikacioneve në ueb
Pra, ne e kemi ndarë sistemin në komponentë, tani duhet të dalim me kontrolle për secilin komponent.
Për të monitoruar një aplikacion në internet ne përdorim kontrollet e mëposhtme:
1. Kontrollimi i hapjes së faqes kryesore
Ky kontroll kryhet nga sistemi i monitorimit. Për ta ekzekutuar, ne tregojmë adresën e faqes, fragmentin e pritur të përgjigjes dhe kohën maksimale të ekzekutimit të kërkesës.
2. Kontrollimi i afatit të pagesës së domenit
Një kontroll shumë i rëndësishëm. Kur një domen mbetet i papaguar, përdoruesit nuk mund ta hapin faqen. Zgjidhja e problemit mund të zgjasë disa ditë, sepse... Ndryshimet në DNS nuk zbatohen menjëherë.
3. Kontrollimi i certifikatës SSL
Në ditët e sotme, pothuajse të gjitha faqet e internetit përdorin protokollin https për akses. Që protokolli të funksionojë siç duhet, ju nevojitet një certifikatë e vlefshme SSL.
Më poshtë është komponenti "Llogaria personale" në sistemin e monitorimit:
Të gjitha kontrollet e mësipërme do të funksionojnë për shumicën e aplikacioneve dhe nuk kërkojnë kodim. Kjo është shumë interesante sepse mund të filloni të monitoroni çdo aplikacion në ueb në 5 minuta. Më poshtë janë kontrollet shtesë që mund të kryhen për një aplikacion ueb, por zbatimi i tyre është më kompleks dhe më specifik për aplikacionin, kështu që ne nuk do t'i trajtojmë ato në këtë artikull.
Çfarë tjetër mund të kontrolloni?
Për të monitoruar më plotësisht aplikacionin tuaj të internetit, mund të kryeni kontrollet e mëposhtme:
- Numri i gabimeve në JavaScript për periudhë
- Numri i gabimeve në anën e aplikacionit në internet (back-end) për periudhën
- Numri i përgjigjeve të pasuksesshme të aplikacionit në ueb (kodi i përgjigjes 404, 500, etj.)
- Koha mesatare e ekzekutimit të pyetjes
Monitorimi i një shërbimi të Windows (agjent)
Në sistemin ASMO, agjenti luan rolin e një planifikuesi detyrash, i cili ekzekuton detyrat e planifikuara në sfond.
Nëse të gjitha detyrat e agjentit përfundojnë me sukses, agjenti po punon siç duhet. Rezulton se për të monitoruar një agjent, duhet të monitoroni detyrat e tij. Prandaj, ne e ndajmë komponentin "Agjent" në detyra. Për çdo detyrë, ne do të krijojmë një komponent të veçantë në sistemin e monitorimit, ku komponenti "Agjent" do të jetë "prindi".
Ne e ndajmë komponentin Agjent në komponentë fëmijë (detyra):
Pra, ne kemi ndarë një komponent kompleks në disa të thjeshta. Tani duhet të dalim me kontrolle për çdo komponent të thjeshtë. Ju lutemi, vini re se komponenti mëmë "Agjent" nuk do të ketë asnjë kontroll, sepse sistemi i monitorimit do të llogarisë statusin e tij në mënyrë të pavarur bazuar në statusin e komponentëve të tij fëmijë. Me fjalë të tjera, nëse të gjitha detyrat janë përfunduar me sukses, atëherë agjenti po funksionon me sukses.
Ka më shumë se njëqind detyra në sistemin ASMO, a është vërtet e nevojshme të krijohen kontrolle unike për secilën detyrë? Sigurisht, kontrolli do të jetë më i mirë nëse ne krijojmë dhe zbatojmë kontrollet tona të veçanta për çdo detyrë agjenti, por në shumicën e rasteve mjafton të përdorim kontrolle universale.
Sistemi ASMO përdor vetëm kontrolle universale për detyrat dhe kjo mjafton për të monitoruar performancën e sistemit.
Kontrollimi i progresit
Kontrolli më i thjeshtë dhe më efektiv është kontrolli i ekzekutimit. Kontrolli verifikon që detyra është kryer pa gabime. Të gjitha detyrat e kanë këtë kontroll.
Algoritmi i verifikimit
Pas çdo ekzekutimi të detyrës, duhet të dërgoni rezultatin e kontrollit SUCCESS në sistemin e monitorimit nëse ekzekutimi i detyrës ishte i suksesshëm, ose ERROR nëse ekzekutimi përfundoi me një gabim.
Ky kontroll mund të zbulojë problemet e mëposhtme:
- Detyra ekzekutohet por dështon me një gabim.
- Detyra ka ndaluar së funksionuari, për shembull, është ngrirë.
Le të shohim se si zgjidhen këto probleme në më shumë detaje.
Çështja 1 - Detyra funksionon por dështon me një gabim
Më poshtë është një rast kur detyra funksionon por dështon midis orës 14:00 dhe 16:00.
Figura tregon se kur një detyrë dështon, një sinjal dërgohet menjëherë në sistemin e monitorimit dhe statusi i kontrollit përkatës në sistemin e monitorimit bëhet alarm.
Ju lutemi vini re se në sistemin e monitorimit, statusi i komponentit varet nga statusi i verifikimit. Statusi i alarmit të kontrollit do t'i ndryshojë të gjithë komponentët e nivelit më të lartë në alarm, shihni figurën më poshtë.
Problemi 2 - Detyra ndaloi së ekzekutuari (i ngrirë)
Si do ta kuptojë sistemi i monitorimit që një detyrë ka ngecur?
Rezultati i kontrollit ka një periudhë vlefshmërie, për shembull, 1 orë. Nëse kalon një orë dhe nuk ka rezultat të ri të testit, sistemi i monitorimit do të vendosë statusin e testit në alarm.
Në foton e mësipërme, dritat janë fikur në orën 14:00. Në orën 15:00, sistemi i monitorimit do të zbulojë se rezultati i testit (nga ora 14:00) është i kalbur, sepse Koha e lidhjes ka skaduar (një orë), por nuk ka asnjë rezultat të ri dhe do ta kalojë kontrollin në statusin e alarmit.
Në orën 16:00 dritat u ndezën përsëri, programi do të përfundojë detyrën dhe do të dërgojë rezultatin e ekzekutimit në sistemin e monitorimit, statusi i testit do të bëhet përsëri sukses.
Çfarë kohe të lidhjes së kontrollit duhet të përdor?
Koha e lidhjes duhet të jetë më e madhe se periudha e ekzekutimit të detyrës. Unë rekomandoj të vendosni kohën e rëndësisë 2-3 herë më shumë se periudha e ekzekutimit të detyrës. Kjo është e nevojshme për të shmangur marrjen e njoftimeve të rreme kur, për shembull, një detyrë zgjati më shumë se zakonisht ose kur dikush rifreskoi programin.
Kontrollimi i progresit
Sistemi ASMO ka një detyrë "Parashikimi i Ngarkesës", i cili përpiqet të shkarkojë një parashikim të ri nga një burim i jashtëm një herë në orë. Koha e saktë kur shfaqet një parashikim i ri në sistemin e jashtëm nuk dihet, por dihet se kjo ndodh 2 herë në ditë. Rezulton se nëse nuk ka parashikim të ri për disa orë, atëherë kjo është normale, por nëse nuk ka parashikim të ri për më shumë se një ditë, atëherë diçka ka prishur diku. Për shembull, formati i të dhënave në një sistem parashikimi të jashtëm mund të ndryshojë, prandaj ASMO nuk do të shohë një version të ri të parashikimit.
Algoritmi i verifikimit
Detyra dërgon rezultatin e kontrollit të SUKSES në sistemin e monitorimit kur ai arrin të bëjë përparim (shkarkimi i një parashikimi të ri të motit). Nëse nuk ka përparim ose ndodh një gabim, atëherë asgjë nuk dërgohet në sistemin e monitorimit.
Kontrolli duhet të ketë një interval relevance të tillë që gjatë kësaj kohe të garantohet të marrë përparim të ri.
Ju lutemi vini re se do të mësojmë për problemin me vonesë, sepse sistemi i monitorimit pret derisa të skadojë periudha e vlefshmërisë së rezultatit të skanimit të fundit. Prandaj, periudha e vlefshmërisë së çekut nuk ka nevojë të zgjatet shumë.
Monitorimi i bazës së të dhënave
Për të kontrolluar bazën e të dhënave në sistemin ASMO, ne kryejmë kontrollet e mëposhtme:
- Po verifikon krijimin e rezervës
- Kontrollimi i hapësirës së lirë të diskut
Po verifikon krijimin e rezervës
Në shumicën e aplikacioneve, është e rëndësishme të keni kopje rezervë të përditësuar të bazës së të dhënave, në mënyrë që nëse serveri dështon, mund ta vendosni programin në një server të ri.
ASMO krijon një kopje rezervë një herë në javë dhe e dërgon atë në ruajtje. Kur kjo procedurë të përfundojë me sukses, rezultati i kontrollit të suksesit i dërgohet sistemit të monitorimit. Rezultati i verifikimit është i vlefshëm për 9 ditë. ato. Për të kontrolluar krijimin e kopjeve rezervë, përdoret mekanizmi i "kontrollit të progresit", të cilin e diskutuam më lart.
Kontrollimi i hapësirës së lirë të diskut
Nëse nuk ka hapësirë të mjaftueshme të lirë në disk, baza e të dhënave nuk do të jetë në gjendje të funksionojë siç duhet, prandaj është e rëndësishme të kontrolloni sasinë e hapësirës së lirë.
Është i përshtatshëm për të përdorur metrikë për të kontrolluar parametrat numerikë.
Metrikat është një ndryshore numerike, vlera e së cilës transmetohet në sistemin e monitorimit. Sistemi i monitorimit kontrollon vlerat e pragut dhe llogarit statusin metrikë.
Më poshtë është një fotografi e asaj se si duket komponenti "Baza e të dhënave" në sistemin e monitorimit:
Monitorimi i serverit
Për të monitoruar serverin ne përdorim kontrollet dhe matjet e mëposhtme:
1. Hapësirë e lirë në disk
Nëse hapësira e diskut mbaron, aplikacioni nuk do të mund të funksionojë. Ne përdorim 2 vlera pragu: niveli i parë është PARALAJMËRIMI, niveli i dytë është ALARM.
2. Vlera mesatare e RAM-it në përqindje në orë
Ne përdorim mesataren për orë sepse... ne nuk jemi të interesuar për racat e rralla.
3. Përqindja mesatare e CPU në orë
Ne përdorim mesataren për orë sepse... ne nuk jemi të interesuar për racat e rralla.
4. Kontrollo ping
Kontrollon që serveri të jetë në linjë. Sistemi i monitorimit mund ta kryejë këtë kontroll, nuk ka nevojë të shkruhet kodi.
Më poshtë është një fotografi e asaj se si duket komponenti "Server" në sistemin e monitorimit:
Monitorimi i pajisjeve
Unë do t'ju tregoj se si merren të dhënat. Për çdo pikë kontrolli rrugor (MPC) ka një detyrë në planifikuesin e detyrave, për shembull, "Anketa MPC M2 km 200". Detyra merr të dhëna nga të gjitha pajisjet MPC çdo 30 minuta.
Problemi i kanalit të komunikimit
Shumica e pajisjeve janë të vendosura jashtë qytetit për transmetimin e të dhënave përdoret një rrjet GSM, i cili nuk funksionon në mënyrë të qëndrueshme (ka një rrjet ose nuk ka një të tillë).
Për shkak të dështimeve të shpeshta të rrjetit, fillimisht kontrollimi i anketës MPC në monitorim dukej kështu:
U bë e qartë se ky nuk ishte një opsion funksional, sepse kishte shumë njoftime të rreme për probleme. Më pas u vendos që të përdoret një “kontroll progresi” për secilën pajisje, d.m.th. Vetëm sinjali i suksesit dërgohet në sistemin e monitorimit kur pajisja anketohet pa gabim. Koha përkatëse u caktua në 5 orë.
Tani monitorimi dërgon njoftime për problemet vetëm kur pajisja nuk mund të anketohet për më shumë se 5 orë. Me një shkallë të lartë probabiliteti, këto nuk janë alarme false, por probleme reale.
Më poshtë është një fotografi se si duken pajisjet në sistemin e monitorimit:
Rëndësishme!
Kur rrjeti GSM ndalon së punuari, të gjitha pajisjet MDC nuk anketohen. Për të reduktuar numrin e emaileve nga sistemi i monitorimit, inxhinierët tanë abonohen në njoftimet për problemet e komponentëve me llojin "MPC" dhe jo "Pajisje". Kjo ju lejon të merrni një njoftim për çdo MPC, në vend që të merrni një njoftim të veçantë për secilën pajisje.
Skema përfundimtare e monitorimit ASMO
Le të bashkojmë gjithçka dhe të shohim se çfarë skeme monitorimi kemi.
Përfundim
Le të përmbledhim.
Çfarë na dha monitorimi i performancës së ASMO?
1. Koha e eliminimit të defektit është ulur
Ne kemi dëgjuar më parë për defekte nga përdoruesit, por jo të gjithë përdoruesit raportojnë defekte. Ndodhi që mësuam për një mosfunksionim të një komponenti të sistemit një javë pasi u shfaq. Tani sistemi i monitorimit na njofton për problemet sapo zbulohet një problem.
2. Stabiliteti i sistemit është rritur
Meqenëse defektet filluan të eliminohen më herët, sistemi në tërësi filloi të funksionojë shumë më i qëndrueshëm.
3. Reduktimi i numrit të thirrjeve për mbështetjen teknike
Shumë probleme tani janë rregulluar para se përdoruesit të dinë për to. Përdoruesit filluan të kontaktojnë mbështetjen teknike më rrallë. E gjithë kjo ka një efekt të mirë në reputacionin tonë.
4. Rritja e besnikërisë së klientit dhe përdoruesit
Klienti vuri re ndryshime pozitive në stabilitetin e sistemit. Përdoruesit hasin më pak probleme duke përdorur sistemin.
5. Ulja e kostove të mbështetjes teknike
Ne kemi ndaluar kryerjen e çdo kontrolli manual. Tani të gjitha kontrollet janë të automatizuara. Më parë, ne mësuam për problemet nga përdoruesit, shpesh ishte e vështirë të kuptonim se për çfarë problemi po fliste përdoruesi. Tani, shumica e problemeve raportohen nga sistemi i monitorimit, që përmbajnë të dhëna teknike, të cilat gjithmonë e bëjnë të qartë se çfarë shkoi keq dhe ku.
Rëndësishme!
Nuk mund ta instaloni sistemin e monitorimit në të njëjtin server ku ekzekutohen aplikacionet tuaja. Nëse serveri bie, aplikacionet do të ndalojnë së punuari dhe nuk do të ketë njeri që të njoftojë për këtë.
Sistemi i monitorimit duhet të funksionojë në një server të veçantë në një qendër tjetër të dhënash.
Nëse nuk dëshironi të përdorni një server të dedikuar në një qendër të re të dhënash, mund të përdorni një sistem monitorimi cloud. Kompania jonë përdor sistemin e monitorimit të resë kompjuterike Zidium, por ju mund të përdorni çdo sistem tjetër monitorimi. Kostoja e një sistemi monitorimi cloud është më e ulët se marrja me qira e një serveri të ri.
Rekomandime:
- Zbërtheni aplikacionet dhe sistemet në formën e një peme të komponentëve në sa më shumë detaje që të jetë e mundur, kështu që do të jetë e përshtatshme për të kuptuar se ku dhe çfarë është prishur, dhe kontrolli do të jetë më i plotë.
- Për të kontrolluar funksionalitetin e një komponenti, përdorni teste. Është më mirë të përdorni shumë kontrolle të thjeshta sesa një të ndërlikuar.
- Konfiguroni pragjet metrike në anën e sistemit të monitorimit, në vend që t'i shkruani ato në kod. Kjo do t'ju shpëtojë nga nevoja për të ripërpiluar, rikonfiguruar ose rifilluar aplikacionin.
- Për kontrollet e personalizuara, përdorni një diferencë të kohës së relevancës për të shmangur marrjen e njoftimeve të rreme sepse disa kontrolleve iu deshën pak më shumë se zakonisht për t'u kryer.
- Përpiquni që komponentët në sistemin e monitorimit të kthehen në të kuqe vetëm kur ka patjetër një problem. Nëse ato bëhen të kuqe për asgjë, atëherë do të ndaloni t'i kushtoni vëmendje njoftimeve të sistemit të monitorimit, kuptimi i tij do të humbasë.
Nëse nuk po përdorni ende një sistem monitorimi, filloni! Nuk është aq e vështirë sa duket. Hiqni dorë nga shikimi i pemës së përbërësve të gjelbër që e rritët vetë.
Fat të mirë.
Burimi: www.habr.com