Modelování stavu pro úlohy

Cloudové aplikace generují velké objemy provozních dat, což ztěžuje rychlé určení a řešení problémů. Běžným důvodem této výzvy je absence standardních hodnot stavu, která je přizpůsobená funkcím úlohy a nemožnost zjistit odchylku od tohoto směrného plánu.

Modelování stavu je pozorovatelné cvičení, které kombinuje obchodní kontext s nezpracovanými daty monitorování a kvantifikuje celkový stav úlohy. Pomáhá nastavit směrný plán, se kterým můžete monitorovat zatížení. Měli byste zvážit data, jako je telemetrie z infrastruktury a komponent aplikací. Modelování stavu může také zahrnovat další informace, které jsou nezbytné k dosažení cílů kvality úlohy.

Problémy s výkonem nebo snížení provozu můžou způsobit posun od očekávaného provozního stavu. Modelováním stavu úlohy můžete identifikovat odchylky a provádět informovaná provozní rozhodnutí, která berou v úvahu obchodní dopad.

Modelování stavu překlenuje mezeru mezi provozními znalostmi kmene a použitelnými přehledy. Pomáhá efektivně spravovat kritické problémy. Koncept je nezbytný k maximalizaci spolehlivosti a provozní efektivity.

Tato příručka nabízí praktické pokyny k modelování stavu, včetně toho, jak sestavit model, který vyhodnocuje stav modulu runtime úlohy a všech jeho subsystémů.

Terminologie	Definice
Modelování stavu	Cvičení pozorovatelnosti, které používá obchodní kontext k interpretaci dat monitorování jako stavů
Model stavu	Grafické znázornění logických entit a jejich vztahů pro daný obor Každý uzel má definici stavu pro racionalizaci dat monitorování v rámci modelu.
Entita stavu	Logická komponenta, která představuje jednotlivou jednotku systému, logickou kombinaci více souvisejících entit nebo celkového systému.
Stav	Definovaný a měřitelný stav, který poskytuje smysluplné provozní přehledy o stavu entity.
Signál stavu	Jednotlivé datové proudy, které poskytují přehled o provozním chování entity.
Model modelů	Agregovaný obor modelování, ve kterém entity představují jedinečné modely stavu pro systémy komponent.

Doporučujeme, abyste se na toto video dívali, abyste získali základní znalosti o modelování stavu.

Co je stav, modelování stavu a model stavu?

Termín health odkazuje na provozní stav entity a její závislosti. Tato entita může být samostatnou jednotkou systému, logickou kombinací více souvisejících entit nebo celkovým systémem.

Doporučujeme, abyste reprezentovali zdraví v jednom ze tří stavů:

• Zdravé: Funguje optimálně a splňuje očekávání kvality.

• Snížený výkon: Vykazuje méně než zdravé chování, které značí potenciální problémy.

• Není v pořádku: V kritickém stavu a vyžaduje okamžitou pozornost.

Poznámka:

Můžete znázornit stav s skóre místo stavů, abyste získali větší členitost dat.

Stavy se odvozují zkombinováním dat monitorování s informacemi o doméně. Každý stav musí být definován a musí být měřitelný. Stavy se počítají pomocí signálů stavu, což jsou jednotlivé datové proudy, které poskytují přehled o provozním chování entity. Signály můžou zahrnovat metriky, protokoly, trasování nebo jiné charakteristiky kvality. Například signál stavu pro entitu virtuálního počítače může sledovat metriku využití procesoru. Mezi další signály pro tuto entitu patří využití paměti, latence sítě nebo míra chyb.

Při definování zdravotních signálů zaužte nefunkční požadavky na úlohu. V příkladu využití procesoru zahrňte očekávané prahové hodnoty pro každý stav. Pokud využití překročí tolerovanou prahovou hodnotu v souladu s požadavky na úlohy, systém přejde ze stavu V pořádku na Degradovaný nebo Není v pořádku. Tyto změny stavu aktivují příslušné výstrahy nebo akce.

Modelování stavu vyžaduje, aby entity měly dobře definované stavy odvozené z více signálů stavu a jsou pro úlohu kontextově zarovnané. Definice stavu pro virtuální počítač může být například:

