Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Sveiki visiem!

MÅ«su uzņēmums nodarbojas ar programmatÅ«ras izstrādi un tai sekojoÅ”o tehnisko atbalstu. Tehniskajam atbalstam ir nepiecieÅ”ams ne tikai labot kļūdas, bet arÄ« uzraudzÄ«t mÅ«su lietojumprogrammu veiktspēju.

Piemēram, ja kāds no pakalpojumiem ir avarējis, Ŕī problēma ir automātiski jāreÄ£istrē un jāsāk to risināt, nevis jāgaida, lÄ«dz neapmierinātie lietotāji sazināsies ar tehnisko atbalstu.

Mums ir mazs uzņēmums, mums nav resursu, lai izpētÄ«tu un uzturētu sarežģītus risinājumus lietojumprogrammu uzraudzÄ«bai, mums bija jāatrod vienkārÅ”s un efektÄ«vs risinājums.

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Uzraudzības stratēģija

Nav viegli pārbaudÄ«t lietojumprogrammas funkcionalitāti, Å”is uzdevums nav triviāls, varētu pat teikt, ka radoÅ”s. ÄŖpaÅ”i grÅ«ti ir pārbaudÄ«t sarežģītu vairāku saiÅ”u sistēmu.

Kā jÅ«s varat ēst ziloni? Tikai pa daļām! Mēs izmantojam Å”o pieeju, lai uzraudzÄ«tu lietojumprogrammas.

Mūsu uzraudzības stratēģijas būtība:

Sadaliet savu pieteikumu komponentos.
Izveidojiet kontroles pārbaudes katram komponentam.

Komponents tiek uzskatÄ«ts par funkcionējoÅ”u, ja visas tās kontroles pārbaudes tiek veiktas bez kļūdām. Lietojumprogramma tiek uzskatÄ«ta par veselÄ«gu, ja visas tās sastāvdaļas darbojas.

Tādējādi jebkuru sistēmu var attēlot kā komponentu koku. Sarežģītās sastāvdaļas tiek sadalÄ«tas vienkārŔākos. VienkārŔām sastāvdaļām ir pārbaudes.

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Etaloni nav paredzēti funkcionālās pārbaudes veikÅ”anai, tie nav vienÄ«bas testi. Kontrolpārbaudēs jāpārbauda, ā€‹ā€‹kā komponents jÅ«tas konkrētajā laika brÄ«dÄ«, vai ir visi tā darbÄ«bai nepiecieÅ”amie resursi un vai nav problēmu.

Brīnumu nav, lielākā daļa pārbaužu būs jāizstrādā neatkarīgi. Bet nebaidieties, jo vairumā gadījumu viena pārbaude aizņem 5-10 koda rindiņas, taču jūs varat ieviest jebkuru loģiku un skaidri sapratīsit, kā čeks darbojas.

Uzraudzības sistēma

Pieņemsim, ka mēs sadalÄ«jām lietojumprogrammu komponentos, izdomājām un ieviesām katra komponenta pārbaudes, bet ko darÄ«t ar Å”o pārbaužu rezultātiem? Kā mēs zinām, vai kāda pārbaude neizdevās?

Mums bÅ«s nepiecieÅ”ama uzraudzÄ«bas sistēma. Viņa veiks Ŕādus uzdevumus:

  • Saņemiet testa rezultātus un izmantojiet tos, lai noteiktu komponentu statusu.
    Vizuāli tas izskatās kā komponentu koka izcelŔana. Funkcionālās sastāvdaļas kļūst zaļas, problemātiskās - sarkanas.
  • Veiciet vispārÄ«gas pārbaudes ārpus kastes.
    Uzraudzības sistēma pati var veikt dažas pārbaudes. Kāpēc no jauna izgudrot riteni, izmantosim tos. Piemēram, varat pārbaudīt, vai tiek atvērta vietnes lapa vai serveris veic ping.
  • NosÅ«tiet paziņojumus par problēmām ieinteresētajām pusēm.
  • Monitoringa datu vizualizācija, atskaiÅ”u, grafiku un statistikas nodroÅ”ināŔana.

ASMO sistēmas īss apraksts

Vislabāk ir izskaidrot ar piemēru. Apskatīsim, kā tiek organizēta ASMO sistēmas darbības uzraudzība.

