Modelování stavu a pozorovatelnost důležitých úloh v Azure

Modelování stavu a pozorovatelnost jsou základní koncepty pro maximalizaci spolehlivosti, které se zaměřují na robustní a kontextovou instrumentaci a monitorování. Tyto koncepty poskytují kritický přehled o stavu aplikací a podporují rychlou identifikaci a řešení problémů.

Většina klíčových aplikací je významná z hlediska rozsahu i složitosti, a proto generuje velké objemy provozních dat, což ztěžuje vyhodnocení a určení optimální provozní akce. Modelování stavu se nakonec snaží maximalizovat pozorovatelnost tím, že rozšiřuje nezpracované monitorovací protokoly a metriky o klíčové obchodní požadavky, aby se kvantifikoval stav aplikace, a aby bylo dosaženo konzistentních a zrychlených operací.

Tato oblast návrhu se zaměřuje na proces definování robustního modelu stavu a mapování kvantifikovaných stavů stavu aplikace prostřednictvím pozorovatelnosti a provozních konstruktorů za účelem dosažení provozní vyspělosti.

Důležité

Tento článek je součástí řady klíčových úloh Azure Well-Architected . Pokud tuto řadu neznáte, doporučujeme začít s tím, co je kritická úloha?

Při snaze o maximalizaci spolehlivosti existují tři hlavní úrovně provozní vyspělosti.

1. Zjišťovat problémy a reagovat na ně, jakmile k nim dochází.
2. Diagnostikujte problémy, ke kterým dochází nebo už došlo.
3. Predikovat a předcházet problémům předtím, než k nim dojde.

Video: Definování modelu stavu pro klíčové úlohy

Stav vrstvené aplikace

Pokud chcete vytvořit model stavu, nejprve definujte stav aplikace v kontextu klíčových obchodních požadavků kvantifikováním stavů "v pořádku" a "není v pořádku" ve vrstveném a měřitelném formátu. Potom pro každou komponentu aplikace upřesněte definici v kontextu stabilního stavu běhu a agregujte ji podle toků uživatelů aplikace. Zaplněte klíčovými nefunkčními obchodními požadavky na výkon a dostupnost. Nakonec agregujte stavy jednotlivých toků uživatelů, abyste vytvořili přijatelnou reprezentaci celkového stavu aplikace. Po vytvoření by se tyto definice stavu vrstev měly používat k informování důležitých metrik monitorování napříč všemi komponentami systému a k ověření složení provozního subsystému.

Důležité

Při definování stavů "není v pořádku", reprezentujte pro všechny úrovně aplikace. Pokud chcete kvalifikovat snížení výkonu služby vzhledem k nedostupnosti, je důležité rozlišovat mezi přechodnými a ne přechodnými stavy selhání.

Na co dát pozor při navrhování

• Proces modelování stavu je aktivita návrhu shora dolů, která začíná cvičením architektury, které definuje všechny toky uživatelů a mapuje závislosti mezi funkčními a logickými komponentami, a tím implicitně mapuje závislosti mezi prostředky Azure.

• Model stavu je zcela závislý na kontextu řešení, které představuje, a proto ho není možné vyřešit "před balením", protože "jedna velikost nevyhovuje všem".

  • Aplikace se budou lišit ve složení a závislostech.
  • Metriky a prahové hodnoty metrik pro prostředky musí být také jemně vyladěné z hlediska toho, jaké hodnoty představují stav v pořádku a není v pořádku, které jsou výrazně ovlivněné funkcemi zahrnuté aplikace a cílovými požadavky na nefunkční funkce.

• Model vrstveného stavu umožňuje trasování stavu aplikace zpět do závislostí nižší úrovně, což pomáhá rychle zhoršovat příčinu degradace služby.

• Aby bylo možné zachytit stav jednotlivých komponent, musí být odlišné provozní charakteristiky této komponenty pochopeny ve stabilním stavu, který odráží produkční zatížení. Testování výkonu je proto klíčovou funkcí pro definování a průběžné vyhodnocování stavu aplikace.

• K selháním v rámci cloudového řešení nemusí docházet izolovaně. Výpadek v jedné komponentě může vést k několika možnostem nebo nedostupnosti dalších součástí.

  • Takové chyby nemusí být okamžitě pozorovatelné.

Doporučení k návrhu

• Definujte měřitelný model stavu jako prioritu, abyste zajistili jasné provozní porozumění celé aplikaci.

  • Model stavu by měl být vrstvený a měl by odrážet strukturu aplikace.
  • Základní vrstva by měla brát v úvahu jednotlivé komponenty aplikace, jako jsou prostředky Azure.
  • Základní komponenty by se měly agregovat společně s klíčovými požadavky na nefunkční funkce, aby se do stavu systémových toků zabudoval kontextový obchodní kontext.
  • Systémové toky by se měly agregovat s odpovídajícími váhami na základě obchodní důležitosti, aby bylo možné vytvořit smysluplnou definici celkového stavu aplikace. Prioritu by měly mít finančně významné toky uživatelů nebo toky uživatelů orientované na zákazníka.
  • Každá vrstva modelu stavu by měla zaznamenávat, co představuje stav "v pořádku" a "není v pořádku".
  • Ujistěte se, že model heath dokáže rozlišovat mezi přechodnými a nepřemísnými stavy, které nejsou v pořádku, a izolovat tak degradaci služby od nedostupnosti.

