Tere kõigile!
Meie ettevõte tegeleb tarkvaraarenduse ja sellele järgneva tehnilise toega. Tehniline tugi ei nõua ainult vigade parandamist, vaid ka meie rakenduste toimivuse jälgimist.
Näiteks kui üks teenustest jookseb kokku, peate selle probleemi automaatselt salvestama ja hakkama seda lahendama, mitte ootama, kuni rahulolematud kasutajad võtavad ühendust tehnilise toega.
Meil on väike ettevõte, meil pole ressursse rakenduste monitooringu keerukate lahenduste uurimiseks ja hooldamiseks, tuli leida lihtne ja tõhus lahendus.
Seirestrateegia
Rakenduse funktsionaalsust pole lihtne kontrollida, see ülesanne on mittetriviaalne, võib isegi öelda, et loominguline. Eriti keeruline on kontrollida keerukat mitmelülilist süsteemi.
Kuidas saab elevanti süüa? Ainult osadena! Kasutame seda lähenemist rakenduste jälgimiseks.
Meie seirestrateegia olemus:
Jagage oma rakendus komponentideks.
Looge iga komponendi jaoks kontrollkontrollid.
Komponent loetakse töökorras, kui kõik selle kontrollkontrollid on tehtud vigadeta. Rakendus loetakse tervislikuks, kui kõik selle komponendid on töökorras.
Seega saab mis tahes süsteemi esitada komponentide puuna. Komplekssed komponendid jaotatakse lihtsamateks. Lihtsatel komponentidel on kontroll.
Võrdlusuuringud ei ole mõeldud funktsionaalse testimise läbiviimiseks, need ei ole ühikutestid. Kontrollkontrollid peaksid kontrollima, kuidas komponent praegusel ajahetkel tunneb, kas kõik selle toimimiseks vajalikud ressursid on olemas ja kas pole probleeme.
Imesid pole, enamik kontrolle tuleb välja töötada iseseisvalt. Kuid ärge kartke, sest enamasti kulub ühele kontrollile 5-10 koodirida, kuid saate rakendada mis tahes loogikat ja saate selgelt aru, kuidas kontroll töötab.
Järelevalvesüsteem
Oletame, et jagasime rakenduse komponentideks, mõtlesime välja ja rakendasime iga komponendi kontrollid, kuid mida teha nende kontrollide tulemustega? Kuidas me teame, kas mõni kontroll ebaõnnestus?
Meil on vaja seiresüsteemi. Ta täidab järgmisi ülesandeid:
- Saate testitulemusi ja kasutada neid komponentide oleku määramiseks.
Visuaalselt näeb see välja nagu komponendipuu esiletõstmine. Funktsionaalsed komponendid muutuvad roheliseks, probleemsed punaseks. - Tehke üldised kontrollid karbist välja.
Järelevalvesüsteem võib mõningaid kontrolle ise teha. Miks ratast uuesti leiutada, kasutame neid. Näiteks saate kontrollida, kas veebisaidi leht avaneb või server pingib. - Saatke huvitatud isikutele teateid probleemidest.
- Seireandmete visualiseerimine, aruannete, graafikute ja statistika esitamine.
ASMO süsteemi lühikirjeldus
Parim on selgitada näitega. Vaatame, kuidas on korraldatud ASMO süsteemi jõudluse jälgimine.
ASMO on automatiseeritud meteoroloogiline tugisüsteem. Süsteem aitab teeteeninduse spetsialistidel aru saada, kus ja millal on vaja teed libedusetõrjematerjalidega töödelda. Süsteem kogub andmeid teekontrollipunktidest. Teejuhtimispunkt on koht teel, kuhu on paigaldatud tehnika: ilmajaam, videokaamera jne. Ohtlike olukordade ennustamiseks saab süsteem ilmateateid välistest allikatest.
Seega on süsteemi koostis üsna tüüpiline: veebisait, agent, seadmed. Hakkame jälgima.
Süsteemi jagamine komponentideks
ASMO süsteemis saab eristada järgmisi komponente:
1. Isiklik konto
See on veebirakendus. Vähemalt peate kontrollima, kas rakendus on Internetis saadaval.
2. Andmebaas
Andmebaas salvestab aruandluse jaoks olulised andmed ja peate tagama andmebaasi varukoopiate eduka loomise.
3. Server
Serveri all peame silmas riistvara, millel rakendused töötavad. On vaja kontrollida HDD, RAM, CPU olekut.
4. Agent
See on Windowsi teenus, mis täidab ajakava alusel palju erinevaid ülesandeid. Vähemalt peate kontrollima, kas teenus töötab.
5. Agendi ülesanne
Ainult teadmisest, et agent töötab, ei piisa. Agent võib töötada, kuid mitte täita talle määratud ülesandeid. Jagame agendikomponendi ülesanneteks ja kontrollime, kas iga agendiülesanne töötab edukalt.
6. Teejuhtimispunktid (kõikide MPC-de konteiner)
Teejuhtimispunkte on palju, nii et ühendame kõik MPC-d ühte komponenti. See muudab seireandmete lugemise mugavamaks. ASMO süsteemi komponendi olekut vaadates on kohe selge, kus on probleemid: rakendustes, riistvaras või maksimaalses juhtimissüsteemis.
7. Maantee kontrollpunkt (üks maksimumpiirang)
Peame seda komponenti hooldatavaks, kui kõik selle MPC seadmed on hooldatavad.
8. Seade
See on videokaamera või ilmajaam, mis on paigaldatud maksimaalse kontsentratsiooni piirile. On vaja kontrollida, kas seade töötab korralikult.
Seiresüsteemis näeb komponentide puu välja järgmine:
Veebirakenduste jälgimine
Niisiis, oleme jaganud süsteemi komponentideks, nüüd peame iga komponendi jaoks kontrollima.
Veebirakenduse jälgimiseks kasutame järgmisi kontrolle:
1. Pealehe avamise kontrollimine
Selle kontrolli teostab seiresüsteem. Selle täitmiseks märgime lehe aadressi, oodatava vastuse fragmendi ja päringu maksimaalse täitmise aja.
2. Domeeni maksetähtaja kontrollimine
Väga oluline kontroll. Kui domeen jääb tasumata, ei saa kasutajad saiti avada. Probleemi lahendamine võib võtta mitu päeva, sest... DNS-i muudatusi ei rakendata kohe.
3. SSL-sertifikaadi kontrollimine
Tänapäeval kasutavad peaaegu kõik veebisaidid juurdepääsuks https-protokolli. Protokolli korrektseks tööks on vaja kehtivat SSL-sertifikaati.
Allpool on seiresüsteemi komponent "Isiklik konto".
Kõik ülaltoodud kontrollid töötavad enamiku rakenduste puhul ega vaja kodeerimist. See on väga lahe, sest saate 5 minutiga alustada mis tahes veebirakenduse jälgimist. Allpool on toodud täiendavad kontrollid, mida saab veebirakenduse jaoks teha, kuid nende rakendamine on keerulisem ja rakendusespetsiifilisem, mistõttu me neid selles artiklis ei käsitle.
Mida saab veel kontrollida?
Veebirakenduse täielikumaks jälgimiseks saate teha järgmisi kontrolle.
- JavaScripti vigade arv perioodi kohta
- Vigade arv veebirakenduse poolel (tagaosa) perioodil
- Ebaõnnestunud veebirakenduste vastuste arv (vastusekood 404, 500 jne)
- Keskmine päringu täitmise aeg
Windowsi teenuse jälgimine (agent)
ASMO süsteemis täidab agent tegumiplaneerija rolli, mis täidab plaanitud ülesandeid taustal.
Kui kõik agendi ülesanded on edukalt lõpule viidud, töötab agent korralikult. Selgub, et agendi jälgimiseks peate jälgima tema ülesandeid. Seetõttu jagame komponendi “Agent” ülesanneteks. Iga ülesande jaoks loome seiresüsteemis eraldi komponendi, kus komponendiks “Agent” saab “vanem”.
Jagame agendi komponendi alamkomponentideks (ülesanneteks):
Niisiis, oleme jaotanud keeruka komponendi mitmeks lihtsaks. Nüüd peame iga lihtsa komponendi jaoks kontrollima. Pange tähele, et ülemkomponendil "Agent" ei ole kontrolle, kuna seiresüsteem arvutab selle oleku iseseisvalt alamkomponentide oleku alusel. Teisisõnu, kui kõik toimingud on edukalt lõpule viidud, töötab agent edukalt.
ASMO süsteemis on üle saja ülesande, kas tõesti on vaja iga ülesande jaoks välja mõelda unikaalsed kontrollid? Loomulikult on kontroll parem, kui mõtleme välja ja rakendame iga agendiülesande jaoks oma spetsiaalsed kontrollid, kuid enamikul juhtudel piisab universaalsete kontrollide kasutamisest.
ASMO süsteem kasutab ülesannete jaoks ainult universaalseid kontrolle ja sellest piisab süsteemi toimimise jälgimiseks.
Edenemise kontrollimine
Lihtsaim ja tõhusaim kontroll on täitmise kontroll. Kontroll kinnitab, et ülesanne on tehtud vigadeta. Kõigil ülesannetel on see kontroll.
Kontrollimise algoritm
Pärast iga ülesande täitmist peate saatma seiresüsteemile EDU kontrolli tulemuse, kui ülesande täitmine oli edukas, või ERROR, kui täitmine lõppes veaga.
See kontroll võib tuvastada järgmised probleemid:
- Ülesanne töötab, kuid ebaõnnestub vea tõttu.
- Ülesande jooksmine on peatunud, näiteks külmunud.
Vaatame üksikasjalikumalt, kuidas need probleemid lahendatakse.
Probleem 1 – ülesanne töötab, kuid ebaõnnestub vea tõttu
Allpool on näide, kus ülesanne jookseb, kuid ebaõnnestub ajavahemikus 14–00.
Joonisel on näha, et ülesande ebaõnnestumisel saadetakse koheselt seiresüsteemi signaal ja vastava kontrolli olek seiresüsteemis muutub häireks.
Pange tähele, et seiresüsteemis sõltub komponendi olek verifitseerimise olekust. Kontrolli häire olek muudab kõik kõrgema taseme komponendid häireks, vt allolevat joonist.
Probleem 2 – ülesande täitmine peatus (külmutatud)
Kuidas saab seiresüsteem aru, et ülesanne on takerdunud?
Kontrolli tulemusel on kehtivusaeg, näiteks 1 tund. Kui möödub tund ja uut testitulemust pole, seab seiresüsteem testi olekuks häire.
Ülaloleval pildil kustutati tuled kell 14. Kell 00:15 tuvastab seiresüsteem, et testi tulemus (alates 00:14) on mäda, kuna Asjakohasusaeg on möödas (üks tund), kuid uut tulemust pole ja see lülitab kontrolli häireolekusse.
Kell 16:00 lülitatakse tuled uuesti sisse, programm täidab ülesande ja saadab täitmistulemuse seiresüsteemi, testi olek muutub taas edukaks.
Millist kontrolli asjakohasuse aega peaksin kasutama?
Asjakohasusaeg peab olema pikem kui ülesande täitmise periood. Soovitan määrata asjakohasuse aja 2-3 korda pikemaks kui ülesande täitmise periood. See on vajalik selleks, et vältida valeteadete saamist, kui mõni ülesanne võttis näiteks tavapärasest kauem aega või keegi laadis programmi uuesti.
Edenemise kontrollimine
ASMO süsteemil on ülesanne “Load Forecast”, mis proovib kord tunnis uue prognoosi välisest allikast alla laadida. Täpne aeg, millal uus prognoos välissüsteemis ilmub, pole teada, kuid teadaolevalt juhtub seda 2 korda päevas. Selgub, et kui mitu tundi uut prognoosi pole, siis see on normaalne, aga kui üle päeva uut prognoosi pole, siis on kuskil midagi katki läinud. Näiteks võib välise prognoosisüsteemi andmevorming muutuda, mistõttu ASMO uut prognoosiväljaannet ei näe.
Kontrollimise algoritm
Ülesanne saadab edenemise (uue ilmaprognoosi allalaadimise) õnnestumisel EDU kontrolli tulemuse seiresüsteemi. Kui edenemist ei toimu või ilmneb tõrge, ei saadeta seiresüsteemi midagi.
Kontrollimisel peab olema selline asjakohasuse intervall, et selle aja jooksul oleks tagatud uute edusammude saamine.
Pange tähele, et saame probleemist teada viivitusega, sest seiresüsteem ootab kuni viimase skannimise tulemuse kehtivusaeg läbi saab. Seetõttu ei pea tšeki kehtivusaega liiga pikaks muutma.
Andmebaasi monitooring
Andmebaasi juhtimiseks ASMO süsteemis teostame järgmised kontrollid:
- Varukoopia loomise kontrollimine
- Vaba kettaruumi kontrollimine
Varukoopia loomise kontrollimine
Enamiku rakenduste puhul on oluline, et andmebaasi varukoopiad oleksid ajakohased, et kui server ebaõnnestub, saate programmi uude serverisse juurutada.
ASMO loob kord nädalas varukoopia ja saadab selle salvestusruumi. Kui see protseduur on edukalt lõpule viidud, saadetakse edukuse kontrolli tulemus seiresüsteemi. Kontrolli tulemus kehtib 9 päeva. Need. Varukoopiate loomise kontrollimiseks kasutatakse "edenemise kontrolli" mehhanismi, millest me eespool rääkisime.
Vaba kettaruumi kontrollimine
Kui kettal pole piisavalt vaba ruumi, ei saa andmebaas korralikult töötada, mistõttu on oluline kontrollida vaba ruumi hulka.
Numbriliste parameetrite kontrollimiseks on mugav kasutada mõõdikuid.
Mõõdikud on numbriline muutuja, mille väärtus edastatakse seiresüsteemi. Seiresüsteem kontrollib läviväärtusi ja arvutab mõõdiku oleku.
Allpool on pilt sellest, kuidas seiresüsteemis komponent “Andmebaas” välja näeb:
Serveri jälgimine
Serveri jälgimiseks kasutame järgmisi kontrolle ja mõõdikuid:
1. Vaba kettaruumi
Kui kettaruum saab otsa, ei saa rakendus töötada. Kasutame 2 läviväärtust: esimene tase on HOIATUS, teine tase on ALARM.
2. Keskmine RAM-i väärtus protsentides tunnis
Kasutame tunni keskmist, sest... meid ei huvita haruldased võistlused.
3. Keskmine protsessori protsent tunnis
Kasutame tunni keskmist, sest... meid ei huvita haruldased võistlused.
4. Ping kontroll
Kontrollib, kas server on võrgus. Seiresüsteem saab seda kontrolli teha, koodi pole vaja kirjutada.
Allpool on pilt sellest, kuidas komponent “Server” jälgimissüsteemis välja näeb:
Seadmete jälgimine
Ma räägin teile, kuidas andmeid saadakse. Iga teejuhtimispunkti (MPC) kohta on ülesannete planeerijas ülesanne, näiteks “Uuring MPC M2 km 200”. Ülesanne saab andmeid kõikidelt MPC seadmetelt iga 30 minuti järel.
Sidekanali probleem
Enamus seadmeid asub linnast väljas, andmeedastuseks kasutatakse GSM võrku, mis ei tööta stabiilselt (võrk on või ei ole).
Sagedaste võrgutõrgete tõttu nägi MPC uuringu kontrollimine monitooringus esmalt välja järgmine:
Selgus, et see ei ole toimiv variant, sest probleemide kohta saadeti palju valeteateid. Seejärel otsustati iga seadme puhul kasutada “edenemise kontrolli”, st. Seadme tõrketa pollimisel saadetakse jälgimissüsteemi ainult edusignaal. Asjakohasuse ajaks määrati 5 tundi.
Nüüd saadab monitooring probleemide kohta teateid ainult siis, kui seadet ei saa enam kui 5 tundi pollida. Suure tõenäosusega pole tegemist valehäiretega, vaid tõeliste probleemidega.
Allpool on pilt sellest, kuidas seadmed seiresüsteemis välja näevad:
Tähtis!
Kui GSM-võrk lakkab töötamast, ei küsita kõiki MDC-seadmeid. Järelevalvesüsteemist saadetavate meilide arvu vähendamiseks tellivad meie insenerid teatised komponentide probleemide kohta, mille tüüp on „MPC”, mitte „Seade”. See võimaldab teil saada iga MPC kohta ühe teatise, selle asemel et saada iga seadme kohta eraldi teatist.
ASMO lõplik seireskeem
Paneme kõik kokku ja vaatame, milline seireskeem meil on.
Järeldus
Teeme kokkuvõtte.
Mida andis meile ASMO tegevuse jälgimine?
1. Defektide kõrvaldamise aeg on vähenenud
Oleme varem kuulnud kasutajatelt defektidest, kuid mitte kõik kasutajad ei teata defektidest. Juhtus, et saime süsteemikomponendi rikkest teada nädal pärast selle ilmnemist. Nüüd teavitab seiresüsteem meid probleemidest kohe, kui probleem avastatakse.
2. Süsteemi stabiilsus on suurenenud
Kuna defekte hakati likvideerima varem, hakkas süsteem tervikuna palju stabiilsemalt töötama.
3. Tehnilise toe kõnede arvu vähendamine
Paljud probleemid on nüüd lahendatud enne, kui kasutajad neist üldse teada saavad. Kasutajad hakkasid tehnilise toega harvemini ühendust võtma. See kõik mõjub meie mainele hästi.
4. Klientide ja kasutajate lojaalsuse suurendamine
Klient märkas positiivseid muutusi süsteemi stabiilsuses. Kasutajad kogevad süsteemi kasutamisel vähem probleeme.
5. Vähendage tehnilise toe kulusid
Oleme lõpetanud mis tahes käsitsi kontrollimise. Nüüd on kõik kontrollid automatiseeritud. Varem saime probleemidest teada kasutajatelt, sageli oli raske aru saada, mis probleemist kasutaja rääkis. Nüüd teatab enamikest probleemidest seiresüsteem, teated sisaldavad tehnilisi andmeid, millest saab alati selgeks, mis ja kus valesti läks.
Tähtis!
Järelevalvesüsteemi ei saa installida samasse serverisse, kus teie rakendused töötavad. Kui server läheb alla, lakkavad rakendused töötamast ja pole kedagi, kes sellest teavitaks.
Jälgimissüsteem peab töötama teises andmekeskuses eraldi serveris.
Kui te ei soovi uues andmekeskuses spetsiaalset serverit kasutada, võite kasutada pilveseiresüsteemi. Meie ettevõttes on kasutusel Zidium pilveseiresüsteem, kuid sina võid kasutada mis tahes muud seiresüsteemi. Pilveseiresüsteemi maksumus on madalam kui uue serveri rentimine.
Soovitused:
- Jaotage rakendused ja süsteemid komponentide puu kujul võimalikult üksikasjalikult lahti, et oleks mugav aru saada, kus ja mis on katki, ning juhtimine on täielikum.
- Komponendi funktsionaalsuse kontrollimiseks kasutage teste. Parem on kasutada palju lihtsaid kontrolle kui ühte keerulist.
- Konfigureerige meetrilised läved jälgimissüsteemi küljel, selle asemel, et neid koodi kirjutada. See säästab teid rakenduse uuesti kompileerimise, ümberkonfigureerimise või taaskäivitamise eest.
- Kohandatud kontrollide puhul kasutage valeteadete saamise vältimiseks asjakohasuse varu, kuna mõne kontrolli sooritamine võttis tavapärasest veidi kauem aega.
- Proovige panna seiresüsteemi komponendid punaseks ainult siis, kui probleem on kindlasti olemas. Kui need muutuvad asjata punaseks, siis lõpetate jälgimissüsteemi teadetele tähelepanu pööramise, selle tähendus kaob.
Kui te veel seiresüsteemi ei kasuta, alustage! See pole nii raske, kui tundub. Nautige seda rohelist koostisosade puud, mille olete ise kasvatanud.
Õnn kaasa.
Allikas: www.habr.com