Strategie architektury pro monitorování spolehlivosti úloh

se vztahuje na toto doporučení kontrolního seznamu spolehlivosti v Azure Well-Architected Framework:

RE:10 Nepřetržitě měří a sleduje stav systému pomocí indikátorů dostupnosti a spolehlivosti napříč komponentami a kritickými toky. Zajistěte, aby byla tato data zachována a přístupná, aby byla zajištěna podpora včasné detekce, reakce a analýzy po incidentu.

Monitorování spolehlivosti je postup měření, jak dobře systém splňuje své obchodní požadavky v průběhu času s ohledem na odolnost a obnovitelnost. Dobře navržená monitorovací systém poskytuje zobrazení a trendy chování systému v reálném čase tím, že vytváří viditelnost napříč platformami, infrastrukturou a vrstvami úloh.

Díky korelaci těchto signálů mezi komponentami a v průběhu času umožňuje monitorování rychlé a sebevědomé analýzy incidentů a výpadků. Vytvořte strukturovaný přístup, aby přehledy byly smysluplné, výstrahy řídí správné akce a učení se vrátily do architektury a provozu.

Klíčové strategie v tomto článku vycházejí ze základní provozní praxe pozorovatelnosti popsané ve strategiích architektury OE:07 pro návrh monitorovacího systému. Pokyny k implementaci postupu monitorování jsou k dispozici v průvodci návrhem monitorování. Doporučujeme tyto prostředky nejprve zkontrolovat.

Definice

Term definice
SMLOUVA SLA (smlouva o úrovni služeb) Externí závazky, které dostáváte od dodavatelů, nebo které činíte vůči svým zákazníkům. Splnění smluv SLA může vést k finančním sankcím, poškození reputace nebo zhoršení uživatelského prostředí.
Cíle úrovně služeb (SLO) Cíle interního výkonu a spolehlivosti používané k definování prahových hodnot, které aktivují výstrahy a měří stav systému proti obchodním cílům.
Model zdraví Hierarchické znázornění stavu systému pomocí jasných stavů (v pořádku, snížený výkon, není v pořádku) se signály v reálném čase a schopnostmi přechodu k podrobnostem z celkového systému na jednotlivé komponenty.
Razítko Jednotka nasazení s definovanými limity kapacity, jako jsou maximální počet souběžných uživatelů, propustnosti nebo prahové hodnoty využití prostředků. Více razítek umožňuje škálování a regionální distribuci.
FMA (analýza režimu selhání) Systematická analýza pro identifikaci potenciálních bodů selhání v systému, která slouží k vedení strategie monitorování a vylepšení spolehlivosti.
RTO (cíl doby obnovení) Maximální přijatelná doba detekce, reakce a zotavení po selhání nebo incidentu.
Cíl bodu obnovení Maximální přijatelné množství ztráty dat měřené v čase, které představuje, kolik dat může být ztraceno během scénáře selhání.
Syntetické transakce Automatizované testy, které simulují skutečné akce uživatelů a ucelené interakce za účelem ověření stavu systému a zjišťování problémů z hlediska zákazníka a poskytují externí ověřování dostupnosti systému.
ID korelací Jedinečné identifikátory používané ke sledování transakcí a požadavků napříč několika službami a komponentami a umožňují identifikaci a analýzu problémů v distribuovaných systémech.
Přechodné chyby Dočasná selhání v závislostech systému, které se obvykle řeší během krátkého časového období, jako jsou vypršení časového limitu sítě nebo dočasná nedostupnost služby.
Koncová latence Doba odezvy u nejpomalejších požadavků, obvykle měřená při vysokých percentilech (p95, p99), kde se problémy s výkonem často objevují nejdříve.

Monitorování funkcí úloh

Sledujte, co váš systém skutečně přináší. Začněte sledováním toho, jestli se kritické pracovní postupy úspěšně dokončily a vytvořily platné výsledky. Systém může být v pořádku, zatímco stále vytváří nesprávné nebo neúplné výstupy, takže samotné spuštění nestačí.

Pokud například úloha generuje sestavy každých šest hodin, mělo by monitorování potvrdit dvě věci: že úloha běžela podle plánu a že vytvořila platný výsledek, například neprázdnou sestavu s očekávaným obsahem a velikostí. Tento druh ověřování pomáhá zajistit, aby systém nejen plnil úkoly, ale také poskytoval funkcionalitu, pro kterou byl navržen.

