Pozdrav!
Naša tvrtka se bavi razvojem softvera i naknadnom tehničkom podrškom. Tehnička podrška ne zahtijeva samo ispravljanje grešaka, već i praćenje rada naših aplikacija.
Na primjer, ako se jedna od usluga srušila, tada morate automatski zabilježiti ovaj problem i početi ga rješavati, a ne čekati da se nezadovoljni korisnici obrate tehničkoj podršci.
Imamo malu tvrtku, nemamo resurse za proučavanje i održavanje složenih rješenja za nadzor aplikacija, morali smo pronaći jednostavno i učinkovito rješenje.
Strategija praćenja
Nije jednostavno provjeriti funkcionalnost aplikacije, ovaj zadatak nije trivijalan, moglo bi se reći čak i kreativan. Posebno je teško verificirati složeni sustav s više veza.
Kako možeš pojesti slona? Samo u dijelovima! Ovaj pristup koristimo za nadzor aplikacija.
Bit naše strategije praćenja:
Rastavite svoju aplikaciju na komponente.
Napravite kontrolne provjere za svaku komponentu.
Komponenta se smatra operativnom ako su sve njene kontrolne provjere obavljene bez grešaka. Aplikacija se smatra ispravnom ako su sve njezine komponente funkcionalne.
Stoga se svaki sustav može prikazati kao stablo komponenti. Složene komponente rastavljaju se na jednostavnije. Jednostavne komponente imaju provjere.
Benchmarkovi nisu namijenjeni za izvođenje funkcionalnog testiranja, oni nisu jedinični testovi. Kontrolnim provjerama treba provjeriti kako se komponenta osjeća u trenutnom trenutku, postoje li svi potrebni resursi za njezino funkcioniranje te postoje li problemi.
Nema čuda; većinu će se provjera morati samostalno razviti. Ali nemojte se bojati, jer u većini slučajeva jedna provjera traje 5-10 redaka koda, ali možete implementirati bilo koju logiku i jasno ćete razumjeti kako provjera radi.
Sustav nadzora
Recimo da smo podijelili aplikaciju na komponente, osmislili i implementirali provjere za svaku komponentu, ali što učiniti s rezultatima tih provjera? Kako znamo da neka provjera nije uspjela?
Trebat će nam sustav praćenja. Ona će obavljati sljedeće poslove:
- Primite rezultate ispitivanja i koristite ih za određivanje statusa komponenti.
Vizualno, ovo izgleda kao isticanje stabla komponenti. Funkcionalne komponente postaju zelene, a problematične crvene. - Izvršite opće provjere izvan okvira.
Sustav za nadzor može sam izvršiti neke provjere. Zašto izmišljati kotač, iskoristimo ih. Na primjer, možete provjeriti otvara li se web stranica ili pinga li poslužitelj. - Slanje obavijesti o problemima zainteresiranima.
- Vizualizacija podataka praćenja, pružanje izvješća, grafikona i statistike.
Kratak opis ASMO sustava
Najbolje je objasniti na primjeru. Pogledajmo kako je organizirano praćenje performansi ASMO sustava.
ASMO je automatizirani sustav meteorološke podrške. Sustav pomaže stručnjacima cestovnih službi da razumiju gdje i kada je potrebno tretirati cestu materijalima za odleđivanje. Sustav prikuplja podatke s kontrolnih točaka na cesti. Kontrolna točka je mjesto na cesti gdje je postavljena oprema: meteorološka stanica, video kamera itd. Kako bi predvidio opasne situacije, sustav prima vremensku prognozu iz vanjskih izvora.
Dakle, sastav sustava je prilično tipičan: web stranica, agent, oprema. Počnimo pratiti.
Rastavljanje sustava na komponente
U sustavu ASMO mogu se razlikovati sljedeće komponente:
1. Osobni račun
Ovo je web aplikacija. Najmanje je potrebno provjeriti je li aplikacija dostupna na internetu.
2. Baza podataka
Baza podataka pohranjuje podatke koji su važni za izvješćivanje i morate osigurati da su sigurnosne kopije baze podataka uspješno izrađene.
3. Poslužitelj
Pod poslužiteljem podrazumijevamo hardver na kojem se pokreću aplikacije. Potrebno je provjeriti status HDD-a, RAM-a, CPU-a.
4. Agent
Ovo je Windows usluga koja izvršava mnogo različitih zadataka prema rasporedu. Najmanje morate provjeriti radi li usluga.
5. Zadatak agenta
Samo znati da agent radi nije dovoljno. Agent može raditi, ali ne i izvršavati dodijeljene zadatke. Podijelimo komponentu agenta na zadatke i provjerimo radi li svaki zadatak agenta uspješno.
6. Kontrolne točke na cesti (spremnik svih MPC-ova)
Postoji mnogo kontrolnih točaka na cesti, pa kombinirajmo sve MPC-ove u jednu komponentu. To će učiniti jednostavnijim čitanje podataka praćenja. Pri pregledu statusa komponente “ASMO sustav” odmah će biti jasno gdje su problemi: u aplikacijama, hardveru ili u sustavu maksimalne kontrole.
7. Kontrolna točka na cesti (jedno maksimalno ograničenje)
Smatrat ćemo ovu komponentu ispravnom ako su svi uređaji na ovom MPC-u ispravni.
8. Uređaj
Ovo je video kamera ili meteorološka stanica koja je instalirana na granici maksimalne koncentracije. Potrebno je provjeriti radi li uređaj ispravno.
U sustavu nadzora stablo komponenti će izgledati ovako:
Nadgledanje web aplikacija
Dakle, podijelili smo sustav na komponente, sada moramo osmisliti provjere za svaku komponentu.
Za nadzor web aplikacije koristimo sljedeće provjere:
1. Provjera otvaranja glavne stranice
Ovu provjeru obavlja nadzorni sustav. Da bismo ga izvršili, navodimo adresu stranice, očekivani fragment odgovora i maksimalno vrijeme izvršenja zahtjeva.
2. Provjera roka plaćanja domene
Vrlo važna provjera. Kada domena ostane neplaćena, korisnici ne mogu otvoriti stranicu. Rješavanje problema može potrajati nekoliko dana, jer... Promjene DNS-a ne primjenjuju se odmah.
3. Provjera SSL certifikata
Danas gotovo sve web stranice koriste https protokol za pristup. Za ispravan rad protokola potreban vam je važeći SSL certifikat.
Ispod je komponenta "Osobni račun" u sustavu nadzora:
Sve gore navedene provjere funkcionirat će za većinu aplikacija i ne zahtijevaju kodiranje. Ovo je jako cool jer možete početi nadzirati bilo koju web aplikaciju u 5 minuta. U nastavku su navedene dodatne provjere koje se mogu izvršiti za web aplikaciju, ali njihova je implementacija složenija i specifična za aplikaciju, pa ih nećemo pokrivati u ovom članku.
Što još možete provjeriti?
Za potpuniji nadzor vaše web aplikacije možete izvršiti sljedeće provjere:
- Broj JavaScript pogrešaka po razdoblju
- Broj pogrešaka na strani web aplikacije (back-end) za razdoblje
- Broj neuspješnih odgovora web aplikacije (šifra odgovora 404, 500 itd.)
- Prosječno vrijeme izvršenja upita
Praćenje Windows usluge (agent)
U ASMO sustavu agent igra ulogu planera zadataka koji u pozadini izvršava zakazane zadatke.
Ako su svi zadaci agenta uspješno završeni, agent radi ispravno. Ispada da, kako biste nadzirali agenta, trebate nadzirati njegove zadatke. Stoga komponentu “Agent” dijelimo na zadatke. Za svaki zadatak izradit ćemo zasebnu komponentu u sustavu nadzora, gdje će komponenta “Agent” biti “roditelj”.
Komponentu agenta dijelimo na podređene komponente (zadatke):
Dakle, složenu smo komponentu rastavili na nekoliko jednostavnih. Sada moramo smisliti provjere za svaku jednostavnu komponentu. Imajte na umu da nadređena komponenta “Agent” neće imati nikakve provjere, jer će sustav za praćenje izračunati njen status neovisno na temelju statusa svojih podređenih komponenti. Drugim riječima, ako su svi zadaci uspješno dovršeni, agent radi uspješno.
U sustavu ASMO postoji više od stotinu zadataka, je li stvarno potrebno smisliti jedinstvene provjere za svaki zadatak? Naravno, kontrola će biti bolja ako osmislimo i implementiramo vlastite posebne provjere za svaki zadatak agenta, ali u većini slučajeva dovoljno je koristiti univerzalne provjere.
ASMO sustav koristi samo univerzalne provjere za zadatke i to je dovoljno za praćenje performansi sustava.
Provjera napretka
Najjednostavnija i najučinkovitija provjera je provjera izvršenja. Provjerom se potvrđuje da je zadatak dovršen bez grešaka. Svi zadaci imaju ovu provjeru.
Algoritam provjere
Nakon svakog izvršenja zadatka potrebno je sustavu za nadzor poslati rezultat provjere USPJEH ako je izvršenje zadatka uspješno, odnosno GREŠKU ako je izvršenje završeno s greškom.
Ova provjera može otkriti sljedeće probleme:
- Zadatak se izvodi, ali ne uspijeva uz pogrešku.
- Zadatak se prestao izvoditi, na primjer, zamrznuo se.
Pogledajmo detaljnije kako se ti problemi rješavaju.
Problem 1 – Zadatak se izvodi, ali ne uspijeva uz pogrešku
Ispod je slučaj u kojem se zadatak izvodi, ali ne uspijeva između 14:00 i 16:00.
Slika pokazuje da kada zadatak ne uspije, signal se odmah šalje sustavu za nadzor i status odgovarajuće provjere u sustavu za nadzor postaje alarm.
Imajte na umu da u sustavu nadzora status komponente ovisi o statusu verifikacije. Status alarma provjere promijenit će sve komponente više razine u alarm, pogledajte sliku u nastavku.
Problem 2 - Zadatak se prestao izvršavati (zamrznut)
Kako će sustav za praćenje shvatiti da je zadatak zapeo?
Rezultat provjere ima rok valjanosti, na primjer, 1 sat. Ako prođe sat vremena i nema novog rezultata testa, sustav za nadzor će postaviti status testa na alarm.
Na gornjoj slici svjetla su ugašena u 14:00 sati. U 15:00 sustav za nadzor će otkriti da je rezultat testa (od 14:00) pokvaren, jer Vrijeme relevantnosti je isteklo (jedan sat), ali nema novih rezultata, pa će se provjera prebaciti na status alarma.
U 16:00 ponovno su se upalila svjetla, program će dovršiti zadatak i poslati rezultat izvršenja sustavu za nadzor, status testa ponovno će postati uspjeh.
Koje vrijeme provjere relevantnosti trebam koristiti?
Vrijeme relevantnosti mora biti veće od razdoblja izvršenja zadatka. Preporučujem postavljanje vremena relevantnosti 2-3 puta dulje od razdoblja izvršenja zadatka. To je neophodno kako bi se izbjeglo primanje lažnih obavijesti kada je, na primjer, zadatak trajao dulje nego inače ili je netko ponovno učitao program.
Provjera napretka
ASMO sustav ima zadatak “Load Forecast” koji pokušava preuzeti novu prognozu iz vanjskog izvora jednom u satu. Točno vrijeme kada se nova prognoza pojavljuje u vanjskom sustavu nije poznato, ali se zna da se to događa 2 puta dnevno. Ispada da ako nema nove prognoze nekoliko sati, onda je to normalno, ali ako nema nove prognoze dulje od jednog dana, onda je negdje nešto puklo. Na primjer, format podataka u vanjskom sustavu predviđanja može se promijeniti, zbog čega ASMO neće vidjeti novo izdanje predviđanja.
Algoritam provjere
Zadatak šalje rezultat provjere SUCCESS sustavu za praćenje kada uspije postići napredak (preuzimanje nove vremenske prognoze). Ako nema napretka ili se pojavi greška, ništa se ne šalje sustavu za nadzor.
Provjera mora imati interval relevantnosti tako da tijekom tog vremena zajamčeno dobije novi napredak.
Imajte na umu da ćemo o problemu saznati sa zakašnjenjem, jer sustav za nadzor čeka da istekne rok valjanosti zadnjeg rezultata skeniranja. Stoga rok valjanosti čeka ne mora biti predug.
Praćenje baze podataka
Za kontrolu baze podataka u ASMO sustavu vršimo sljedeće provjere:
- Provjera izrade sigurnosne kopije
- Provjera slobodnog prostora na disku
Provjera izrade sigurnosne kopije
U većini aplikacija važno je imati ažurirane sigurnosne kopije baze podataka tako da u slučaju kvara poslužitelja možete implementirati program na novi poslužitelj.
ASMO jednom tjedno stvara sigurnosnu kopiju i šalje je u pohranu. Kada se ovaj postupak uspješno završi, rezultat provjere uspjeha šalje se sustavu za nadzor. Rezultat provjere vrijedi 9 dana. Oni. Za kontrolu stvaranja sigurnosnih kopija koristi se mehanizam "provjera napretka", o kojem smo gore govorili.
Provjera slobodnog prostora na disku
Ako na disku nema dovoljno slobodnog prostora, baza podataka neće moći pravilno funkcionirati, stoga je važno kontrolirati količinu slobodnog prostora.
Prikladno je koristiti metriku za provjeru numeričkih parametara.
Metrika je numerička varijabla čija se vrijednost prenosi u sustav praćenja. Sustav za praćenje provjerava vrijednosti praga i izračunava metrički status.
Ispod je slika kako komponenta "Baza podataka" izgleda u sustavu nadzora:
Praćenje poslužitelja
Za praćenje poslužitelja koristimo sljedeće provjere i metrike:
1. Slobodan prostor na disku
Ako ponestane prostora na disku, aplikacija neće moći raditi. Koristimo 2 granične vrijednosti: prva razina je UPOZORENJE, druga razina je ALARM.
2. Prosječna vrijednost RAM-a u postocima po satu
Koristimo prosjek po satu jer... ne zanimaju nas rijetke rase.
3. Prosječni postotak CPU-a po satu
Koristimo prosjek po satu jer... ne zanimaju nas rijetke rase.
4. Provjera pinga
Provjerava je li poslužitelj na mreži. Sustav za nadzor može izvršiti ovu provjeru; nema potrebe za pisanjem koda.
Ispod je slika kako komponenta “Server” izgleda u sustavu nadzora:
Praćenje opreme
Reći ću vam kako se dolazi do podataka. Za svaku kontrolnu točku ceste (MPC) postoji zadatak u planeru zadataka, na primjer, "Survey MPC M2 km 200". Zadatak prima podatke sa svih MPC uređaja svakih 30 minuta.
Problem s komunikacijskim kanalom
Većina opreme nalazi se izvan grada, za prijenos podataka koristi se GSM mreža koja ne radi stabilno (mreža postoji ili je nema).
Zbog čestih kvarova na mreži, isprva je provjera MPC ankete u monitoringu izgledala ovako:
Postalo je jasno da to nije uspješna opcija, jer je bilo mnogo lažnih dojava o problemima. Zatim je odlučeno koristiti "provjeru napretka" za svaki uređaj, tj. Samo se signal uspjeha šalje sustavu za nadzor kada je uređaj ispitan bez greške. Vrijeme relevantnosti postavljeno je na 5 sati.
Sada nadzor šalje obavijesti o problemima samo kada se uređaj ne može prozvati dulje od 5 sati. Uz visok stupanj vjerojatnosti, to nisu lažne uzbune, već stvarni problemi.
Ispod je slika kako oprema izgleda u sustavu nadzora:
Važno!
Kada GSM mreža prestane s radom, svi MDC uređaji nisu anketirani. Kako bi smanjili broj e-poruka od sustava za nadzor, naši se inženjeri pretplaćuju na obavijesti o problemima s komponentama tipa "MPC", a ne "Uređaj". To vam omogućuje primanje jedne obavijesti za svaki MPC, umjesto primanja zasebne obavijesti za svaki uređaj.
Konačna shema praćenja ASMO
Sastavimo sve zajedno i vidimo kakvu shemu praćenja imamo.
Zaključak
Sažmimo.
Što nam je praćenje performansi ASMO-a dalo?
1. Vrijeme otklanjanja kvara se smanjilo
Već smo čuli o nedostacima od korisnika, ali ne prijavljuju svi korisnici nedostatke. Dogodilo se da smo saznali za kvar komponente sustava tjedan dana nakon što se pojavio. Sada nas sustav nadzora obavještava o problemima čim se problem otkrije.
2. Stabilnost sustava je povećana
Budući da su se nedostaci počeli otklanjati ranije, sustav je u cjelini počeo raditi mnogo stabilnije.
3. Smanjenje broja poziva tehničkoj podršci
Mnogi problemi sada su riješeni prije nego što korisnici uopće saznaju za njih. Korisnici su počeli rjeđe kontaktirati tehničku podršku. Sve to dobro utječe na našu reputaciju.
4. Povećanje lojalnosti kupaca i korisnika
Kupac je primijetio pozitivne promjene u stabilnosti sustava. Korisnici se susreću s manje problema korištenjem sustava.
5. Smanjite troškove tehničke podrške
Prestali smo s izvođenjem bilo kakvih ručnih provjera. Sada su sve provjere automatizirane. Ranije smo o problemima saznavali od korisnika, često je bilo teško razumjeti o kojem problemu korisnik govori. Sada većinu problema prijavljuje nadzorni sustav, obavijesti sadrže tehničke podatke iz kojih je uvijek jasno što je pošlo po zlu i gdje.
Važno!
Ne možete instalirati sustav za nadzor na istom poslužitelju na kojem se pokreću vaše aplikacije. Ako poslužitelj padne, aplikacije će prestati raditi i o tome neće imati koga obavijestiti.
Sustav za nadzor mora raditi na zasebnom poslužitelju u drugom podatkovnom centru.
Ako ne želite koristiti namjenski poslužitelj u novom podatkovnom centru, možete koristiti sustav za praćenje u oblaku. Naša tvrtka koristi sustav nadzora oblaka Zidium, no vi možete koristiti bilo koji drugi sustav nadzora. Cijena sustava za nadzor u oblaku niža je od najma novog poslužitelja.
Preporuke:
- Razdvojite aplikacije i sustave u obliku stabla komponenti što je moguće detaljnije, tako da će biti zgodno razumjeti gdje i što je pokvareno, a kontrola će biti potpunija.
- Da biste provjerili funkcionalnost komponente, koristite testove. Bolje je koristiti mnogo jednostavnih provjera nego jednu složenu.
- Konfigurirajte metričke pragove na strani sustava za praćenje, umjesto da ih pišete u kodu. To će vas spasiti od ponovnog kompajliranja, ponovnog konfiguriranja ili ponovnog pokretanja aplikacije.
- Za prilagođene provjere upotrijebite marginu vremena relevantnosti kako biste izbjegli primanje lažnih obavijesti jer je nekim provjerama trebalo malo više vremena nego inače.
- Nastojte da komponente u sustavu nadzora postanu crvene samo kada definitivno postoji problem. Ako postanu crveni uzalud, tada ćete prestati obraćati pozornost na obavijesti nadzornog sustava, njegovo značenje će se izgubiti.
Ako još ne koristite sustav za nadzor, počnite! Nije tako teško kao što se čini. Oduševite se pogledom na stablo zelenih sastojaka koje ste sami uzgojili.
Sretno.
Izvor: www.habr.com