• V pořádku: Klíčové nefunkční požadavky a cíle, jako je doba odezvy, využití prostředků a celkový výkon systému, jsou plně splněné. Například 95 % požadavků se zpracovává do 500 milisekund. Úloha využívá prostředky virtuálních počítačů, jako jsou procesor, paměť a úložiště, optimálně a udržuje rovnováhu mezi požadavky na úlohy a dostupnou kapacitou. Uživatelské prostředí je na očekávaných úrovních.

• Snížený výkon: Prostředky nefungují optimálně, ale jsou stále funkční. Například na disku úložiště dochází k problémům s omezováním. Uživatelé můžou zaznamenat pomalé odpovědi.

• Není v pořádku: Snížení výkonu přesahuje tolerované limity. Prostředky už nereagují nebo jsou k dispozici a systém už nesplňuje přijatelné úrovně výkonu. Uživatelské prostředí je vážně ovlivněno.

Výsledkem modelování stavu je model nebo grafické znázornění logických entit a jejich vztahů pro architekturu úloh. Každý uzel má definici stavu.

Důležité

Modelování stavu je abstraktní koncept, který můžete implementovat a použít v různých oborech, pokud máte dobrý přehled o obchodních scénářích.

Na obrázku:

• Entity jsou logické komponenty úlohy, které představují aspekty systému. Můžou to být komponenty infrastruktury, jako jsou servery, databáze a sítě. Můžou to být také konkrétní aplikační moduly, pody, služby nebo mikroslužby. Entity můžou také zaznamenávat interakce uživatelů a systémové toky v rámci úlohy.

  Poznámka:

  Toky uživatelů a systémů shrnují nefunkční požadavky napříč obchodními scénáři, které zahrnují komponenty aplikací a infrastruktury. Tento souhrn odráží obchodní hodnotu aplikace.

• Vztahy mezi entitami zrcadlí řetězy závislostí v systému. Například modul aplikace může volat konkrétní komponenty infrastruktury, které tvoří relaci.

Představte si scénář, ve kterém u úlohy elektronického obchodování dochází k prudkému nárůstu neúspěšných zpráv ve frontě služby Azure Service Bus, což způsobuje selhání plateb. Tento problém je pro organizaci kritický kvůli předpokládané ztrátě výnosů. I když vývojář aplikace může pochopit vliv této špičky metrik na platby, tyto kmenové znalosti se často nesdílí napříč provozním týmem.

Model stavu může operátorům poskytnout okamžitý přehled o problému a jejích dopadech. Tok plateb závisí na službě Service Bus, což je jedna z komponent úloh. Vizuální reprezentace ukazuje snížený stav instance služby Service Bus a jeho vliv na tok platby. Operátoři můžou porozumět důležitosti problému a zaměřit své úsilí na nápravu na danou konkrétní komponentu.

Modelování stavu bylo v předchozím scénáři důležité následujícími způsoby:

• Vylepšila dobu detekce (TTD) a času pro zmírnění (TTM) tím, že umožnila rychlejší izolaci problémů, což vedlo k rychlejší detekci problémů a potenciálních oprav.

• Operátory obdržely výstrahy na základě stavů, které snížily zbytečný šum. Operátoři obdrželi oznámení, která poskytla konkrétní kontext týkající se obchodního dopadu na platby.

• Řetězy závislostí pomohly operátorům plně porozumět rozsahu provozních problémů. Tyto znalosti urychlily posouzení dopadu a vedly k prioritním odpovědím. Operátory také snadno identifikovaly kaskádové nebo korelované problémy.

• Operátoři prováděli aktivity po incidentu s přesností, protože model stavu poskytuje přehledy o původních příčinách anomálií a konkrétních signálech stavu, které se týkají.

• Data monitorování byla smysluplná pro všechny členy týmu. Překlela mezeru mezi kmenovými znalostmi a sdílenými přehledy.

• Organizace použila model stavu jako základ pro budoucí investice do operací řízených AI k odvození inteligentních přehledů.

Schéma modelu stavu

