Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Ahoj všichni!

Naše společnost se zabývá vývojem softwaru a následnou technickou podporou. Technická podpora vyžaduje nejen opravu chyb, ale také sledování výkonu našich aplikací.

Pokud například jedna ze služeb spadla, musíte tento problém automaticky zaznamenat a začít jej řešit a nečekat, až se nespokojení uživatelé obrátí na technickou podporu.

Máme malou firmu, nemáme prostředky na studium a údržbu jakýchkoli složitých řešení pro monitorování aplikací, potřebovali jsme najít jednoduché a efektivní řešení.

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Strategie monitorování

Ověřit funkčnost aplikace není snadné, tento úkol je netriviální, dalo by se říci až kreativní. Obzvláště obtížné je ověřit komplexní vícečlánkový systém.

Jak můžeš jíst slona? Pouze po částech! Tento přístup používáme k monitorování aplikací.

Podstata naší strategie monitorování:

Rozdělte aplikaci na komponenty.
Vytvořte kontrolní kontroly pro každou komponentu.

Komponenta je považována za funkční, pokud jsou všechny její kontrolní kontroly provedeny bez chyb. Aplikace je považována za zdravou, pokud jsou všechny její součásti funkční.

Každý systém tedy může být reprezentován jako strom komponent. Složité komponenty jsou rozděleny na jednodušší. Jednoduché komponenty mají kontroly.

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Benchmarky nejsou určeny k provádění funkčního testování, nejsou to testy jednotek. Kontrolní kontroly by měly prověřit, jak se komponent v aktuálním okamžiku cítí, zda jsou k dispozici všechny zdroje nezbytné pro jeho fungování a zda se nevyskytují nějaké problémy.

Neexistují žádné zázraky, většinu kontrol bude nutné vyvinout nezávisle. Ale nebojte se, protože ve většině případů jedna kontrola zabere 5-10 řádků kódu, ale můžete implementovat jakoukoli logiku a jasně pochopíte, jak kontrola funguje.

Monitorovací systém

Řekněme, že jsme aplikaci rozdělili na komponenty, vymysleli a implementovali kontroly pro každou komponentu, ale co dělat s výsledky těchto kontrol? Jak poznáme, že některá kontrola selhala?

Budeme potřebovat monitorovací systém. Bude plnit následující úkoly:

  • Získejte výsledky testů a použijte je k určení stavu součástí.
    Vizuálně to vypadá jako zvýraznění stromu komponent. Funkční komponenty zelenají, problematické červenají.
  • Proveďte obecné kontroly po vybalení z krabice.
    Monitorovací systém může provádět některé kontroly sám. Proč znovu vynalézat kolo, pojďme je použít. Můžete například zkontrolovat, zda se otevírá webová stránka nebo zda server pingne.
  • Zasílejte zainteresovaným stranám oznámení o problémech.
  • Vizualizace monitorovacích dat, poskytování reportů, grafů a statistik.

Stručný popis systému ASMO

Nejlepší je to vysvětlit na příkladu. Podívejme se, jak je organizováno sledování výkonu systému ASMO.

ASMO je automatizovaný meteorologický podpůrný systém. Systém pomáhá specialistům silničních služeb pochopit, kde a kdy je nutné vozovku ošetřit odmrazovacími materiály. Systém sbírá data ze silničních kontrolních bodů. Silniční kontrolní bod je místo na silnici, kde je instalováno zařízení: meteorologická stanice, videokamera atd. Aby bylo možné předvídat nebezpečné situace, systém přijímá předpovědi počasí z externích zdrojů.

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Takže složení systému je docela typické: web, agent, vybavení. Začněme monitorovat.

Rozdělení systému na komponenty

V systému ASMO lze rozlišit následující komponenty:

1. Osobní účet
Toto je webová aplikace. Minimálně je potřeba zkontrolovat, zda je aplikace dostupná na internetu.