ASMO ir automatizēta meteoroloÄ£iskā atbalsta sistēma. Sistēma palÄ«dz ceļu dienesta speciālistiem saprast, kur un kad nepiecieÅ”ams ceļu apstrādāt ar atledoÅ”anas materiāliem. Sistēma apkopo datus no ceļu kontroles punktiem. Ceļu kontroles punkts ir vieta uz ceļa, kur uzstādÄ«ts aprÄ«kojums: meteoroloÄ£iskā stacija, videokamera u.c. Lai prognozētu bÄ«stamas situācijas, sistēma saņem laika prognozes no ārējiem avotiem.

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Tātad sistēmas sastāvs ir diezgan tipisks: vietne, aģents, aprīkojums. Sāksim uzraudzību.

Sistēmas sadalÄ«Å”ana komponentos

ASMO sistēmā var atŔķirt Ŕādus komponentus:

1. Personīgais konts
Å Ä« ir tÄ«mekļa lietojumprogramma. Jums vismaz jāpārbauda, ā€‹ā€‹vai lietojumprogramma ir pieejama internetā.

2. Datu bāze
Datu bāzē tiek glabāti dati, kas ir svarÄ«gi pārskatu veidoÅ”anai, un jums ir jānodroÅ”ina, lai datu bāzes dublējumkopijas tiktu izveidotas veiksmÄ«gi.

3. Serveris
Ar serveri mēs domājam aparatÅ«ru, kurā darbojas lietojumprogrammas. NepiecieÅ”ams pārbaudÄ«t HDD, RAM, CPU statusu.

4. AÄ£ents
Å is ir Windows pakalpojums, kas pēc grafika veic daudz dažādu uzdevumu. Vismaz jums ir jāpārbauda, ā€‹ā€‹vai pakalpojums darbojas.

5. AÄ£enta uzdevums
Nepietiek tikai ar apziņu, ka aģents strādā. Aģents var strādāt, bet nepildīt viņam uzticētos uzdevumus. Sadalīsim aģenta komponentu uzdevumos un pārbaudīsim, vai katrs aģenta uzdevums darbojas veiksmīgi.

6. Ceļu kontroles punkti (visu MPC konteiners)
Ir daudz ceļu kontroles punktu, tāpēc apvienosim visus MPC vienā komponentā. Tādējādi bÅ«s ērtāk nolasÄ«t monitoringa datus. Apskatot ā€œASMO sistēmasā€ komponenta statusu, uzreiz bÅ«s skaidrs, kur ir problēmas: lietojumprogrammās, aparatÅ«rā vai maksimālās vadÄ«bas sistēmā.

7. Ceļa kontroles punkts (viens maksimālais ierobežojums)
Mēs uzskatÄ«sim, ka Å”is komponents ir izmantojams, ja visas ierÄ«ces Å”ajā MPC ir apkalpojamas.

8. Ierīce
Šī ir videokamera vai meteoroloģiskā stacija, kas uzstādīta pie maksimālās koncentrācijas robežas. Ir nepiecieŔams pārbaudīt, vai ierīce darbojas pareizi.

UzraudzÄ«bas sistēmā komponentu koks izskatÄ«sies Ŕādi:

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Tīmekļa lietojumprogrammu uzraudzība

Tātad, mēs esam sadalÄ«juÅ”i sistēmu komponentos, tagad mums ir jānāk klajā ar katra komponenta pārbaudes.

Lai pārraudzÄ«tu tÄ«mekļa lietojumprogrammu, mēs izmantojam Ŕādas pārbaudes:

1. Galvenās lapas atvērÅ”anas pārbaude
Šo pārbaudi veic uzraudzības sistēma. Lai to izpildītu, mēs norādām lapas adresi, paredzamo atbildes fragmentu un maksimālo pieprasījuma izpildes laiku.

2. Domēna apmaksas termiņa pārbaude
Ä»oti svarÄ«ga pārbaude. Ja domēns paliek neapmaksāts, lietotāji nevar atvērt vietni. Problēmas atrisināŔana var aizņemt vairākas dienas, jo... DNS izmaiņas netiek piemērotas nekavējoties.

3. SSL sertifikāta pārbaude
Mūsdienās gandrīz visas vietnes piekļuvei izmanto https protokolu. Lai protokols darbotos pareizi, ir nepiecieŔams derīgs SSL sertifikāts.

