Doporučení pro návrh a vytvoření monitorovacího systému

Platí pro toto doporučení kontrolního seznamu provozní efektivity architektury Azure Well-Architected Framework:

OE:07	Návrh a implementace monitorovacího systému, který ověřuje volby návrhu a informuje budoucí návrh a obchodní rozhodnutí. Tento systém zachycuje a zveřejňuje provozní telemetrii, metriky a protokoly, které generují z infrastruktury a kódu úlohy.

Související průvodce: Doporučení pro instrumentaci aplikace

Tato příručka popisuje doporučení pro návrh a vytvoření monitorovacího systému. K efektivnímu monitorování úloh pro zajištění zabezpečení, výkonu a spolehlivosti potřebujete komplexní systém s vlastním zásobníkem, který poskytuje základ pro všechny funkce monitorování, detekce a upozorňování.

Definice

Pojem	definice
Protokoly	Zaznamenané systémové události. Protokoly můžou obsahovat různé typy dat ve strukturovaném nebo volném textovém formátu. Obsahují časové razítko.
Metriky	Číselné hodnoty, které se shromažďují v pravidelných intervalech. Metriky popisují určité aspekty systému v určitém okamžiku.

Klíčové strategie návrhu

Pokud chcete implementovat komplexní návrh systému monitorování pro vaši úlohu, postupujte podle těchto základních principů:

• Kdykoli je to praktické, využijte monitorovací nástroje poskytované platformou, které obvykle vyžadují velmi malou konfiguraci a můžou poskytovat podrobné přehledy o úlohách, které by jinak mohly být obtížné dosáhnout.

• Shromážděte protokoly a metriky z celého zásobníku úloh. Všechny prostředky infrastruktury a aplikační funkce by měly být nakonfigurované tak, aby vytvářely standardizovaná, smysluplná data a tato data se musí shromažďovat.

• Uložte shromážděná data do standardizovaného, spolehlivého a zabezpečeného řešení úložiště.

• Zpracovávat uložená data, aby je bylo možné zpracovat řešeními pro analýzu a vizualizaci.

• Analyzujte zpracovávaná data, abyste přesně určili stav úlohy.

• Vizualizujte stav úlohy ve smysluplných řídicích panelech nebo sestavách pro týmy úloh a další zúčastněné strany.

• Nakonfigurujte upozornění s možností reakce a další automatické odpovědi na inteligentně definované prahové hodnoty, které týmy úloh upozorní, když dojde k problémům.

• Do celkových postupů testování úloh můžete zahrnout systémy monitorování a upozorňování.

• Zajistěte, aby systémy monitorování a upozorňování byly v rozsahu pro průběžné vylepšování. Chování aplikací a infrastruktury v produkčním prostředí poskytuje možnosti průběžného učení. Tyto lekce začleníte do návrhů monitorování a upozorňování.

• Svázejte data monitorování, která shromáždíte a analyzujete zpět do systému a toků uživatelů, aby byly korelovány stav toků s daty společně s celkovým stavem úlohy. Analýza těchto dat z hlediska toků pomůže sladit strategii pozorovatelnosti s vaším modelem stavu.

Měli byste automatizovat všechny funkce monitorovacího systému co nejvíce a všechny by měly běžet nepřetržitě, celý den, každý den.

Tento kanál pracovního postupu znázorňuje monitorovací systém:

Shromažďování dat instrumentace

Poznámka:

K povolení protokolování potřebujete instrumentaci aplikace. Další informace najdete v průvodci instrumentací.

Měli byste nakonfigurovat všechny komponenty úloh, ať už jde o prostředky infrastruktury nebo aplikační funkce, zachytávat telemetrická data nebo události, jako jsou protokoly a metriky.

Protokoly jsou primárně užitečné pro detekci a zkoumání anomálií. Protokoly se obvykle vytvářejí komponentou úlohy a pak se odesílají do monitorovací platformy nebo je vytáhnou monitorovací platformou prostřednictvím automatizace.