• Reprezentujte stavy pomocí podrobného skóre stavu pro každou jedinečnou komponentu aplikace a každý tok uživatele agregací skóre stavu pro mapované závislé komponenty s ohledem na klíčové požadavky na nefunkční funkce jako koeficienty.

  • Skóre stavu toku uživatele by mělo být reprezentováno nejnižším skóre ve všech mapovaných komponentách, které by mělo zohlednit relativní dosažené výsledky vzhledem k nefunkčním požadavkům na tok uživatele.
  • Model použitý k výpočtu skóre stavu musí konzistentně odrážet provozní stav, a pokud ne, měl by se model upravit a znovu nasadit tak, aby odrážel nové poznatky.
  • Definujte prahové hodnoty skóre stavu tak, aby odrážely stav.

• Skóre stavu se musí automaticky vypočítat na základě podkladových metrik, které je možné vizualizovat prostřednictvím vzorů pozorovatelnosti a na které je možné reagovat prostřednictvím automatizovaných provozních postupů.

  • Skóre stavu by se mělo stát jádrem řešení monitorování, aby provozní týmy už nemusely interpretovat a mapovat provozní data na stav aplikace.

• Model stavu použijte k výpočtu dostupnosti dosažení cíle na úrovni služby (SLO) místo nezpracované dostupnosti, čímž zajistíte, aby se vymezení mezi snížením výkonu služby a nedostupností projevilo jako samostatné SLO.

• Pomocí modelu stavu v kanálech CI/CD a testovacích cyklech ověřte, že je stav aplikace po aktualizaci kódu a konfigurace zachován.

  • Model stavu by se měl používat ke sledování a ověření stavu během zátěžového testování a testování chaosu v rámci procesů CI/CD.

• Vytváření a údržba modelu stavu je iterativní proces a technické investice by měly být sladěny tak, aby podporovaly neustálé zlepšování.

  • Definujte proces pro průběžné vyhodnocování a doladění přesnosti modelu a zvažte investice do modelů strojového učení, abyste mohli model dále trénovat.

Příklad – Model vrstveného stavu

Toto je zjednodušená reprezentace modelu stavu vrstvené aplikace pro ilustrativní účely. Komplexní a kontextový model stavu je k dispozici v Mission-Critical referenčních implementacích:

• Klíčové online
• Připojeno k kritickým funkcím

Při implementaci modelu stavu je důležité definovat stav jednotlivých komponent prostřednictvím agregace a interpretace klíčových metrik na úrovni prostředků. Příklad použití metrik prostředků je na následujícím obrázku:

Tuto definici stavu lze následně reprezentovat dotazem KQL, jak ukazuje následující příklad dotazu, který agreguje InsightsMetrics (Container Insights) a AzureMetrics (nastavení diagnostiky pro cluster AKS) a porovnává (vnitřní spojení) s modelovanými prahovými hodnotami stavu.

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

Výsledný výstup tabulky lze následně transformovat na skóre stavu pro snadnější agregaci na vyšších úrovních modelu stavu.

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

Tato agregovaná skóre lze následně reprezentovat jako graf závislostí pomocí vizualizačních nástrojů, jako je Grafana, které ilustrují model stavu.

Tento obrázek ukazuje příklad modelu vrstveného stavu z online referenční implementace Azure Mission-Critical a ukazuje, jak může mít změna stavu základní komponenty kaskádový dopad na toky uživatelů a celkový stav aplikace (ukázkové hodnoty odpovídají tabulce na předchozím obrázku).

Ukázkové video: Ukázka monitorování a modelování stavu

Sjednocená datová jímka pro korelační analýzu

Mnoho provozních datových sad musí být shromážděno ze všech systémových komponent, aby bylo možné přesně znázorňovat definovaný heath model s ohledem na protokoly a metriky z komponent aplikací i základních prostředků Azure. Toto obrovské množství dat musí být nakonec uloženo ve formátu, který umožňuje interpretaci téměř v reálném čase, aby se usnadnila rychlá provozní akce. Kromě toho se vyžaduje korelace napříč všemi zahrnutími datových sad, aby se zajistilo, že efektivní analýza je bez vazby, což umožňuje vrstvenou reprezentaci stavu.

Jednotná datová jímka je potřebná k zajištění rychlého uložení a zpřístupnění všech provozních dat pro korelační analýzu, aby bylo možné vytvořit reprezentaci stavu aplikace v jednom podokně. Azure poskytuje několik různých provozních technologií v rámci služby Azure Monitor a pracovní prostor služby Log Analytics slouží jako základní datová jímka nativní pro Azure pro ukládání a analýzu provozních dat.

shromažďování

Na co dát pozor při navrhování

Azure Monitor

• Služba Azure Monitor je ve výchozím nastavení povolená pro všechna předplatná Azure, ale protokoly Služby Azure Monitor (pracovní prostor Služby Log Analytics) a prostředky Application Insights se musí nasadit a nakonfigurovat tak, aby zahrnovaly funkce shromažďování dat a dotazování.

