Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Ahoj všetci!

Naša spoločnosť sa zaoberá vývojom softvéru a následnou technickou podporou. Technická podpora si vyžaduje nielen opravu chýb, ale aj sledovanie výkonu našich aplikácií.

Ak napríklad niektorá zo služieb zlyhala, musíte tento problém automaticky zaznamenať a začať ho riešiť a nečakať, kým sa nespokojní používatelia obrátia na technickú podporu.

Máme malú firmu, nemáme zdroje na štúdium a údržbu akýchkoľvek komplexných riešení pre monitorovanie aplikácií, potrebovali sme nájsť jednoduché a efektívne riešenie.

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Stratégia monitorovania

Overiť funkčnosť aplikácie nie je jednoduché, táto úloha je netriviálna, dalo by sa povedať až kreatívna. Obzvlášť ťažké je overiť zložitý viacčlánkový systém.

Ako môžete jesť slona? Len po častiach! Tento prístup používame na monitorovanie aplikácií.

Podstata našej monitorovacej stratégie:

Rozdeľte svoju aplikáciu na komponenty.
Vytvorte kontroly kontroly pre každý komponent.

Komponent sa považuje za funkčný, ak sú všetky jeho kontroly vykonané bez chýb. Aplikácia sa považuje za zdravú, ak sú všetky jej súčasti funkčné.

Každý systém teda môže byť reprezentovaný ako strom komponentov. Zložité komponenty sú rozdelené na jednoduchšie. Jednoduché komponenty majú kontroly.

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Benchmarky nie sú určené na vykonávanie funkčného testovania, nie sú to testy jednotiek. Kontrolné kontroly by mali skontrolovať, ako sa komponent cíti v aktuálnom čase, či sú k dispozícii všetky zdroje potrebné na jeho fungovanie a či sa nevyskytujú nejaké problémy.

Neexistujú žiadne zázraky, väčšina kontrol bude musieť byť vyvinutá nezávisle. Ale nezľaknite sa, pretože vo väčšine prípadov jedna kontrola zaberie 5-10 riadkov kódu, ale môžete implementovať akúkoľvek logiku a jasne pochopíte, ako kontrola funguje.

Monitorovací systém

Povedzme, že sme aplikáciu rozdelili na komponenty, vymysleli a implementovali kontroly pre každý komponent, ale čo robiť s výsledkami týchto kontrol? Ako zistíme, že niektorá kontrola zlyhala?

Budeme potrebovať monitorovací systém. Bude vykonávať tieto úlohy:

  • Získajte výsledky testov a použite ich na určenie stavu komponentov.
    Vizuálne to vyzerá ako zvýraznenie stromu komponentov. Funkčné komponenty zozelenajú, problematické do červena.
  • Vykonajte všeobecné kontroly hneď po vybalení.
    Monitorovací systém môže vykonávať niektoré kontroly sám. Prečo znovu vynájsť koleso, poďme ich použiť. Môžete napríklad skontrolovať, či sa otvára webová stránka alebo či server pingne.
  • Posielajte zainteresovaným stranám oznámenia o problémoch.
  • Vizualizácia monitorovacích údajov, poskytovanie reportov, grafov a štatistík.

Stručný popis systému ASMO

Najlepšie je to vysvetliť na príklade. Pozrime sa, ako je organizované sledovanie výkonu systému ASMO.

ASMO je automatizovaný meteorologický podporný systém. Systém pomáha špecialistom na cestné služby pochopiť, kde a kedy je potrebné ošetriť vozovku rozmrazovacím materiálom. Systém zbiera údaje z cestných kontrolných bodov. Cestný kontrolný bod je miesto na ceste, kde je nainštalované zariadenie: meteorologická stanica, videokamera atď. Na predpovedanie nebezpečných situácií systém prijíma predpovede počasia z externých zdrojov.

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Takže zloženie systému je celkom typické: webová stránka, agent, vybavenie. Začnime monitorovať.

Rozdelenie systému na komponenty

V systéme ASMO je možné rozlíšiť tieto komponenty:

1. Osobný účet
Toto je webová aplikácia. Minimálne je potrebné skontrolovať, či je aplikácia dostupná na internete.

