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

Článek
04/19/2024

Platí pro toto doporučení kontrolního seznamu pro efektivitu provozu azure Well-Architected Framework:

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

Související příručka: 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 z hlediska 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

Období	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í některé aspekty systému v určitém čase.

Klíčové strategie návrhu

Pokud chcete implementovat komplexní návrh monitorovacího systému pro vaše úlohy, postupujte podle těchto základních zásad:

Kdykoli je to praktické, využijte monitorovací nástroje poskytované platformou, které obvykle vyžadují velmi malou konfiguraci a můžou poskytnout podrobné přehledy o úlohách, které by jinak bylo obtížné provést.
Shromážděte protokoly a metriky z celého zásobníku úloh. Všechny prostředky infrastruktury a funkce aplikací by měly být nakonfigurované tak, aby vytvářely standardizovaná a smysluplná data a tato data se musí shromažďovat.
Shromážděná data ukládejte ve standardizovaném, spolehlivém a zabezpečeném řešení úložiště.
Zpracování uložených dat tak, aby je bylo možné zpracovat pomocí řešení analýzy a vizualizace.
Analyzujte zpracovaná data, abyste mohli přesně určit 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í akce a další automatické odpovědi na inteligentně definované prahové hodnoty, které upozorní týmy úloh, když dojde k problémům.
Do celkových postupů testování úloh zahrňte systémy monitorování a upozorňování.
Zajistěte, aby systémy monitorování a upozorňování byly v rozsahu pro neustálé zlepšování. Chování aplikací a infrastruktury v produkčním prostředí poskytuje možnosti průběžného učení. Začlenit tyto lekce do návrhů monitorování a upozorňování.
Data monitorování, která shromáždíte a analyzujete, spojte zpět s toky systému a uživatele , abyste kromě celkového stavu úloh korelovaly stav toků s daty. Analýza těchto dat z hlediska toků vám pomůže sladit strategii pozorovatelnosti s modelem stavu.

Měli byste co nejvíce automatizovat všechny funkce monitorovacího systému 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 systém monitorování:

Kolekce

Poznámka

Abyste povolili protokolování, musíte aplikaci instrumentovat. Další informace najdete v průvodci instrumentací.

Všechny komponenty úloh, ať už se jedná o prostředky infrastruktury nebo funkce aplikace, byste měli nakonfigurovat tak, aby zaznamenávaly telemetrii nebo události, jako jsou protokoly a metriky.

Protokoly jsou primárně užitečné pro detekci a zkoumání anomálií. Protokoly obvykle vytváří komponenta úlohy a pak se odesílají na monitorovací platformu nebo se prostřednictvím automatizace odesílají monitorovací platformou.

Metriky jsou primárně užitečné pro vytvoření modelu stavu a identifikaci trendů v oblasti 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 můžou pomoct při rozhodování o vylepšeních z pohledu zákazníka. Metriky se obvykle definují na platformě monitorování a monitorovací platforma a další nástroje se dotazují úlohy, aby metriky zachytily.

Data aplikací

Pro aplikace může být služba shromažďování nástrojů pro správu výkonu aplikací (APM), který může běžet nezávisle na aplikaci, která generuje data instrumentace. Po povolení APM budete mít jasný přehled o důležitých metrikách v reálném čase i historicky. Použijte odpovídající úroveň protokolování. Podrobné protokolování může znamenat značné náklady. Nastavte úrovně protokolu 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é k pochopení toho, jak aplikace funguje v různých prostředích, ke kterým událostem dochází a za jakých podmínek k nim dochází.

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

Události aplikace ve strukturovaných datových typech byste měli zaznamenávat pomocí strojově čitelných datových bodů, nikoli 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 vygenerujte informace v samopopisové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šich úlohách se ujistěte, že shromažďujete protokoly i metriky. Pro systémy infrastruktury jako služby (IaaS) zachytejte kromě metrik souvisejících se stavem úloh také protokoly operačního systému, aplikační vrstvy a diagnostické protokoly. U prostředků PaaS (platforma jako služba) může být omezená schopnost zaznamenávat protokoly, které souvisejí se základní infrastrukturou, ale ujistěte se, že kromě metrik souvisejících se stavem úloh můžete zaznamenávat i diagnostické protokoly.

Pokud je to možné, shromážděte protokoly z vaší 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 ze všech komponent. Přesuňte data do centrálního umístění a konsolidovat 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 potom agregovat regionální data do jednoho centrálního systému.

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

Pokud chcete optimalizovat využití šířky pásma, určete prioritu na základě důležitosti dat. Méně naléhavá data můžete přenášet v dávkách. Tato data však nesmí být odložena na neurčito, zejména pokud obsahují časově citlivé informace.

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

Vyžádat model: Aktivně načítá data z různých protokolů a dalších zdrojů pro každou instanci aplikace.
Model nabízení: Pasivně čeká na odeslání dat ze součástí, které tvoří každou instanci aplikace.

Agenti monitorování