Tālāk ir norādÄ«ts uzraudzÄ«bas sistēmas komponents ā€œPersonÄ«gais kontsā€.

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Visas iepriekÅ” minētās pārbaudes darbosies lielākajā daļā lietojumprogrammu, un tām nav nepiecieÅ”ama kodÄ“Å”ana. Tas ir ļoti forÅ”i, jo 5 minÅ«Å”u laikā varat sākt uzraudzÄ«t jebkuru tÄ«mekļa lietojumprogrammu. Tālāk ir norādÄ«tas papildu pārbaudes, kuras var veikt tÄ«mekļa lietojumprogrammai, taču to ievieÅ”ana ir sarežģītāka un specifiskāka, tāpēc Å”ajā rakstā mēs tās neaplÅ«kosim.

Ko vēl var pārbaudīt?

Lai pilnīgāk pārraudzītu savu tīmekļa lietojumprogrammu, varat veikt Ŕādas pārbaudes:

  • JavaScript kļūdu skaits periodā
  • Kļūdu skaits tÄ«mekļa lietojumprogrammas pusē (back-end) attiecÄ«gajā periodā
  • NeveiksmÄ«go tÄ«mekļa lietojumprogrammu atbilžu skaits (atbildes kods 404, 500 utt.)
  • Vidējais vaicājuma izpildes laiks

Windows pakalpojuma uzraudzība (aģents)

ASMO sistēmā aģents pilda uzdevumu plānotāja lomu, kas fonā izpilda ieplānotos uzdevumus.

Ja visi aÄ£enta uzdevumi ir veiksmÄ«gi pabeigti, aÄ£ents darbojas pareizi. Izrādās, lai aÄ£entu uzraudzÄ«tu, jāuzrauga tā uzdevumi. Tāpēc mēs sadalām komponentu ā€œAÄ£entsā€ uzdevumos. Katram uzdevumam izveidosim atseviŔķu komponenti uzraudzÄ«bas sistēmā, kur komponents ā€œAÄ£entsā€ bÅ«s ā€œvecāksā€.

Mēs sadalām aģenta komponentu pakārtotajos komponentos (uzdevumos):

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Tātad, mēs esam sadalÄ«juÅ”i sarežģītu komponentu vairākos vienkārÅ”os. Tagad mums ir jānāk klajā ar katras vienkārÅ”as sastāvdaļas pārbaudes. LÅ«dzu, ņemiet vērā, ka vecākkomponentam ā€œAÄ£entsā€ nebÅ«s nekādu pārbaužu, jo uzraudzÄ«bas sistēma neatkarÄ«gi aprēķinās tā statusu, pamatojoties uz tā pakārtoto komponentu statusu. Citiem vārdiem sakot, ja visi uzdevumi ir veiksmÄ«gi izpildÄ«ti, aÄ£ents darbojas veiksmÄ«gi.

ASMO sistēmā ir vairāk nekā simts uzdevumu, vai tieŔām katram uzdevumam ir jāizdomā unikālas pārbaudes? Protams, kontrole bÅ«s labāka, ja katram aÄ£enta uzdevumam izdomāsim un ieviesÄ«sim savas Ä«paŔās pārbaudes, taču vairumā gadÄ«jumu pietiek ar universālo čeku izmantoÅ”anu.

ASMO sistēma izmanto tikai universālas uzdevumu pārbaudes, un ar to pietiek, lai uzraudzītu sistēmas darbību.

Pārbauda progresu
VienkārŔākā un efektÄ«vākā pārbaude ir izpildes pārbaude. Pārbaude pārbauda, ā€‹ā€‹vai uzdevums ir izpildÄ«ts bez kļūdām. Visiem uzdevumiem ir Ŕī pārbaude.

Pārbaudes algoritms

Pēc katras uzdevuma izpildes jums jānosūta VEIKSMES pārbaudes rezultāts uz uzraudzības sistēmu, ja uzdevuma izpilde bija veiksmīga, vai ERROR, ja izpilde tika pabeigta ar kļūdu.

Å Ä« pārbaude var atklāt Ŕādas problēmas:

  1. Uzdevums tiek izpildīts, bet neizdodas ar kļūdu.
  2. Uzdevums ir pārstājis darboties, piemēram, tas ir iesaldēts.

ApskatÄ«sim, kā Ŕīs problēmas tiek atrisinātas sÄ«kāk.

1. problēma ā€” uzdevums tiek izpildÄ«ts, bet neizdodas un radās kļūda
Tālāk ir parādīts gadījums, kad uzdevums tiek izpildīts, bet neizdodas laikā no 14:00 līdz 16:00.

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Attēlā redzams, ka, ja uzdevums neizdodas, uz uzraudzÄ«bas sistēmu nekavējoties tiek nosÅ«tÄ«ts signāls un atbilstoŔās pārbaudes statuss uzraudzÄ«bas sistēmā kļūst par trauksmi.