• Azure Monitor podporuje tři typy dat pozorovatelnosti: protokoly, metriky a distribuované trasování.

  • Protokoly se ukládají v pracovních prostorech služby Log Analytics, které jsou založené na azure Data Explorer. Dotazy na protokoly se ukládají v balíčcích dotazů, které je možné sdílet napříč předplatnými, a používají se k řízení pozorovatelných komponent, jako jsou řídicí panely, sešity nebo jiné nástroje pro vytváření sestav a vizualizace.
  • Metriky se ukládají v interní databázi časových řad. U většiny prostředků Azure se metriky automaticky shromažďují a uchovávají po dobu 93 dnů. Data metrik je také možné odesílat do pracovního prostoru služby Log Analytics pomocí nastavení diagnostiky prostředku.

• Všechny prostředky Azure zpřístupňují protokoly a metriky, ale prostředky musí být správně nakonfigurované tak, aby směrovaly diagnostická data do požadované datové jímky.

Tip

Azure poskytuje různé předdefinované zásady , které je možné použít k zajištění konfigurace nasazených prostředků tak, aby odesílaly protokoly a metriky do pracovního prostoru služby Log Analytics.

• Není neobvyklé, že regulační kontroly vyžadují, aby provozní data zůstala v oblastech původu nebo zemích nebo oblastech. Zákonné požadavky mohou stanovit uchovávání kritických datových typů po delší dobu. Například v regulovaném bankovnictví musí být údaje auditu uchovávány nejméně sedm let.

• Různé provozní datové typy můžou vyžadovat různé doby uchovávání. Například protokoly zabezpečení může být potřeba uchovávat po dlouhou dobu, zatímco data o výkonu pravděpodobně nebudou vyžadovat dlouhodobé uchovávání mimo kontext AIOps.

• Data je možné archivovat nebo exportovat z pracovních prostorů služby Log Analytics pro účely dlouhodobého uchovávání nebo auditování.

• Vyhrazené clustery poskytují možnost nasazení, která umožňuje Zóny dostupnosti ochrany před selháními zón v podporovaných oblastech Azure. Vyhrazené clustery vyžadují závazek minimálního denního příjmu dat.

• Pracovní prostory služby Log Analytics se nasazují do zadané oblasti Azure.

• V zájmu ochrany před ztrátou dat z nedostupnosti pracovního prostoru služby Log Analytics je možné nakonfigurovat prostředky s několika nastaveními diagnostiky. Každé nastavení diagnostiky může odesílat metriky a protokoly do samostatného pracovního prostoru služby Log Analytics.

  • Za data odesílaná do každého dalšího pracovního prostoru služby Log Analytics se účtují další náklady.
  • Redundantní pracovní prostor služby Log Analytics je možné nasadit do stejné oblasti Azure nebo do samostatných oblastí Azure pro další regionální redundanci.
  • Odesílání protokolů a metrik z prostředku Azure do pracovního prostoru služby Log Analytics v jiné oblasti bude účtují náklady na výchozí přenos dat mezi oblastmi.
  • Některé prostředky Azure vyžadují pracovní prostor služby Log Analytics ve stejné oblasti jako samotný prostředek.
  • Další možnosti dostupnosti pracovního prostoru služby Log Analytics najdete v tématu Osvědčené postupy pro protokoly služby Azure Monitor .

• Data pracovního prostoru služby Log Analytics je možné exportovat do služby Azure Storage nebo Azure Event Hubs průběžně, podle plánu nebo jednorázově.

  • Export dat umožňuje dlouhodobou archivaci dat a chrání před možnou provozní ztrátou dat v důsledku nedostupnosti.
  • Dostupné cíle exportu jsou Azure Storage nebo Azure Event Hubs. Azure Storage je možné nakonfigurovat pro různé úrovně redundance , včetně zónových nebo regionálních. Export dat do Azure Storage ukládá data v souborech .json.
  • Cíle exportu dat musí být ve stejné oblasti Azure jako pracovní prostor služby Log Analytics. Cíl exportu dat centra událostí do stejné oblasti jako pracovní prostor služby Log Analytics. Azure Event Hubs geografické zotavení po havárii se pro tento scénář nevztahuje.
  • Export dat má několik omezení. Export dat se podporuje jenom u konkrétních tabulek v pracovním prostoru .
  • Archivaci je možné použít k ukládání dat v pracovním prostoru služby Log Analytics za účelem dlouhodobého uchovávání za sníženou cenu bez nutnosti jejich exportu.

• Protokoly Azure Monitoru mají limity omezení uživatelských dotazů, které se můžou zobrazovat jako omezená dostupnost pro klienty, jako jsou řídicí panely pozorovatelnosti.

  • Pět souběžných dotazů na uživatele: Pokud je již spuštěno pět dotazů, další dotazy se umístí do fronty souběžnosti jednotlivých uživatelů, dokud neskončí spuštěný dotaz.
  • Čas ve frontě souběžnosti: Pokud je dotaz ve frontě souběžnosti více než tři minuty, ukončí se a vrátí se kód chyby 429.
  • Limit hloubky fronty souběžnosti: Fronta souběžnosti je omezená na 200 dotazů a další dotazy budou odmítnuty s kódem chyby 429.
  • Omezení četnosti dotazů: Pro všechny pracovní prostory platí limit 200 dotazů na uživatele za 30 sekund.

• Balíčky dotazů jsou prostředky Azure Resource Manager, které je možné použít k ochraně a obnovení dotazů na protokoly, pokud je pracovní prostor služby Log Analytics nedostupný.

  • Balíčky dotazů obsahují dotazy ve formátu JSON a dají se podobně jako jiné prostředky infrastruktury jako kódu ukládat externě do Azure.
    • Nasaditelné prostřednictvím rozhraní REST API Microsoft.Insights.
    • Pokud je potřeba znovu vytvořit pracovní prostor služby Log Analytics, je možné balíček dotazů znovu nasadit z externě uložené definice.