Monitorování uživatelského prostředí

Monitorujte spolehlivost z hlediska firmy a uživatele. V rámci analýzy režimu selhání (FMA) byste už měli identifikovat klíčové toky uživatelů. U každého toku sledujte, jak selhání v libovolné komponentě nebo závislosti ovlivňují uživatelské prostředí a jaký bude očekávaný výsledek. Například v pokladním procesu v elektronickém obchodování může výpadek služby nebo přetížení v platebních nebo systémech zásob zabránit zákazníkům v dokončení nákupů.

Spolehlivost také odráží kvalitu služeb. V toku pokladny by uživatelé měli být schopni dokončit nákupy bez přerušení. Pomocí metrik latence založených na percentilu, jako jsou p50, p95 a p99, můžete porozumět skutečnému uživatelskému prostředí se zvláštní pozorností na koncovou latenci, kdy se problémy s výkonem často zobrazí jako první.

Začleňte do modelu stavu signály, které jsou přístupné uživatelům, takže degradovaná kvalita služby aktivuje změny stavu. Modeluje kritické toky uživatelů, aby se snížení výkonu komponent rozšířilo směrem nahoru a propojilo dopad uživatele na viditelnost systému. Pomocí Azure Monitor modelů stavu můžete posoudit spolehlivost vašich Azure úloh.

Important

Monitorování výkonu poskytuje přehled o tom, jak se systém chová v reálném zatížení, a to rozdělením celkové latence napříč vrstvami systému. Spojuje změny výkonu, abyste pochopili, co ovlivnilo změnu chování. Příčinou můžou být nasazení, aktualizace konfigurace a události škálování. Monitorování spolehlivosti a výkonu společně poskytují kompletní přehled o chování systému a ukazují, kde zaměření pozornosti může mít největší dopad. Informace o monitorování výkonu naleznete v tématu Monitorování výkonu.

Sledování cílů dostupnosti

Sledujte, jak dobře systém splňuje definované cíle pro dostupnost, propustnost a dobu odezvy. Tyto cíle se často formalizují jako smlouvy o úrovni služeb (SLA) a cíle úrovně služeb (SLA) a odrážejí očekávání, která jste nastavili u uživatelů. Monitorování proti nim udržuje spolehlivost v souladu se skutečnými obchodními výsledky. Další informace najdete v tématu Cíle spolehlivosti a smlouvy o úrovni služeb.

Zaměřte se na klíčové ukazatele, které přispívají k těmto cílům, a sledujte je v průběhu času. Když dojde k odchylce, měli byste být schopni podrobně analyzovat konkrétní součásti nebo subsystémy. Zachyťte všechny relevantní signály, včetně problémů, které jsou skryté redundancí nebo přechodem na záložní systém, abyste pochopili, co se skutečně stalo, a zabránili opakování.

Zkombinujte povědomí v reálném čase s historickým kontextem. Signály v reálném čase pomáhají rychle reagovat, když jsou cíle ohroženy, zatímco trendy v průběhu času odhalí vzory a opakované problémy. Klasifikace příčin nedosažení cílů a agregace těchto metrik také podporuje jasné hlášení SLA a pomáhá s průběžným vylepšováním.

Monitorujte klíčové smlouvy SLA poskytované vašimi dodavateli a službami platforem (od Microsoftu a dalších). Měli byste:

  • Použijte model stavu k vyjádření plnění SLO, což umožňuje měřit celkový stav úlohy ve všech atributech kvality, nejen z hlediska dostupnosti/provozuschopnosti
  • Sledování indikátorů potenciálních porušení smlouvy SLA v reálném čase
  • Zachyťte a zachovejte důkazy potřebné k podpoře žádosti SLA, pokud dojde k porušení zabezpečení.

Sledování cílů obnovitelnosti

Sledujte obnovitelnost tím, že zacházíte s každým testem a skutečným incidentem jako s měřitelnou událostí. Pomocí dat monitorování ověřte, že váš systém a tým můžou za reálných podmínek splnit definované cíle obnovení.

Měření klíčových signálů, jako je čas detekce, reakce a obnovení (RTO), spolu s expozicí ztráty dat (RPO). Uveďte indikátory, jako je připravenost na převzetí služeb při selhání a kapacita, míra úspěšnosti převzetí služeb při selhání a doba provádění, úspěch zálohování a obnovení, prodleva replikace a požadovaný počet ručních zásahů.