2. Databáze
Databáze ukládá data, která jsou důležitá pro vytváření sestav, a vy musíte zajistit úspěšné vytvoření záloh databáze.

3. Server
Serverem rozumíme hardware, na kterém běží aplikace. Je nutné zkontrolovat stav HDD, RAM, CPU.

4. Agent
Toto je služba Windows, která provádí mnoho různých úkolů podle plánu. Minimálně musíte zkontrolovat, zda služba běží.

5. Úkol agenta
Jen vědět, že agent pracuje, nestačí. Agent může pracovat, ale ne vykonávat přidělené úkoly. Rozdělme komponentu agenta na úlohy a zkontrolujme, zda každá úloha agenta funguje úspěšně.

6. Silniční kontrolní body (kontejner všech MPC)
Existuje mnoho silničních kontrolních bodů, takže spojme všechny MPC do jedné komponenty. Díky tomu bude čtení monitorovacích dat pohodlnější. Při prohlížení stavu komponenty „ASMO system“ bude okamžitě jasné, kde jsou problémy: v aplikacích, hardwaru nebo v maximálním řídicím systému.

7. Silniční kontrolní bod (jeden maximální limit)
Tuto komponentu budeme považovat za opravitelnou, pokud budou opravitelná všechna zařízení na tomto MPC.

8. Zařízení
Jedná se o videokameru nebo meteostanici, která je instalována na hranici maximální koncentrace. Je nutné zkontrolovat, zda zařízení správně funguje.

V monitorovacím systému bude strom komponent vypadat takto:

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Monitorování webových aplikací

Takže jsme rozdělili systém na komponenty, nyní musíme přijít s kontrolami pro každou komponentu.

Pro sledování webové aplikace používáme následující kontroly:

1. Kontrola otevření hlavní stránky
Tuto kontrolu provádí monitorovací systém. Pro jeho provedení uvádíme adresu stránky, očekávaný fragment odpovědi a maximální dobu provedení požadavku.

2. Kontrola termínu platby domény
Velmi důležitá kontrola. Když doména zůstane nezaplacená, uživatelé nemohou web otevřít. Řešení problému může trvat několik dní, protože... Změny DNS se neprojeví okamžitě.

3. Kontrola SSL certifikátu
V dnešní době téměř všechny webové stránky využívají pro přístup protokol https. Pro správnou funkci protokolu potřebujete platný SSL certifikát.

Níže je komponenta „Osobní účet“ v monitorovacím systému:

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Všechny výše uvedené kontroly budou fungovat pro většinu aplikací a nevyžadují žádné kódování. To je velmi cool, protože můžete začít sledovat jakoukoli webovou aplikaci za 5 minut. Níže jsou uvedeny dodatečné kontroly, které lze u webové aplikace provést, ale jejich implementace je složitější a specifická pro aplikaci, proto se jim v tomto článku nebudeme věnovat.

Co ještě můžete zkontrolovat?

Chcete-li plně monitorovat svou webovou aplikaci, můžete provést následující kontroly:

  • Počet chyb JavaScriptu za období
  • Počet chyb na straně webové aplikace (back-end) za období
  • Počet neúspěšných odpovědí webové aplikace (kód odpovědi 404, 500 atd.)
  • Průměrná doba provádění dotazu

Sledování služby Windows (agent)

V systému ASMO plní agent roli plánovače úloh, který provádí naplánované úlohy na pozadí.

Pokud jsou všechny úlohy agenta dokončeny úspěšně, agent pracuje správně. Ukazuje se, že abyste mohli agenta sledovat, musíte sledovat jeho úkoly. Komponentu „Agent“ proto rozdělujeme na úkoly. Pro každý úkol vytvoříme samostatnou komponentu v monitorovacím systému, kde komponenta „Agent“ bude „rodičem“.