Metriky jsou primárně užitečné pro vytvoření modelu stavu a identifikaci trendů v výkonu a spolehlivosti úloh. Metriky jsou také užitečné pro identifikaci trendů v chování využití vašich zákazníků. Tyto trendy vám můžou pomoct při rozhodování o vylepšeních z pohledu zákazníka. Metriky se obvykle definují v monitorovací platformě a monitorovací platforma a další nástroje se dotazují úlohy, aby zachytily metriky.

Data aplikací

Pro aplikace může být shromažďováním služeb nástroj pro správu výkonu aplikací (APM), který může běžet nezávisle z aplikace, která generuje data instrumentace. Po povolení APM máte jasný přehled o důležitých metrikách v reálném čase a historii. Použijte odpovídající úroveň protokolování. Podrobné protokolování může znamenat značné náklady. Nastavte úrovně protokolů podle prostředí. Nižší prostředí například nepotřebují stejnou úroveň podrobností jako produkční prostředí.

Protokoly aplikací podporují kompletní životní cyklus aplikace. Protokolování je nezbytné pro pochopení fungování aplikace v různých prostředích, ke kterým událostem dochází, a podmínek, za kterých k nim dochází.

Doporučujeme shromažďovat protokoly aplikací a události ve všech hlavních prostředích. Data mezi prostředími oddělte co nejvíce pomocí různých úložišť dat pro každé prostředí, pokud je to praktické. Pomocí filtrů se ujistěte, že nekritická prostředí nekomplikují interpretaci produkčních protokolů. Odpovídající položky protokolu v aplikaci by měly zachytávat ID korelace pro příslušné transakce.

Události aplikace byste měli zaznamenávat ve strukturovaných datových typech pomocí strojově čitelných datových bodů místo nestrukturovaných typů řetězců. Strukturovaný formát, který používá dobře známé schéma, může usnadnit analýzu a analýzu protokolů. Strukturovaná data je také možné snadno indexovat a prohledávat a výrazně zjednodušit vytváření sestav.

Data by měla být v nezávislém formátu, který je nezávislý na počítači, operačním systému nebo síťovém protokolu. Například vygenerování informací ve vlastním formátu, jako je JSON, MessagePack nebo Protobuf, místo ETL/ETW. Standardní formát umožňuje systému vytvářet kanály zpracování. Komponenty, které čtou, transformují a odesílají data ve standardním formátu, je možné snadno integrovat.

Data infrastruktury

U prostředků infrastruktury ve vaší úloze se ujistěte, že shromažďujete protokoly i metriky. Pro systémy infrastruktury jako služby (IaaS) zachyťte kromě metrik souvisejících se stavem úloh také operační systém, aplikační vrstvu a diagnostické protokoly. U prostředků PaaS (Platforma jako služba) můžete být omezeni schopností zaznamenávat protokoly, které souvisejí s základní infrastrukturou, ale ujistěte se, že kromě metrik souvisejících se stavem úloh můžete zaznamenávat diagnostické protokoly.

Co nejvíce shromážděte protokoly z cloudové platformy. Možná budete moct shromažďovat protokoly aktivit pro vaše předplatné a diagnostické protokoly pro rovinu správy.

Strategie shromažďování

Vyhněte se ručnímu načítání telemetrických dat z každé komponenty. Přesuňte data do centrálního umístění a sloučit je tam. V případě řešení s více oblastmi doporučujeme nejprve shromažďovat, konsolidovat a ukládat data v jednotlivých oblastech a pak je agregovat do jednoho centrálního systému.

Kompromis: Mějte na paměti, že na regionální a centralizovaná úložiště dat mají vliv náklady.

Pokud chcete optimalizovat využití šířky pásma, určete prioritu na základě důležitosti dat. V dávkách můžete přenášet méně urgentní data. Tato data však nesmí být zpožděna na neomezenou dobu, zejména pokud obsahují informace citlivé na čas.