Modely stavu poskytují jedinečné schéma dat optimalizované pro případy použití pozorovatelnosti. Toto schéma přebírá modelování stavu z abstraktního konceptu do měřitelného řešení. Modelováním konkrétních požadavků, cílů a kontextu architektury můžete přizpůsobit data o stavu vašemu jedinečnému scénáři.

Stav je relativní koncept dat. Každý model představuje data o stavu, která jsou jedinečná a upřednostněná pro její kontextový obor, i když používá stejnou sadu entit. To, co je v určitém scénáři v pořádku , se může výrazně lišit v jiných kontextech.

Představte si například prostředky Azure stejného typu v rámci vaší úlohy.

• Virtuální počítač A spouští aplikaci citlivou na procesor.
• Virtuální počítač B zpracovává službu náročnou na paměť.

Definice stavu těchto počítačů se liší. Metriky využití procesoru pravděpodobně ovlivňují stav virtuálního počítače A a virtuální počítač B může určovat prioritu metrik souvisejících s pamětí.

Důležité

Model stavu by neměl zacházet se všemi selháními stejně. Měl by jasně rozlišovat mezi očekávaným nebo přechodným, ale obnovitelným selháním a skutečným stavem havárie.

Sestavení modelu stavu

Prvním krokem k vytvoření modelu stavu je logické cvičení návrhu, které obvykle zahrnuje aktivity popsané v následujících částech.

Vyhodnocení návrhu úloh

Zahajte toto cvičení logického návrhu vyhodnocením následujících součástí návrhu úloh.

• Komponenty infrastruktury, jako jsou výpočetní clustery a databáze

• Komponenty aplikací, které běží na výpočetních prostředcích a jejich relevantních komponentách

• Logické nebo fyzické závislosti mezi komponentami

• Toky uživatelů a systémů

Například model stavu pro aplikaci elektronického obchodování by měl představovat aktuální stav kritických procesů, jako je přihlášení uživatele, pokladna a platby.

Contextualizace s využitím obchodních požadavků

Vyhodnoťte relativní důležitost a celkový dopad jednotlivých toků na vaši organizaci. Zvažte faktory, jako je uživatelské prostředí, zabezpečení a provozní efektivita. Ve většině scénářů je například selhání procesu platby pravděpodobně důležitější než selhání procesu generování sestav.

Identifikujte cesty eskalace pro řešení problémů souvisejících s každým tokem. Další informace najdete v tématu Optimalizace návrhu úloh pomocí toků.

Poznámka:

Hodnotu modelování stavu si uvědomujete pouze v případě, že zahrnete obchodní scénáře a kontext. Pak můžete racionalizovat obchodní dopad z provozních problémů.

Mapování na metriky spolehlivosti

V návrhu aplikace vyhledejte relevantní metriky spolehlivosti.

Zvažte definování ukazatelů úrovně služeb (SLI) a cílů na úrovni služeb (SLO) pro celou aplikaci a její jednotlivé obchodní procesy. Tyto úrovně služby a cíle úrovně služby by měly odpovídat konkrétním signálům stavu, které se považují za váš model stavu. Tím vytvoříte komplexní definici stavu, která přesně odráží dosažení přijatelné úrovně služby pro aplikaci.

Důležité

SLI a SLO jsou kritické signály stavu. Vytvoří smysluplnou definici stavu, která odráží požadovanou úroveň služby spolu s dalšími atributy kvality. Můžete také definovat cíle stavu služby (SHO) pro zachycení stavu, kterého chcete dosáhnout v agregovaném časovém rozsahu.

Identifikace signálů stavu

Pokud chcete vytvořit komplexní model stavu, korelujte různé typy dat monitorování, včetně metrik, protokolů a trasování. Tím zajistíte, že koncept stavu přesně odpovídá stavu modulu runtime konkrétní entity nebo celé úlohy.

Použití metrik a protokolů platformy

V kontextu modelování stavu je nezbytné shromáždit metriky a protokoly na úrovni platformy z podkladových prostředků Azure. Mezi tyto metriky patří procento procesoru, síť v síti a odchozí síťové operace a diskové operace za sekundu. Tato data můžete použít ve svém modelu stavu k detekci a předpovídání potenciálních problémů při zachování spolehlivého prostředí.