Tyto metriky také zvýrazňují provozní mezery, jako jsou nejasné postupy, zpoždění rozhodování nebo obtížně přístupná dokumentace, které mohou ovlivnit výkon obnovy. Pomocí těchto přehledů můžete posílit postupy návrhu systému i reakce na incidenty.

Poznámka:

Dávejte pozor, aby zásady čištění nebo uchovávání informací nejsou tak agresivní, že odstraňují protokoly nebo telemetrii jenom tehdy, když je potřebujete nejvíce. V každém scénáři se zeptejte: Jaká data bychom potřebovali pochopit, co se stalo před incidentem a během incidentu? Užitečným přístupem je zamyslet se nad různými typy vyšetřování po incidentech, například:

  • Výpadky platformy nebo infrastruktury
  • Problémy s dostupností aplikací (například po změně nasazení nebo konfigurace)
  • Chyby aplikací způsobující ztrátu nebo poškození dat
  • Bezpečnostní incidenty

Vytváření výstrah s možností akce s využitím modelu stavu

Navrhněte výstrahy tak, aby jasně ukazovaly na něco, co stojí za to, a podložte je ve zdravotnickém modelu, který představuje systém, který používá jednoduché stavy, jako jsou zdravé, degradované a špatné.

Strukturujte model stavu hierarchicky, od jednotlivých komponent až po celý systém, abyste mohli rychle sledovat problémy s jejich zdrojem. Definujte prahové hodnoty pomocí cílů úrovně služeb (SLO) a kombinujte signály, jako jsou metriky, protokoly, trasování a syntetické kontroly, a vytvořte tak spolehlivý přehled o stavu systému. To dává operátorům jasný přehled o tom, co funguje, co není a kde se chovat bez zkoumání nezpracovaných dat. Další informace najdete v průvodci návrhem modelování stavu.

Vylaďte výstrahy pro skutečné podmínky tím, že se zaměříte na komplexní prostředí a kritické transakce, aby odrážely skutečný dopad na uživatele. Snižte šum tím, že zohledníte přechodné výkyvy a spustíte detekci významných změn zdravotního stavu namísto izolovaných výkyvů nebo špiček. Zkombinujte výstrahy v reálném čase s přehledy trendů, abyste zachytili okamžité problémy i postupné snížení výkonu a pomohli týmům rychle reagovat a soustředit se na ně.

Riziko: Modelování stavu vyžaduje shromažďování smysluplných signálů v celém systému. Spoléhání pouze na jednoduché metriky, jako je procesor nebo paměť, může chybět, co je ve skutečnosti důležité. Pokud chcete získat úplné zobrazení, zahrňte data uživatelského prostředí a syntetické kontroly. Definování "zdravý" vyžaduje sladění, a špatně vyladěné prahové hodnoty můžou způsobit šum a snížit efektivitu.

Monitorování všech vrstev systému

Monitorujte každou vrstvu systému, aplikace, dat/úložiště a sítě, abyste zachovali kompletní přehled o signálech spolehlivosti.

Pomocí modelu stavu můžete sjednotit signály napříč vrstvami systému, které představují Azure prostředky a komponenty aplikací v rámci toků uživatelů a systémů.

Ve vrstvě aplikace sledujte úspěšnost, selhání a latenci pomocí protokolů, metrik a sond stavu. Pomocí ID korelace můžete sledovat požadavky napříč službami a usnadnit řešení potíží. Shromážděte protokoly asynchronně, aby neměly vliv na výkon požadavků, a aby byly diagnostické a auditní protokoly oddělené, aby byly přehledné. Přidejte syntetické transakce a sondy koncových bodů, abyste ověřili, co zákazníci skutečně zažívají.

Kompromis. Volba mezi asynchronním a synchronním protokolováním zahrnuje rovnováhu mezi výkonem a spolehlivostí telemetrie.

  • Asynchronní protokolování udržuje protokolování mimo kritickou cestu, snižuje latenci a zlepšuje výkon systému. Přináší ale riziko ztráty telemetrie, zejména pokud dojde k selhání před vyprázdněním nebo uložením protokolů.

  • Synchronní protokolování zajišťuje, že se protokoly zapisují před pokračováním zpracování, což zlepšuje odolnost dat a auditovatelnost. Kompromis je zvýšená latence a užší párování mezi výkonem aplikace a systémem protokolování.