2. Databáza
Databáza ukladá údaje, ktoré sú dôležité pre vytváranie prehľadov, a vy musíte zabezpečiť úspešné vytvorenie záloh databázy.

3. Server
Serverom rozumieme hardvér, na ktorom bežia aplikácie. Je potrebné skontrolovať stav HDD, RAM, CPU.

4. Agent
Toto je služba systému Windows, ktorá vykonáva mnoho rôznych úloh podľa plánu. Minimálne musíte skontrolovať, či je služba spustená.

5. Úloha agenta
Len vedieť, že agent pracuje, nestačí. Agent môže pracovať, ale nie vykonávať pridelené úlohy. Rozdeľme komponent agenta na úlohy a skontrolujte, či každá úloha agenta funguje úspešne.

6. Cestné kontrolné body (kontajner všetkých MPC)
Existuje veľa cestných kontrolných bodov, takže spojme všetky MPC do jedného komponentu. Vďaka tomu bude čítanie monitorovacích údajov pohodlnejšie. Pri prezeraní stavu komponentu „ASMO system“ bude hneď jasné, kde sú problémy: v aplikáciách, hardvéri alebo v maximálnom riadiacom systéme.

7. Cestný kontrolný bod (jeden maximálny limit)
Tento komponent budeme považovať za opraviteľný, ak budú opraviteľné všetky zariadenia na tomto MPC.

8. Zariadenie
Ide o videokameru alebo meteorologickú stanicu, ktorá je inštalovaná na hranici maximálnej koncentrácie. Je potrebné skontrolovať, či zariadenie funguje správne.

V monitorovacom systéme bude strom komponentov vyzerať takto:

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Monitorovanie webových aplikácií

Takže sme systém rozdelili na komponenty, teraz musíme prísť s kontrolami pre každý komponent.

Na monitorovanie webovej aplikácie používame nasledujúce kontroly:

1. Kontrola otvorenia hlavnej stránky
Túto kontrolu vykonáva monitorovací systém. Na jej vykonanie uvádzame adresu stránky, očakávaný fragment odpovede a maximálny čas vykonania požiadavky.

2. Kontrola termínu platby domény
Veľmi dôležitá kontrola. Keď doména zostane nezaplatená, používatelia nemôžu otvoriť stránku. Riešenie problému môže trvať niekoľko dní, pretože... Zmeny DNS sa neprejavia okamžite.

3. Kontrola SSL certifikátu
V súčasnosti takmer všetky webové stránky používajú na prístup protokol https. Aby protokol fungoval správne, potrebujete platný certifikát SSL.

Nižšie je uvedený komponent „Osobný účet“ v monitorovacom systéme:

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Všetky vyššie uvedené kontroly budú fungovať pre väčšinu aplikácií a nevyžadujú žiadne kódovanie. To je veľmi cool, pretože môžete začať monitorovať akúkoľvek webovú aplikáciu za 5 minút. Nižšie sú uvedené dodatočné kontroly, ktoré je možné vykonať pre webovú aplikáciu, no ich implementácia je zložitejšia a špecifickejšia pre aplikáciu, preto sa im v tomto článku nebudeme venovať.

Čo ešte môžete skontrolovať?

Ak chcete lepšie monitorovať svoju webovú aplikáciu, môžete vykonať nasledujúce kontroly:

  • Počet chýb JavaScript za obdobie
  • Počet chýb na strane webovej aplikácie (back-end) za dané obdobie
  • Počet neúspešných odpovedí webovej aplikácie (kód odpovede 404, 500 atď.)
  • Priemerný čas vykonania dotazu

Monitorovanie služby systému Windows (agent)

V systéme ASMO plní agent úlohu plánovača úloh, ktorý vykonáva naplánované úlohy na pozadí.

Ak sa všetky úlohy agenta dokončia úspešne, agent funguje správne. Ukazuje sa, že ak chcete monitorovať agenta, musíte sledovať jeho úlohy. Preto komponent „Agent“ rozdeľujeme na úlohy. Pre každú úlohu vytvoríme samostatný komponent v monitorovacom systéme, kde komponent „Agent“ bude „rodič“.