• Application Insights je možné nasadit v modelu nasazení založeném na pracovním prostoru, který je založený na pracovním prostoru služby Log Analytics, ve kterém jsou uložená všechna data.

• V Application Insights je možné povolit vzorkování, abyste snížili množství odesílaných telemetrických dat a optimalizovali náklady na ingestování dat.

• Všechna data shromážděná službou Azure Monitor, včetně Application Insights, se účtují na základě objemu přijatých dat a doby uchovávání dat.

  • Data ingestovaná do pracovního prostoru služby Log Analytics je možné uchovávat bez dalších poplatků až do prvních 31 dnů (90 dnů, pokud je služba Sentinel povolená).
  • Data ingestovaná do Služby Application Insights založené na pracovním prostoru se uchovávají po dobu prvních 90 dnů bez dalších poplatků.

• Cenový model úrovně závazku Log Analytics poskytuje nižší náklady a předvídatelný přístup k poplatkům za příjem dat.

  • Veškeré využití nad úrovní rezervace se účtuje za stejnou cenu jako aktuální úroveň.

• Log Analytics, Application Insights a Azure Data Explorer používají dotazovací jazyk Kusto (KQL).

• Dotazy Log Analytics se ukládají jako funkce v rámci pracovního prostoru služby Log Analytics (savedSearches).

Doporučení k návrhu

• Použijte pracovní prostor služby Log Analytics jako jednotnou datovou jímku, abyste zajistili jednotné podokno napříč všemi provozními datovými sadami.

  • Decentralizace pracovních prostorů služby Log Analytics napříč všemi použitými oblastmi nasazení Každá oblast Azure s nasazením aplikace by měla zvážit pracovní prostor služby Log Analytics ke shromáždění všech provozních dat pocházejících z této oblasti. Všechny globální prostředky by měly používat samostatný vyhrazený pracovní prostor služby Log Analytics, který by se měl nasadit v primární oblasti nasazení.
    • Odeslání všech provozních dat do jednoho pracovního prostoru služby Log Analytics by vytvořilo jediný bod selhání.
    • Požadavky na rezidenci dat můžou zakázat opuštění původní oblasti dat a federované pracovní prostory tento požadavek ve výchozím nastavení řeší.
    • S přenosem protokolů a metrik napříč oblastmi jsou spojené značné náklady na výchozí přenos dat.
  • Všechna razítka nasazení ve stejné oblasti můžou používat stejný místní pracovní prostor služby Log Analytics.

• Zvažte konfiguraci prostředků s několika nastaveními diagnostiky odkazujícími na různé pracovní prostory služby Log Analytics, abyste se ochránili před nedostupností služby Azure Monitor pro aplikace s menším počtem místních razítek nasazení.

• Používejte Application Insights jako konzistentní nástroj Application Performance Monitoring (APM) napříč všemi komponentami aplikace ke shromažďování aplikačních protokolů, metrik a trasování.

  • Nasaďte Application Insights v konfiguraci založené na pracovním prostoru, abyste zajistili, že každý regionální pracovní prostor služby Log Analytics obsahuje protokoly a metriky z komponent aplikace i základních prostředků Azure.

• Pomocí dotazů napříč pracovními prostory můžete udržovat jednotné jedno podokno v různých pracovních prostorech.

• Balíčky dotazů můžete použít k ochraně dotazů na protokoly v případě nedostupnosti pracovního prostoru.

  • Ukládejte balíčky dotazů v úložišti Git aplikace jako prostředky infrastruktury jako kódu.

• Se všemi pracovními prostory služby Log Analytics by se mělo zacházet jako s dlouhotrvajícími prostředky s jiným životním cyklem než s prostředky aplikace v rámci místního razítka nasazení.

• Exportujte důležitá provozní data z pracovního prostoru služby Log Analytics za účelem dlouhodobého uchovávání a analýzy, abyste usnadnili AIOps a pokročilou analýzu za účelem upřesnění základního modelu stavu a informací o prediktivních akcích.

• Pečlivě vyhodnoťte, které úložiště dat by se mělo používat k dlouhodobému uchovávání. ne všechna data musí být uložená v horkém úložišti dat s dotazem.

  • Pro dlouhodobé provozní úložiště dat důrazně doporučujeme používat Azure Storage v konfiguraci GRS.
    • Pomocí funkce exportu pracovního prostoru služby Log Analytics vyexportujte všechny dostupné zdroje dat do služby Azure Storage.

• Vyberte vhodné doby uchovávání pro provozní datové typy v rámci Log Analytics a nakonfigurujte delší doby uchovávání v pracovním prostoru, kde existují požadavky na pozorovatelnost "horké".

• Pomocí Azure Policy zajistíte, že všechny místní prostředky směrují provozní data do správného pracovního prostoru služby Log Analytics.

Poznámka