Existují dva primární modely, které může služba kolekce použít ke shromažďování dat instrumentace:

• Model vyžádání obsahu: Aktivně načítá data z různých protokolů a dalších zdrojů pro každou instanci aplikace.

• Model nabízení: Pasivní čekání na odeslání dat ze součástí, které tvoří každou instanci aplikace.

Agenti monitorování

Agenty monitorování můžete použít v modelu vyžádané replikace. Agenti se spouštějí místně v samostatném procesu s každou instancí aplikace, pravidelně stahují data a zapisují informace přímo do společného úložiště, které sdílí všechny instance aplikace.

Poznámka:

Použití agenta monitorování se ideálně hodí k zachytávání dat instrumentace, která se přirozeně stahují ze zdroje dat. Je vhodné pro malou aplikaci, která běží na omezeném počtu uzlů v jednom umístění. Mezi příklady patří informace ze zobrazení dynamické správy SQL Serveru nebo délky fronty služby Azure Service Bus.

Důležité informace o výkonu

Složitá a vysoce škálovatelná aplikace může generovat obrovské objemy dat. Množství dat může snadno zahltit šířku pásma vstupně-výstupních operací dostupnou pro jedno centrální umístění. Řešení telemetrie nesmí fungovat jako kritické body a musí být škálovatelné, protože se systém rozšiřuje. V ideálním případě by řešení mělo zahrnovat určitou redundanci, aby se snížila rizika ztráty důležitých informací monitorování (například auditování nebo fakturačních dat), pokud část systému selže.

Jedním ze způsobů, jak ukládat data instrumentace do vyrovnávací paměti, je použití řazení do front:

V této architektuře služba shromažďování dat publikuje data do fronty. Fronta zpráv je vhodná, protože poskytuje sémantiku "alespoň jednou", která pomáhá zajistit, aby se po publikování dat ve frontě neztratila. Službu zápisu do úložiště můžete implementovat pomocí samostatné role pracovního procesu. K implementaci této architektury můžete použít model Prioritní fronta.

Kvůli škálovatelnosti můžete spustit několik instancí služby zápisu do úložiště. Pokud se monitoruje velký objem událostí nebo velkého počtu datových bodů, můžete pomocí služby Azure Event Hubs odeslat data do jiné výpočetní instance pro zpracování a úložiště.

Strategie konsolidace

Data shromážděná z jedné instance aplikace poskytují lokalizované zobrazení stavu a výkonu dané instance. Pokud chcete posoudit celkový stav systému, musíte konsolidovat některé aspekty dat z místních zobrazení. Můžete to udělat po uložení dat, ale v některých případech to můžete udělat při shromažďování dat.

Data instrumentace mohou projít samostatnou službou konsolidace dat, která kombinuje data a funguje jako filtr a proces čištění. Můžete například amalgamovat data instrumentace, která obsahují stejné informace o korelaci, jako je ID aktivity. (Uživatel může spustit obchodní operaci na jednom uzlu a pak se přenést do jiného uzlu, pokud selže první uzel nebo kvůli konfiguraci vyrovnávání zatížení.) Tento proces může také rozpoznat a odebrat všechna duplicitní data. (Duplikace může nastat, pokud služba telemetrie používá fronty zpráv k odesílání dat instrumentace do úložiště.)

Ukládání dat pro dotazy a analýzu

Když zvolíte řešení úložiště, zvažte typ dat, způsob jejich použití a to, jak je naléhavě potřeba.

Poznámka:

Pro neprodukční a produkční prostředí používejte samostatná řešení úložiště, abyste zajistili, že data z každého prostředí budou snadno identifikovat a spravovat.

Technologie úložiště

Zvažte přístup polyglotní trvalosti, kdy různé typy informací jsou uloženy v technologiích, které jsou nejvhodnější pro způsob, jakým bude každý typ pravděpodobně používán.