Komponent Agent sme rozdelili na podradené komponenty (úlohy):

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Zložitú zložku sme teda rozdelili na niekoľko jednoduchých. Teraz musíme prísť s kontrolami pre každý jednoduchý komponent. Upozorňujeme, že nadradený komponent „Agent“ nebude mať žiadne kontroly, pretože monitorovací systém vypočíta svoj stav nezávisle na základe stavu svojich podradených komponentov. Inými slovami, ak sú všetky úlohy úspešne dokončené, potom agent úspešne beží.

V systéme ASMO je viac ako sto úloh, je naozaj potrebné pre každú úlohu vymýšľať jedinečné kontroly? Kontrola bude samozrejme lepšia, ak si pre každú úlohu agenta vymyslíme a zavedieme vlastné špeciálne kontroly, no vo väčšine prípadov stačí použiť univerzálne kontroly.

Systém ASMO používa iba univerzálne kontroly úloh a to stačí na sledovanie výkonu systému.

Kontrola pokroku
Najjednoduchšou a najúčinnejšou kontrolou je kontrola vykonania. Kontrola overí, či je úloha dokončená bez chýb. Všetky úlohy majú túto kontrolu.

Kontrolný algoritmus

Po každom vykonaní úlohy musíte do monitorovacieho systému odoslať výsledok kontroly ÚSPECH, ak bola úloha úspešná, alebo CHYBA, ak sa vykonávanie dokončilo s chybou.

Táto kontrola môže odhaliť nasledujúce problémy:

  1. Úloha sa spustí, ale zlyhá s chybou.
  2. Úloha prestala bežať, napríklad zamrzla.

Pozrime sa, ako sa tieto problémy riešia podrobnejšie.

Problém 1 – Úloha sa spustí, ale zlyhá s chybou
Nižšie je uvedený prípad, keď sa úloha spustí, ale zlyhá medzi 14:00 a 16:00.

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Obrázok ukazuje, že keď úloha zlyhá, okamžite sa odošle signál do monitorovacieho systému a stav príslušnej kontroly v monitorovacom systéme sa stane alarmom.

Upozorňujeme, že v monitorovacom systéme závisí stav komponentu od stavu overenia. Alarmový stav kontroly zmení všetky komponenty vyššej úrovne na alarm, pozri obrázok nižšie.

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Problém 2 – Úloha sa prestala vykonávať (zamrzla)
Ako monitorovací systém pochopí, že sa úloha zasekla?

Výsledok kontroly má dobu platnosti, napríklad 1 hodinu. Ak uplynie hodina a nie je k dispozícii žiadny nový výsledok testu, monitorovací systém nastaví stav testu na alarm.

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Na obrázku vyššie boli svetlá zhasnuté o 14:00 hod. O 15:00 monitorovací systém zistí, že výsledok testu (od 14:00) je zhnitý, pretože Čas relevantnosti uplynul (jedna hodina), ale nie je k dispozícii žiadny nový výsledok a kontrola sa prepne do stavu alarmu.

O 16:00 sa svetlá opäť rozsvietili, program dokončí úlohu a odošle výsledok vykonania do monitorovacieho systému, stav testu bude opäť úspešný.

Aký čas kontroly relevantnosti by som mal použiť?

Čas relevantnosti musí byť dlhší ako obdobie vykonávania úlohy. Odporúčam nastaviť čas relevancie 2-3 krát dlhší ako je doba vykonávania úlohy. Je to potrebné, aby ste sa vyhli prijímaniu falošných upozornení, keď napríklad úloha trvala dlhšie ako zvyčajne alebo keď niekto znova načítal program.

Kontrola pokroku

Systém ASMO má úlohu „Load Forecast“, ktorá sa pokúša stiahnuť novú predpoveď z externého zdroja raz za hodinu. Presný čas, kedy sa v externom systéme objaví nová predpoveď, nie je známy, ale je známe, že sa to deje 2-krát denne. Ukazuje sa, že ak nie je nová predpoveď niekoľko hodín, je to normálne, ale ak nie je nová predpoveď viac ako jeden deň, niekde sa niečo pokazilo. Napríklad formát údajov v externom predpovednom systéme sa môže zmeniť, a preto ASMO neuvidí nové vydanie predpovedí.

Kontrolný algoritmus