Tento přístup navíc pomáhá rozlišovat mezi přechodnými chybami nebo dočasnými přerušeními a nepřehlednými chybami nebo trvalými problémy.

Poznámka:

Osvědčeným postupem je nakonfigurovat všechny prostředky aplikace tak, aby směrily diagnostické protokoly a metriky do zvolené technologie agregace protokolů. Vytvářejte ochranné mantinely pomocí azure Policy , abyste zajistili konzistentní nastavení diagnostiky napříč aplikací a vynucujte zvolenou konfiguraci pro každou službu Azure.

Přidání protokolů aplikace

Protokoly aplikací jsou důležitým zdrojem diagnostických dat pro váš model stavu. Tady je několik osvědčených postupů pro protokolování aplikací:

• Používejte sémantické nebo strukturované protokolování. Strukturované protokoly usnadňují automatizovanou spotřebu a analýzu dat protokolů ve velkém měřítku.

  Místo účtu úložiště zvažte ukládání metrik prostředků Azure a diagnostických dat do pracovního prostoru protokolů služby Azure Monitor. Pomocí této metody můžete vytvářet signály stavu pomocí dotazů Kusto pro efektivní vyhodnocení.

• Protokolování dat v produkčním prostředí Zachyťte komplexní data, zatímco aplikace pracuje v produkčním prostředí. Dostatečné informace jsou nezbytné pro posouzení stavu a k diagnostice případných zjištěných produkčních problémů.

• Protokolování událostí na hranicích služby Zahrňte ID korelace, které prochází hranicemi služby. Pokud transakce zahrnuje více služeb a jedna z nich selže, ID korelace vám pomůže sledovat požadavky v celé aplikaci a určit příčinu selhání.

• Použijte asynchronní protokolování. Vyhněte se synchronním operacím protokolování, které by mohly blokovat kód aplikace. Asynchronní protokolování zajišťuje dostupnost tím, že během zápisů protokolu brání backlogům požadavků.

• Oddělte protokolování aplikace od auditování. Udržujte protokoly auditu odděleně od diagnostických protokolů. I když záznamy auditu obsluhují požadavky na dodržování předpisů nebo zákonné požadavky, jejich zachování jedinečné brání vyřazeným transakcím.

Implementace distribuovaného trasování

Implementujte distribuované trasování korelací telemetrie mezi kritickými toky systému. Korelace telemetrie poskytuje přehledy o komplexních transakcích a je nezbytné pro efektivní analýzu původní příčiny (RCA), když dojde k selháním.

Použití sond stavu

Implementujte a spouštějte sondy stavu mimo aplikaci, abyste explicitně zkontrolovali stav a rychlost odezvy aplikace. Použijte odpovědi sondy jako signály v rámci modelu stavu.

Sondy stavu můžete implementovat měřením doby odezvy z aplikace jako celku nebo z jednotlivých komponent. Sondy můžou spouštět procesy, které měří latenci a kontrolují dostupnost nebo extrahují informace z aplikace. Další informace najdete v tématu Model monitorování koncových bodů stavu.

Většina nástrojů pro vyrovnávání zatížení podporuje spouštění sond stavu, které testují koncové body aplikace ping v nakonfigurovaných intervalech. Alternativně můžete použít externí službu watchdog. Služba watchdog agreguje kontroly stavu z více komponent v úloze. Watchdogs může také hostovat kód, který okamžitě opravuje známé stavy.

Přijetí technik strukturálního a funkčního monitorování

Strukturální monitorování zahrnuje vybavení aplikace sémantickými protokoly a metrikami. Aplikace přímo shromažďuje tyto metriky, mezi které patří aktuální spotřeba paměti, latence požadavků a další relevantní data na úrovni aplikace.

Posílit procesy monitorování pomocí funkčního monitorování. Tento přístup se zaměřuje na měření služeb platformy a jejich vliv na celkové uživatelské prostředí. Na rozdíl od strukturálního monitorování nevyžaduje funkční monitorování podrobné znalosti systému. Testuje externě viditelné chování aplikace. Tento přístup je užitečný při posuzování cílů úrovně služby a cílů úrovně služby.