Podobně se například přistupuje ke službě Azure Blob Storage a Azure Table Storage. Operace, které s nimi můžete provádět, se ale liší stejně jako členitost dat, která obsahují. Pokud potřebujete provádět analytičtější operace nebo vyžadujete funkce fulltextového vyhledávání dat, může být vhodnější použít úložiště dat, které poskytuje funkce optimalizované pro konkrétní typy dotazů a přístupu k datům. Příklad:

• Data čítačů výkonu se dají uložit do SQL databáze, která umožňuje analýzu ad hoc.

• Může být lepší ukládat protokoly trasování v protokolech služby Azure Monitor nebo Azure Data Exploreru.

• Informace o zabezpečení můžete ukládat v řešení HDFS.

Stejná data instrumentace se můžou dát využít k více účelům. Můžete například použít čítače výkonu k zajištění historického zobrazení výkonu systému v průběhu času. Tyto informace se dají zkombinovat s jinými údaji o využití a na základě toho se můžou generovat fakturační údaje zákazníků. V těchto situacích se stejná data můžou posílat do více než jednoho cíle, například do databáze dokumentů, která může být dlouhodobým úložištěm pro uchovávání fakturačních údajů, a do multidimenzionálního úložiště pro zpracování komplexní analýzy výkonu.

Nezapomeňte povolit funkci, která chrání data před náhodným odstraněním, jako jsou zámky prostředků a obnovitelné odstranění.

Také se ujistěte, že zabezpečený přístup k úložišti pomocí řízení přístupu na základě role pomáhá zajistit, aby to mohli udělat jenom jednotlivci, kteří potřebují přístup k datům.

Služba konsolidace

Můžete implementovat jinou službu, která pravidelně načítá data ze sdíleného úložiště, oddílů a filtruje je podle jeho účelu, a pak je zapíše do příslušné sady úložišť dat.

Tato funkce se dá taky zahrnout do procesu konsolidace a čištění, aby se data zapisovala do těchto úložišť přímo při načítání, místo aby se ukládala do přechodného sdíleného úložiště.

Každý z těchto přístupů má své výhody a nevýhody. Implementace samostatné služby dělení snižuje zatížení služby konsolidace a čištění a umožňuje v případě potřeby vygenerovat alespoň některá dělená data (v závislosti na tom, kolik dat se uchovává ve sdíleném úložišti). Tento přístup ale spotřebovává další prostředky. Navíc může docházet ke zpoždění mezi přijetím dat instrumentace z jednotlivých instancí aplikace a převodem těchto dat na využitelné informace.

Důležité informace o dotazování

Zvažte, jak jsou data naléhavě nutná. Data, která generují výstrahy, musí být rychle přístupná, takže by se měla uchovávat v rychlém úložišti dat a indexovaná nebo strukturovaná, aby se optimalizovaly dotazy, které systém upozornění provádí. V některých případech může být nutné, aby služba shromažďování naformátovat a ukládat data místně, aby místní instance systému upozornění mohla rychle odesílat oznámení. Stejná data se dají odeslat do služby zápisu do úložiště znázorněné na předchozích obrázcích a zároveň uložit do centrálního úložiště, pokud jsou potřebná i k jiným účelům.

Důležité informace o uchovávání dat

V některých případech můžete po zpracování a přenosu dat odebrat původní nezpracovaná zdrojová data uložená místně. V jiných případech může být nutné nebo užitečné uložit nezpracované informace. Můžete například chtít zachovat data vygenerovaná pro ladění dostupná v nezpracované podobě, ale po vyřešení všech chyb je rychle zahodit.

Data o výkonu mají často delší životnost, abyste je mohli použít ke zjišťování trendů výkonu a k plánování kapacity. Konsolidované zobrazení těchto dat se většinou po omezené období uchovává online, aby se k němu dal rychle získat přístup. Potom je můžete archivovat nebo zahodit.