Pokud při nasazování do cílové zóny Azure existuje požadavek na centralizované úložiště provozních dat, můžete při vytváření instance vytvořit fork dat, aby se ingestovala do centralizovaných nástrojů i do pracovních prostorů služby Log Analytics vyhrazených pro aplikaci. Případně můžete zpřístupnit přístup k pracovním prostorům služby Log Analytics aplikace, aby centrální týmy mohly dotazovat data aplikací. V konečném důsledku je důležité, aby provozní data pocházející z řešení byla k dispozici v pracovních prostorech služby Log Analytics vyhrazených pro aplikaci.

Pokud se vyžaduje integrace SIEM, neodesílejte nezpracované položky protokolu, ale odesílejte kritické výstrahy.

• V Application Insights nakonfigurujte vzorkování jenom v případě, že je to potřeba k optimalizaci výkonu nebo pokud ne, vzorkování se stane cenově nevýkonným.

  • Nadměrné vzorkování může vést k vynechání nebo nepřesným provozním signálům.

• Použijte ID korelace pro všechny události trasování a zprávy protokolu k jejich svázání s daným požadavkem.

  • Vrácení ID korelace volajícímu pro všechna volání nejen neúspěšných požadavků.

• Ujistěte se, že kód aplikace zahrnuje správnou instrumentaci a protokolování, které model stavu informuje a v případě potřeby usnadní následné řešení potíží nebo analýzu původní příčiny.

  • Kód aplikace by měl používat Application Insights k usnadnění distribuovaného trasování tím, že volajícímu poskytne komplexní chybovou zprávu, která v případě selhání obsahuje ID korelace.

• Pro všechny zprávy protokolu používejte strukturované protokolování .

• Přidejte smysluplné sondy stavu do všech komponent aplikace.

  • Pokud používáte AKS, nakonfigurujte pro každé nasazení (pod) koncové body stavu, aby Kubernetes mohl správně určit, jestli je pod v pořádku nebo není v pořádku.
  • Při používání Azure App Service nakonfigurujte kontroly stavu tak, aby operace horizontálního navýšení kapacity nezpůsobovaly chyby odesíláním provozu do instancí, které ještě nejsou připravené, a zajistily rychlou recyklaci instancí, které nejsou v pořádku.

Pokud je aplikace přihlášená k odběru podpory Microsoft Mission-Critical, zvažte zveřejnění klíčových sond stavu podpora Microsoftu, aby bylo možné modelovat stav aplikace přesněji pomocí podpora Microsoftu.

• Protokolujte úspěšné žádosti o kontrolu stavu, pokud není možné tolerovat zvýšené objemy dat v kontextu výkonu aplikace, protože poskytují další přehledy pro analytické modelování.

• Nekonfigurujte produkční pracovní prostory služby Log Analytics tak, aby se použil denní limit, který omezuje denní příjem provozních dat, protože to může vést ke ztrátě důležitých provozních dat.

  • V nižších prostředích, jako je vývoj a testování, lze denní limit považovat za volitelný mechanismus úspory nákladů.

• Za předpokladu, že svazky ingestování provozních dat splňují prahovou hodnotu minimální úrovně, nakonfigurujte pracovní prostory služby Log Analytics tak, aby používaly ceny založené na úrovni závazku ke zvýšení efektivity nákladů vzhledem k cenovému modelu průběžných plateb.

• Důrazně doporučujeme ukládat dotazy Log Analytics pomocí správy zdrojového kódu a pomocí automatizace CI/CD je nasadit do příslušných instancí pracovních prostorů služby Log Analytics.

Vizualizace

Vizuální znázornění modelu stavu s důležitými provozními daty je nezbytné pro dosažení efektivních operací a maximalizaci spolehlivosti. Řídicí panely by nakonec měly poskytovat téměř v reálném čase přehledy o stavu aplikace pro týmy DevOps a usnadnit tak rychlou diagnostiku odchylek od stabilního stavu.

Microsoft poskytuje několik technologií vizualizace dat, včetně Řídicích panelů Azure, Power BI a Azure Managed Grafana (aktuálně ve verzi Preview). Řídicí panely Azure jsou umístěny tak, aby poskytovaly úzce integrované předefinované řešení vizualizace provozních dat v rámci služby Azure Monitor. Má proto zásadní roli ve vizuální reprezentaci provozních dat a stavu aplikace pro klíčové úlohy. Z hlediska umístění řídicích panelů Azure jako holistické platformy pozorovatelnosti však existuje několik omezení, a proto je potřeba zvážit dodatečné použití špičkových řešení pozorovatelnosti na trhu, jako je Grafana, která je také poskytována jako spravované řešení v rámci Azure.

Tato část se zaměřuje na použití řídicích panelů Azure a Grafany k vytvoření robustního prostředí řídicího panelu, které dokáže poskytnout technické a obchodní objektivy týkající se stavu aplikace a umožnit týmům DevOps efektivní provoz. Robustní řídicí panely jsou nezbytné k diagnostice problémů, ke kterým už došlo, a k podpoře provozních týmů při zjišťování problémů a reagování na ně hned, jak k nim dochází.

Na co dát pozor při navrhování

• Při vizualizaci modelu stavu pomocí dotazů protokolu mějte na paměti, že existují omezení služby Log Analytics pro souběžné dotazy a dotazy ve frontě a také pro celkovou rychlost dotazů s následnými dotazy zařazenými do fronty a omezováním.

• Dotazy pro načtení provozních dat používaných k výpočtu a reprezentaci skóre stavu je možné zapisovat a spouštět v Log Analytics nebo Azure Data Explorer.

  • Ukázkové dotazy jsou k dispozici tady.