V modelu vyžádání můžete použít agenty monitorování. Agenti běží místně v samostatném procesu s každou instancí aplikace, pravidelně načítá data a zapisují informace přímo do společného úložiště, které jsou sdílené všemi instancemi 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 z SQL Server zobrazení dynamické správy nebo délka Azure Service Bus fronty.

Otázky 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ý bod a při rozšiřování systému musí být škálovatelné. V ideálním případě by řešení mělo zahrnovat určitou míru redundance, aby se snížilo riziko ztráty důležitých informací o monitorování (jako jsou auditování nebo fakturační data), pokud dojde k selhání části systému.

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

V této architektuře služba shromažďování dat odesílá data do fronty. Fronta zpráv je vhodná, protože poskytuje sémantiku "alespoň jednou", která pomáhá zajistit, aby se data ve frontě po jejich publikování 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ý počet datových bodů, můžete použít Azure Event Hubs k odeslání dat do jiné výpočetní instance ke zpracování a uložení.

Strategie konsolidace

Data shromážděná z jedné instance aplikace poskytují lokalizované zobrazení stavu a výkonu této instance. Abyste mohli vyhodnotit 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 můžou procházet samostatnou slučovací službou 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 také dokáže rozpoznat a odebrat všechna duplicitní data. (K duplikaci může dojít, pokud služba telemetrie používá fronty zpráv k odesílání dat instrumentace do úložiště.)

Storage

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

Poznámka

Používejte samostatná řešení úložiště pro neprodukční a produkční prostředí, abyste zajistili, že data z každého prostředí se snadno identifikují a spravují.

Technologie úložiště

Zvažte polyglotické trvalost přístupu, kdy jsou různé typy informací uloženy v technologiích, které jsou nejvhodnější pro způsob použití jednotlivých typů.

Například Azure Blob Storage a Azure Table Storage jsou přístupné podobnými způsoby. Operace, které s nimi můžete provádět, se ale liší, stejně jako členitost dat, která uchovávají. 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.
Možná bude lepší ukládat protokoly trasování do protokolů Azure Monitoru nebo azure Data Explorer.
Informace o zabezpečení můžete ukládat do řešení HDFS.

Stejná data instrumentace se můžou dát využít k více účelům. Čítače výkonu můžete například použít k poskytnutí 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 můžou být stejná data odesílána 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í složitých analýz výkonu.

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

Nezapomeňte také zabezpečit přístup k úložišti pomocí řízení přístupu na základě role, abyste zajistili, že to budou moct udělat jenom jednotlivci, kteří potřebují přístup k datům.

Konsolidační služba