Je užitečné ukládat historická data, která umožňují vysledovat dlouhodobé trendy. Místo ukládání starých dat v celém rozsahu můžete data snížit, abyste snížili rozlišení a ušetřili náklady na úložiště. Například místo úspory indikátorů výkonu po minutách můžete konsolidovat data, která jsou starší než měsíc, a vytvořit zobrazení po hodinách.

Data shromažďovaná za účelem měření a fakturace zákazníkům může být potřeba nechat uložené bez omezení. Kromě toho můžou zákonné požadavky diktovat, že se musí archivovat a ukládat informace shromážděné pro auditování a zabezpečení. Tato data jsou navíc citlivá a můžou vyžadovat šifrování nebo jinou ochranu, aby se s nimi nedalo manipulovat. Nikdy byste neměli zaznamenávat uživatelská hesla ani jiné informace, které by mohly být použity k odhalování podvodů s identitou. Před uložením těchto podrobností byste měli tyto podrobnosti z dat vyčíst.

Abyste zajistili, že dodržujete zákony a předpisy, minimalizujte ukládání všech identifikovatelných informací. Pokud potřebujete ukládat identifikovatelné informace, nezapomeňte při návrhu řešení vzít v úvahu požadavky, které jednotlivcům umožňují požádat o odstranění jejich informací.

Analýza dat za účelem pochopení stavu úlohy

Jakmile shromáždíte data z různých zdrojů dat, analyzujte je, abyste posoudili celkovou pohodu systému. Pro tuto analýzu jasně rozumíte:

• Jak strukturovat data na základě klíčových ukazatelů výkonu a metrik výkonu, které jste definovali.

• Jak korelovat data zachycená v různých metrikách a souborech protokolů Tato korelace je důležitá při sledování posloupnosti událostí a může vám pomoct s diagnostikou problémů.

Ve většině případů se data pro každou komponentu architektury zaznamenávají místně a pak přesně v kombinaci s daty generovanými jinými komponentami.

Například třívrstvé aplikace může mít:

• Prezentační úroveň, která uživateli umožňuje připojit se k webu.

• Střední vrstva hostuje sadu mikroslužeb, které zpracovávají obchodní logiku.

• Databázová vrstva, která ukládá data přidružená k operaci.

Data o využití pro jednu obchodní operaci můžou zahrnovat všechny tři úrovně. Tyto informace musí být korelovány, aby poskytovaly celkový přehled o využití prostředků a zpracování operace. Korelace může zahrnovat určité předběžné zpracování a filtrování dat na úrovni databáze. Na střední úrovni jsou agregace a formátování běžnými úlohami.

Doporučení

• Korelace protokolů na úrovni aplikace a prostředků Vyhodnoťte data na obou úrovních, abyste optimalizovali detekci problémů a jejich řešení. Data můžete agregovat v jedné jímce dat nebo využít metody dotazování událostí na obou úrovních. Pro agregaci a dotazování protokolů na úrovni aplikací a prostředků doporučujeme jednotné řešení, jako je Azure Log Analytics.

• Definujte dobu uchovávání informací v úložišti pro studenou analýzu. Tento postup doporučujeme povolit historickou analýzu v určitém období. Může vám také pomoct řídit náklady na úložiště. Implementujte procesy, které zajišťují archivaci dat do levnějšího úložiště a agregace dat pro dlouhodobou analýzu trendu.

• Analýza dlouhodobých trendů za účelem predikce provozních problémů Vyhodnoťte dlouhodobá data tak, aby vytvořila provozní strategie a také předpověděla, k jakým provozním problémům pravděpodobně dojde, a kdy. Můžete si například všimnout, že průměrné doby odezvy se v průběhu času pomalu zvyšují a blíží se k maximálnímu cíli.

Podrobné pokyny k těmto doporučením najdete v tématu Analýza dat monitorování pro cloudové aplikace.

Vizualizace sestav stavu úloh

Řídicí panely