Lūdzu, ņemiet vērā, ka uzraudzības sistēmā komponenta statuss ir atkarīgs no verifikācijas statusa. Pārbaudes trauksmes statuss mainīs visus augstāka līmeņa komponentus uz trauksmi, skatiet attēlu zemāk.

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

2. problēma ā€” uzdevums tika pārtraukts (iesaldēts)
Kā uzraudzības sistēma sapratīs, ka uzdevums ir iestrēdzis?

Pārbaudes rezultātam ir derÄ«guma termiņŔ, piemēram, 1 stunda. Ja paiet stunda un nav jaunu testa rezultātu, uzraudzÄ«bas sistēma iestatÄ«s testa statusu uz trauksmes signālu.

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

AugŔējā attēlā gaismas tika izslēgtas pulksten 14:00. 15:00 monitoringa sistēma konstatēs, ka pārbaudes rezultāts (no plkst. 14:00) ir sapuvis, jo AtbilstÄ«bas laiks ir beidzies (viena stunda), taču jauna rezultāta nav, un pārbaude tiks pārslēgta uz trauksmes statusu.

16:00 atkal tika ieslēgtas gaismas, programma pabeigs uzdevumu un nosūtīs izpildes rezultātu uz uzraudzības sistēmu, testa statuss atkal kļūs veiksmīgs.

Kāds pārbaudes atbilstības laiks man jāizmanto?

AtbilstÄ«bas laikam ir jābÅ«t lielākam par uzdevuma izpildes periodu. Iesaku iestatÄ«t atbilstÄ«bas laiku 2-3 reizes garāku par uzdevuma izpildes periodu. Tas ir nepiecieÅ”ams, lai izvairÄ«tos no nepatiesu paziņojumu saņemÅ”anas, ja, piemēram, uzdevums aizņēma ilgāku laiku nekā parasti vai kāds atkārtoti ielādēja programmu.

Pārbauda progresu

ASMO sistēmai ir uzdevums ā€œLoad Forecastā€, kas reizi stundā mēģina lejupielādēt jaunu prognozi no ārēja avota. PrecÄ«zs laiks, kad ārējā sistēmā parādās jauna prognoze, nav zināms, taču zināms, ka tas notiek 2 reizes dienā. Izrādās, ja nav jaunas prognozes vairākas stundas, tad tas ir normāli, bet, ja nav jaunas prognozes ilgāk par dienu, tad kaut kur kaut kas ir salÅ«zis. Piemēram, datu formāts ārējā prognožu sistēmā var mainÄ«ties, tāpēc ASMO neredzēs jaunu prognožu izlaidumu.

Pārbaudes algoritms

Uzdevums nosūta VEIKSMES pārbaudes rezultātu monitoringa sistēmai, kad tam izdodas panākt progresu (jaunas laika prognozes lejupielāde). Ja nav progresa vai rodas kļūda, nekas netiek nosūtīts uz uzraudzības sistēmu.

Pārbaudei ir jābÅ«t tādam atbilstÄ«bas intervālam, lai Å”ajā laikā tiktu garantēta jauna progresa saņemÅ”ana.

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

LÅ«dzu, ņemiet vērā, ka par problēmu uzzināsim ar kavÄ“Å”anos, jo uzraudzÄ«bas sistēma gaida, lÄ«dz beidzas pēdējā skenÄ“Å”anas rezultāta derÄ«guma termiņŔ. Tāpēc čeka derÄ«guma termiņŔ nav jāpadara pārāk garÅ”.

Datu bāzes uzraudzība

Lai kontrolētu datu bāzi ASMO sistēmā, mēs veicam Ŕādas pārbaudes:

  1. Dublējuma izveides pārbaude
  2. Pārbauda brīvo vietu diskā

Dublējuma izveides pārbaude
Lielākajā daļā lietojumprogrammu ir svarīgi, lai būtu atjauninātas datu bāzes dublējumkopijas, lai, ja serveris neizdodas, jūs varētu izvietot programmu jaunā serverī.

