Hello!
Cégünk szoftverfejlesztéssel és az azt követő műszaki támogatással foglalkozik. A technikai támogatás nemcsak a hibák kijavítását igényli, hanem alkalmazásaink teljesítményének figyelemmel kísérését is.
Például, ha az egyik szolgáltatás összeomlott, akkor automatikusan rögzítenie kell ezt a problémát, és el kell kezdenie a megoldást, és nem kell megvárnia, amíg az elégedetlen felhasználók kapcsolatba lépnek a műszaki támogatással.
Kis cégünk van, nincs forrásunk az alkalmazások figyelésére szolgáló komplex megoldások tanulmányozására és karbantartására, egyszerű és hatékony megoldást kellett találnunk.
Monitoring stratégia
Egy alkalmazás működőképességét nem könnyű ellenőrizni, ez a feladat nem triviális, akár kreatívnak is mondható. Különösen nehéz ellenőrizni egy összetett többlinkes rendszert.
Hogyan lehet megenni egy elefántot? Csak részletekben! Ezt a megközelítést alkalmazzuk az alkalmazások figyelésére.
Monitoring stratégiánk lényege:
Bontsa fel az alkalmazást összetevőkre.
Hozzon létre vezérlőellenőrzéseket minden egyes összetevőhöz.
Egy komponens akkor tekinthető működőképesnek, ha minden ellenőrzési ellenőrzése hiba nélkül történik. Egy alkalmazás akkor tekinthető egészségesnek, ha minden összetevője működőképes.
Így bármely rendszer ábrázolható komponensek fájaként. Az összetett összetevőket egyszerűbbekre bontják. Az egyszerű alkatrészek ellenőrzésekkel rendelkeznek.
A benchmarkok nem funkcionális tesztelést végeznek, nem egységtesztek. Az ellenőrzések során ellenőrizni kell, hogyan érzi magát az adott komponens az adott pillanatban, megvan-e a működéséhez szükséges összes erőforrás, és nincs-e probléma.
Csodák nincsenek, a legtöbb ellenőrzést önállóan kell kidolgozni. De ne ijedjen meg, mert a legtöbb esetben egy ellenőrzés 5-10 sornyi kódot vesz igénybe, de bármilyen logikát megvalósíthat, és világosan megérti az ellenőrzés működését.
Megfigyelő-rendszer
Tegyük fel, hogy az alkalmazást komponensekre bontottuk, minden komponenshez kitaláltuk és végrehajtottuk az ellenőrzéseket, de mi a teendő ezen ellenőrzések eredményeivel? Honnan tudhatjuk, hogy valamelyik ellenőrzés sikertelen volt?
Szükségünk lesz egy ellenőrző rendszerre. A következő feladatokat fogja ellátni:
- Kapja meg a teszteredményeket, és használja azokat az összetevők állapotának meghatározására.
Vizuálisan ez úgy néz ki, mint az összetevőfa kiemelése. A funkcionális alkatrészek zöldre, a problémásak pirosra váltanak. - Végezzen általános ellenőrzéseket a dobozból.
A felügyeleti rendszer bizonyos ellenőrzéseket maga is végezhet. Miért kell újra feltalálni a kereket, használjuk őket. Például ellenőrizheti, hogy egy webhely oldala megnyílik, vagy a szerver ping-el. - A problémákról értesítést küldhet az érdekelt feleknek.
- Monitoring adatok megjelenítése, jelentések, grafikonok és statisztikák biztosítása.
Az ASMO rendszer rövid leírása
A legjobb, ha egy példával magyarázod. Nézzük meg, hogyan van megszervezve az ASMO rendszer teljesítményének monitorozása.
Az ASMO egy automatizált meteorológiai támogató rendszer. A rendszer segít a közúti szolgálat szakembereinek megérteni, hol és mikor szükséges az utat síkosságmentesítő anyagokkal kezelni. A rendszer a közúti ellenőrző pontokról gyűjt adatokat. A közúti ellenőrző pont egy olyan hely az úton, ahol berendezéseket szerelnek fel: meteorológiai állomás, videokamera stb. A veszélyes helyzetek előrejelzéséhez a rendszer időjárás-előrejelzéseket kap külső forrásokból.
Tehát a rendszer összetétele meglehetősen jellemző: weboldal, ügynök, berendezés. Kezdjük a megfigyelést.
A rendszer komponensekre bontása
Az ASMO rendszerben a következő komponensek különböztethetők meg:
1. Személyes számla
Ez egy webes alkalmazás. Legalább ellenőriznie kell, hogy az alkalmazás elérhető-e az interneten.
2. Adatbázis
Az adatbázis a jelentéskészítéshez fontos adatokat tárol, és gondoskodnia kell arról, hogy az adatbázis-mentések sikeresen elkészüljenek.
3. Szerver
Szerver alatt azt a hardvert értjük, amelyen az alkalmazások futnak. Ellenőriznie kell a HDD, RAM, CPU állapotát.
4. Ügynök
Ez egy Windows-szolgáltatás, amely számos különböző feladatot hajt végre ütemezetten. Legalább ellenőriznie kell, hogy a szolgáltatás fut-e.
5. Ügynöki feladat
Nem elég csak tudni, hogy egy ügynök dolgozik. Az ügynök dolgozhat, de nem látja el a rábízott feladatokat. Osszuk fel az ügynökkomponenst feladatokra, és ellenőrizzük, hogy az egyes ügynökfeladatok sikeresen működnek-e.
6. Közúti ellenőrzési pontok (az összes MPC konténerje)
Sok közúti ellenőrző pont van, ezért egyesítsük az összes MPC-t egy komponensben. Ez kényelmesebbé teszi a megfigyelési adatok leolvasását. Az „ASMO rendszer” komponens állapotának megtekintésekor azonnal világossá válik, hogy hol vannak a problémák: az alkalmazásokban, a hardverben vagy a maximális vezérlőrendszerben.
7. Közúti ellenőrzési pont (egy maximális korlát)
Ezt az összetevőt akkor tekintjük szervizelhetőnek, ha ezen az MPC-n lévő összes eszköz szervizelhető.
8. Készülék
Ez egy videokamera vagy meteorológiai állomás, amely a maximális koncentrációs határértékre van telepítve. Ellenőrizni kell, hogy a készülék megfelelően működik-e.
A megfigyelő rendszerben az összetevő fa így fog kinézni:
Webes alkalmazások figyelése
Tehát a rendszert komponensekre bontottuk, most minden komponensre vonatkozóan ellenőrzéseket kell készítenünk.
Egy webalkalmazás figyeléséhez a következő ellenőrzéseket használjuk:
1. A főoldal megnyitásának ellenőrzése
Ezt az ellenőrzést a felügyeleti rendszer végzi. A végrehajtáshoz megadjuk az oldal címét, a várt válaszrészletet és a kérés maximális végrehajtási idejét.
2. Domain fizetési határidő ellenőrzése
Nagyon fontos ellenőrzés. Ha egy domain kifizetetlen marad, a felhasználók nem nyithatják meg a webhelyet. A probléma megoldása több napig is eltarthat, mert... A DNS-módosítások alkalmazása nem történik meg azonnal.
3. Az SSL tanúsítvány ellenőrzése
Manapság szinte minden webhely https protokollt használ a hozzáféréshez. A protokoll megfelelő működéséhez érvényes SSL-tanúsítványra van szükség.
Alább látható a „Személyes fiók” komponens a felügyeleti rendszerben:
A fenti ellenőrzések mindegyike működik a legtöbb alkalmazásnál, és nem igényel kódolást. Ez nagyon klassz, mert 5 perc alatt elkezdheti bármelyik webalkalmazás figyelését. Az alábbiakban további ellenőrzések találhatók, amelyek egy webalkalmazáshoz elvégezhetők, de megvalósításuk összetettebb és alkalmazásspecifikusabb, ezért ebben a cikkben nem térünk ki rájuk.
Mit lehet még ellenőrizni?
A webalkalmazás teljesebb ellenőrzéséhez a következő ellenőrzéseket hajthatja végre:
- JavaScript-hibák száma periódusonként
- Hibák száma a webalkalmazás oldalán (háttér) az időszakra vonatkozóan
- Sikertelen webalkalmazás-válaszok száma (404-es, 500-as válaszkód stb.)
- Átlagos lekérdezés végrehajtási idő
Windows szolgáltatás figyelése (ügynök)
Az ASMO rendszerben az ügynök feladatütemező szerepét tölti be, amely az ütemezett feladatokat a háttérben hajtja végre.
Ha minden ügynöki feladat sikeresen befejeződik, az ügynök megfelelően működik. Kiderült, hogy egy ügynök figyeléséhez figyelemmel kell kísérnie a feladatait. Ezért az „Agent” komponenst feladatokra osztjuk. Minden feladathoz külön komponenst hozunk létre a monitoring rendszerben, ahol az „Agent” komponens lesz a „szülő”.
Az Agent komponenst gyermekkomponensekre (feladatokra) bontjuk:
Tehát egy összetett összetevőt több egyszerűre bontottunk. Most minden egyszerű komponenshez ellenőrzéseket kell kitalálnunk. Kérjük, vegye figyelembe, hogy az „Agent” szülőkomponensnek nem lesz ellenőrzése, mivel a megfigyelő rendszer az utódkomponensek állapota alapján függetlenül számítja ki állapotát. Más szóval, ha minden feladat sikeresen befejeződött, akkor az ügynök sikeresen fut.
Az ASMO rendszerben több mint száz feladat található, valóban szükséges-e minden feladathoz egyedi ellenőrzéseket kitalálni? Természetesen az irányítás jobb lesz, ha minden ügynökfeladathoz saját speciális ellenőrzéseket találunk ki és hajtunk végre, de a legtöbb esetben elegendő az univerzális ellenőrzések alkalmazása.
Az ASMO rendszer csak univerzális ellenőrzéseket használ a feladatokhoz, és ez elegendő a rendszer teljesítményének ellenőrzéséhez.
Haladás ellenőrzése
A legegyszerűbb és leghatékonyabb ellenőrzés a végrehajtási ellenőrzés. Az ellenőrzés ellenőrzi, hogy a feladat hibamentesen befejeződött-e. Minden feladat rendelkezik ezzel az ellenőrzéssel.
Ellenőrző algoritmus
Minden feladatvégrehajtás után el kell küldenie a SIKER ellenőrzés eredményét a felügyeleti rendszernek, ha a feladat végrehajtása sikeres volt, vagy HIBA, ha a végrehajtás hibásan fejeződött be.
Ez az ellenőrzés a következő problémákat észlelheti:
- A feladat fut, de hibával meghiúsul.
- A feladat futása leállt, például lefagyott.
Nézzük meg részletesebben, hogyan oldják meg ezeket a problémákat.
1. probléma – A feladat fut, de hiba miatt meghiúsul
Az alábbiakban egy olyan eset látható, amikor a feladat 14:00 és 16:00 között fut, de meghiúsul.
Az ábrán látható, hogy ha egy feladat meghiúsul, azonnal jelzés érkezik a felügyeleti rendszerhez, és a megfelelő ellenőrzés állapota a felügyeleti rendszerben vészjelzéssé válik.
Felhívjuk figyelmét, hogy a felügyeleti rendszerben az alkatrész állapota a hitelesítési állapottól függ. Az ellenőrzés riasztási állapota az összes magasabb szintű komponenst riasztásra változtatja, lásd az alábbi ábrát.
2. probléma – A feladat végrehajtása leállt (lefagyott)
Hogyan fogja a megfigyelő rendszer megérteni, hogy egy feladat elakadt?
Az ellenőrzés eredményének érvényességi ideje van, például 1 óra. Ha eltelik egy óra, és nincs új vizsgálati eredmény, a felügyeleti rendszer a teszt állapotát riasztásra állítja.
A fenti képen 14:00-kor lekapcsolták a villanyt. A felügyeleti rendszer 15:00-kor észleli, hogy a teszt eredménye (14:00 órától) elromlott, mert A relevancia ideje lejárt (egy óra), de nincs új eredmény, és az ellenőrzést riasztási állapotba kapcsolja.
16:00-kor ismét felkapcsolták a lámpákat, a program elvégzi a feladatot és elküldi a végrehajtás eredményét a felügyeleti rendszernek, a teszt állapot ismét sikeres lesz.
Milyen ellenőrzési relevanciaidőt használjak?
A relevanciaidőnek hosszabbnak kell lennie, mint a feladat végrehajtási időszaka. Azt javaslom, hogy a relevanciaidőt 2-3-szor hosszabbra állítsa be, mint a feladat-végrehajtási időszak. Erre azért van szükség, hogy elkerüljük a hamis értesítéseket, amikor például egy feladat a szokásosnál tovább tartott, vagy valaki újratöltötte a programot.
Haladás ellenőrzése
Az ASMO rendszerben van egy „Load Forecast” feladat, amely óránként egy alkalommal próbál letölteni egy új előrejelzést külső forrásból. Az új előrejelzés megjelenésének pontos időpontja a külső rendszerben nem ismert, de az ismert, hogy ez naponta kétszer történik meg. Kiderült, hogy ha több órára nincs új előrejelzés, akkor ez normális, de ha egy napnál tovább nincs új előrejelzés, akkor valahol eltört valami. Például egy külső előrejelzési rendszer adatformátuma megváltozhat, ezért az ASMO nem lát új előrejelzési kiadást.
Ellenőrző algoritmus
A feladat elküldi a SIKER ellenőrzés eredményét a felügyeleti rendszernek, ha sikerül előrehaladást elérni (új időjárás-előrejelzés letöltése). Ha nincs előrehaladás vagy hiba történik, akkor a rendszer semmit nem küld a felügyeleti rendszernek.
Az ellenőrzésnek olyan relevanciaintervallumnak kell lennie, hogy ezalatt az idő alatt garantáltan új előrehaladást kapjon.
Felhívjuk figyelmét, hogy a problémát késéssel fogjuk értesülni, mert a felügyeleti rendszer megvárja, amíg az utolsó vizsgálati eredmény érvényességi ideje lejár. Ezért a csekk érvényességi idejét nem kell túl hosszúra húzni.
Adatbázis figyelés
Az adatbázis ASMO rendszerben történő vezérléséhez a következő ellenőrzéseket hajtjuk végre:
- Biztonsági másolat létrehozásának ellenőrzése
- Szabad lemezterület ellenőrzése
Biztonsági másolat létrehozásának ellenőrzése
A legtöbb alkalmazásban fontos a naprakész adatbázis-mentés, hogy ha a kiszolgáló meghibásodik, a programot egy új kiszolgálóra telepíthesse.
Az ASMO hetente egyszer készít biztonsági másolatot, és elküldi a tárhelyre. Ha ez az eljárás sikeresen befejeződött, a sikerességi ellenőrzés eredménye elküldésre kerül a felügyeleti rendszernek. Az ellenőrzés eredménye 9 napig érvényes. Azok. A biztonsági mentések létrehozásának ellenőrzésére a fentebb tárgyalt „haladásellenőrző” mechanizmust használjuk.
Szabad lemezterület ellenőrzése
Ha nincs elég szabad hely a lemezen, az adatbázis nem fog megfelelően működni, ezért fontos a szabad terület mennyiségének szabályozása.
Kényelmes a metrikák használata a numerikus paraméterek ellenőrzésére.
Mérések egy numerikus változó, amelynek értéke a felügyeleti rendszerbe kerül. A felügyeleti rendszer ellenőrzi a küszöbértékeket és kiszámítja a metrikus állapotot.
Az alábbiakban egy kép látható arról, hogyan néz ki az „Adatbázis” komponens a felügyeleti rendszerben:
Szerver megfigyelése
A szerver figyeléséhez a következő ellenőrzéseket és mérőszámokat használjuk:
1. Szabad lemezterület
Ha a lemezterület elfogy, az alkalmazás nem fog tudni működni. 2 küszöbértéket használunk: az első szint a WARNING, a második szint az ALARM.
2. Átlagos RAM-érték százalékban óránként
Az óraátlagot használjuk, mert... nem érdekelnek minket a ritka fajok.
3. Átlagos CPU százalékos óránként
Az óraátlagot használjuk, mert... nem érdekelnek minket a ritka fajok.
4. Ping ellenőrzés
Ellenőrzi, hogy a szerver online állapotban van-e. A felügyeleti rendszer ezt az ellenőrzést el tudja végezni, nem kell kódot írni.
Az alábbiakban egy kép látható arról, hogyan néz ki a „Szerver” komponens a felügyeleti rendszerben:
Berendezés felügyelet
Elmondom, hogyan szerzik be az adatokat. Minden útellenőrző ponthoz (MPC) tartozik egy feladat a feladattervezőben, például „MPC M2 km 200 felmérése”. A feladat 30 percenként kap adatokat az összes MPC-eszközről.
Kommunikációs csatorna probléma
A berendezések nagy része a városon kívül található, adatátvitelre GSM hálózatot használnak, ami nem működik stabilan (hálózat van, vagy nincs).
A gyakori hálózati hibák miatt az MPC felmérés ellenőrzése eleinte így nézett ki:
Világossá vált, hogy ez nem működő lehetőség, mert sok téves bejelentés érkezett a problémákról. Aztán úgy döntöttek, hogy minden eszköznél „haladásellenőrzést” alkalmaznak, pl. Csak a sikerjelet küldi el a felügyeleti rendszer, amikor az eszközt hiba nélkül lekérdezik. A relevanciaidőt 5 órára állítottuk be.
A felügyelet mostantól csak akkor küld értesítést a problémákról, ha az eszközt 5 óránál tovább nem lehet lekérdezni. Nagy valószínűséggel ezek nem téves riasztások, hanem valós problémák.
Az alábbiakban egy kép arról, hogyan néz ki a berendezés a felügyeleti rendszerben:
Fontos!
Amikor a GSM-hálózat leáll, az összes MDC-eszköz nem lesz lekérdezve. A felügyeleti rendszertől érkező e-mailek számának csökkentése érdekében mérnökeink feliratkoznak az „MPC” típusú alkatrészproblémákra vonatkozó értesítésekre az „Eszköz” helyett. Ez lehetővé teszi, hogy minden egyes MPC-hez egy értesítést kapjon, ahelyett, hogy minden eszközről külön értesítést kapna.
Végső ASMO monitoring rendszer
Tegyünk össze mindent, és nézzük meg, milyen megfigyelési rendszerünk van.
Következtetés
Foglaljuk össze.
Mit adott nekünk az ASMO teljesítményének nyomon követése?
1. A hibaelhárítási idő csökkent
Korábban is hallottunk a felhasználóktól a hibákról, de nem minden felhasználó jelent meg hibákat. Előfordult, hogy egy rendszerelem meghibásodásáról egy héttel a megjelenése után értesültünk. Mostantól a felügyeleti rendszer azonnal értesít bennünket a problémákról, amint problémát észlel.
2. A rendszer stabilitása nőtt
Mivel a hibákat korábban kezdték kiküszöbölni, a rendszer egésze sokkal stabilabban kezdett működni.
3. A technikai támogatás hívásainak számának csökkentése
Sok probléma már azelőtt kijavítva, hogy a felhasználók egyáltalán tudomást szereznének róluk. A felhasználók ritkábban fordultak a technikai támogatáshoz. Mindez jó hatással van hírnevünkre.
4. A vásárlói és felhasználói hűség növelése
Az ügyfél pozitív változásokat észlelt a rendszer stabilitásában. A felhasználók kevesebb problémába ütköznek a rendszer használata során.
5. Csökkentse a technikai támogatás költségeit
Leállítottuk a kézi ellenőrzéseket. Most minden ellenőrzés automatizált. Korábban a felhasználóktól értesültünk a problémákról, gyakran nehéz volt megérteni, hogy a felhasználó milyen problémáról beszél. Most a legtöbb problémát a felügyeleti rendszer jelenti, az értesítések technikai adatokat tartalmaznak, amelyekből mindig kiderül, hogy mi és hol történt a hiba.
Fontos!
A megfigyelőrendszert nem telepítheti ugyanarra a kiszolgálóra, ahol az alkalmazásai futnak. Ha a szerver leáll, az alkalmazások leállnak, és nem lesz senki, aki értesítsen róla.
A felügyeleti rendszernek egy másik adatközpontban lévő külön szerveren kell futnia.
Ha nem szeretne dedikált szervert használni egy új adatközpontban, használhat felhőfigyelő rendszert. Cégünk a Zidium felhőfigyelő rendszert használja, de Ön bármilyen más felügyeleti rendszert is használhat. A felhőfigyelő rendszer költsége alacsonyabb, mint egy új szerver bérlése.
Ajánlások:
- A lehető legrészletesebben bontsa szét az alkalmazásokat és rendszereket egy komponensfa formájában, így kényelmesebb lesz megérteni, hol és mi hibásodott meg, és teljesebb lesz a vezérlés.
- Egy összetevő működőképességének ellenőrzéséhez használjon teszteket. Jobb sok egyszerű ellenőrzést használni, mint egy összetettet.
- Konfigurálja a metrikus küszöbértékeket a megfigyelő rendszer oldalán, ahelyett, hogy kódba írná őket. Ezzel megóvja az alkalmazás újrafordításától, újrakonfigurálásától vagy újraindításától.
- Egyéni ellenőrzéseknél használjon határértéket, nehogy hamis értesítéseket kapjon, mert egyes ellenőrzések végrehajtása a szokásosnál kicsit tovább tart.
- Próbálja meg elérni, hogy a felügyeleti rendszer alkatrészei csak akkor váljanak pirosra, ha biztosan probléma van. Ha hiába váltanak pirosra, akkor abbahagyja a figyelő rendszer értesítéseinek figyelését, az értelme elvész.
Ha még nem használ felügyeleti rendszert, kezdje el! Nem olyan nehéz, mint amilyennek látszik. Élvezze a saját maga által nevelt zöld összetevők fát.
Sok szerencsét.
Forrás: will.com