Úloha odošle výsledok kontroly ÚSPECH do monitorovacieho systému, keď sa jej podarí získať priebeh (stiahnutie novej predpovede počasia). Ak nedôjde k žiadnemu pokroku alebo sa vyskytne chyba, do monitorovacieho systému sa neodošle nič.

Kontrola musí mať taký interval relevantnosti, že počas tejto doby bude zaručený nový pokrok.

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Upozorňujeme, že o probléme sa dozvieme s oneskorením, pretože monitorovací systém čaká, kým uplynie doba platnosti posledného výsledku kontroly. Obdobie platnosti šeku preto netreba robiť príliš dlho.

Monitorovanie databázy

Pre kontrolu databázy v systéme ASMO vykonávame tieto kontroly:

  1. Overuje sa vytvorenie zálohy
  2. Kontrola voľného miesta na disku

Overuje sa vytvorenie zálohy
Vo väčšine aplikácií je dôležité mať k dispozícii aktuálne zálohy databázy, aby ste v prípade zlyhania servera mohli nasadiť program na nový server.

ASMO vytvorí záložnú kópiu raz týždenne a odošle ju do úložiska. Po úspešnom dokončení tohto postupu sa výsledok kontroly úspešnosti odošle do monitorovacieho systému. Výsledok overenia je platný 9 dní. Tie. Na kontrolu vytvárania záloh sa používa mechanizmus „kontroly priebehu“, o ktorom sme hovorili vyššie.

Kontrola voľného miesta na disku
Ak na disku nie je dostatok voľného miesta, databáza nebude môcť správne fungovať, preto je dôležité kontrolovať množstvo voľného miesta.

Na kontrolu číselných parametrov je vhodné použiť metriky.

Metriky je číselná premenná, ktorej hodnota sa prenáša do monitorovacieho systému. Monitorovací systém kontroluje prahové hodnoty a vypočítava metrický stav.

Nižšie je obrázok toho, ako vyzerá komponent „Databáza“ v monitorovacom systéme:

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Monitorovanie servera

Na monitorovanie servera používame nasledujúce kontroly a metriky:

1. Voľné miesto na disku
Ak sa miesto na disku minie, aplikácia nebude môcť fungovať. Používame 2 prahové hodnoty: prvá úroveň je VAROVANIE, druhá úroveň je ALARM.

2. Priemerná hodnota RAM v percentách za hodinu
Používame hodinový priemer, pretože... nezaujímajú nás zriedkavé rasy.

3. Priemerné percento CPU za hodinu
Používame hodinový priemer, pretože... nezaujímajú nás zriedkavé rasy.

4. Kontrola pingom
Skontroluje, či je server online. Monitorovací systém môže vykonať túto kontrolu, nie je potrebné písať kód.

Nižšie je obrázok, ako vyzerá komponent „Server“ v monitorovacom systéme:

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Monitorovanie zariadení

Poviem vám, ako sa získavajú údaje. Pre každý cestný kontrolný bod (MPC) existuje úloha v plánovači úloh, napríklad „Survey MPC M2 km 200“. Úloha prijíma dáta zo všetkých MPC zariadení každých 30 minút.

Problém komunikačného kanála
Väčšina zariadení sa nachádza mimo mesta, na prenos dát sa používa sieť GSM, ktorá nefunguje stabilne (sieť existuje, resp. nie je).

Kvôli častým výpadkom siete vyzerala kontrola prieskumu MPC v monitoringu najskôr takto:

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Ukázalo sa, že to nie je funkčná možnosť, pretože bolo veľa falošných upozornení na problémy. Potom bolo rozhodnuté použiť „kontrolu priebehu“ pre každé zariadenie, t.j. Do monitorovacieho systému sa odošle iba signál o úspešnosti, keď je zariadenie vyzvané bez chyby. Čas relevantnosti bol nastavený na 5 hodín.

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Monitoring teraz posiela upozornenia o problémoch iba vtedy, keď zariadenie nemôže byť vyzvané dlhšie ako 5 hodín. S vysokou mierou pravdepodobnosti nejde o plané poplachy, ale o skutočné problémy.