Komponentu Agent jsme rozdělili na podřízené komponenty (úkoly):

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Složitou komponentu jsme tedy rozdělili na několik jednoduchých. Nyní musíme přijít s kontrolami pro každou jednoduchou součást. Vezměte prosím na vědomí, že nadřazená komponenta „Agent“ nebude mít žádné kontroly, protože monitorovací systém vypočítá svůj stav nezávisle na stavu svých podřízených komponent. Jinými slovy, pokud jsou všechny úlohy úspěšně dokončeny, agent běží úspěšně.

V systému ASMO je více než sto úloh, je opravdu nutné pro každý úkol vymýšlet unikátní kontroly? Kontrola bude samozřejmě lepší, když pro každý úkol agenta vymyslíme a zavedeme vlastní speciální kontroly, ale ve většině případů stačí použít univerzální kontroly.

Systém ASMO používá pouze univerzální kontroly úloh a to stačí ke sledování výkonu systému.

Kontrola průběhu
Nejjednodušší a nejúčinnější kontrolou je kontrola provedení. Kontrola ověří, zda je úkol dokončen bez chyb. Všechny úkoly mají tuto kontrolu.

Ověřovací algoritmus

Po každém provedení úlohy je třeba odeslat výsledek kontroly ÚSPĚCH do monitorovacího systému, pokud bylo provedení úlohy úspěšné, nebo ERROR, pokud bylo provedení dokončeno s chybou.

Tato kontrola může odhalit následující problémy:

  1. Úloha se spustí, ale selže s chybou.
  2. Úloha přestala běžet, například zamrzla.

Podívejme se na to, jak se tyto problémy řeší podrobněji.

Problém 1 – Úloha se spustí, ale selže s chybou
Níže je uveden případ, kdy se úloha spustí, ale mezi 14:00 a 16:00 selže.

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Obrázek ukazuje, že když úloha selže, je okamžitě odeslán signál do monitorovacího systému a stav příslušné kontroly v monitorovacím systému se stane alarmem.

Upozorňujeme, že v monitorovacím systému závisí stav součásti na stavu ověření. Stav alarmu kontroly změní všechny komponenty vyšší úrovně na alarm, viz obrázek níže.

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Problém 2 – Úloha se přestala provádět (zamrzla)
Jak monitorovací systém pochopí, že se úkol zasekl?

Výsledek kontroly má dobu platnosti, například 1 hodinu. Pokud uplyne hodina a nedojde k žádnému novému výsledku testu, monitorovací systém nastaví stav testu na alarm.

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Na obrázku výše byla světla zhasnuta ve 14:00. V 15:00 monitorovací systém zjistí, že výsledek testu (od 14:00) je shnilý, protože Čas relevance vypršel (jedna hodina), ale není k dispozici žádný nový výsledek a přepne kontrolu do stavu alarmu.

V 16:00 se světla znovu rozsvítila, program dokončí úkol a odešle výsledek provedení do monitorovacího systému, stav testu bude opět úspěšný.

Jaký čas kontroly relevance mám použít?

Doba relevance musí být větší než doba provádění úlohy. Dobu relevance doporučuji nastavit 2-3x delší, než je doba provádění úlohy. To je nezbytné, abyste se vyhnuli přijímání falešných upozornění, když například úkol trval déle než obvykle nebo když někdo znovu načetl program.

Kontrola průběhu

Systém ASMO má úlohu „Load Forecast“, která se jednou za hodinu pokouší stáhnout novou předpověď z externího zdroje. Přesný čas, kdy se v externím systému objeví nová předpověď, není znám, ale ví se, že se tak děje 2x denně. Ukazuje se, že pokud není nová předpověď na několik hodin, je to normální, ale pokud není nová předpověď déle než jeden den, pak se někde něco zlomilo. Například formát dat v externím předpovědním systému se může změnit, a proto ASMO neuvidí nové vydání předpovědi.

Ověřovací algoritmus