ASMO reizi nedēļā izveido rezerves kopiju un nosÅ«ta to uz krātuvi. Kad Ŕī procedÅ«ra ir veiksmÄ«gi pabeigta, veiksmes pārbaudes rezultāts tiek nosÅ«tÄ«ts uz uzraudzÄ«bas sistēmu. Pārbaudes rezultāts ir derÄ«gs 9 dienas. Tie. Lai kontrolētu dublējumu izveidi, tiek izmantots ā€œprogresa pārbaudesā€ mehānisms, par kuru mēs runājām iepriekÅ”.

Pārbauda brīvo vietu diskā
Ja diskā nav pietiekami daudz brīvas vietas, datu bāze nespēs pareizi darboties, tāpēc ir svarīgi kontrolēt brīvās vietas daudzumu.

Skaitlisko parametru pārbaudei ir ērti izmantot metriku.

Metrika ir skaitlisks mainÄ«gais, kura vērtÄ«ba tiek pārraidÄ«ta uz uzraudzÄ«bas sistēmu. UzraudzÄ«bas sistēma pārbauda sliekŔņa vērtÄ«bas un aprēķina metrikas statusu.

Tālāk ir parādÄ«ts, kā monitoringa sistēmā izskatās komponents ā€œDatu bāzeā€:

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Servera uzraudzība

Lai uzraudzÄ«tu serveri, mēs izmantojam Ŕādas pārbaudes un metriku:

1. Brīva vieta diskā
Ja diskā beigsies vieta, lietojumprogramma nevarēs darboties. Mēs izmantojam 2 sliekŔņa vērtÄ«bas: pirmais lÄ«menis ir BRÄŖDINĀJUMS, otrais lÄ«menis ir ALARM.

2. Vidējā RAM vērtība procentos stundā
Mēs izmantojam stundas vidējo, jo... mūs neinteresē retās sacīkstes.

3. Vidējais CPU procents stundā
Mēs izmantojam stundas vidējo, jo... mūs neinteresē retās sacīkstes.

4. Ping pārbaude
Pārbauda, ā€‹ā€‹vai serveris ir tieÅ”saistē. UzraudzÄ«bas sistēma var veikt Å”o pārbaudi, nav nepiecieÅ”ams rakstÄ«t kodu.

Tālāk ir parādÄ«ts, kā uzraudzÄ«bas sistēmā izskatās komponents ā€œServerisā€.

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Iekārtu uzraudzība

Es jums pastāstÄ«Å”u, kā tiek iegÅ«ti dati. Katram ceļa kontroles punktam (MPC) uzdevumu plānotājā ir uzdevums, piemēram, ā€œAptauja MPC M2 km 200ā€. Uzdevums saņem datus no visām MPC ierÄ«cēm ik pēc 30 minÅ«tēm.

Sakaru kanāla problēma
Lielākā daļa iekārtu atrodas ārpus pilsētas, datu pārraidei tiek izmantots GSM tīkls, kas nestrādā stabili (tīkls ir, vai nav).

Biežo tÄ«kla kļūmju dēļ sākotnēji MPC aptaujas pārbaude uzraudzÄ«bā izskatÄ«jās Ŕādi:

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Kļuva skaidrs, ka Ŕī nav piemērota iespēja, jo bija daudz nepatiesu paziņojumu par problēmām. Tad tika nolemts katrai ierÄ«cei izmantot ā€œprogresa pārbaudiā€, t.i. UzraudzÄ«bas sistēmai tiek nosÅ«tÄ«ts tikai veiksmes signāls, ja ierÄ«ce tiek aptaujāta bez kļūdām. AtbilstÄ«bas laiks tika iestatÄ«ts uz 5 stundām.

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Tagad monitorings sūta paziņojumus par problēmām tikai tad, ja ierīci nevar aptaujāt ilgāk par 5 stundām. Ar lielu varbūtības pakāpi tās nav viltus trauksmes, bet gan reālas problēmas.

Zemāk ir attēls, kā iekārta izskatās uzraudzības sistēmā:

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Svarīgi!
Kad GSM tÄ«kls pārstāj darboties, visas MDC ierÄ«ces netiek aptaujātas. Lai samazinātu e-pasta ziņojumu skaitu no uzraudzÄ«bas sistēmas, mÅ«su inženieri abonē paziņojumus par komponentu problēmām ar tipu ā€œMPCā€, nevis ā€œIerÄ«ceā€. Tas ļauj saņemt vienu paziņojumu par katru MPC, nevis saņemt atseviŔķu paziņojumu par katru ierÄ«ci.

Galīgā ASMO monitoringa shēma

Saliksim visu kopā un paskatīsimies, kāda mums ir uzraudzības shēma.