Modelování návrhu

Představuje identifikovaný návrh aplikace jako entity a relace. Namapujte signály stavu na konkrétní komponenty pro kvantifikaci stavů na úrovni entity. Zvažte důležitost komponent a určete, jak se mají stavy rozšířit prostřednictvím modelu. Například komponenty pro vytváření sestav nemusí být tak kritické jako jiné komponenty, což vede k různým dopadům na celkový stav úloh.

Nastavení výstrah s možností akce

Pomocí vyhodnocených stavů můžete aktivovat výstrahy a automatizovanou akci. Stav by se měl integrovat do stávajících provozních runbooků jako základní datová sada pozorovatelnosti.

Obvykle existuje mapování 1:1 mezi daty monitorování a pravidly upozornění, které může vést k nežádoucím výsledkům, jako jsou bouře výstrah a šum okolních výstrah. Například ve výpočetním clusteru můžou velké objemy výstrah na úrovni virtuálního počítače na základě využití procesoru a počtu chyb zahltit operátory během selhání a způsobit zpoždění v řešení. Podobně pokud existuje velký počet nakonfigurovaných výstrah, okolní šum výstrahy často vede k přehlédnutí nebo ignorování výstrah.

Model stavu zavádí oddělení mezi daty monitorování a pravidly upozornění. Definice stavu agreguje mnoho signálů do jednoho stavu, což snižuje počet výstrah, aby se operátoři mohli zaměřit výhradně na výstrahy s vysokou hodnotou, které jsou pro organizaci kritické. Představte si scénář elektronického obchodování. Upozornění můžete nastavit tak, aby odesílala oznámení o změnách stavu toku plateb procesu, a ne změny v podkladových prostředcích, jako je fronta služby Service Bus.

Poznámka:

Možnost upozorňovat na všechny vrstvy modelu stavu poskytuje flexibilitu pro různé osoby úloh. Vlastníci aplikací a produktoví manažeři můžou být upozorněni na změny stavu v klíčových obchodních scénářích nebo v celé úloze. Operátory je možné upozorňovat na základě stavu infrastruktury nebo komponent aplikace.

Vizualizace modelu

Vytvářejte vizuální reprezentace, jako jsou tabulky nebo grafy, abyste efektivně vyjádřili aktuální stav a historii modelu stavu. Zajistěte, aby vizualizace odpovídala obchodnímu kontextu a poskytovala užitečné přehledy.

Když vizualizujete svůj model stavu, zvažte přechod na přístup k semaforu , abyste mohli okamžitě získat přehled o stavu napříč řetězy závislostí.

Přiřaďte zelenou pro zdravé, žlutou pro snížení výkonu a červenou pro špatné stavu. Díky rychlé identifikaci barevně zakódovaných stavů můžete efektivně najít původní příčinu jakéhokoli snížení výkonu aplikace.

Poznámka:

Doporučujeme zvážit požadavky na přístupnost pro osoby se zrakovým postižením při vytváření řídicího panelu pro váš model stavu. Osvědčené postupy vytváření diagramů najdete v tématu Diagramy návrhu architektury.

Přijetí modelu stavu

Po sestavení modelu stavu zvažte následující případy použití k řízení detekce a interpretace selhání nebo provozních problémů.

Použitelnost pro různé role

Modelování stavu může poskytovat informace specifické pro funkce úloh nebo role ve stejném kontextu úlohy. Role DevOps může například potřebovat provozní informace o stavu. Bezpečnostní důstojník by se mohl více zabývat vniknutím signálů a ohrožení zabezpečení. Správce databáze se pravděpodobně zajímá pouze o podmnožinu aplikačního modelu prostřednictvím databázových prostředků.

Přizpůsobte si přehledy o stavu pro různé zúčastněné strany. Zvažte vytvoření samostatných modelů od překrývajících se datových sad.

Průběžné ověřování

