Vzory pozorovatelnosti

Tip

Tento obsah je výňatek z eBooku, Architekting Cloud Native .NET Applications for Azure, který je k dispozici na webu Docs pro .NET nebo jako soubor PDF zdarma ke stažení, který si můžete přečíst offline.

Stáhnout PDF

Stejně jako byly vyvinuty vzory, které pomáhají při rozložení kódu v aplikacích, existují vzory pro provoz aplikací spolehlivým způsobem. Objevily se tři užitečné vzory při údržbě aplikací: protokolování, monitorování a výstrahy.

Kdy použít protokolování

Bez ohledu na to, jak opatrní jsme, se aplikace téměř vždy chovají neočekávaně v produkčním prostředí. Když uživatelé hlásí problémy s aplikací, je užitečné zjistit, co se s aplikací děje, když k problému došlo. Jedním z nejskutenějších a skutečných způsobů zachycení informací o tom, co aplikace dělá, když je spuštěná, je, aby aplikace zapisuje, co dělá. Tento proces se označuje jako protokolování. Kdykoli dojde k selháním nebo problémům v produkčním prostředí, měl by být cílem reprodukovat podmínky, za kterých došlo k selháním v neprodukčním prostředí. Správné protokolování poskytuje vývojářům plán, jak postupovat, aby mohli duplikovat problémy v prostředí, se kterým je možné testovat a experimentovat.

Problémy při protokolování pomocí aplikací nativních pro cloud

V tradičních aplikacích jsou soubory protokolů obvykle uložené na místním počítači. Ve skutečnosti je v operačních systémech Unix definována struktura složek, která uchovává všechny protokoly, obvykle pod /var/log.

Obrázek 7–1 Protokolování do souboru v monolitické aplikaci

Užitečnost protokolování do plochého souboru na jednom počítači se výrazně snižuje v cloudovém prostředí. Aplikace vytvářející protokoly nemusí mít přístup k místnímu disku nebo místní disk může být vysoce přechodný, protože kontejnery se prohazují kolem fyzických počítačů. Dokonce i jednoduché vertikální navýšení kapacity monolitických aplikací napříč několika uzly může usnadnit vyhledání příslušného souboru protokolu založeného na souborech.

Obrázek 7–2 Protokolování do souborů ve škálované monolitické aplikaci

Aplikace nativní pro cloud vyvinuté pomocí architektury mikroslužeb také představují některé výzvy pro protokolovací nástroje založené na souborech. Požadavky uživatelů teď můžou zahrnovat více služeb, které běží na různých počítačích, a můžou obsahovat funkce bez serveru bez přístupu k místnímu systému souborů. Bylo by velmi náročné korelovat protokoly od uživatele nebo relace napříč těmito mnoha službami a počítači.

Obrázek 7–3 Protokolování do místních souborů v aplikaci mikroslužeb

Počet uživatelů v některých aplikacích nativních pro cloud je nakonec vysoký. Představte si, že každý uživatel při přihlášení k aplikaci generuje stovky řádků zpráv protokolu. V izolaci je to spravovatelné, ale vynásobte, že více než 100 000 uživatelů a objem protokolů se stává dostatečně velký, aby specializované nástroje byly potřebné k podpoře efektivního používání protokolů.

Protokolování v aplikacích nativních pro cloud

Každý programovací jazyk má nástroje, které umožňují zápis protokolů a obvykle režijní náklady na zápis těchto protokolů jsou nízké. Mnoho knihoven protokolování poskytuje protokolování různých druhů kritického stavu, které je možné v době běhu ladit. Knihovna Serilog je například oblíbenou knihovnou strukturovaného protokolování pro .NET, která poskytuje následující úrovně protokolování:

• Podrobnosti
• Ladění
• Informační
• Upozorňující
• Error
• Fatální

Tyto různé úrovně protokolů poskytují členitost protokolování. Pokud aplikace funguje správně v produkčním prostředí, může být nakonfigurovaná tak, aby protokolovala jenom důležité zprávy. Při nesprávném chování aplikace je možné zvýšit úroveň protokolu, aby se shromáždily více podrobných protokolů. Tím se vyrovnává výkon proti snadnému ladění.

Vysoký výkon nástrojů pro protokolování a možnosti optimalizace podrobností by měl vývojářům povzbuzovat, aby se často protokolovali. Mnoho dává přednost vzoru protokolování vstupu a ukončení každé metody. Tento přístup může znít jako nadměrné dovednosti, ale není časté, že vývojáři budou chtít méně protokolování. Ve skutečnosti není neobvyklé provádět nasazení pouze za účelem přidání protokolování kolem problematické metody. Rr na straně příliš mnoho protokolování a ne příliš málo. Některé nástroje lze použít k automatickému poskytování tohoto typu protokolování.

Kvůli problémům spojeným s používáním protokolů založených na souborech v aplikacích nativních pro cloud se preferují centralizované protokoly. Protokoly shromažďují aplikace a odesílají se do centrální aplikace protokolování, která protokoly indexuje a ukládá. Tato třída systému může každý den ingestovat desítky gigabajtů protokolů.

Je také užitečné dodržovat některé standardní postupy při vytváření protokolování, které zahrnuje mnoho služeb. Například generování ID korelace na začátku dlouhé interakce a následné protokolování v každé zprávě, která souvisí s danou interakcí, usnadňuje hledání všech souvisejících zpráv. Stačí najít jenom jednu zprávu a extrahovat ID korelace, aby se našly všechny související zprávy. Dalším příkladem je zajištění, aby byl formát protokolu pro každou službu stejný, ať už používá jazyk nebo knihovnu protokolování. Tato standardizace usnadňuje čtení protokolů. Obrázek 7–4 ukazuje, jak může architektura mikroslužeb využívat centralizované protokolování jako součást pracovního postupu.