Mēs ēdam ziloni pa daļām. Pielietojuma veselības uzraudzības stratēģija ar piemēriem

Secinājums

Apkoposim.
Ko mums deva ASMO darbības pārraudzība?

1. Samazinājies defektu novērÅ”anas laiks
IepriekÅ” esam dzirdējuÅ”i par defektiem no lietotājiem, taču ne visi lietotāji ziņo par defektiem. GadÄ«jās, ka par sistēmas komponenta darbÄ«bas traucējumiem uzzinājām nedēļu pēc tās parādÄ«Å”anās. Tagad uzraudzÄ«bas sistēma mÅ«s informē par problēmām, tiklÄ«dz problēma tiek atklāta.

2. Sistēmas stabilitāte ir palielinājusies
Tā kā defektus sāka novērst agrāk, sistēma kopumā sāka darboties daudz stabilāk.

3. Tehniskā atbalsta zvanu skaita samazināŔana
Daudzas problēmas tagad ir novērstas, pirms lietotāji par tām pat uzzina. Lietotāji sāka retāk sazināties ar tehnisko atbalstu. Tas viss labi ietekmē mūsu reputāciju.

4. Klientu un lietotāju lojalitātes palielināŔana
Klients pamanīja pozitīvas izmaiņas sistēmas stabilitātē. Lietotāji saskaras ar mazākām problēmām, izmantojot sistēmu.

5. Samaziniet tehniskā atbalsta izmaksas
Mēs esam pārtraukuÅ”i veikt jebkādas manuālas pārbaudes. Tagad visas pārbaudes ir automatizētas. IepriekÅ” par problēmām uzzinājām no lietotājiem, bieži vien bija grÅ«ti saprast, par kādu problēmu lietotājs runā. Tagad par lielāko daļu problēmu ziņo uzraudzÄ«bas sistēma, paziņojumos ir tehniskie dati, kas vienmēr parāda, kas un kur nogāja greizi.

Svarīgi!
UzraudzÄ«bas sistēmu nevar instalēt tajā paŔā serverÄ«, kurā darbojas jÅ«su lietojumprogrammas. Ja serveris pazudÄ«s, lietojumprogrammas pārtrauks darboties un nebÅ«s neviena, kas par to paziņotu.

UzraudzÄ«bas sistēmai jādarbojas uz atseviŔķa servera citā datu centrā.

Ja nevēlaties izmantot speciālu serveri jaunā datu centrā, varat izmantot mākoņu uzraudzības sistēmu. Mūsu uzņēmums izmanto Zidium mākoņu uzraudzības sistēmu, bet jūs varat izmantot jebkuru citu uzraudzības sistēmu. Mākoņu uzraudzības sistēmas izmaksas ir zemākas nekā jauna servera noma.

Ieteikumi:

  1. Pēc iespējas detalizētāk sadaliet lietojumprogrammas un sistēmas komponentu koka veidā, lai būtu ērti saprast, kur un kas ir bojāts, un kontrole būs pilnīgāka.
  2. Lai pārbaudītu komponenta funkcionalitāti, izmantojiet testus. Labāk ir izmantot daudzas vienkārŔas pārbaudes, nevis vienu sarežģītu.
  3. Konfigurējiet metrikas sliekŔņus uzraudzÄ«bas sistēmas pusē, nevis ierakstiet tos kodā. Tas pasargās jÅ«s no nepiecieÅ”amÄ«bas atkārtoti kompilēt, pārkonfigurēt vai restartēt lietojumprogrammu.
  4. Pielāgotām pārbaudēm izmantojiet atbilstÄ«bas laika rezervi, lai nesaņemtu viltus paziņojumus, jo dažu pārbaužu veikÅ”ana prasÄ«ja nedaudz ilgāku laiku nekā parasti.
  5. Centieties panākt, lai uzraudzības sistēmas komponenti kļūtu sarkani tikai tad, ja noteikti ir kāda problēma. Ja tie par velti kļūs sarkani, tad pārstāsiet pievērst uzmanību uzraudzības sistēmas paziņojumiem, zudīs to nozīme.

Ja jÅ«s vēl neizmantojat uzraudzÄ«bas sistēmu, sāciet! Tas nav tik grÅ«ti, kā Ŕķiet. AtpÅ«tieties, skatoties uz zaļo sastāvdaļu koku, kuru izaudzējāt pats.

Good luck.

Avots: www.habr.com

Pievieno komentāru