Pozdrav svima!
Naša kompanija se bavi razvojem softvera i naknadnom tehničkom podrškom. Tehnička podrška ne zahteva samo ispravljanje grešaka, već i praćenje performansi naših aplikacija.
Na primjer, ako se jedan od servisa srušio, tada morate automatski snimiti ovaj problem i početi ga rješavati, a ne čekati da se nezadovoljni korisnici obrate tehničkoj podršci.
Imamo malu kompaniju, nemamo resurse za proučavanje i održavanje bilo kakvih složenih rješenja za praćenje aplikacija, morali smo pronaći jednostavno i efikasno rješenje.
Strategija praćenja
Nije lako provjeriti funkcionalnost aplikacije, ovaj zadatak je netrivijalan, moglo bi se reći i kreativan. Posebno je teško verifikovati složen sistem sa više veza.
Kako možeš pojesti slona? Samo u dijelovima! Ovaj pristup koristimo za praćenje aplikacija.
Suština naše strategije praćenja:
Podijelite svoju aplikaciju na komponente.
Kreirajte kontrolne provjere za svaku komponentu.
Komponenta se smatra operativnom ako se sve njene kontrolne provjere izvode bez grešaka. Aplikacija se smatra zdravom ako su sve njene komponente funkcionalne.
Dakle, svaki sistem se može predstaviti kao stablo komponenti. Složene komponente se dijele na jednostavnije. Jednostavne komponente imaju provjere.
Merila nisu namenjena za obavljanje funkcionalnog testiranja, oni nisu jedinični testovi. Kontrolne provjere trebaju provjeriti kako se komponenta osjeća u trenutnom trenutku, da li postoje svi resursi potrebni za njeno funkcionisanje i da li ima problema.
Nema čuda; većinu provjera morat će se samostalno razviti. Ali nemojte se plašiti, jer u većini slučajeva jedna provjera traje 5-10 redova koda, ali možete implementirati bilo koju logiku i jasno ćete razumjeti kako provjera funkcionira.
Nadzorni sistem
Recimo da smo aplikaciju podijelili na komponente, osmislili i implementirali provjere za svaku komponentu, ali šta da radimo s rezultatima tih provjera? Kako da znamo da li neka provjera nije uspjela?
Trebaće nam sistem za nadzor. Ona će obavljati sljedeće poslove:
- Primite rezultate testa i koristite ih za određivanje statusa komponenti.
Vizuelno, ovo izgleda kao isticanje stabla komponenti. Funkcionalne komponente postaju zelene, one problematične postaju crvene. - Izvršite opće provjere iz kutije.
Sistem za nadzor može sam izvršiti neke provjere. Zašto ponovo izumiti točak, hajde da ih iskoristimo. Na primjer, možete provjeriti otvara li se web stranica ili server pinguje. - Zainteresovanim stranama šaljite obavještenja o problemima.
- Vizualizacija monitoring podataka, obezbjeđivanje izvještaja, grafikona i statistike.
Kratak opis ASMO sistema
Najbolje je objasniti na primjeru. Pogledajmo kako je organizovano praćenje performansi ASMO sistema.
ASMO je automatizovani sistem meteorološke podrške. Sistem pomaže stručnjacima putnih službi da shvate gde i kada je potrebno tretirati put materijalima za odleđivanje. Sistem prikuplja podatke sa kontrolnih tačaka na putu. Kontrolna tačka na putu je mjesto na putu gdje je instalirana oprema: meteorološka stanica, video kamera itd. Da bi predvidio opasne situacije, sistem prima vremensku prognozu iz eksternih izvora.
Dakle, sastav sistema je prilično tipičan: web stranica, agent, oprema. Počnimo sa praćenjem.
Rastavljanje sistema na komponente
U ASMO sistemu se mogu razlikovati sljedeće komponente:
1. Lični račun
Ovo je web aplikacija. U najmanju ruku, trebate provjeriti da li je aplikacija dostupna na Internetu.
2. Baza podataka
Baza podataka pohranjuje podatke koji su važni za izvještavanje i morate osigurati da su sigurnosne kopije baze podataka uspješno kreirane.
3. Server
Pod serverom 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 po rasporedu. U najmanju ruku, trebate provjeriti da li je usluga pokrenuta.
5. Zadatak agenta
Nije dovoljno samo znati da agent radi. Agent može raditi, ali ne i obavljati dodijeljene zadatke. Podijelimo komponentu agenta na zadatke i provjerimo da li svaki zadatak agenta radi uspješno.
6. Kontrolne tačke na putu (kontejner svih MPC)
Postoji mnogo kontrolnih tačaka na cesti, pa hajde da kombinujemo sve MPC u jednu komponentu. Ovo će učiniti praktičnijim čitanje podataka praćenja. Prilikom pregleda statusa komponente “ASMO sistem” odmah će biti jasno gdje su problemi: u aplikacijama, hardveru ili u sistemu maksimalne kontrole.
7. Kontrolna tačka na putu (jedno maksimalno ograničenje)
Smatrat ćemo da je ova komponenta upotrebljiva ako su svi uređaji na ovom MPC-u uslužni.
8. Uređaj
Ovo je video kamera ili meteorološka stanica koja je instalirana na granici maksimalne koncentracije. Potrebno je provjeriti da li uređaj ispravno radi.
U sistemu za praćenje, stablo komponenti će izgledati ovako:
Nadgledanje web aplikacija
Dakle, podijelili smo sistem na komponente, sada trebamo smisliti provjere za svaku komponentu.
Za praćenje web aplikacije koristimo sljedeće provjere:
1. Provjera otvaranja glavne stranice
Ovu provjeru vrši sistem za nadzor. Da bismo ga izvršili, navodimo adresu stranice, očekivani fragment odgovora i maksimalno vrijeme izvršenja zahtjeva.
2. Provjera roka plaćanja domene
Veoma važna provera. Kada domena ostane neplaćena, korisnici ne mogu otvoriti stranicu. Rješavanje problema može potrajati nekoliko dana, jer... DNS promjene se ne primjenjuju odmah.
3. Provjera SSL certifikata
Danas gotovo sve web stranice koriste https protokol za pristup. Da bi protokol ispravno radio, potreban vam je važeći SSL certifikat.
Ispod je komponenta “Lični račun” u sistemu praćenja:
Sve gore navedene provjere će raditi za većinu aplikacija i ne zahtijevaju kodiranje. Ovo je jako cool jer možete početi nadgledati bilo koju web aplikaciju za 5 minuta. Ispod su dodatne provjere koje se mogu izvršiti za web aplikaciju, ali je njihova implementacija složenija i specifična za aplikaciju, pa ih nećemo obrađivati u ovom članku.
Šta još možete provjeriti?
Da biste potpunije nadgledali svoju web aplikaciju, možete izvršiti sljedeće provjere:
- Broj JavaScript grešaka po periodu
- Broj grešaka na strani web aplikacije (back-end) za period
- Broj neuspješnih odgovora web aplikacije (kod odgovora 404, 500, itd.)
- Prosječno vrijeme izvršenja upita
Nadgledanje Windows servisa (agent)
U ASMO sistemu agent igra ulogu planera zadataka, koji izvršava zakazane zadatke u pozadini.
Ako se svi zadaci agenta uspješno završe, agent radi ispravno. Ispostavilo se da da biste nadgledali agenta, morate pratiti njegove zadatke. Stoga komponentu “Agent” dijelimo na zadatke. Za svaki zadatak ćemo kreirati posebnu komponentu u sistemu za praćenje, gdje će komponenta „Agent“ biti „roditelj“.
Komponentu agenta dijelimo na podređene komponente (zadatke):
Dakle, složenu komponentu smo rastavili na nekoliko jednostavnih. Sada moramo smisliti provjere za svaku jednostavnu komponentu. Imajte na umu da roditeljska komponenta “Agent” neće imati nikakve provjere, jer će sistem nadzora izračunati njen status nezavisno na osnovu statusa svojih podređenih komponenti. Drugim riječima, ako su svi zadaci uspješno završeni, onda agent uspješno radi.
U ASMO sistemu postoji više od stotinu zadataka, da li je zaista potrebno osmisliti 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 sistem koristi samo univerzalne provjere za zadatke i to je dovoljno za praćenje performansi sistema.
Provjera napretka
Najjednostavnija i najefikasnija provjera je provjera izvršenja. Provjera potvrđuje da je zadatak završen bez grešaka. Svi zadaci imaju ovu provjeru.
Algoritam verifikacije
Nakon svakog izvršenja zadatka, morate poslati rezultat provjere USPJEHA u sistem za nadzor ako je izvršenje zadatka bilo uspješno, ili GREŠKA ako je izvršenje završeno sa greškom.
Ova provjera može otkriti sljedeće probleme:
- Zadatak se pokreće, ali ne uspijeva uz grešku.
- Zadatak je prestao da se izvodi, na primjer, zamrznuo se.
Pogledajmo kako se ovi problemi rješavaju detaljnije.
Problem 1 – Zadatak se pokreće, ali ne uspijeva uz grešku
Ispod je slučaj u kojem se zadatak pokreće, ali ne uspijeva između 14:00 i 16:00.
Slika pokazuje da kada zadatak ne uspije, signal se odmah šalje u sistem za nadzor i status odgovarajuće provjere u sistemu za praćenje postaje alarm.
Imajte na umu da u sistemu za nadzor status komponente zavisi od statusa verifikacije. Status alarma provjere će promijeniti sve komponente višeg nivoa u alarm, pogledajte sliku ispod.
Problem 2 - Zadatak je prestao da se izvršava (zamrznut)
Kako će sistem za praćenje shvatiti da je zadatak zapeo?
Rezultat provjere ima rok važenja, na primjer, 1 sat. Ako prođe sat vremena i nema novog rezultata testa, sistem za nadzor će postaviti status testa na alarm.
Na gornjoj slici, svjetla su ugašena u 14:00 sati. U 15:00, sistem za praćenje će otkriti da je rezultat testa (od 14:00) pokvaren, jer Vrijeme relevantnosti je isteklo (jedan sat), ali nema novog rezultata, te će provjeru prebaciti na status alarma.
U 16:00 svjetla su se ponovo upalila, program će završiti zadatak i poslati rezultat izvršenja u sistem za praćenje, status testa će ponovo postati uspješan.
Koje vrijeme provere relevantnosti trebam koristiti?
Vrijeme relevantnosti mora biti veće od perioda izvršenja zadatka. Preporučujem da postavite vrijeme relevantnosti 2-3 puta duže od perioda izvršenja zadatka. Ovo je neophodno kako biste izbjegli primanje lažnih obavijesti kada je, na primjer, zadatak trajao duže nego inače ili je neko ponovo učitao program.
Provjera napretka
ASMO sistem ima zadatak “Load Forecast” koji pokušava da preuzme novu prognozu sa eksternog izvora jednom na sat. Tačno vrijeme kada se nova prognoza pojavljuje u eksternom sistemu nije poznato, ali se zna da se to dešava 2 puta dnevno. Ispada da ako nema nove prognoze nekoliko sati, onda je to normalno, ali ako nema nove prognoze duže od jednog dana, onda je negdje nešto puklo. Na primjer, format podataka u eksternom sistemu prognoze može se promijeniti, zbog čega ASMO neće vidjeti novo izdanje prognoze.
Algoritam verifikacije
Zadatak šalje rezultat provjere USPJEHA u sistem za praćenje kada uspije ostvariti napredak (preuzimanje nove vremenske prognoze). Ako nema napretka ili se pojavi greška, onda se ništa ne šalje u sistem za nadzor.
Provjera mora imati interval relevantnosti tako da se za to vrijeme garantuje da će primiti novi napredak.
Imajte na umu da ćemo o problemu saznati sa zakašnjenjem, jer sistem za praćenje čeka da istekne period važenja posljednjeg rezultata skeniranja. Stoga, rok važenja provjere ne mora biti predug.
Praćenje baze podataka
Za kontrolu baze podataka u ASMO sistemu vršimo sljedeće provjere:
- Provjera kreiranja sigurnosne kopije
- Provjera slobodnog prostora na disku
Provjera kreiranja sigurnosne kopije
U većini aplikacija važno je imati ažurirane sigurnosne kopije baze podataka, tako da ako server pokvari, možete postaviti program na novi server.
ASMO kreira rezervnu kopiju jednom sedmično i šalje je u skladište. Kada se ovaj postupak uspješno završi, rezultat provjere uspjeha se šalje u sistem za praćenje. Rezultat verifikacije važi 9 dana. One. Za kontrolu stvaranja sigurnosnih kopija koristi se mehanizam „provjere 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, pa je važno kontrolirati količinu slobodnog prostora.
Pogodno je koristiti metriku za provjeru numeričkih parametara.
Metrics je numerička varijabla čija se vrijednost prenosi u sistem za praćenje. Sistem za nadzor provjerava granične vrijednosti i izračunava metrički status.
Ispod je slika kako izgleda komponenta “Baza podataka” u sistemu za praćenje:
Nadgledanje servera
Za praćenje servera koristimo sljedeće provjere i metrike:
1. Oslobodite prostor na disku
Ako ponestane prostora na disku, aplikacija neće moći raditi. Koristimo 2 granične vrijednosti: prvi nivo je UPOZORENJE, drugi nivo je ALARM.
2. Prosječna vrijednost RAM-a u postocima po satu
Koristimo satni prosjek jer... ne zanimaju nas rijetke rase.
3. Prosječan CPU postotak po satu
Koristimo satni prosjek jer... ne zanimaju nas rijetke rase.
4. Ping provjera
Provjerava da li je server na mreži. Sistem za nadzor može izvršiti ovu provjeru; nema potrebe za pisanjem koda.
Ispod je slika kako izgleda komponenta "Server" u sistemu za praćenje:
Monitoring opreme
Reći ću vam kako se dobijaju podaci. Za svaku kontrolnu tačku puta (MPC) postoji zadatak u planeru zadataka, na primjer, „Snimanje MPC M2 km 200“. Zadatak prima podatke sa svih MPC uređaja svakih 30 minuta.
Problem sa komunikacijskim kanalom
Većina opreme nalazi se van grada, za prenos podataka se koristi GSM mreža koja ne radi stabilno (mreža postoji, ili je nema).
Zbog čestih kvarova na mreži, u početku je provjera MPC ankete u monitoringu izgledala ovako:
Postalo je jasno da to nije funkcionalna opcija, jer je bilo mnogo lažnih obavijesti o problemima. Tada je odlučeno da se za svaki uređaj koristi „provjera napretka“, tj. Sistemu za nadzor se šalje samo signal uspjeha kada se uređaj anketira bez greške. Vrijeme relevantnosti je postavljeno na 5 sati.
Sada praćenje šalje obavještenja o problemima samo kada uređaj ne može biti ispitan duže od 5 sati. Sa velikim stepenom vjerovatnoće, to nisu lažni alarmi, već stvarni problemi.
Ispod je slika kako oprema izgleda u sistemu za praćenje:
Važno!
Kada GSM mreža prestane da radi, svi MDC uređaji se ne prozivaju. Kako bi smanjili broj e-poruka od sistema za praćenje, naši inženjeri se pretplate na obavijesti o problemima s komponentama tipa “MPC” umjesto “Uređaj”. Ovo vam omogućava da primite jedno obavještenje za svaki MPC, umjesto da primate zasebno obavještenje za svaki uređaj.
Konačna šema ASMO monitoringa
Hajde da sve sastavimo i vidimo kakvu šemu monitoringa imamo.
zaključak
Hajde da sumiramo.
Šta nam je dalo praćenje učinka ASMO?
1. Vrijeme otklanjanja kvarova je smanjeno
Ranije smo čuli za nedostatke od korisnika, ali svi korisnici ne prijavljuju nedostatke. Dešavalo se da smo za kvar neke sistemske komponente saznali nedelju dana nakon što se pojavio. Sada nas sistem za praćenje obavještava o problemima čim se problem otkrije.
2. Stabilnost sistema je povećana
Pošto su se kvarovi počeli otklanjati ranije, sistem je u cjelini počeo raditi mnogo stabilnije.
3. Smanjenje broja poziva tehničkoj podršci
Mnogi problemi su sada riješeni prije nego što korisnici i saznaju za njih. Korisnici su rjeđe počeli kontaktirati tehničku podršku. Sve ovo dobro utiče na našu reputaciju.
4. Povećanje lojalnosti kupaca i korisnika
Kupac je primijetio pozitivne promjene u stabilnosti sistema. Korisnici se susreću sa manje problema pri korištenju sistema.
5. Smanjite troškove tehničke podrške
Prestali smo obavljati bilo kakve ručne provjere. Sada su sve provjere automatizirane. Ranije smo o problemima učili od korisnika, često je bilo teško razumjeti o kojem problemu korisnik govori. Sada većinu problema prijavljuje sistem za praćenje; obavještenja sadrže tehničke podatke, koji uvijek jasno pokazuju šta je pošlo po zlu i gdje.
Važno!
Ne možete instalirati sistem za nadzor na istom serveru na kojem se pokreću vaše aplikacije. Ako server padne, aplikacije će prestati da rade i neće biti nikoga da o tome obavesti.
Sistem za nadzor mora raditi na posebnom serveru u drugom data centru.
Ako ne želite da koristite namenski server u novom data centru, možete koristiti sistem za praćenje u oblaku. Naša kompanija koristi Zidium cloud monitoring sistem, ali možete koristiti bilo koji drugi sistem za praćenje. Troškovi sistema za praćenje u oblaku su niži od iznajmljivanja novog servera.
Preporuke:
- Razbijte aplikacije i sisteme u obliku stabla komponenti što je moguće detaljnije, tako da će biti zgodno razumjeti gdje i šta je pokvareno, a kontrola će biti potpunija.
- Da biste provjerili funkcionalnost komponente, koristite testove. Bolje je koristiti više jednostavnih provjera nego jednu složenu.
- Konfigurišite metričke pragove na strani sistema za praćenje, umjesto da ih pišete u kodu. Ovo će vas uštedjeti od ponovnog kompajliranja, rekonfiguracije ili ponovnog pokretanja aplikacije.
- Za prilagođene provjere koristite vremensku marginu relevantnosti kako biste izbjegli primanje lažnih obavještenja jer je za neke provjere bilo potrebno malo duže nego inače.
- Pokušajte da komponente u sistemu za praćenje postanu crvene samo kada definitivno postoji problem. Ako uzalud pocrvene, tada ćete prestati obraćati pažnju na obavještenja sistema za praćenje, njegovo značenje će se izgubiti.
Ako još ne koristite sistem za nadzor, počnite! Nije tako teško kao što se čini. Opustite se gledajući drvo zelenih sastojaka koje ste sami uzgojili.
Sretno.
izvor: www.habr.com