Ve většině scénářů je upřednostňovaným přístupem asynchronní protokolování kvůli minimálnímu dopadu na výkon. V silně regulovaných prostředích nebo v prostředích citlivých na audit však může být vyžadováno synchronní protokolování, aby se zajistilo spolehlivé zachycení kritických událostí.

Ve vrstvě dat a úložiště se zaměřte na dostupnost, míru úspěšnosti zápisu, latenci dotazů, vypršení časového limitu, zámky a tlak na prostředky. Podívejte se na trendy v průběhu času, abyste identifikovali rostoucí kritické body a odlišili krátkodobé problémy od trvalého snížení výkonu.

V síťové vrstvě monitorujte připojení, latenci, ztrátu paketů, šířku pásma a vzorce provozu. Zkombinujte protokoly toku, kontroly koncových bodů a syntetické testy pro problémy se směrováním, anomálie nebo chování související se zabezpečením. Připojte tyto signály zpět k datům aplikací a platforem, abyste pochopili, odkud problémy pocházejí.

Provozní protokoly pomáhají diagnostikovat problémy, sledovat výkon a pochopit chování systému. Nejsou navrženy tak, aby sloužily jako zdroj pravdivých informací pro obchodní události, auditování nebo regulační hlášení, které obvykle vyžadují silnější sledovatelnost.

Podrobnosti o monitorování jednotlivých vrstev najdete v průvodci návrhem monitorování.

Monitorujte administrativní panely a stavová rozhraní API

Rozšiřte monitorování na dashboardy, stavová API a reporty, na které operátoři a navazující nástroje spoléhají při zjišťování stavu systému. Považujte nesprávné nebo zastaralé hodnoty za problém se spolehlivostí, který vyžaduje stejnou míru důslednosti, aby systém fungoval správně.

Například v aplikaci pro správu objednávek může řídicí panel správy zobrazovat počet čekajících objednávek ze souhrnné tabulky aktualizované úlohou na pozadí. Pokud aktualizace selže bez upozornění, objednávky dál přicházejí, ale provozní pracovníci vycházejí z neaktuálního backlogu. Pravidelné porovnávání počtu na dashboardu s aktuálním dotazem nad tabulkou objednávek odhalí nesoulad dříve, než ovlivní zákazníky.

Definujte a monitorujte kapacitu razítka

Definujte jasné limity kapacity pro každou jednotku nasazení nebo razítko a pečlivě je monitorujte. Každé razítko funguje v rámci konečného limitu, ať už jde o maximální počet souběžných uživatelů, propustnosti nebo prahových hodnot využití prostředků. Díky těmto omezením tedy získáte spolehlivý základ pro rozhodování.

Tato viditelnost vám pomůže zjistit, kdy se razítko blíží sytosti, a to dříve, než ovlivní spolehlivost. Podporuje také včasná rozhodnutí o škálování, jako je přidání nových uzlů nebo redistribuce zatížení, a potvrzuje, že provoz probíhá podle vašeho návrhu.

Definování těchto limitů není vždy jednoduché. Kapacitu může být obtížné měřit, zejména pokud závisí na několika základních službách s různými charakteristikami škálování. Jako výchozí bod byste měli použít pokyny k platformě, jako jsou kvóty a limity z Microsoft Azure. V praxi se kapacita často určuje prostřednictvím zátěžového testování, pozorování a iterativního ladění místo přesného počátečního modelování.

Monitorování distribuce zatížení napříč redundantními instancemi

Když spustíte úlohu napříč několika redundantními instancemi, včetně toho, že distribuujete instance mezi různé oblasti nebo zóny, provoz a využití prostředků by měly zůstat v těchto instancích vyváženy.

Chcete odhalit nerovnováhy, které často odkazují na problémy se směrováním, problémy s konfigurací nebo omezení závislostí. Zajišťuje také, že cíle převzetí mají dostatečnou kapacitu pro převzetí provozu, pokud je to potřeba, a potvrzuje, že mechanismy redundance se chovají podle očekávání během stabilního provozu i při selhání.

Detekce režimů selhání

V rámci cvičení analýzy režimu selhání (FMA) byste měli identifikovat potenciální body selhání.