• Log Analytics má několik omezení dotazů, pro která je potřeba při návrhu provozních řídicích panelů navrhnout.

• Vizualizace nezpracovaných metrik prostředků, jako je využití procesoru nebo propustnost sítě, vyžaduje ruční vyhodnocení provozními týmy, aby zjistily dopady na stav, což může být během aktivního incidentu náročné.

• Pokud řídicí panely v rámci nástroje, jako je Grafana, používá více uživatelů, počet dotazů odeslaných do Log Analytics se rychle znásobí.

  • Při dosažení limitu souběžných dotazů v Log Analytics se následné dotazy zavedou do fronty, takže prostředí řídicího panelu bude pomalé.

Doporučení k návrhu

• Shromážděte a prezentujte dotazované výstupy ze všech regionálních pracovních prostorů služby Log Analytics a globálního pracovního prostoru služby Log Analytics a vytvořte jednotné zobrazení stavu aplikace.

Poznámka

Pokud nasazujete do cílové zóny Azure, zvažte dotazování pracovního prostoru Log Analytics centrální platformy , pokud existují klíčové závislosti na prostředcích platformy, jako je Například ExpressRoute pro místní komunikaci.

• Model semaforu by se měl použít k vizuálnímu znázornění stavů "v pořádku" a "není v pořádku", přičemž zelená se používá k ilustraci, kdy jsou plně splněny klíčové požadavky na nefunkční funkce a prostředky jsou optimálně využity. Jako výrazy "V pořádku", "Snížený výkon" a "Nedostupný" použijte výrazy "Zelená", "Jantarová" a "Červená".

• Pomocí řídicích panelů Azure můžete vytvářet operační čočky pro globální prostředky a razítka regionálního nasazení, která představují klíčové metriky, jako je počet požadavků na službu Azure Front Door, latence na straně serveru pro službu Azure Cosmos DB, příchozí/odchozí zprávy pro službu Event Hubs a využití procesoru nebo stav nasazení pro AKS. Řídicí panely by měly být přizpůsobené tak, aby řídily provozní efektivitu a nabíjely poznatky ze scénářů selhání, aby týmy DevOps měly přímý přehled o klíčových metrikách.

• Pokud řídicí panely Azure nelze použít k přesnému vyjádření modelu stavu a požadovaných obchodních požadavků, důrazně doporučujeme zvážit Grafana jako alternativní řešení vizualizace, které poskytuje špičkové funkce na trhu a rozsáhlý ekosystém opensourcových modulů plug-in. Vyhodnoťte nabídku spravované grafany ve verzi Preview, abyste se vyhnuli provozním složitostem při správě infrastruktury Grafana.

• Při nasazování grafany v místním prostředí použijte vysoce dostupný a geograficky distribuovaný návrh, který zajistí odolnost důležitých provozních řídicích panelů vůči selháním regionální platformy a kaskádovým scénářům chyb.

  • Oddělte stav konfigurace do externího úložiště dat, jako je Azure Database for Postgres nebo MySQL, abyste zajistili, že uzly aplikací Grafana zůstanou bezstavové.

    • Konfigurace replikace databáze napříč oblastmi nasazení

  • Nasaďte uzly Grafana do služby App Services ve vysoce dostupné konfiguraci napříč uzly v rámci oblasti pomocí kontejnerových nasazení.

    • Nasazení App Service instancí napříč zvaženou oblastí nasazení

    App Services poskytuje kontejnerovou platformu s minimálním třením, která je ideální pro scénáře s nízkým měřítkem, jako jsou provozní řídicí panely, a izolace Grafany od AKS poskytuje jasné oddělení zájmu mezi primární aplikační platformou a provozní reprezentací pro danou platformu. Další doporučení ke konfiguraci najdete v oblasti Věnované platformě aplikací.

  • Azure Storage v konfiguraci GRS můžete použít k hostování a správě vlastních vizuálů a modulů plug-in.

  • Nasaďte komponenty Služby App Service a repliky Grafany pro čtení do minimálně dvou oblastí nasazení a zvažte použití modelu, ve kterém se Grafana nasadí do všech oblastí nasazení.

Pro scénáře, jejichž cílem je >= 99,99% cílová úroveň služeb, by se Grafana měla nasadit v rámci minimálně 3 oblastí nasazení, aby se maximalizovala celková spolehlivost klíčových provozních řídicích panelů.

• Omezení limitů dotazů Log Analytics můžete zmírnit agregací dotazů do jednoho nebo malého počtu dotazů, například pomocí operátoru union KQL, a nastavením odpovídající obnovovací frekvence na řídicím panelu.

  • Vhodná maximální obnovovací frekvence bude záviset na počtu a složitosti dotazů na řídicí panel. Vyžaduje se analýza implementovaných dotazů.

• Pokud je dosaženo limitu souběžných dotazů Log Analytics, zvažte optimalizaci způsobu načítání tím, že (dočasně) uložíte data potřebná pro řídicí panel do vysoce výkonného úložiště dat, jako je Azure SQL.

Automatizovaná reakce na incidenty

I když vizuální znázornění stavu aplikace poskytuje neocenitelné provozní a obchodní přehledy pro podporu detekce a diagnostiky problémů, spoléhá na připravenost a interpretaci provozních týmů a také na efektivitě následných reakcí aktivovaných člověkem. Proto je pro zajištění maximální spolehlivosti nutné implementovat rozsáhlé upozorňování, které bude proaktivně zjišťovat problémy a reagovat na problémy téměř v reálném čase.

