Pozdravljeni vsi!
Naše podjetje se ukvarja z razvojem programske opreme in kasnejšo tehnično podporo. Tehnična podpora ne zahteva samo odpravljanja napak, temveč tudi spremljanje delovanja naših aplikacij.
Na primer, če se je ena od storitev zrušila, morate samodejno zabeležiti to težavo in jo začeti reševati, ne pa čakati, da se nezadovoljni uporabniki obrnejo na tehnično podporo.
Imamo majhno podjetje, nimamo sredstev za preučevanje in vzdrževanje kompleksnih rešitev za spremljanje aplikacij, morali smo najti preprosto in učinkovito rešitev.
Strategija spremljanja
Preverjanje funkcionalnosti aplikacije ni lahko, ta naloga je netrivialna, lahko bi rekli celo ustvarjalna. Še posebej težko je preveriti zapleten sistem z več povezavami.
Kako lahko poješ slona? Samo po delih! Ta pristop uporabljamo za spremljanje aplikacij.
Bistvo naše strategije spremljanja:
Razčlenite aplikacijo na komponente.
Ustvarite kontrolne preglede za vsako komponento.
Komponenta se šteje za delujočo, če so vsi njeni kontrolni pregledi izvedeni brez napak. Aplikacija velja za zdravo, če vse njene komponente delujejo.
Tako lahko vsak sistem predstavimo kot drevo komponent. Kompleksne komponente so razdeljene na enostavnejše. Enostavne komponente imajo preglede.
Primerjalna merila niso namenjena izvajanju funkcionalnega testiranja, niso testi enot. Kontrolni pregledi morajo preveriti, kako se komponenta počuti v trenutnem trenutku, ali so na voljo vsi viri, ki so potrebni za njeno delovanje, in ali obstajajo težave.
Čudežev ni, večino pregledov bo treba razviti neodvisno. Vendar naj vas ne bo strah, saj v večini primerov eno preverjanje traja 5-10 vrstic kode, vendar lahko uporabite katero koli logiko in jasno boste razumeli, kako preverjanje deluje.
Sistem spremljanja
Recimo, da smo aplikacijo razdelili na komponente, si zamislili in izvedli preverjanja za vsako komponento, toda kaj narediti z rezultati teh preverjanj? Kako vemo, če kakšen pregled ni uspel?
Potrebovali bomo nadzorni sistem. Opravljala bo naslednje naloge:
- Prejmite rezultate testov in jih uporabite za določitev stanja komponent.
Vizualno je to videti kot poudarjanje drevesa komponent. Funkcionalne komponente postanejo zelene, problematične pa rdeče. - Izvedite splošne preglede takoj po namestitvi.
Sistem za spremljanje lahko sam opravi nekatere preglede. Zakaj bi znova izumljali kolo, uporabimo jih. Preverite lahko na primer, ali se stran spletnega mesta odpira ali strežnik pinga. - Pošljite obvestila o težavah zainteresiranim stranem.
- Vizualizacija podatkov spremljanja, zagotavljanje poročil, grafov in statistik.
Kratek opis sistema ASMO
Najbolje je razložiti s primerom. Poglejmo, kako je organizirano spremljanje delovanja sistema ASMO.
ASMO je avtomatiziran sistem meteorološke podpore. Sistem pomaga strokovnjakom cestnih služb razumeti, kje in kdaj je treba cestišče obdelati z materiali za odmrzovanje. Sistem zbira podatke s cestnih nadzornih točk. Cestna nadzorna točka je mesto na cesti, kjer je nameščena oprema: vremenska postaja, video kamera itd. Za predvidevanje nevarnih situacij sistem prejema vremenske napovedi iz zunanjih virov.
Torej je sestava sistema precej tipična: spletna stran, agent, oprema. Začnimo s spremljanjem.
Razčlenitev sistema na komponente
V sistemu ASMO lahko ločimo naslednje komponente:
1. Osebni račun
To je spletna aplikacija. Preveriti morate najmanj, ali je aplikacija na voljo na internetu.
2. Baza podatkov
Baza podatkov shranjuje podatke, ki so pomembni za poročanje, zato morate zagotoviti, da so varnostne kopije baze podatkov uspešno ustvarjene.
3. Strežnik
S strežnikom mislimo na strojno opremo, na kateri tečejo aplikacije. Potrebno je preveriti stanje HDD, RAM, CPU.
4. Agent
To je storitev Windows, ki izvaja veliko različnih nalog po urniku. Preveriti morate najmanj, ali storitev deluje.
5. Naloga agenta
Samo vedeti, da agent dela, ni dovolj. Agent lahko dela, vendar ne opravlja nalog, ki so mu dodeljene. Razdelimo komponento agenta na naloge in preverimo, ali posamezna naloga agenta deluje uspešno.
6. Cestne kontrolne točke (vsebnik vseh MPC)
Kontrolnih točk na cestah je veliko, zato združimo vse MPC v eno komponento. To bo olajšalo branje podatkov spremljanja. Pri ogledu statusa komponente “ASMO sistem” bo takoj jasno, kje so težave: v aplikacijah, strojni opremi ali v sistemu maksimalnega nadzora.
7. Cestna kontrolna točka (ena največja omejitev)
To komponento bomo šteli za uporabno, če so vse naprave na tem MPC uporabne.
8. Naprava
To je videokamera ali vremenska postaja, ki je nameščena na najvišjo koncentracijsko mejo. Potrebno je preveriti, ali naprava deluje pravilno.
V nadzornem sistemu bo drevo komponent videti takole:
Spremljanje spletnih aplikacij
Torej, sistem smo razdelili na komponente, zdaj moramo pripraviti preverjanja za vsako komponento.
Za spremljanje spletne aplikacije uporabljamo naslednja preverjanja:
1. Preverjanje odpiranja glavne strani
To preverjanje izvaja nadzorni sistem. Za izvedbo navedemo naslov strani, pričakovani fragment odgovora in najdaljši čas izvedbe zahteve.
2. Preverjanje roka plačila domene
Zelo pomemben pregled. Ko domena ostane neplačana, uporabniki ne morejo odpreti strani. Reševanje težave lahko traja več dni, saj... Spremembe DNS se ne uporabijo takoj.
3. Preverjanje SSL certifikata
Dandanes skoraj vse spletne strani za dostop uporabljajo protokol https. Za pravilno delovanje protokola potrebujete veljaven SSL certifikat.
Spodaj je komponenta »Osebni račun« v sistemu za spremljanje:
Vsa zgornja preverjanja bodo delovala za večino aplikacij in ne zahtevajo kodiranja. To je zelo kul, saj lahko začnete spremljati katero koli spletno aplikacijo v 5 minutah. Spodaj so navedena dodatna preverjanja, ki jih je mogoče izvesti za spletno aplikacijo, vendar je njihova izvedba bolj zapletena in specifična za aplikacijo, zato jih v tem članku ne bomo obravnavali.
Kaj še lahko preverite?
Za popolnejši nadzor vaše spletne aplikacije lahko izvedete naslednja preverjanja:
- Število napak JavaScript na obdobje
- Število napak na strani spletne aplikacije (backend) za obdobje
- Število neuspešnih odgovorov spletne aplikacije (odzivna koda 404, 500 itd.)
- Povprečni čas izvedbe poizvedbe
Spremljanje storitve Windows (agent)
V sistemu ASMO ima agent vlogo načrtovalca opravil, ki v ozadju izvaja načrtovana opravila.
Če so vse naloge agenta uspešno zaključene, agent deluje pravilno. Izkazalo se je, da morate za spremljanje agenta spremljati njegove naloge. Zato komponento »Agent« razdelimo na naloge. Za vsako nalogo bomo ustvarili ločeno komponento v nadzornem sistemu, kjer bo komponenta “Agent” “starš”.
Komponento agenta razdelimo na podrejene komponente (naloge):
Tako smo kompleksno komponento razdelili na več preprostih. Zdaj moramo pripraviti preverjanja za vsako preprosto komponento. Upoštevajte, da nadrejena komponenta »Agent« ne bo imela nobenih preverjanj, ker bo nadzorni sistem izračunal njen status neodvisno na podlagi statusa njenih podrejenih komponent. Z drugimi besedami, če so vse naloge uspešno zaključene, agent deluje uspešno.
V sistemu ASMO je več kot sto nalog, ali je res treba za vsako nalogo pripraviti edinstvena preverjanja? Seveda bo nadzor boljši, če si za vsako nalogo agenta izmislimo in implementiramo svoja posebna preverjanja, a v večini primerov zadošča uporaba univerzalnih preverjanj.
Sistem ASMO uporablja le univerzalna preverjanja nalog in to je dovolj za spremljanje delovanja sistema.
Preverjanje napredka
Najenostavnejši in najučinkovitejši pregled je pregled izvajanja. Preverjanje preveri, ali je naloga opravljena brez napak. Vse naloge imajo to preverjanje.
Algoritem preverjanja
Po vsaki izvedbi naloge morate nadzornemu sistemu poslati rezultat preverjanja USPEH, če je bila izvedba naloge uspešna, ali NAPAKA, če se je izvedba zaključila z napako.
To preverjanje lahko odkrije naslednje težave:
- Naloga se izvaja, vendar ne uspe z napako.
- Naloga se je ustavila, na primer zamrznila.
Oglejmo si podrobneje, kako se te težave rešujejo.
1. težava – Naloga se izvaja, vendar ne uspe z napako
Spodaj je primer, ko se naloga izvaja, vendar ne uspe med 14:00 in 16:00.
Na sliki je prikazano, da se ob neuspelem opravilu v nadzorni sistem takoj pošlje signal in status ustreznega preverjanja v nadzornem sistemu postane alarm.
Upoštevajte, da je v sistemu spremljanja status komponente odvisen od statusa preverjanja. Status alarma preverjanja bo spremenil vse komponente višje ravni v alarm, glejte spodnjo sliko.
Težava 2 – Naloga se je prenehala izvajati (zamrznjena)
Kako bo nadzorni sistem razumel, da je naloga obstala?
Rezultat preverjanja ima obdobje veljavnosti, na primer 1 uro. Če mine ena ura in ni novih rezultatov testa, bo nadzorni sistem nastavil status testa na alarm.
Na zgornji sliki so luči ugasnili ob 14. Ob 00:15 bo nadzorni sistem zaznal, da je rezultat testa (od 00:14) pokvarjen, ker Čas ustreznosti je potekel (ena ura), vendar ni nobenega novega rezultata in bo preverjanje preklopilo na status alarma.
Ob 16:00 so se luči ponovno prižgale, program bo dokončal nalogo in poslal rezultat izvedbe v sistem za spremljanje, status testa bo ponovno postal uspeh.
Kateri čas preverjanja ustreznosti naj uporabim?
Čas ustreznosti mora biti daljši od obdobja izvajanja naloge. Priporočam, da čas ustreznosti nastavite 2-3 krat dlje od obdobja izvajanja naloge. To je potrebno, da se izognete prejemanju lažnih obvestil, ko je na primer opravilo trajalo dlje kot običajno ali je nekdo znova naložil program.
Preverjanje napredka
Sistem ASMO ima nalogo »Napoved obremenitve«, ki enkrat na uro poskuša prenesti novo napoved iz zunanjega vira. Natančen čas, ko se pojavi nova napoved v zunanjem sistemu, ni znan, vendar je znano, da se to zgodi 2-krat na dan. Izkazalo se je, da če ni nove napovedi več ur, je to normalno, če pa ni nove napovedi več kot en dan, potem se je nekje nekaj zalomilo. Na primer, format podatkov v zunanjem sistemu napovedi se lahko spremeni, zato ASMO ne bo videl nove objave napovedi.
Algoritem preverjanja
Naloga pošlje rezultat preverjanja SUCCESS sistemu za spremljanje, ko uspe doseči napredek (prenos nove vremenske napovedi). Če ni napredka ali pride do napake, se sistemu za spremljanje ne pošlje nič.
Preverjanje mora imeti interval ustreznosti, tako da je v tem času zagotovljeno, da bo prejelo nov napredek.
Upoštevajte, da bomo za težavo izvedeli z zamudo, ker nadzorni sistem čaka, da poteče obdobje veljavnosti zadnjega rezultata skeniranja. Zato ni treba, da je obdobje veljavnosti čeka predolgo.
Spremljanje baze podatkov
Za nadzor podatkovne baze v sistemu ASMO izvajamo naslednje preglede:
- Preverjanje ustvarjanja varnostne kopije
- Preverjanje prostega prostora na disku
Preverjanje ustvarjanja varnostne kopije
V večini aplikacij je pomembno, da imate posodobljene varnostne kopije baze podatkov, tako da lahko v primeru okvare strežnika namestite program na nov strežnik.
ASMO enkrat tedensko ustvari varnostno kopijo in jo pošlje v shrambo. Ko je ta postopek uspešno zaključen, se rezultat preverjanja uspešnosti pošlje sistemu za spremljanje. Rezultat preverjanja velja 9 dni. Tisti. Za nadzor ustvarjanja varnostnih kopij se uporablja mehanizem "preverjanje napredka", o katerem smo razpravljali zgoraj.
Preverjanje prostega prostora na disku
Če na disku ni dovolj prostega prostora, baza podatkov ne bo mogla pravilno delovati, zato je pomembno nadzorovati količino prostega prostora.
Za preverjanje numeričnih parametrov je priročno uporabljati metrike.
Meritve je numerična spremenljivka, katere vrednost se posreduje sistemu za spremljanje. Sistem za spremljanje preveri mejne vrednosti in izračuna stanje metrike.
Spodaj je slika, kako izgleda komponenta »Baza podatkov« v nadzornem sistemu:
Spremljanje strežnika
Za spremljanje strežnika uporabljamo naslednja preverjanja in meritve:
1. Prosti prostor na disku
Če na disku zmanjka prostora, aplikacija ne bo mogla delovati. Uporabljamo 2 mejni vrednosti: prva stopnja je OPOZORILO, druga stopnja je ALARM.
2. Povprečna vrednost RAM-a v odstotkih na uro
Uporabljamo urno povprečje, ker... redke rase nas ne zanimajo.
3. Povprečni odstotek procesorja na uro
Uporabljamo urno povprečje, ker... redke rase nas ne zanimajo.
4. Preverjanje pinga
Preveri, ali je strežnik povezan. Nadzorni sistem lahko izvede to preverjanje; kode ni treba pisati.
Spodaj je slika, kako izgleda komponenta »Server« v nadzornem sistemu:
Spremljanje opreme
Povedal vam bom, kako se podatki pridobivajo. Za vsako cestno kontrolno točko (MPC) je v načrtovalcu nalog naloga, na primer »Pregled MPC M2 km 200«. Naloga prejme podatke iz vseh naprav MPC vsakih 30 minut.
Težava s komunikacijskim kanalom
Večina opreme je zunaj mesta, za prenos podatkov se uporablja GSM omrežje, ki ne deluje stabilno (omrežje je ali pa ga ni).
Zaradi pogostih okvar omrežja je sprva preverjanje ankete MPC v monitoringu izgledalo takole:
Postalo je jasno, da to ne deluje, saj je bilo veliko lažnih obvestil o težavah. Potem je bilo odločeno, da se uporabi "preverjanje napredka" za vsako napravo, tj. Samo signal o uspehu je poslan sistemu za spremljanje, ko je naprava vprašana brez napake. Čas ustreznosti je bil nastavljen na 5 ur.
Zdaj spremljanje pošilja obvestila o težavah le, če naprave ni mogoče anketirati več kot 5 ur. Z veliko verjetnostjo ne gre za lažne alarme, ampak za resnične težave.
Spodaj je slika, kako izgleda oprema v nadzornem sistemu:
Pomembno!
Ko omrežje GSM preneha delovati, vse naprave MDC niso anketirane. Da bi zmanjšali število e-poštnih sporočil iz nadzornega sistema, se naši inženirji naročijo na obvestila o težavah s komponentami z vrsto »MPC« in ne »Device«. To vam omogoča, da prejmete eno obvestilo za vsak MPC namesto prejemanja ločenega obvestila za vsako napravo.
Končna shema spremljanja ASMO
Združimo vse skupaj in poglejmo, kakšno shemo spremljanja imamo.
Zaključek
Naj povzamemo.
Kaj nam je dalo spremljanje delovanja ASMO?
1. Čas odprave napake se je zmanjšal
Od uporabnikov smo že slišali za napake, vendar vsi uporabniki ne poročajo o napakah. Zgodilo se je, da smo za okvaro sistemske komponente izvedeli teden dni po tem, ko se je pojavila. Zdaj nas nadzorni sistem obvesti o težavah takoj, ko je težava zaznana.
2. Stabilnost sistema se je povečala
Ker so se napake začele odpravljati prej, je sistem kot celota začel delovati veliko bolj stabilno.
3. Zmanjšanje števila klicev tehnične podpore
Številne težave so zdaj odpravljene, preden uporabniki sploh izvedo zanje. Uporabniki so začeli manj pogosto kontaktirati tehnično podporo. Vse to dobro vpliva na naš ugled.
4. Povečanje zvestobe strank in uporabnikov
Stranka je opazila pozitivne spremembe v stabilnosti sistema. Uporabniki imajo pri uporabi sistema manj težav.
5. Zmanjšajte stroške tehnične podpore
Prenehali smo izvajati ročna preverjanja. Zdaj so vsi pregledi avtomatizirani. Prej smo o težavah izvedeli od uporabnikov, pogosto je bilo težko razumeti, o kateri težavi uporabnik govori. Sedaj večino težav poroča nadzorni sistem, obvestila vsebujejo tehnične podatke, iz katerih je vedno jasno, kaj in kje je šlo narobe.
Pomembno!
Sistema za spremljanje ne morete namestiti na isti strežnik, kjer se izvajajo vaše aplikacije. Če strežnik odpove, bodo aplikacije prenehale delovati in ne bo nikogar, ki bi o tem obvestil.
Sistem za spremljanje mora delovati na ločenem strežniku v drugem podatkovnem centru.
Če v novem podatkovnem centru ne želite uporabljati namenskega strežnika, lahko uporabite sistem za spremljanje v oblaku. Naše podjetje uporablja sistem za spremljanje v oblaku Zidium, vendar lahko uporabite kateri koli drug sistem za nadzor. Stroški sistema za spremljanje v oblaku so nižji od najema novega strežnika.
Priporočila:
- Razčlenite aplikacije in sisteme v obliki drevesa komponent čim bolj podrobno, tako da bo priročno razumeti, kje in kaj je pokvarjeno, nadzor pa bo popolnejši.
- Če želite preveriti delovanje komponente, uporabite teste. Bolje je uporabiti veliko preprostih pregledov kot eno kompleksno.
- Konfigurirajte mejne vrednosti meritev na strani nadzornega sistema, namesto da jih zapisujete v kodo. Tako vam ne bo treba znova prevajati, ponovno konfigurirati ali znova zagnati aplikacije.
- Za preverjanja po meri uporabite mejo časa ustreznosti, da se izognete prejemu lažnih obvestil, ker so nekatera preverjanja trajala nekoliko dlje kot običajno.
- Poskusite, da se komponente v sistemu za spremljanje obarvajo rdeče le, če zagotovo obstaja težava. Če postanejo rdeče za nič, potem ne boste več pozorni na obvestila nadzornega sistema, njegov pomen bo izgubljen.
Če še ne uporabljate nadzornega sistema, začnite! Ni tako težko, kot se zdi. Navdušite se ob pogledu na drevo zelenih sestavin, ki ste ga vzgojili sami.
Vso srečo.
Vir: www.habr.com