Pomocí modelu stavu můžete optimalizovat procesy testování a ověřování, jako je zátěžové testování a chaosové testování. Provozní stav modulu runtime můžete během testování ověřit a vyhodnotit efektivitu modelu ve scénářích škálování a selhání tím, že do technického životního cyklu začleníte modely stavu.

Stav organizace

I když modelování stavu je běžně spojené s kvantifikujícími stavy stavu pro jednotlivé aplikace, jeho použitelnost přesahuje tento rozsah.

Modely stavu na úrovni jednotlivých úloh poskytují základ pro pozorovatelnost aplikací a provozní přehledy. Každá aplikace může mít svůj vlastní model stavu, který zachycuje, co každý stav znamená v kontextu.

Více modelů stavu můžete kombinovat do konstrukce vysoké úrovně tím, že vytvoříte model modelů. Můžete například vytvořit pozorovatelnost obchodní jednotky nebo celého cloudového majetku pomocí modelů stavu jako komponent v rámci většího modelu. Modely stavu představují úlohy v rámci aktiv jako uzly v grafu nejvyšší úrovně. Relace v tomto modelu slouží k zachycení závislostí mezi aplikacemi, včetně toků dat, interakcí služeb a sdílené infrastruktury.

Vezměte v úvahu maloobchodní společnost, která má různé aplikace pro elektronické obchodování, platby a zpracování objednávek. Každou z těchto aplikací můžete definovat jako nezávislý model stavu a kvantifikovat, co pro danou úlohu znamená stav. Potom můžete pomocí nadřazeného modelu namapovat všechny tyto modely stavu komponent jako entity a zachytit provozní dopad mezi aplikacemi prostřednictvím řetězů závislostí. Pokud například aplikace elektronického obchodování není v pořádku, má kaskádový vliv na platební aplikaci.

Trendy stavu a AI pro IT provoz

Modelování stavu poskytuje kvantifikovaný provozní směrný plán, který je vyladěný na konkrétní obchodní kontext. AI pro IT provoz (AIOps) je oblíbený způsob, jak zvýšit efektivitu provozu. Data o stavu jsou základním vstupem pro modely strojového učení k analýze trendů stavu. Modely strojového učení můžou například:

• Extrahujte další přehledy ze změn stavu a doporučte akce.

• Analýza trendů stavu v průběhu času za účelem řízení predikce problému a upřesnění modelu

Údržba modelu stavu

Údržba heath modelu je nepřetržitá technická aktivita, která je v souladu s vývojem a provozem vaší aplikace. S vývojem vaší aplikace se ujistěte, že se váš model stavu vyvíjí paralelně.

Zacházet s modely stavu, jako jsou artefakty úloh, které by se měly integrovat do životního cyklu vývoje. Přijměte infrastrukturu jako kód (IaC) pro konzistentní správu modelu stavu řízenou verzí. Použijte automatizaci, aby model zůstal aktuální při přidávání nebo odebírání komponent infrastruktury a aplikací z úlohy.

Data o stavu se postupně snižují v hodnotě v průběhu času. Pokud chcete optimalizovat provozní efektivitu a minimalizovat náklady, vyhněte se uchovávání dat o stavu po dobu 30 dnů. V případě potřeby můžete archivovat data tak, aby splňovala požadavky auditu nebo ve scénářích, které zahrnují dlouhodobou analýzu vzorů v AI pro it operace.

Poznámka:

Když archivujete data o stavu, nezapomeňte je spojit se stavem konfigurace modelu. Interpretace změn stavu může být bez tohoto kontextu náročná.

Související odkazy

• Informace o implementaci sond stavu v ASP.NET najdete v tématu Kontroly stavu v ASP.NET Core.
• Informace o monitorování metrik najdete v přehledu metrik služby Azure Monitor.
• Informace o používání Application Insights najdete v tématu Application Insights.
• Aspekty návrhu a doporučení týkající se důležitých úloh najdete v tématu Modelování stavu a pozorovatelnosti důležitých úloh v Azure.
• Praktické zkušenosti najdete v tématu Návrh modelu stavu pro vaše klíčové úlohy.

Další krok

Doporučení pro návrh spolehlivé strategie monitorování a upozorňování