Úloha odešle výsledek kontroly ÚSPĚCH do monitorovacího systému, když se jí podaří získat průběh (stažení nové předpovědi počasí). Pokud nedojde k žádnému pokroku nebo dojde k chybě, pak se do monitorovacího systému nic neodešle.

Kontrola musí mít takový interval relevance, aby během této doby bylo zaručeno, že obdrží nový pokrok.

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Upozorňujeme, že o problému se dozvíme se zpožděním, protože monitorovací systém čeká, dokud nevyprší doba platnosti posledního výsledku kontroly. Dobu platnosti šeku proto není třeba provádět příliš dlouho.

Monitorování databáze

Pro ovládání databáze v systému ASMO provádíme následující kontroly:

  1. Ověřování vytvoření zálohy
  2. Kontrola volného místa na disku

Ověřování vytvoření zálohy
Ve většině aplikací je důležité mít aktuální zálohy databáze, abyste v případě selhání serveru mohli program nasadit na nový server.

ASMO vytvoří záložní kopii jednou týdně a odešle ji do úložiště. Po úspěšném dokončení tohoto postupu je výsledek kontroly úspěšnosti odeslán do monitorovacího systému. Výsledek ověření je platný 9 dní. Tito. Pro kontrolu vytváření záloh se používá mechanismus „kontroly průběhu“, o kterém jsme hovořili výše.

Kontrola volného místa na disku
Pokud na disku není dostatek volného místa, databáze nebude schopna správně fungovat, proto je důležité kontrolovat množství volného místa.

Pro kontrolu číselných parametrů je vhodné použít metriky.

Metriky je číselná proměnná, jejíž hodnota se přenáší do monitorovacího systému. Monitorovací systém kontroluje prahové hodnoty a vypočítává metrický stav.

Níže je obrázek, jak vypadá komponenta „Databáze“ v monitorovacím systému:

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Monitorování serveru

K monitorování serveru používáme následující kontroly a metriky:

1. Volné místo na disku
Pokud dojde místo na disku, aplikace nebude moci fungovat. Používáme 2 prahové hodnoty: první úroveň je VAROVÁNÍ, druhá úroveň je ALARM.

2. Průměrná hodnota RAM v procentech za hodinu
Používáme hodinový průměr, protože... nezajímají nás vzácné rasy.

3. Průměrné procento CPU za hodinu
Používáme hodinový průměr, protože... nezajímají nás vzácné rasy.

4. Kontrola pingem
Zkontroluje, zda je server online. Monitorovací systém může tuto kontrolu provést, není třeba psát kód.

Níže je obrázek, jak vypadá komponenta „Server“ v monitorovacím systému:

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Monitorování zařízení

Řeknu vám, jak se data získávají. Pro každý silniční kontrolní bod (MPC) existuje úloha v plánovači úloh, například „Survey MPC M2 km 200“. Úloha přijímá data ze všech zařízení MPC každých 30 minut.

Problém komunikačního kanálu
Většina zařízení je umístěna mimo město, pro přenos dat je využívána GSM síť, která nefunguje stabilně (síť existuje, nebo není).

Kvůli častým výpadkům sítě zpočátku kontrola MPC průzkumu v monitoringu vypadala takto:

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Ukázalo se, že to není funkční možnost, protože bylo mnoho falešných oznámení o problémech. Poté bylo rozhodnuto použít „kontrolu průběhu“ pro každé zařízení, tzn. Pouze signál o úspěšnosti je odeslán do monitorovacího systému, když je zařízení dotazováno bez chyby. Doba relevance byla nastavena na 5 hodin.

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Nyní monitoring zasílá upozornění na problémy pouze v případě, že zařízení nemůže být dotazováno déle než 5 hodin. S vysokou mírou pravděpodobnosti se nejedná o plané poplachy, ale o skutečné problémy.