Nejběžnější způsob, jak vizualizovat data, je použít řídicí panely, které můžou zobrazovat informace jako řadu grafů nebo grafů nebo v nějaké jiné vizuální podobě. Tyto položky je možné parametrizovat a analytik může vybrat důležité parametry, jako je časové období, pro každou konkrétní situaci.

Zarovnejte řídicí panely s modelem stavu tak, aby indikovaly, kdy jsou úlohy nebo komponenty úlohy v pořádku, degradované nebo špatné.

Aby systém řídicího panelu fungoval efektivně, musí být pro tým úloh smysluplný. Vizualizujte informace, které se týkají stavu úloh a které jsou také použitelné. Pokud je úloha nebo komponenta degradovaná nebo není v pořádku, členové týmu úloh by měli být schopni snadno identifikovat, odkud problém pochází, a zahájit nápravné akce nebo šetření. Naopak zahrnutí informací, které nejsou použitelné nebo které nesouvisí se stavem úloh, může řídicí panel zbytečně zkomplikovat a frustrovat členy týmu, kteří se snaží rozpoznat šum na pozadí od dat s možností akce.

Můžete mít řídicí panely pro zúčastněné strany nebo vývojáře, kteří jsou přizpůsobeni tak, aby zobrazovaly jenom data o úlohách, které najdou relevantní. Před sdílením řídicích panelů se ujistěte, že tým úloh rozumí typům datových bodů, které mají ostatní týmy zájem o zobrazení řídicích panelů a jejich náhledy. Poskytnutí řídicích panelů o vašich úlohách pro zúčastněné strany je dobrým způsobem, jak je ohodnotit stavem úloh, ale přináší riziko, že budou neproduktivní, pokud účastníci jasně nerozumí datům, která vidí.

Dobrý řídicí panel nezobrazuje jenom informace. Analytik může také analytici klást improvizované otázky týkající se této informace. Některé systémy poskytují nástroje pro správu, které může operátor použít k dokončení těchto úloh a prozkoumání podkladových dat. Místo toho může být v závislosti na úložišti, které se používá k uložení informací, možné dotazovat data přímo nebo je importovat do nástrojů, jako je Excel pro další analýzu a vytváření sestav.

Poznámka:

Omezte přístup k řídicímu panelu autorizovaným pracovníkům. Informace na řídicích panelech můžou být komerčně citlivé. Měli byste také chránit podkladová data, abyste uživatelům zabránili v jejich změně.

Sestavy

Vytváření sestav se používá k vygenerování celkového přehledu o systému. Může zahrnovat historická data a aktuální informace. Požadavky na vytváření sestav spadají do dvou širokých kategorií: provozní generování sestav a vytváření sestav zabezpečení.

Provozní generování sestav obvykle zahrnuje následující:

• Agregace statistik, které můžete použít k pochopení využití prostředků celkového systému nebo zadaných subsystémů během zadaného časového intervalu.

• Identifikace trendů využití prostředků pro celkový systém nebo zadané subsystémy během zadaného období

• Monitorování výjimek, ke kterým došlo v celém systému nebo v zadaných subsystémech během zadaného období

• Určení efektivity aplikace pro nasazené prostředky a zjištění, jestli je možné snížit objem prostředků a jejich související náklady, aniž by to zbytečně ovlivnilo výkon.

Generování sestav zabezpečení sleduje využití systému zákazníky. Může zahrnovat tyto úkony:

• Audity uživatelských operací. Tato úloha vyžaduje zaznamenávání jednotlivých požadavků, které každý uživatel dokončí, spolu s daty a časy. Data by měla být strukturovaná tak, aby správce mohl rychle rekonstruovat posloupnost operací, které uživatel v zadaném období dokončí.

• Sledování využití prostředků podle uživatele. Tato úloha vyžaduje zaznamenávání, jak každý požadavek od uživatele přistupuje k různým prostředkům, které systém tvoří, a jak dlouho. Správce může tato data použít k vygenerování sestavy využití podle uživatele za určité období, případně k fakturaci.