Obrázek 7–4 Protokoly z různých zdrojů se ingestují do centralizovaného úložiště protokolů.

Problémy se zjišťováním a reagováním na potenciální problémy se stavem aplikace

Některé aplikace nejsou klíčové. Možná se používají interně a když dojde k problému, uživatel může kontaktovat zodpovědný tým a aplikaci je možné restartovat. Zákazníci ale často mají vyšší očekávání pro aplikace, které spotřebovávají. Než vás uživatelé upozorní, měli byste vědět, kdy u aplikace dojde k problémům. V opačném případě může být první, co víte o problému, když si všimnete rozzlobeného poplašného příspěvku sociálních médií, které vaši aplikaci nebo dokonce vaši organizaci oznamují.

Mezi scénáře, které možná budete muset zvážit, patří:

• Jedna služba ve vaší aplikaci neustále selhává a restartuje, což vede k přerušovaným pomalým odpovědím.
• V některých denních časech je doba odezvy vaší aplikace pomalá.
• Po posledním nasazení se zatížení databáze ztrojnásobí.

Správně implementované monitorování vám může dát vědět o podmínkách, které můžou vést k problémům, což vám umožní vyřešit základní podmínky, než způsobí jakýkoli významný dopad na uživatele.

Monitorování aplikací nativních pro cloud

Některé centralizované systémy protokolování přebírají další roli shromažďování telemetrie mimo čistě protokoly. Můžou shromažďovat metriky, například čas spuštění databázového dotazu, průměrnou dobu odezvy z webového serveru a dokonce průměrné zatížení procesoru a zatížení paměti, jak hlásí operační systém. Ve spojení s protokoly mohou tyto systémy poskytovat ucelený pohled na stav uzlů v systému a aplikaci jako celek.

Možnosti shromažďování metrik monitorovacích nástrojů lze také ručně předávat z aplikace. Obchodní toky, které jsou obzvláště zajímavé, jako je registrace nových uživatelů nebo zadávání objednávek, mohou být instrumentovány tak, aby inkrementovaly čítač v centrálním monitorovacím systému. Tento aspekt odemyká monitorovací nástroje nejen ke sledování stavu aplikace, ale i ke stavu firmy.

Dotazy je možné vytvořit v nástrojích pro agregaci protokolů a hledat určité statistiky nebo vzory, které se pak dají zobrazit v grafické podobě na vlastních řídicích panelech. Týmy často investují do velkých displejů připojených zeď, které otáčejí statistikou související s aplikací. Tímto způsobem je jednoduché vidět problémy, ke kterým dochází.

Nástroje pro monitorování nativní pro cloud poskytují telemetrii a přehled o aplikacích v reálném čase bez ohledu na to, jestli jde o monolitické aplikace s jedním procesem nebo distribuované architektury mikroslužeb. Zahrnují nástroje, které umožňují shromažďování dat z aplikace a také nástroje pro dotazování a zobrazování informací o stavu aplikace.

Problémy s reakcí na kritické problémy v aplikacích nativních pro cloud

Pokud potřebujete reagovat na problémy s aplikací, potřebujete nějaký způsob, jak upozornit správné pracovníky. Jedná se o třetí model pozorovatelnosti aplikací nativní pro cloud a závisí na protokolování a monitorování. Vaše aplikace musí mít zavedené protokolování, aby bylo možné diagnostikovat problémy, a v některých případech je potřeba ho připojit k monitorovacím nástrojům. Potřebuje monitorování pro agregaci metrik aplikací a dat o stavu na jednom místě. Po vytvoření je možné vytvořit pravidla, která aktivují výstrahy, když některé metriky spadají mimo přijatelné úrovně.

Obecně platí, že výstrahy jsou vrstvené nad monitorováním, aby určité podmínky aktivovaly příslušné výstrahy, které upozorní členy týmu na naléhavé problémy. Mezi scénáře, které můžou vyžadovat upozornění, patří:

• Jedna ze služeb vaší aplikace nereaguje po 1 minutě výpadku.
• Vaše aplikace vrací neúspěšné odpovědi HTTP na více než 1 % požadavků.
• Průměrná doba odezvy pro koncové body klíče vaší aplikace překračuje 2 000 ms.

Upozornění v aplikacích nativních pro cloud

Můžete vytvářet dotazy na monitorovací nástroje a hledat známé stavy selhání. Dotazy můžou například prohledat příchozí protokoly s informacemi o stavovém kódu HTTP 500, což značí problém na webovém serveru. Jakmile se zjistí některá z těchto možností, může se odeslat e-mail nebo zpráva SMS vlastníkovi původní služby, která může začít zkoumat.

Obvykle ale jedna chyba 500 nestačí k určení, že došlo k problému. Může to znamenat, že uživatel nesprávně zadal heslo nebo zadal nějaká poškozená data. Dotazy na výstrahy je možné vytvořit tak, aby se aktivovaly pouze v případech, kdy se zjistí větší než průměrný počet chyb 500.

Jedním z nejškodivějších vzorců v upozorňování je aktivovat příliš mnoho výstrah, aby lidé mohli vyšetřovat. Vlastníci služeb se rychle změní na chyby, které dříve prošetřili a zjistili, že jsou neškodné. Když dojde k pravdivým chybám, ztratí se v šumu stovek falešně pozitivních výsledků. Podobenství Chlapce Kdo Cried Wolf je často řečeno dětem, aby je varovaly před tímto nebezpečím. Je důležité zajistit, aby výstrahy, které se aktivují, značily skutečný problém.

PředchozíDalší