Vývoj operací s pozorovatelnostmi
 Získejte přehled o systému, odvozujte přehled a proveďte rozhodnutí řízená daty. |
|---|
Vytvořte kulturu, která nepřetržitě zlepšuje kvalitu monitorováním úlohy a zohledněním všech pilířů architektury Azure Well-Architected Framework. Umožňuje týmu a zúčastněným stranám provádět krátkodobá i dlouhodobá rozhodnutí napříč mnoha omezujícími vlastnostmi tím, že poskytují potřebná data, statistiky a trendy. Seznamte se s vylepšeními dat a jednotek.
Operace vytvořené pro účely pozorovatelnosti jsou klíčem k proaktivní údržbě aplikace, kontroly kvality a zabezpečení, plánování kapacity a řízení produktů.
Klíčovým aspektem monitorování aplikací je použití modelování stavu, které vám pomůže předvídat problémy před tím, než se stanou incidenty a ovlivní prostředí zákazníků. Efektivní monitorování snižuje reaktivní cykly strávené na řízení incidentů.
Ukázkový scénář
Společnost Contoso vyvinula aplikaci pro interní použití s názvem Contoso Real Estate. Tato webová aplikace umožňuje novým zaměstnancům nebo stávajícím zaměstnancům, kteří se přesouvají, hledat a rezervovat krátkodobé bydlení, aby pomohli s jejich přemístěním. Personální oddělení společnosti Contoso také aplikaci používá k usnadnění přemístění.
Aplikace je v produkčním prostředí a nasazuje se zcela v Azure. Je založená na mikroslužbách využívajících Azure Container Apps a používá také Azure Functions, Azure Database for PostrgreSQL, Azure Blob Storage a Azure Monitor.
Sledování úloh prostřednictvím telemetrie
Vygenerujte telemetrii z kódu aplikace, který koreluje klíčové body toku provádění, a poskytuje ucelené zobrazení na různých úrovních členitosti.
Určete prioritu akcí na základě úrovně závažnosti a porozumíte kontextu vzhledem k jeho podrobnostem. Tyto informace jsou zásadní pro účely řešení potíží.
Výzva společnosti Contoso
- Uživatelé hlásí, že po nedávné aktualizaci aplikace Contoso Real Estate se jim občas zobrazuje prázdná stránka nebo obecná chybová zpráva na vyhledávací stránce webové aplikace. Chyby se zdají být náhodné a funkce vyhledávání obvykle funguje, pokud uživatelé jenom aktualizují stránku nebo znovu odešle vyhledávání.
- Při kontrole protokolů v mikroslužbě vyhledávání si tým všimne nárůstu chyb kvůli vypršení časových limitů připojení ke službě Azure Database for PostgreSQL, ale momentálně nemají žádný způsob, jak zjistit, jestli chyba, která se zobrazí v protokolech mikroslužeb vyhledávání, odpovídá chybovým stránkám, které uživatelé vidí, nebo ne.
Použití přístupu a výsledků
- Vývojový tým se rozhodl rozšířit informace, které protokolují z webové aplikace i základních mikroslužeb, aby se podrobněji podívali na problém. V případě scénáře hledání se ujistěte, že zachytí hledané termíny spolu s dalšími dostupnými atributy transakcí, jako je čas, IP adresa klienta a uživatelské jméno přidružené k hledání. Tato další data by jim měla poskytnout dostatek informací, aby bylo možné korelovat transakce napříč vrstvami.
- Tato změna týmu umožnila potvrdit, že došlo k vypršení časových limitů databázových dotazů, které nebyly správně zpracovány v nejnovější aktualizaci aplikace, byly hlavní příčinou selhání, ke kterým došlo u uživatelů. Po nalezení původní příčiny bylo pro tým jednoduché implementovat opravu.
- Tým teď navrhuje nový přístup pomocí OpenTelemetry k implementaci komplexnějšího distribuovaného trasovacího řešení, které pokrývá všechny úrovně řešení.
Vizualizace dat monitorování na řídicích panelech
Agregace a vizualizace dat na řídicích panelech za účelem prezentace dat monitorování, která jsou zaměřená na cílové skupiny, a mějte na paměti obchodní kontext. Pomocí situačních řídicích panelů můžete získat přehled o datech mezi zúčastněnými stranami. Používejte provozní řídicí panely a sešity s možnostmi přechodu k podrobnostem pro aktivity operátorů, jako je reakce na incidenty. Často aktualizujte řídicí panely a poskytněte podrobná data.
Pomocí vizualizací můžete analyzovat trendy, sledovat obchodní cíle a spravovat incidenty.
Řídicí panely, které jsou přizpůsobené zájmu zákazníka, činí interpretace relevantní a urychlují dobu detekce a akcelerace.
Výzva společnosti Contoso
- Tým úloh agreguje telemetrická data z různých úrovní řešení do jednoho pracovního prostoru služby Log Analytics, ke kterému můžou přistupovat provozní a vývojové týmy a další účastníci projektu. Interakce s daty je ale obtížná a složitá, což je frustrující pro členy týmu, kteří potřebují rozlišovat šum na pozadí od použitelných dat.
Použití přístupu a výsledků
- Tým se snaží agregovat a vizualizovat data pomocí řídicích panelů. Každý řídicí panel se přizpůsobí konkrétnímu cílové skupině:
- Řídicí panely zúčastněných stran řešení budou více orientované na obchodní činnost, které představují přehled celkového stavu řešení, spolu s obchodními indikátory, jako je počet uživatelů obsluhovaných, vyhledávání a rezervace.
- Provozní řídicí panely a sešity budou obsahovat podrobnější a podrobná data provozního týmu. Tyto řídicí panely budou mít možnosti přechodu k podrobnostem, které uživatelům umožňují zkoumat data na různých úrovních členitosti. Uživatelé budou moct tyto řídicí panely a sešity používat k řešení potíží a dalších úloh reakce na incidenty.
- Řídicí panely umožní uživatelům efektivněji analyzovat trendy, sledovat obchodní cíle a spravovat incidenty. Data prezentovaná na každém řídicím panelu budou pro svou zamýšlenou cílovou skupinu relevantnější a budou řízena jejich zájmy a potřebami.
Návrh robustní strategie upozorňování
Upozorňováním na zodpovědné role pomocí standardizovaných popisů a úrovní závažnosti můžete nastavit výstrahy. Zadejte informace kompletované z různých zdrojů a sledujte odchylky od obchodních cílů.
Aktivujte výstrahy pouze pro incidenty, které vyžadují akci, a snažte se proaktivní a promyšlené výstrahy, které iniciují akce před degradovaným stavem se stane selháním. Dobrý systém upozornění identifikuje akce a závažnost a poskytuje pouze dostatek dat, aby mohl řídit srozumitelnost a účel. Operátory se můžou spustit při nápravě bez zpoždění.
Výzva společnosti Contoso
- Azure Monitor se používá k odesílání upozornění provoznímu týmu, když se něco nepovede. V současné době ale tým dostává příliš mnoho upozornění, která nejsou relevantní, nejasná nebo redundantní. To způsobuje únavu výstrah a ovlivňuje produktivitu týmu a způsobuje, že některé důležité výstrahy se nevšimnou.
- Došlo také k některým situacím výpadků, kterým se mohlo zabránit nebo minimalizovat, pokud byla výstraha odeslána s očekáváním selhání. Pokud by tým měl lepší upozornění na snížení výkonu před výpadky, mohly by se těmto situacím vyhnout. Došlo například k případům, kdy došlo ke zpomalení doby zpracování databázových dotazů kvůli výpadkům. Při řešení potíží s výpadky si tým všimne, že výkon zpracování dotazů se v průběhu času pomalu snižuje, horší a horší, dokud nezpůsobí úplný výpadek.
Použití přístupu a výsledků
- Provozní tým spustí iniciativu, která vyčistí všechna upozornění s nízkou prioritou, což způsobuje únavu výstrah. Aktivní zůstanou pouze kritická a použitelná upozornění. Tým také zkontroluje (a podle potřeby vylepší) výstrahy, které zůstanou aktivní, aby zajistily, že obsahují dostatečný kontext, který jim umožní provést nezbytná nápravná opatření.
- Také využijí příležitost definovat nové proaktivní a použitelné výstrahy, které jim umožní provést akci před selháním. Například vygenerují novou výstrahu, která upozorní dbA, jakmile se zobrazí konzistentní zpomalení v databázovém dotazu.
- V dalším kroku se tým snaží automatizovat odpovědi na běžné výstrahy, jako je situace s výkonem databázových dotazů.