Azure Monitor poskytuje rozsáhlou architekturu pro upozorňování pro detekci, kategorizaci a reakci na provozní signály prostřednictvím skupin akcí. Tato část se proto zaměří na použití upozornění služby Azure Monitor k řízení automatizovaných akcí v reakci na aktuální nebo potenciální odchylky od stavu aplikace, která je v pořádku.

Důležité

Upozorňování a automatizované akce jsou důležité pro efektivní detekci problémů a rychlou reakci na ně hned, než může dojít k většímu negativnímu dopadu. Výstrahy také poskytují mechanismus pro interpretaci příchozích signálů a reakci, aby se zabránilo problémům dříve, než k nim dojde.

Na co dát pozor při navrhování

• Pravidla upozornění se definují tak, aby se aktivovalo při splnění podmíněných kritérií příchozích signálů, která mohou zahrnovat různé zdroje dat, jako jsou metriky, dotazy na protokoly nebo testy dostupnosti.

• Výstrahy je možné definovat v rámci Log Analytics nebo Azure Monitoru pro konkrétní prostředek.

• Některé metriky se dají dotazovat jenom v rámci Služby Azure Monitor, protože ne všechny diagnostické datové body jsou dostupné ve službě Log Analytics.

• K načtení aktivních a historických výstrah je možné použít rozhraní API pro upozornění služby Azure Monitor.

• Existují omezení předplatného související s upozorňováním a skupinami akcí, které musí být navržené pro:

  • Existují omezení počtu konfigurovatelných pravidel upozornění.
  • Rozhraní API pro upozornění má limity omezení, které byste měli zvážit ve scénářích extrémního využití.
  • Skupiny akcí mají několik pevných omezení pro počet konfigurovatelných odpovědí, pro které musí být navrženy.
    • Každý typ odpovědi má kromě e-mailu limit 10 akcí, které mají limit 1 000 akcí.

• Výstrahy je možné integrovat do modelu stavu vrstev vytvořením pravidla upozornění pro uložený dotaz prohledávání protokolu z kořenové funkce vyhodnocování modelu. Například pomocí funkce WebsiteHealthScore a upozorňováním na číselnou hodnotu, která představuje stav Není v pořádku.

Doporučení k návrhu

• V případě upozorňování zaměřeného na prostředky vytvořte pravidla upozornění ve službě Azure Monitor, abyste zajistili dostupnost všech diagnostických dat pro kritéria pravidla upozornění.

• Konsolidujte automatizované akce do minimálního počtu skupin akcí, které jsou v souladu se servisními týmy, aby podporovaly přístup DevOps.

• Reagujte na signály nadměrného využití prostředků prostřednictvím automatizovaných operací škálování s využitím funkcí automatického škálování nativních pro Azure, kde je to možné. Tam, kde integrované funkce automatického škálování nejsou použitelné, použijte skóre stavu komponenty k modelování signálů a určení, kdy reagovat automatizovanými operacemi škálování. Zajistěte, aby automatizované operace škálování byly definovány podle modelu kapacity, který kvantifikuje vztahy škálování mezi komponentami, aby odpovědi na škálování zahrnovaly komponenty, které je potřeba škálovat vzhledem k jiným komponentám.

• Akce modelu pro seřazení podle priority, které by mělo být určeno obchodním dopadem.

• Rozhraní API pro upozornění služby Azure Monitor můžete použít ke shromažďování historických upozornění, která budou začleněna do "studeného" provozního úložiště pro pokročilou analýzu.

• V případě kritických scénářů selhání, které nelze splnit pomocí automatizované reakce, se ujistěte, že je provozní automatizace runbooků nastavená tak, aby se po poskytnutí ruční interpretace a odhlášení řídily rychlé a konzistentní akce. Použití oznámení o upozorněních k rychlé identifikaci problémů vyžadujících ruční interpretaci

• Vytvářejte v rámci technických sprintů povolenky, které vám pomůžou postupně vylepšovat upozorňování, aby se zajistilo, že nové scénáře selhání, které se dříve nezohledňovaly, se dají plně přizpůsobit novým automatizovaným akcím.

• V rámci procesů CI/CD proveďte testy provozní připravenosti za účelem ověření klíčových pravidel upozornění na aktualizace nasazení.

Prediktivní akce a operace AI (AIOps)

Modely strojového učení je možné použít ke korelaci a stanovení priorit provozních dat, což pomáhá shromažďovat důležité přehledy související s filtrováním nadměrného šumu upozornění a předvídání problémů dříve, než způsobí dopad, a také urychlit reakci na incidenty, když se tak stane.

Konkrétně se metodologie AIOps dá použít na kritické přehledy o chování systému, uživatelů a procesů DevOps. Tyto přehledy můžou zahrnovat identifikaci problému, ke které dochází právě teď (zjistit), kvantifikovat, proč k problému dochází (diagnostikovat) nebo signalizovat, co se stane v budoucnu (predikovat). Tyto přehledy se dají použít k řízení akcí, které upraví a optimalizují aplikaci, aby se zmírnily aktivní nebo potenciální problémy, a to pomocí klíčových obchodních metrik, metrik kvality systému a metrik produktivity DevOps, a stanovit prioritu podle obchodního dopadu. Prováděné akce mohou být samy o sobě začleněny do systému prostřednictvím smyčky zpětné vazby, která dále trénuje podkladový model, aby se provedla další efektivita.

