Sveiki visi!
Mūsų įmonė užsiima programinės įrangos kūrimu ir vėlesniu techniniu palaikymu. Techninė pagalba reikalauja ne tik taisyti klaidas, bet ir stebėti mūsų programų veikimą.
Pavyzdžiui, jei viena iš paslaugų sugenda, turite automatiškai įrašyti šią problemą ir pradėti ją spręsti, o ne laukti, kol nepatenkinti vartotojai susisieks su technine pagalba.
Turime nedidelę įmonę, neturime resursų tyrinėti ir prižiūrėti kokių nors kompleksinių programų stebėjimo sprendimų, reikėjo rasti paprastą ir efektyvų sprendimą.
Stebėjimo strategija
Patikrinti programos funkcionalumą nėra lengva, ši užduotis yra nebanali, netgi galima sakyti, kūrybinga. Ypač sunku patikrinti sudėtingą kelių grandžių sistemą.
Kaip galite valgyti dramblį? Tik dalimis! Šį metodą naudojame programoms stebėti.
Mūsų stebėjimo strategijos esmė:
Padalinkite programą į komponentus.
Sukurkite kiekvieno komponento valdymo patikras.
Komponentas laikomas geros būklės, jei visi jo valdymo patikrinimai atliekami be klaidų. Programa laikoma sveika, jei visi jos komponentai veikia.
Taigi bet kurią sistemą galima pavaizduoti kaip komponentų medį. Sudėtingi komponentai skirstomi į paprastesnius. Paprasti komponentai turi patikrinimus.
Etalonai nėra skirti funkciniams testams atlikti, jie nėra vienetiniai testai. Kontroliniai patikrinimai turėtų patikrinti, kaip komponentas jaučiasi esamu laiko momentu, ar yra visi jo veikimui reikalingi ištekliai ir ar nėra problemų.
Stebuklų nebūna; daugumą čekių reikės sukurti savarankiškai. Tačiau neišsigąskite, nes daugeliu atvejų vienas patikrinimas užima 5-10 kodo eilučių, tačiau galite įgyvendinti bet kokią logiką ir aiškiai suprasite, kaip patikrinimas veikia.
Stebėjimo sistema
Tarkime, suskirstėme programą į komponentus, sugalvojome ir įdiegėme kiekvieno komponento patikras, bet ką daryti su šių patikrinimų rezultatais? Kaip sužinoti, ar koks nors patikrinimas nepavyko?
Mums reikės stebėjimo sistemos. Ji atliks šias užduotis:
- Gaukite bandymo rezultatus ir naudokite juos komponentų būsenai nustatyti.
Vizualiai tai atrodo kaip komponento medžio paryškinimas. Funkciniai komponentai nusidažo žaliai, probleminiai – raudonai. - Atlikite bendrąsias patikras iš dėžutės.
Stebėjimo sistema kai kuriuos patikrinimus gali atlikti pati. Kam išradinėti dviratį iš naujo, naudokimės jais. Pavyzdžiui, galite patikrinti, ar atidaromas svetainės puslapis arba ar serveris neveikia. - Siųsti pranešimus apie problemas suinteresuotoms šalims.
- Stebėsenos duomenų vizualizavimas, ataskaitų, grafikų ir statistikos teikimas.
Trumpas ASMO sistemos aprašymas
Geriausia paaiškinti pavyzdžiu. Pažiūrėkime, kaip organizuojamas ASMO sistemos veikimo stebėjimas.
ASMO yra automatizuota meteorologinės pagalbos sistema. Sistema padeda kelių tarnybos specialistams suprasti, kur ir kada reikia apdoroti kelią ledą šalinančiomis medžiagomis. Sistema renka duomenis iš kelių kontrolės punktų. Kelių kontrolės punktas – tai vieta kelyje, kurioje sumontuota įranga: meteorologinė stotis, vaizdo kamera ir kt. Siekdama numatyti pavojingas situacijas, sistema gauna orų prognozes iš išorinių šaltinių.
Taigi, sistemos sudėtis gana tipiška: svetainė, agentas, įranga. Pradėkime stebėti.
Sistemos suskaidymas į komponentus
ASMO sistemoje galima išskirti šiuos komponentus:
1. Asmeninė sąskaita
Tai žiniatinklio programa. Bent jau turite patikrinti, ar programa yra prieinama internete.
2. Duomenų bazė
Duomenų bazėje saugomi ataskaitoms svarbūs duomenys, todėl turite užtikrinti, kad duomenų bazės atsarginės kopijos būtų sukurtos sėkmingai.
3. Serveris
Serveryje turime omenyje aparatinę įrangą, kurioje veikia programos. Būtina patikrinti HDD, RAM, procesoriaus būseną.
4. Agentas
Tai „Windows“ paslauga, kuri pagal tvarkaraštį atlieka daugybę skirtingų užduočių. Bent jau turite patikrinti, ar paslauga veikia.
5. Agento užduotis
Vien žinoti, kad agentas dirba, neužtenka. Agentas gali dirbti, bet neatlikti jam pavestų užduočių. Padalinkime agento komponentą į užduotis ir patikrinkime, ar kiekviena agento užduotis veikia sėkmingai.
6. Kelių kontrolės punktai (visų MPC konteineris)
Yra daug kelių kontrolės punktų, todėl sujungkime visus MPC į vieną komponentą. Taip bus patogiau skaityti stebėjimo duomenis. Peržiūrėjus „ASMO sistemos“ komponento būseną, iš karto bus aišku, kur yra problemos: programose, techninėje įrangoje ar maksimalioje valdymo sistemoje.
7. Kelių kontrolės punktas (viena didžiausia riba)
Laikysime, kad šis komponentas yra tinkamas naudoti, jei visi šio MPC įrenginiai yra tinkami naudoti.
8. Įrenginys
Tai vaizdo kamera arba meteorologinė stotis, kuri sumontuota esant maksimaliai koncentracijos ribai. Būtina patikrinti, ar įrenginys tinkamai veikia.
Stebėjimo sistemoje komponentų medis atrodys taip:
Žiniatinklio programų stebėjimas
Taigi, mes suskirstėme sistemą į komponentus, dabar turime sugalvoti kiekvieno komponento patikrinimus.
Norėdami stebėti žiniatinklio programą, naudojame šiuos patikrinimus:
1. Pagrindinio puslapio atidarymo tikrinimas
Šį patikrinimą atlieka stebėjimo sistema. Norėdami jį įvykdyti, nurodome puslapio adresą, laukiamą atsakymo fragmentą ir maksimalų užklausos vykdymo laiką.
2. Domeno mokėjimo termino tikrinimas
Labai svarbus patikrinimas. Kai domenas lieka neapmokėtas, vartotojai negali atidaryti svetainės. Problemos sprendimas gali užtrukti kelias dienas, nes... DNS pakeitimai taikomi ne iš karto.
3. SSL sertifikato tikrinimas
Šiais laikais beveik visos svetainės prieigai naudoja https protokolą. Kad protokolas veiktų tinkamai, reikalingas galiojantis SSL sertifikatas.
Žemiau yra stebėjimo sistemos komponentas „Asmeninė paskyra“.
Visi aukščiau pateikti patikrinimai veiks daugumoje programų ir nereikalauja kodavimo. Tai labai šaunu, nes per 5 minutes galite pradėti stebėti bet kurią žiniatinklio programą. Toliau pateikiami papildomi žiniatinklio programos patikrinimai, tačiau jų įgyvendinimas yra sudėtingesnis ir labiau būdingas konkrečiai programai, todėl šiame straipsnyje jų neapžvelgsime.
Ką dar galite patikrinti?
Norėdami visapusiškiau stebėti žiniatinklio programą, galite atlikti šiuos patikrinimus:
- „JavaScript“ klaidų skaičius per laikotarpį
- Klaidų skaičius žiniatinklio programos pusėje (galinėje dalyje) per laikotarpį
- Nesėkmingų žiniatinklio programų atsakymų skaičius (atsakymo kodas 404, 500 ir kt.)
- Vidutinis užklausos vykdymo laikas
„Windows“ paslaugos stebėjimas (agentas)
ASMO sistemoje agentas atlieka užduočių planuotojo vaidmenį, kuris fone vykdo suplanuotas užduotis.
Jei visos agento užduotys sėkmingai baigtos, agentas veikia tinkamai. Pasirodo, norint stebėti agentą, reikia stebėti jo užduotis. Todėl „Agento“ komponentą suskirstome į užduotis. Kiekvienai užduočiai stebėjimo sistemoje sukursime atskirą komponentą, kur komponentas „Agentas“ bus „tėvas“.
Agento komponentą padalijame į antrinius komponentus (užduotis):
Taigi, mes suskirstėme sudėtingą komponentą į keletą paprastų. Dabar turime sugalvoti kiekvieno paprasto komponento patikrinimus. Atkreipkite dėmesį, kad pirminis komponentas „Agentas“ neturės jokių patikrinimų, nes stebėjimo sistema apskaičiuos jo būseną savarankiškai, remdamasi antrinių komponentų būsena. Kitaip tariant, jei visos užduotys sėkmingai atliktos, agentas veikia sėkmingai.
ASMO sistemoje yra daugiau nei šimtas užduočių, ar tikrai kiekvienai užduočiai reikia sugalvoti unikalius patikrinimus? Žinoma, kontrolė bus geresnė, jei kiekvienai agento užduočiai sugalvosime ir įdiegsime savo specialius patikrinimus, tačiau daugeliu atvejų pakanka naudoti universalius patikrinimus.
ASMO sistemoje naudojami tik universalūs užduočių patikrinimai ir to pakanka sistemos veikimui stebėti.
Tikrinama eiga
Paprasčiausias ir efektyviausias patikrinimas yra vykdymo patikrinimas. Patikrinimas patvirtina, kad užduotis atlikta be klaidų. Visos užduotys turi šį patikrinimą.
Tikrinimo algoritmas
Po kiekvienos užduoties vykdymo turite išsiųsti SĖKMĖS patikrinimo rezultatą stebėjimo sistemai, jei užduotis buvo įvykdyta sėkmingai, arba ERROR, jei vykdymas baigtas su klaida.
Šis patikrinimas gali aptikti šias problemas:
- Užduotis vykdoma, bet nepavyksta dėl klaidos.
- Užduotis nustojo vykdyti, pavyzdžiui, ji užstrigo.
Pažiūrėkime, kaip šios problemos sprendžiamos išsamiau.
1 problema – užduotis vykdoma, bet nepavyksta dėl klaidos
Toliau pateikiamas atvejis, kai užduotis vykdoma, bet nepavyksta nuo 14:00 iki 16:00.
Paveikslėlyje parodyta, kad nepavykus užduočiai nedelsiant siunčiamas signalas į stebėjimo sistemą ir atitinkamo patikrinimo būsena stebėjimo sistemoje tampa aliarmu.
Atkreipkite dėmesį, kad stebėjimo sistemoje komponento būsena priklauso nuo patikros būsenos. Patikros aliarmo būsena pakeis visus aukštesnio lygio komponentus į aliarmą, žr. toliau pateiktą paveikslėlį.
2 problema – užduotis nustojo vykdyti (užšaldyta)
Kaip stebėjimo sistema supras, kad užduotis užstrigo?
Patikrinimo rezultato galiojimo laikas, pavyzdžiui, 1 valanda. Jei praeina valanda ir nėra naujo testo rezultato, stebėjimo sistema nustatys testo būseną į aliarmą.
Viršuje esančiame paveikslėlyje šviesa buvo išjungta 14:00 val. 15:00 stebėjimo sistema nustatys, kad tyrimo rezultatas (nuo 14:00) yra supuvęs, nes Aktualumo laikas baigėsi (viena valanda), tačiau naujo rezultato nėra ir patikrinimas bus perjungtas į aliarmo būseną.
16:00 vėl buvo įjungtos šviesos, programa atliks užduotį ir išsiųs vykdymo rezultatą į stebėjimo sistemą, testo būsena vėl taps sėkminga.
Kokį patikrinimo tinkamumo laiką turėčiau naudoti?
Aktualumo laikas turi būti ilgesnis nei užduoties vykdymo laikotarpis. Rekomenduoju nustatyti aktualumo laiką 2-3 kartus ilgesnį nei užduoties vykdymo laikotarpis. Tai būtina norint išvengti klaidingų pranešimų, kai, pavyzdžiui, užduotis užtruko ilgiau nei įprastai arba kažkas iš naujo įkėlė programą.
Tikrinama eiga
ASMO sistema turi užduotį „Įkelti prognozę“, kuri kartą per valandą bando atsisiųsti naują prognozę iš išorinio šaltinio. Tikslus laikas, kada išorinėje sistemoje pasirodo nauja prognozė, nėra žinomas, tačiau žinoma, kad tai nutinka 2 kartus per dieną. Pasirodo, jei kelioms valandoms nėra naujos prognozės, tai yra normalu, bet jei daugiau nei dienai nėra naujos prognozės, tada kažkas kažkur sugedo. Pavyzdžiui, išorinės prognozių sistemos duomenų formatas gali pasikeisti, todėl ASMO nematys naujos prognozės leidimo.
Tikrinimo algoritmas
Užduotis siunčia SĖKMĖS patikrinimo rezultatą į stebėjimo sistemą, kai pavyksta gauti pažangą (atsisiunčiant naują orų prognozę). Jei nėra pažangos arba įvyksta klaida, niekas nesiunčiamas į stebėjimo sistemą.
Patikrinimas turi turėti tokį aktualumo intervalą, kad per tą laiką būtų garantuotas naujas progresas.
Atkreipkite dėmesį, kad apie problemą sužinosime su vėlavimu, nes stebėjimo sistema laukia, kol baigsis paskutinio nuskaitymo rezultato galiojimo laikas. Todėl čekio galiojimo laikas neturi būti per ilgas.
Duomenų bazės stebėjimas
Norėdami valdyti duomenų bazę ASMO sistemoje, atliekame šiuos patikrinimus:
- Atsarginės kopijos kūrimo patikrinimas
- Tikrinama laisvos vietos diske
Atsarginės kopijos kūrimo patikrinimas
Daugumoje programų svarbu turėti atnaujintas duomenų bazės atsargines kopijas, kad sugedus serveriui galėtumėte įdiegti programą naujame serveryje.
ASMO kartą per savaitę sukuria atsarginę kopiją ir siunčia ją į saugyklą. Sėkmingai užbaigus šią procedūrą, sėkmės patikrinimo rezultatas siunčiamas į stebėjimo sistemą. Patikrinimo rezultatas galioja 9 dienas. Tie. Norint kontroliuoti atsarginių kopijų kūrimą, naudojamas „pažangos tikrinimo“ mechanizmas, kurį aptarėme aukščiau.
Tikrinama laisvos vietos diske
Jei diske nėra pakankamai laisvos vietos, duomenų bazė negalės tinkamai veikti, todėl svarbu kontroliuoti laisvos vietos kiekį.
Skaitiniams parametrams patikrinti patogu naudoti metriką.
Metrika yra skaitinis kintamasis, kurio reikšmė perduodama stebėjimo sistemai. Stebėjimo sistema tikrina ribines vertes ir apskaičiuoja metrinę būseną.
Žemiau pateikiamas paveikslėlis, kaip stebėjimo sistemoje atrodo „Duomenų bazės“ komponentas:
Serverio stebėjimas
Norėdami stebėti serverį, naudojame šiuos patikrinimus ir metrikas:
1. Laisvos vietos diske
Jei diske baigsis vieta, programa neveiks. Mes naudojame 2 ribines vertes: pirmasis lygis yra ĮSPĖJIMAS, antrasis lygis yra ALARM.
2. Vidutinė RAM vertė procentais per valandą
Naudojame valandinį vidurkį, nes... mūsų nedomina retos rasės.
3. Vidutinis procesoriaus procentas per valandą
Naudojame valandinį vidurkį, nes... mūsų nedomina retos rasės.
4. Ping patikrinimas
Patikrina, ar serveris yra prisijungęs. Stebėjimo sistema gali atlikti šį patikrinimą, kodo rašyti nereikia.
Žemiau pateikiamas vaizdas, kaip stebėjimo sistemoje atrodo „Serveris“ komponentas:
Įrangos stebėjimas
Aš jums pasakysiu, kaip gauti duomenys. Kiekvienam kelių valdymo taškui (MPC) užduočių planuoklyje yra užduotis, pavyzdžiui, „Apklausa MPC M2 km 200“. Užduotis gauna duomenis iš visų MPC įrenginių kas 30 minučių.
Ryšio kanalo problema
Didžioji dalis įrangos yra už miesto, duomenų perdavimui naudojamas GSM tinklas, kuris neveikia stabiliai (tinklas yra arba jo nėra).
Dėl dažnų tinklo gedimų iš pradžių MPC apklausos tikrinimas stebėjime atrodė taip:
Tapo aišku, kad tai neveikianti parinktis, nes buvo daug melagingų pranešimų apie problemas. Tada buvo nuspręsta kiekvienam įrenginiui naudoti „progreso patikrą“, t.y. Stebėjimo sistemai siunčiamas tik sėkmės signalas, kai įrenginys apklausiamas be klaidos. Atitinkamas laikas buvo nustatytas į 5 valandas.
Dabar stebėjimas siunčia pranešimus apie problemas tik tada, kai įrenginys negali būti apklausiamas ilgiau nei 5 valandas. Su didele tikimybe tai ne klaidingi pavojaus signalai, o tikros problemos.
Žemiau pateikiamas vaizdas, kaip įranga atrodo stebėjimo sistemoje:
Svarbu!
Kai GSM tinklas nustoja veikti, visi MDC įrenginiai neapklausomi. Siekdami sumažinti el. laiškų iš stebėjimo sistemos skaičių, mūsų inžinieriai prenumeruoja pranešimus apie „MPC“, o ne „Įrenginio“ tipo komponentų problemas. Tai leidžia gauti vieną pranešimą apie kiekvieną MPC, o ne gauti atskirą pranešimą apie kiekvieną įrenginį.
Galutinė ASMO stebėjimo schema
Sudėkime viską ir pažiūrėkime, kokią stebėjimo schemą turime.
išvada
Apibendrinkime.
Ką mums davė ASMO veiklos stebėjimas?
1. Sutrumpėjo defektų šalinimo laikas
Anksčiau girdėjome apie defektus iš vartotojų, tačiau ne visi vartotojai praneša apie defektus. Taip atsitiko, kad apie sistemos komponento gedimą sužinojome praėjus savaitei po jo atsiradimo. Dabar stebėjimo sistema praneša mums apie problemas, kai tik aptinkama problema.
2. Padidėjo sistemos stabilumas
Kadangi defektai buvo pradėti šalinti anksčiau, visa sistema pradėjo veikti daug stabiliau.
3. Sumažinti skambučių skaičių į techninę pagalbą
Daugelis problemų dabar išspręstos vartotojams net apie jas nesužinojus. Vartotojai rečiau kreipėsi į techninę pagalbą. Visa tai turi gerą poveikį mūsų reputacijai.
4. Klientų ir vartotojų lojalumo didinimas
Klientas pastebėjo teigiamus sistemos stabilumo pokyčius. Naudodami sistemą vartotojai susiduria su mažiau problemų.
5. Sumažinkite techninės pagalbos išlaidas
Nustojome atlikti bet kokius rankinius patikrinimus. Dabar visi patikrinimai yra automatizuoti. Anksčiau apie problemas sužinodavome iš vartotojų, dažnai būdavo sunku suprasti, apie kokią problemą vartotojas kalba. Dabar apie daugumą problemų praneša stebėjimo sistema, pranešimuose pateikiami techniniai duomenys, kurie visada aiškiai parodo, kas ir kur nutiko.
Svarbu!
Negalite įdiegti stebėjimo sistemos tame pačiame serveryje, kuriame veikia jūsų programos. Jei serveris sugenda, programos nustos veikti ir nebus kam apie tai pranešti.
Stebėjimo sistema turi veikti atskirame serveryje kitame duomenų centre.
Jei nenorite naudoti dedikuoto serverio naujame duomenų centre, galite naudoti debesų stebėjimo sistemą. Mūsų įmonė naudoja Zidium debesų stebėjimo sistemą, tačiau galite naudoti bet kurią kitą stebėjimo sistemą. Debesų stebėjimo sistemos kaina yra mažesnė nei naujo serverio nuoma.
Rekomendacijos:
- Suskaidykite programas ir sistemas komponentų medžio pavidalu kuo detaliau, kad būtų patogu suprasti, kur ir kas sugedo, o valdymas bus pilnesnis.
- Norėdami patikrinti komponento funkcionalumą, naudokite testus. Geriau naudoti daug paprastų patikrinimų nei vieną sudėtingą.
- Konfigūruokite metrinius slenksčius stebėjimo sistemos šone, o ne rašykite jas kodu. Taip nereikės iš naujo kompiliuoti, iš naujo konfigūruoti ar paleisti programą iš naujo.
- Tinkintoms patikroms naudokite atitinkamo laiko ribą, kad negautumėte klaidingų pranešimų, nes kai kurios patikros užtruko šiek tiek ilgiau nei įprastai.
- Stenkitės, kad stebėjimo sistemos komponentai taptų raudoni tik tada, kai tikrai yra problemų. Jei jie veltui pasidarys raudoni, tada nustosite kreipti dėmesį į stebėjimo sistemos pranešimus, jų prasmė bus prarasta.
Jei dar nenaudojate stebėjimo sistemos, pradėkite! Tai nėra taip sunku, kaip atrodo. Mėgaukitės žiūrėdami į žalią ingredientų medį, kurį užauginote patys.
Sėkmės.
Šaltinis: www.habr.com