V praxi monitorování spolehlivosti sledujte tyto body průběžně. Začněte tím, že se zaměříte na jednodušší signály, jako jsou přechodné chyby. Monitorujte chování opakování a přechodné míry chyb, abyste pochopili, jak se vaše závislosti a základní služby chovají za skutečných provozních podmínek. Tyto signály poskytují včasný pohled na vznikající nestabilitu. Pomáhají rozpoznat, kdy se vzory opakování pokusů odchylují od očekávané normy, monitorují, zda je systém při zatížení zdravý, a identifikují, kdy závislost nebo externí služba začne zhoršovat, než to ovlivní uživatelské prostředí.

cs-CZ: Zahrňte také selhání s větším dopadem, jako jsou výpadky zóny dostupnosti, které ovlivňují část infrastruktury, výpadky služeb nebo oblastní výpadky, které mohou způsobit, že celá oblast Azure přejde do offline režimu. Dokonce sledujte scénáře zabezpečení, jako je DDoS nebo jiná škodlivá aktivita, chybná konfigurace komponent a problémy s výkonem, protože každá z nich může ovlivnit celkovou spolehlivost vašeho řešení.

Informace o FMA naleznete v tématu Strategie architektury pro analýzu režimu selhání.

Informujte se o stavu spolehlivosti platformy

K efektivní správě spolehlivosti potřebujete jasný přehled o stavu platformy. Toto povědomí vám pomůže rychle určit, jestli problém pochází z vaší úlohy nebo na základní cloudové platformě.

Azure Service Health poskytuje přehled o stavu Azure. Nakonfigurujte upozornění ve službě Service Health, abyste dostávali oznámení při změně podmínek platformy. Získáte aktualizace aktivních výpadků, které ovlivňují vaše prostředky, události plánované údržby, které můžou způsobit přerušení a snížení výkonu specifické pro jednotlivé oblasti nebo služby.

Usnadnění na platformě Azure

  • Začlenění služeb monitorování a upozorňování cloudových platforem, včetně:

  • Azure Monitor je komplexní řešení monitorování, které se používá ke shromažďování, analýze a reagování na data monitorování z cloudových a místních prostředí.

  • Modely stavu v Azure Monitoru vám pomáhají definovat, měřit a vizualizovat stav úloh tím, že propojují metriky, protokoly a trasování do použitelných stavů stavu napříč prostředky a komponentami Azure.

  • Log Analytics je nástroj na webu Azure Portal, který slouží k úpravám a spouštění dotazů protokolu na data v pracovním prostoru služby Log Analytics.

  • Application Insights je rozšíření služby Azure Monitor. Poskytuje funkce monitorování výkonu aplikací (APM).

  • Přehledy Azure Monitoru jsou pokročilé analytické nástroje, které pomáhají monitorovat služby Azure, jako jsou virtuální počítače, aplikační služby a kontejnery. Přehledy jsou postavené na službě Azure Monitor a Log Analytics.

  • Azure Monitor pro řešení SAP je nativní monitorovací produkt Azure pro prostředí SAP, která běží na Azure.

  • Monitorování připojení je nástroj pro průběžné sledování síťového připojení a výkonu napříč prostředky Azure. Spouští syntetické testy a poskytuje výstrahy a diagnostiku v reálném čase pro včasné zjišťování selhání. Můžete vytvořit vlastní sešity pro vizualizaci stavu připojení a agregovaných metrik výkonu.

  • Protokoly toku virtuální sítě je možné povolit napříč úlohami za účelem monitorování síťového provozu. Analýzy provozu jsou možné použít k analýze a rozšíření těchto protokolů toku, aby se mohly zobrazit přehledy, jako je blokovaný provoz, škodlivé toky a aktivní porty vystavené internetu. Vytváření pracovních sešitů umožňuje týmům monitorovat chování živého síťového provozu a přijímat výstrahy. Pomocí vizualizací časové osy a topologie můžete snadno monitorovat vzory provozu, které můžou značit snížení výkonu nebo bezpečnostní hrozby.

  • Osvědčené postupy pro více pracovních prostorů najdete v tématu Návrh architektury pracovního prostoru služby Log Analytics.

Example

Příklady řešení pro monitorování z reálného světa najdete v tématu Monitorování webových aplikací v Azure a základní architektuře pro cluster Azure Kubernetes Service.

  • Azure Monitor Baseline Alerts (AMBA) je centrální úložiště definic výstrah, které můžou zákazníci a partneři využít ke zlepšení jejich pozorovatelnosti prostřednictvím přijetí služby Azure Monitor.

Kontrolní seznam pro spolehlivost

Podívejte se na úplný soubor doporučení.

Kontrolní seznam pro spolehlivost

  • Last updated on