Nižšie je obrázok toho, ako vyzerá zariadenie v monitorovacom systéme:

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Dôležité!
Keď sieť GSM prestane fungovať, všetky zariadenia MDC nebudú vyzvané. Aby sme znížili počet e-mailov z monitorovacieho systému, naši inžinieri sa prihlásia na odber upozornení na problémy s komponentmi s typom „MPC“ a nie „Zariadenie“. To vám umožňuje prijímať jedno upozornenie pre každé MPC namiesto toho, aby ste dostávali samostatné upozornenie pre každé zariadenie.

Konečná monitorovacia schéma ASMO

Poďme si dať všetko dokopy a uvidíme, aký druh monitorovacej schémy máme.

Slona jeme po častiach. Stratégia monitorovania zdravia aplikácií s príkladmi

Záver

Poďme si to zhrnúť.
Čo nám dalo sledovanie výkonu ASMO?

1. Čas odstránenia defektu sa skrátil
O chybách sme už od používateľov počuli, no nie všetci používatelia chyby hlásia. Stalo sa, že o poruche niektorej súčasti systému sme sa dozvedeli týždeň po jej objavení. Teraz nás monitorovací systém upozorní na problémy hneď, ako sa zistí problém.

2. Stabilita systému sa zvýšila
Keďže defekty sa začali odstraňovať skôr, systém ako celok začal fungovať oveľa stabilnejšie.

3. Zníženie počtu volaní na technickú podporu
Mnohé problémy sú teraz vyriešené skôr, ako o nich používatelia vôbec vedia. Používatelia začali menej často kontaktovať technickú podporu. To všetko má dobrý vplyv na našu povesť.

4. Zvýšenie lojality zákazníkov a používateľov
Zákazník zaznamenal pozitívne zmeny v stabilite systému. Používatelia majú pri používaní systému menej problémov.

5. Znížte náklady na technickú podporu
Prestali sme vykonávať akékoľvek manuálne kontroly. Teraz sú všetky kontroly automatizované. Predtým sme sa o problémoch dozvedeli od používateľov, často bolo ťažké pochopiť, o akom probléme používateľ hovorí. Teraz väčšinu problémov hlási monitorovací systém, notifikácie obsahujú technické údaje, z ktorých je vždy jasné, čo sa pokazilo a kde.

Dôležité!
Monitorovací systém nemôžete nainštalovať na rovnaký server, kde bežia vaše aplikácie. Ak dôjde k výpadku servera, aplikácie prestanú fungovať a nebude nikto, kto by o tom informoval.

Monitorovací systém musí bežať na samostatnom serveri v inom dátovom centre.

Ak nechcete používať dedikovaný server v novom dátovom centre, môžete použiť cloudový monitorovací systém. Naša spoločnosť používa cloudový monitorovací systém Zidium, ale môžete použiť akýkoľvek iný monitorovací systém. Náklady na cloudový monitorovací systém sú nižšie ako prenájom nového servera.

Odporúčanie:

  1. Rozdeľte aplikácie a systémy vo forme stromu komponentov čo najpodrobnejšie, takže bude vhodné pochopiť, kde a čo je pokazené, a ovládanie bude úplnejšie.
  2. Na kontrolu funkčnosti komponentu použite testy. Je lepšie použiť veľa jednoduchých kontrol ako jednu komplexnú.
  3. Nakonfigurujte metrické prahy na strane monitorovacieho systému namiesto ich zapisovania do kódu. To vám ušetrí potrebu prekompilovať, prekonfigurovať alebo reštartovať aplikáciu.
  4. Pri vlastných kontrolách použite určitý čas, aby ste sa vyhli prijímaniu falošných upozornení, pretože dokončenie niektorých kontrol trvalo o niečo dlhšie ako zvyčajne.
  5. Pokúste sa, aby sa komponenty v monitorovacom systéme rozsvietili na červeno iba vtedy, keď sa určite vyskytne problém. Ak sa pre nič za nič rozsvietia na červeno, potom prestanete venovať pozornosť upozorneniam monitorovacieho systému, stratí sa jeho význam.

Ak ešte nepoužívate monitorovací systém, začnite! Nie je to také ťažké, ako sa zdá. Vychutnajte si pohľad na strom zelených ingrediencií, ktorý ste si sami vypestovali.

Veľa šťastia.

Zdroj: hab.com

Pridať komentár