Níže je obrázek, jak zařízení vypadá v monitorovacím systému:

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Důležité!
Když GSM síť přestane fungovat, všechna MDC zařízení nebudou dotazována. Aby se snížil počet e-mailů z monitorovacího systému, naši inženýři se přihlásili k odběru oznámení o problémech součástí typu „MPC“ spíše než „Zařízení“. To vám umožní obdržet jedno oznámení pro každé MPC, nikoli samostatné oznámení pro každé zařízení.

Finální ASMO monitorovací schéma

Pojďme si dát vše dohromady a uvidíme, jaké máme monitorovací schéma.

Slona jíme po částech. Strategie monitorování stavu aplikace s příklady

Závěr

Pojďme si to shrnout.
Co nám dalo sledování výkonu ASMO?

1. Doba odstranění defektu se zkrátila
Již dříve jsme od uživatelů slyšeli o závadách, ale ne všichni uživatelé závady hlásí. Stalo se, že jsme se o nefunkčnosti některé systémové komponenty dozvěděli týden poté, co se objevila. Nyní nás monitorovací systém upozorní na problémy, jakmile je problém zjištěn.

2. Stabilita systému se zvýšila
Jelikož se závady začaly odstraňovat dříve, začal systém jako celek fungovat mnohem stabilněji.

3. Snížení počtu volání na technickou podporu
Mnoho problémů je nyní vyřešeno dříve, než o nich uživatelé vůbec vědí. Uživatelé začali méně často kontaktovat technickou podporu. To vše má dobrý vliv na naši pověst.

4. Zvyšování loajality zákazníků a uživatelů
Zákazník zaznamenal pozitivní změny ve stabilitě systému. Uživatelé se při používání systému setkávají s méně problémy.

5. Snižte náklady na technickou podporu
Přestali jsme provádět jakékoli ruční kontroly. Nyní jsou všechny kontroly automatizované. Dříve jsme se o problémech dozvěděli od uživatelů, často bylo obtížné pochopit, o jakém problému uživatel mluví. Většinu problémů nyní hlásí monitorovací systém, upozornění obsahují technické údaje, ze kterých je vždy jasné, co a kde se stalo.

Důležité!
Monitorovací systém nemůžete nainstalovat na stejný server, kde běží vaše aplikace. Pokud dojde k výpadku serveru, aplikace přestanou fungovat a nebude nikdo, kdo by o tom informoval.

Monitorovací systém musí běžet na samostatném serveru v jiném datovém centru.

Pokud nechcete v novém datovém centru používat dedikovaný server, můžete využít cloudový monitorovací systém. Naše společnost využívá cloudový monitorovací systém Zidium, ale můžete použít jakýkoli jiný monitorovací systém. Náklady na cloudový monitorovací systém jsou nižší než pronájem nového serveru.

Doporučení:

  1. Rozdělte aplikace a systémy ve formě stromu komponent co nejpodrobněji, takže bude vhodné pochopit, kde a co je rozbité, a ovládání bude úplnější.
  2. Pro kontrolu funkčnosti komponenty použijte testy. Je lepší použít mnoho jednoduchých kontrol než jednu složitou.
  3. Nakonfigurujte prahové hodnoty metrik na straně monitorovacího systému, spíše než je zapisujte do kódu. To vám ušetří nutnost překompilovat, překonfigurovat nebo restartovat aplikaci.
  4. U vlastních kontrol používejte určitou časovou rezervu, abyste nedostávali falešná oznámení, protože dokončení některých kontrol trvalo o něco déle než obvykle.
  5. Snažte se, aby komponenty v monitorovacím systému zčervenaly pouze tehdy, když je definitivně problém. Pokud zčervenají pro nic za nic, přestanete věnovat pozornost upozorněním monitorovacího systému, jeho význam se ztratí.

Pokud ještě nepoužíváte monitorovací systém, začněte! Není to tak těžké, jak se zdá. Vychutnejte si pohled na strom zelených ingrediencí, který jste sami vypěstovali.

Hodně štěstí.

Zdroj: www.habr.com

Přidat komentář