V Azure existuje několik analytických technologií, jako jsou Azure Synapse a Azure Databricks, které je možné použít k vytváření a trénování analytických modelů pro AIOps. Tato část se proto zaměří na to, jak lze tyto technologie umístit v rámci návrhu aplikace, aby vyhovovaly AIOps a podnítěly prediktivní akci, a zaměřuje se na Azure Synapse, které snižují třecí plochy tím, že spojují to nejlepší z datových služeb Azure spolu s výkonnými novými funkcemi.

AIOps se používá k řízení prediktivní akce, interpretaci a korelaci složitých provozních signálů pozorovaných během dlouhodobého období s cílem lépe reagovat na problémy a předcházet jim dříve, než k nim dojde.

Na co dát pozor při navrhování

• Azure Synapse Analytics nabízí několik možností strojového učení (ML).

  • Modely ML je možné trénovat a spouštět ve fondech Synapse Spark s knihovnami, jako jsou MLLib, SparkML a MMLSpark, a také oblíbené opensourcové knihovny, jako je Scikit Learn.
  • Modely ML je možné trénovat pomocí běžných nástrojů pro datové vědy, jako jsou PySpark/Python, Scala nebo .NET.

• Služba Synapse Analytics je integrovaná s Azure ML prostřednictvím Azure Synapse Notebooks, což umožňuje trénování modelů ML v pracovním prostoru Azure ML pomocí automatizovaného strojového učení.

• Synapse Analytics také umožňuje funkce strojového učení pomocí Azure Cognitive Services k řešení obecných problémů v různých oblastech, jako je detekce anomálií. Služby Cognitive Services je možné používat v Azure Synapse, Azure Databricks a prostřednictvím sad SDK a rozhraní REST API v klientských aplikacích.

• Azure Synapse se nativně integruje s Azure Data Factory nástroji pro extrakci, transformaci a načítání (ETL) nebo ingestování dat v rámci kanálů orchestrace.

• Azure Synapse umožňuje registraci externí datové sady pro data uložená ve službě Azure Blob Storage nebo Azure Data Lake Storage.

  • Registrované datové sady je možné použít v úlohách analýzy dat fondu Synapse Spark.

• Azure Databricks je možné integrovat do kanálů Azure Synapse Analytics a získat tak další možnosti Sparku.

  • Synapse orchestruje čtení dat a posílá je do clusteru Databricks, kde je možné je transformovat a připravit na trénování modelu ML.

• Zdrojová data je obvykle potřeba připravit na analýzu a strojové učení.

  • Synapse nabízí různé nástroje, které vám pomůžou s přípravou dat, včetně Apache Sparku, poznámkových bloků Synapse a bezserverových fondů SQL s T-SQL a integrovanými vizualizacemi.

• Modely ML, které se vytrénovaly, zprovoznily a nasadily, se dají použít pro dávkové vyhodnocování v Synapse.

  • Scénáře AIOps, jako je spuštění regrese nebo predikce snížení výkonu v kanálu CI/CD, můžou vyžadovat bodování v reálném čase .

• Pro Azure Synapse existují omezení předplatného, která by měla být plně srozumitelná v kontextu metodologie AIOps.

• Pokud chcete plně začlenit AIOps, je nutné průběžně dodávat data pozorovatelnosti téměř v reálném čase do modelů odvozování ML v reálném čase.

  • Funkce, jako je detekce anomálií, by se měly vyhodnocovat v datovém proudu pozorovatelnosti.

Doporučení k návrhu

• Ujistěte se, že všechny prostředky a komponenty aplikací Azure jsou plně instrumentované, aby byla pro trénování modelu AIOps k dispozici kompletní provozní datová sada.

• Ingestujte provozní data Log Analytics z globálních a regionálních účtů Azure Storage do Azure Synapse pro účely analýzy.

• Pomocí rozhraní API pro upozornění služby Azure Monitor načtěte historická upozornění a uložte je do studeného úložiště, aby se provozní data následně použila v rámci modelů ML. Pokud se používá export dat Log Analytics, uložte historická data upozornění do stejných účtů Azure Storage jako exportovaná data Log Analytics.

• Jakmile jsou ingestovaná data připravená na trénování ML, zapište je zpět do služby Azure Storage, aby byla k dispozici pro trénování modelu ML, aniž by bylo nutné spustit výpočetní prostředky pro přípravu dat Synapse.

• Ujistěte se, že zprovoznění modelu ML podporuje dávkové vyhodnocování i bodování v reálném čase.

• Při vytváření modelů AIOps implementujte MLOps a použijte postupy DevOps k automatizaci životního cyklu ML pro trénování, operacionalizaci, bodování a průběžné vylepšování. Vytvořte iterativní proces CI/CD pro modely AIOps ML.

• Vyhodnoťte azure Cognitive Services z hlediska konkrétních prediktivních scénářů kvůli nízké režii na správu a integraci. Zvažte detekci anomálií , abyste mohli rychle označit neočekávané odchylky v datových proudech pozorovatelnosti.

Další krok

Projděte si důležité informace o nasazení a testování.

Nasazení a testování