Můžete implementovat jinou službu, která pravidelně načítá data ze sdíleného úložiště, rozdělí je do oddílů a vyfiltruje je podle svého úč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ň část dělených dat (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 urgentně jsou data potřeba. K datům, která generují výstrahy, se musí přistupovat rychle, takže by se měla uchovávat v rychlém úložišti dat a indexovat nebo strukturovat, 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í dat 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 nezbytné nebo užitečné uložit nezpracované informace. Můžete například chtít zachovat data vygenerovaná pro ladění k dispozici v nezpracované podobě, ale po vyřešení jakýchkoli 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 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í celých starých dat můžete data zmenšit, abyste snížili jejich rozlišení a ušetřili náklady na úložiště. Například místo ukládání ukazatelů výkonu po minutách můžete konsolidovat data, která jsou starší než měsíc, a vytvořit tak 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 informace shromážděné pro auditování a zabezpečení se musí archivovat a ukládat. 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 nebo jiné informace, které by mohly být použity k páchání podvodu s identitou. Před uložením byste měli tyto podrobnosti z dat vymýt.

Abyste měli jistotu, ž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í informací.

Analýza

Po shromáždění dat z různých zdrojů dat je analyzujte a vyhodnoťte celkovou pohodu systému. Pro účely této analýzy 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 diagnostikovat problémy.

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

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

Prezentační úroveň, která umožňuje uživateli připojit se k webu.
Střední vrstva, která hostuje sadu mikroslužeb, které zpracovávají obchodní logiku.
Datová 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 prostředku a využití zpracování pro operaci. Korelace může zahrnovat určité předběžné zpracování a filtrování dat na databázové úrovni. Na střední úrovni jsou agregace a formátování běžnými úkoly.

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é datové jímce nebo využít metody, které dotazují události napříč oběma úrovněmi. Doporučujeme jednotné řešení, jako je Azure Log Analytics, které agreguje a dotazuje protokoly na úrovni aplikace a prostředků.
Definujte jasné doby uchovávání informací v úložišti pro studenou analýzu. Tento postup doporučujeme k povolení historických analýz v určitém období. Může vám také pomoct řídit náklady na úložiště. Implementujte procesy, které zajistí archivaci dat do levnějšího úložiště a agregují data pro dlouhodobou analýzu trendu.
Analyzujte dlouhodobé trendy a predikujte provozní problémy. Vyhodnocujte dlouhodobá data, abyste mohli vytvořit provozní strategie a také předpovědět, k jakým provozním problémům pravděpodobně dojde a kdy. Můžete si například všimnout, že průměrná doba odezvy se v průběhu času pomalu zvyšuje a blíží se 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

Řídicí panely

Nejběžnějším způsobem vizualizace dat je použití řídicích panelů, které můžou zobrazovat informace jako řadu grafů nebo grafů nebo v nějaké jiné vizuální podobě. Tyto položky lze 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 součásti úloh v pořádku, degradované nebo v pořádku.

Aby systém řídicích panelů fungoval efektivně, musí být pro tým úloh smysluplný. Vizualizujte informace, které souvisejí se stavem ú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, kde v úloze 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, která se dají použít.

Můžete mít řídicí panely pro zúčastněné strany nebo vývojáře, které jsou přizpůsobené tak, aby zobrazovaly jenom data o úlohách, které jim přijdou relevantní. Ujistěte se, že tým úloh rozumí typům datových bodů, o které mají ostatní týmy zájem, a před sdílením řídicích panelů zobrazí jejich náhled, aby bylo jasné. Poskytnutí řídicích panelů o úlohách pro zúčastněné strany je dobrým způsobem, jak je instruovat o stavu úloh, ale představuje riziko, že bude kontraproduktivní, pokud zúčastněné strany jasně nerozumí datům, která vidí.

Dobrý řídicí panel nezobrazuje jenom informace. Umožňuje také analytikům 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 zkoumání podkladových dat. Místo toho může být v závislosti na úložišti, které se používá k uchovávání informací, možné data dotazovat přímo nebo je importovat do nástrojů, jako je Excel, za účelem další analýzy a vytváření sestav.

Poznámka

Omezte přístup k řídicímu panelu na autorizované pracovníky. 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ě.

Generování sestav

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

Generování provozních sestav obvykle zahrnuje následující:

Agregační statistiky, které můžete použít k pochopení využití prostředků v celém systému nebo zadaných subsystémech během zadaného časového období.
Identifikace trendů ve 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 související náklady, aniž by to zbytečně ovlivnilo výkon.

Generování sestav zabezpečení sleduje použ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čí, společně s daty a časy. Data by měla být strukturovaná tak, aby správce mohl rychle rekonstruovat posloupnost operací, které uživatel dokončí během zadaného období.
Sledování využití prostředků podle uživatele. Tato úloha vyžaduje zaznamenání, jak každý požadavek od uživatele přistupuje k různým prostředkům, které tvoří systém, 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ě pro účely fakturace.

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 v případě potřeby generovat sestavy spontánně. 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.

Výstrahy

Pokud chcete zajistit, aby systém zůstal v pořádku, responzivní a zabezpečený, nastavte výstrahy tak, aby na ně operátoři mohli včas reagovat. Výstraha může obsahovat dostatek kontextových informací, které jim pomůžou rychle začít s diagnostickými aktivitami. Výstrahy se dají použít k vyvolání nápravných funkcí, jako je automatické škálování nebo jiné mechanismy samoopravování. Výstrahy můžou také zvýšit povědomí o nákladech tím, že poskytují přehled o rozpočtech a limitech.

Doporučení

Definujte proces pro reakci na upozornění, který identifikuje odpovědné vlastníky a akce.
Nakonfigurujte upozornění pro dobře definovaný obor (typy prostředků a skupiny prostředků) a upravte podrobnosti, abyste minimalizovali šum.
Místo toho, aby lidé museli aktivně hledat problémy, používejte řešení automatizovaného upozorňování, jako je Splunk nebo Azure Monitor.
Pomocí výstrah můžete zprovoznit 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 doporučeních ke stavu.

Prahové hodnoty

Výstrahy se generují při překročení prahových hodnot, které zjistí váš monitorovací systém. Ujistěte se, že nastavené prahové hodnoty obecně poskytují dostatek času na implementaci potřebných změn v úlohách, abyste se vyhnuli snížení nebo výpadkům. Nastavte například prahovou hodnotu automatického škálování tak, aby se škálování zahájilo dříve, než se některý ze spuštěných systémů zahltí až do bodu sníženého uživatelského prostředí. Založte prahové hodnoty, které přiřadíte, na základě vašich minulých zkušeností se správou infrastruktury a ověřte je prostřednictvím testování, které provádíte v rámci testovacích postupů.

Podrobné pokyny k upozorňování případů použití a další důležité informace 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 data monitorování z cloudových a místních prostředí.
Log Analytics je nástroj v 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ů, projděte si osvědčené postupy v průvodci architekturou pracovních prostorů 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í Azure Monitoru a Log Analytics.
Azure Monitor pro řešení SAP je nástroj pro monitorování prostředí SAP, který běží v Azure.
Azure Policy vám může pomoct vynucovat standardy organizace a vyhodnocovat dodržování předpisů ve velkém.

Odkazy na komunitu

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

Kontrolní seznam provozní efektivity

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

Kontrolní seznam provozní efektivity

Share via

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