V mnoha případech se můžou sestavy generovat pomocí dávkových procesů podle určeného časového plánu. Latence obvykle není problém. Měli byste mít také dávkové procesy, které můžou generovat sestavy spontánně podle potřeby. Pokud například ukládáte data do relační databáze, jako je Azure SQL Database, můžete pomocí nástroje, jako je SQL Server Reporting Services, extrahovat a formátovat data a prezentovat je jako sadu sestav.

Definování výstrah pro klíčové události

Aby se zajistilo, že systém zůstane v pořádku, responzivní a zabezpečený, nastavte výstrahy, aby na ně operátoři mohli reagovat včas. Výstraha může obsahovat dostatek kontextových informací, které jim pomůžou rychle začít s diagnostickými aktivitami. Upozorňování lze použít k vyvolání nápravných funkcí, jako je automatické škálování nebo jiné mechanismy samoopravení. Výstrahy můžou také umožnit informovanost o nákladech tím, že poskytují přehled o rozpočtech a limitech.

Doporučení

• Definujte proces pro odpověď upozornění, který identifikuje zodpovědné vlastníky a akce.

• Nakonfigurujte výstrahy pro dobře definovaný obor (typy prostředků a skupiny prostředků) a upravte úroveň podrobností, abyste minimalizovali šum.

• Místo toho, aby lidé aktivně hledali problémy, použijte automatizované řešení pro upozorňování, jako je Splunk nebo Azure Monitor.

• Pomocí výstrah zprovozníte procesy nápravy. Můžete například automaticky vytvářet lístky pro sledování problémů a jejich řešení.

• Sledujte stav služeb cloudové platformy v oblastech, komunikaci o výpadkech, aktivitách plánované údržby a dalších poradci pro stav.

Prahové hodnoty

Výstrahy se generují při překročení prahových hodnot, jak zjistí váš monitorovací systém. Ujistěte se, že vámi nastavené prahové hodnoty obvykle poskytují dostatek času k implementaci nezbytných změn v úloze, aby nedocházelo ke snížení nebo výpadkům. Například nastavte prahovou hodnotu automatického škálování tak, aby iniciovala škálování před tím, než se některý z běžících systémů zahltí do bodu sníženého uživatelského prostředí. Založte prahové hodnoty, které přiřadíte k minulým zkušenostem při správě infrastruktury, a ověřte je prostřednictvím testování, které provádíte jako součást vašich testovacích postupů.

Podrobné pokyny k upozorňování případů použití a dalších aspektech najdete v tématu Návrh spolehlivé strategie monitorování a upozorňování.

Usnadnění azure

• Azure Monitor je komplexní řešení monitorování pro shromažďování, analýzu a reagování na monitorování dat z cloudu a místních prostředí.

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

  Pokud používáte více pracovních prostorů, pro osvědčené postupy se podívejte do průvodce architekturou pracovního prostoru služby Log Analytics.

• Application Insights je rozšíření služby Azure Monitor. Poskytuje funkce APM.

• Azure Monitor Insights jsou pokročilé analytické nástroje pro konkrétní technologie Azure (jako jsou virtuální počítače, aplikační služby a kontejnery). Tyto nástroje jsou součástí služby Azure Monitor a Log Analytics.

• Azure Monitor pro řešení SAP je monitorovací nástroj Azure pro prostředí SAP, který běží v Azure.

• Azure Policy vám může pomoct vynutit standardy organizace a vyhodnotit dodržování předpisů ve velkém měřítku.

Související odkazy

• Průvodce instrumentací
• Doporučení pro návrh spolehlivé strategie monitorování a upozorňování
• Doporučení pro monitorování a detekci hrozeb
• Doporučení pro shromažďování dat o výkonu

Komunitní odkazy

• 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 efektivitu provozu

Projděte si kompletní sadu doporučení.

Kontrolní seznam pro efektivitu provozu