Pokyny k monitorování a diagnostice

Azure Monitor

Distribuované aplikace a služby běžící v cloudu jsou podle své povahy komplexní části softwaru, které tvoří mnoho pohyblivých částí. V produkčním prostředí je důležité sledovat způsob, jakým uživatelé používají váš systém, sledovat využití prostředků a obecně monitorovat stav a výkon systému. Tyto informace můžete použít jako diagnostickou pomůcku k rozpoznání a opravě problémů a také k tomu, abyste si všimli potenciálních problémů a zabránili jejich výskytu.

Scénáře monitorování a diagnostiky

Monitorování můžete použít k získání přehledu o tom, jak dobře systém funguje. Monitorování je klíčovou součástí udržování cílů kvality služeb. Mezi běžné scénáře shromažďování dat monitorování patří:

• Zajištění, aby systém zůstal v pořádku.
• Sledování dostupnosti systému a jeho součástí
• Udržování výkonu, aby se zajistila neočekávaná propustnost systému při nárůstu objemu práce.
• Záruka, že systém splňuje všechny smlouvy o úrovni služeb (SLA) vytvořené se zákazníky.
• Ochrana soukromí a zabezpečení systému, uživatelů a jejich dat.
• Sledování operací prováděných pro účely auditování nebo právních předpisů
• Monitorování každodenního používání systému a sledování trendů, které můžou vést k problémům, pokud nejsou vyřešené.
• Sledování problémů, ke kterým dochází, od počátečních zpráv až po analýzu možných příčin, nápravy, následných aktualizací softwaru a nasazení.
• Operace trasování a ladění vydaných verzí softwaru

Poznámka:

Tento seznam není určen k tomu, aby byl vyčerpávající. Tento dokument se zaměřuje na tyto scénáře jako nejčastější situace pro provádění monitorování. Můžou existovat i jiné, které jsou méně časté nebo jsou specifické pro vaše prostředí.

Následující části popisují tyto scénáře podrobněji. Informace pro jednotlivé scénáře jsou popsány v následujícím formátu:

1. Stručný přehled scénáře
2. Typické požadavky tohoto scénáře.
3. Nezpracovaná data instrumentace, která jsou nutná k podpoře scénáře, a možné zdroje těchto informací.
4. Způsob analýzy a kombinování těchto nezpracovaných dat za účelem generování smysluplných diagnostických informací

Monitorování stavu

Systém je v pořádku, pokud je spuštěný a schopný zpracovávat požadavky. Účelem monitorování stavu je vygenerovat snímek aktuálního stavu systému, abyste mohli ověřit, že všechny součásti systému fungují podle očekávání.

Požadavky na monitorování stavu

Operátor by měl být rychle upozorněn (během několika sekund), pokud je některá část systému považována za špatnou. Operátor by měl být schopen zjistit, které části systému fungují normálně a které části mají problémy. Stav systému je možné zvýraznit prostřednictvím systému semaforu:

• Červená pro stav není v pořádku (systém se zastavil)
• Žlutá pro částečně v pořádku (systém běží se sníženou funkčností)
• Zelená pro zcela zdravé

Komplexní systém pro monitorování stavu umožňuje operátorovi přejít k podrobnostem systému a zobrazit stav subsystémů a komponent. Pokud je například celkový systém znázorněný jako částečně v pořádku, měl by být operátor schopný přiblížit a určit, které funkce jsou aktuálně nedostupné.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Nezpracovaná data potřebná k podpoře monitorování stavu se dají vygenerovat v důsledku:

• Trasování provádění uživatelských požadavků Tyto informace lze použít k určení, které požadavky byly úspěšné, které selhaly a jak dlouho trvá jednotlivé požadavky.
• Syntetické monitorování uživatelů. Tento proces simuluje kroky prováděné uživatelem a řídí se předdefinovanou řadou kroků. Výsledky jednotlivých kroků by se měly zachytit.
• Protokolování výjimek, chyb a upozornění Tyto informace je možné zachytit v důsledku příkazů trasování vložených do kódu aplikace a také načtení informací z protokolů událostí všech služeb, na které systém odkazuje.
• Monitorování stavu všech služeb třetích stran, které systém používá. Toto monitorování může vyžadovat načtení a analýzu dat o stavu, která tyto služby poskytují. Tyto informace můžou mít různé formáty.
• Monitorování koncových bodů Tento mechanismus je podrobněji popsán v části Monitorování dostupnosti.
• Shromažďování informací o okolním výkonu, jako je využití procesoru na pozadí nebo vstupně-výstupní aktivita (včetně sítě).

Analýza dat o stavu

Hlavním cílem monitorování stavu je rychle indikovat, jestli je systém spuštěný. Horká analýza okamžitých dat může aktivovat výstrahu, pokud se zjistí, že kritická komponenta není v pořádku. (Například nereaguje na po sobě jdoucí řadu příkazů ping.) Operátor pak může provést příslušnou nápravnou akci.

Pokročilejší systém může zahrnovat prediktivní prvek, který provádí studenou analýzu za posledních a aktuálních úloh. Studená analýza dokáže odhalit trendy a určit, jestli systém pravděpodobně zůstane v pořádku nebo jestli systém potřebuje další prostředky. Tento prediktivní prvek by měl být založený na důležitých metrikách výkonu, například:

• Rychlost požadavků směrovaných na každou službu nebo subsystém.
• Doby odezvy těchto požadavků.
• Objem dat, která se přetékají do a z každé služby.

Pokud hodnota jakékoli metriky překročí definovanou prahovou hodnotu, může systém vyvolat výstrahu, která operátorovi nebo automatickému škálování (pokud je k dispozici) umožnit provedení preventivních akcí nezbytných k zachování stavu systému. Tyto akce můžou zahrnovat přidání prostředků, restartování jedné nebo více služeb, které selhávají, nebo omezení požadavků s nižší prioritou.

Monitorování dostupnosti

Skutečně zdravý systém vyžaduje, aby byly dostupné komponenty a subsystémy, které systém tvoří. Monitorování dostupnosti úzce souvisí s monitorováním stavu. Zatímco monitorování stavu poskytuje okamžitý přehled o aktuálním stavu systému, monitorování dostupnosti se zabývá sledováním dostupnosti systému a jeho součástí za účelem generování statistik o době provozu systému.

V mnoha systémech jsou některé komponenty (například databáze) nakonfigurované s integrovanou redundancí, která umožňuje rychlé převzetí služeb při selhání v případě závažné chyby nebo ztráty připojení. V ideálním případě by uživatelé neměli vědět, že k takové chybě došlo. Z hlediska monitorování dostupnosti je ale nutné shromáždit co nejvíce informací o takových selháních, abyste zjistili příčinu a podnikli nápravné akce, aby se zabránilo jejich opakovanému opakování.

Data potřebná ke sledování dostupnosti můžou záviset na několika faktorech nižší úrovně. Mnoho z těchto faktorů může být specifické pro aplikaci, systém a prostředí. Efektivní monitorovací systém zaznamenává data o dostupnosti, která odpovídají těmto faktorům nízké úrovně, a pak je agreguje, aby získal celkový přehled o systému. Například v systému elektronického obchodování můžou obchodní funkce, které zákazníkovi umožňují zadávat objednávky, záviset na úložišti, kde jsou uloženy podrobnosti objednávky, a platební systém, který zpracovává peněžní transakce za platbu za tyto objednávky. Dostupnost části systému pro umísťování objednávek je proto funkcí dostupnosti úložiště a subsystému plateb.

Požadavky na monitorování dostupnosti

Operátor by měl mít také možnost zobrazit historickou dostupnost jednotlivých systémů a subsystémů a tyto informace použít ke sledování trendů, které by mohly způsobit pravidelné selhání jednoho nebo více subsystémů. (Začnou služby selhávat v konkrétní denní době, která odpovídá hodině zpracování ve špičce?)

Řešení monitorování by mělo poskytnout okamžitý a historický přehled o dostupnosti nebo nedostupnosti jednotlivých subsystémů. Měl by také být schopný rychle upozornit operátora, když jedna nebo více služeb selže nebo když se uživatelé nemůžou připojit ke službám. Jedná se nejen o monitorování jednotlivých služeb, ale také zkoumání akcí, které každý uživatel provede, pokud tyto akce selžou při pokusu o komunikaci se službou. V určitém rozsahu je míra selhání připojení normální a může být způsobená přechodnými chybami. Může ale být užitečné, aby systém mohl vyvolat upozornění na počet selhání připojení k zadanému subsystému, ke kterému dochází během určitého období.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Stejně jako u monitorování stavu je možné nezpracovaná data požadovaná k podpoře monitorování dostupnosti vygenerovat v důsledku syntetického monitorování uživatelů a protokolování všech výjimek, chyb a upozornění, ke kterým může dojít. Kromě toho je možné získat data o dostupnosti z monitorování koncových bodů. Aplikace může zveřejnit jeden nebo více koncových bodů stavu, přičemž každý testuje přístup k funkční oblasti v rámci systému. Monitorovací systém může každý koncový bod otestovat příkazem ping podle definovaného plánu a shromáždit výsledky (úspěch nebo selhání).

Všechny časové limity, chyby připojení k síti a pokusy o opakování připojení se musí zaznamenávat. Všechna data by měla být časová razítka.

Analýza dat o dostupnosti

Data instrumentace musí být agregovaná a korelovaná, aby podporovala následující typy analýz:

• Okamžitá dostupnost systému a subsystémů.
• Míra selhání dostupnosti systému a subsystémů. V ideálním případě by měl být operátor schopný korelovat selhání s konkrétními aktivitami: co se stalo, když došlo k selhání systému?
• Historický pohled na míru selhání systému nebo všech subsystémů v jakémkoli zadaném období a zatížení systému (například počet uživatelských požadavků), když došlo k selhání.
• Důvody nedostupnosti systému nebo jakýchkoli subsystémů Důvodem může být například neběžení služby, ztráta připojení, ztráta připojení, časový limit připojení a připojení, ale vrácení chyb.

Procentuální dostupnost služby můžete vypočítat v určitém časovém období pomocí následujícího vzorce:

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

To je užitečné pro účely smlouvy SLA. (Monitorování smluv SLA je podrobněji popsáno dále v těchto doprovodných materiálech.) Definice výpadků závisí na službě. Například Visual Studio Team Services Build Service definuje výpadek jako období (celkové kumulované minuty), během kterého je služba buildu nedostupná. Minuta se považuje za nedostupnou, pokud všechny průběžné požadavky HTTP na službu sestavení za účelem provádění operací iniciovaných zákazníkem během této minuty buď způsobí kód chyby, nebo nevrátí odpověď.

Monitorování výkonu

Vzhledem k tomu, že je systém více a více stresů (zvýšením objemu uživatelů), velikost datových sad, ke kterým tito uživatelé přistupují, roste a pravděpodobnost selhání jedné nebo více součástí bude pravděpodobnější. Často se selhání komponent předchází snížením výkonu. Pokud takové snížení dokážete zjistit, můžete proaktivně provést kroky k nápravě situace.

Výkon systému závisí na několika faktorech. Každý faktor se obvykle měří prostřednictvím klíčových ukazatelů výkonu (KPI), jako je počet databázových transakcí za sekundu nebo objem síťových požadavků, které se úspěšně obsluhují v zadaném časovém rámci. Některé z těchto klíčových ukazatelů výkonu můžou být k dispozici jako konkrétní míry výkonu, zatímco jiné můžou být odvozené z kombinace metrik.

Poznámka:

Určení špatného nebo dobrého výkonu vyžaduje, abyste pochopili úroveň výkonu, při které by měl být systém schopný běžet. To vyžaduje sledování systému, zatímco funguje v typickém zatížení a zaznamenává data pro každý klíčový ukazatel výkonu v určitém časovém období. To může zahrnovat spuštění systému pod simulovaným zatížením v testovacím prostředí a shromáždění příslušných dat před nasazením systému do produkčního prostředí.

Měli byste také zajistit, aby monitorování pro účely výkonu nezatěžuje systém. Možná budete moct dynamicky upravit úroveň podrobností pro data, která proces monitorování výkonu shromažďuje.

Požadavky na monitorování výkonu

Aby operátor prozkoumal výkon systému, obvykle potřebuje zobrazit informace, které zahrnují:

• Míra odpovědí pro požadavky uživatelů.
• Počet souběžných uživatelských požadavků.
• Objem síťového provozu.
• Sazby, za které jsou obchodní transakce dokončeny.
• Průměrná doba zpracování požadavků.

Může být také užitečné poskytnout nástroje, které operátorovi umožňují odhalit korelace, například:

• Počet souběžných uživatelů oproti latenci požadavků (jak dlouho trvá zahájení zpracování požadavku po odeslání žádosti).
• Počet souběžných uživatelů oproti průměrné době odezvy (jak dlouho trvá dokončení požadavku po zahájení zpracování).
• Objem požadavků versus počet chyb zpracování.

Kromě těchto informací o funkcích vysoké úrovně by měl být operátor schopný získat podrobné zobrazení výkonu pro každou komponentu v systému. Tato data se obvykle poskytují prostřednictvím čítačů výkonu nízké úrovně, které sledují informace, jako jsou:

• Využití paměti.
• Počet vláken
• Doba zpracování procesoru.
• Délka fronty požadavku.
• Rychlost a chyby vstupně-výstupních operací disku nebo sítě.
• Počet zapsaných nebo přečtených bajtů
• Indikátory middlewaru, jako je délka fronty.

Všechny vizualizace by měly operátorovi umožnit zadat časové období. Zobrazená data můžou být snímkem aktuální situace nebo historickým zobrazením výkonu.

Operátor by měl být schopen vyvolat výstrahu na základě jakékoli míry výkonu pro libovolnou zadanou hodnotu během libovolného zadaného časového intervalu.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Můžete shromažďovat data o výkonu vysoké úrovně (propustnost, počet souběžných uživatelů, počet obchodních transakcí, chybovosti atd.) monitorováním průběhu požadavků uživatelů při jejich doručení a průchodu systémem. To zahrnuje zahrnutí příkazů trasování v klíčových bodech kódu aplikace spolu s informacemi o načasování. Všechny chyby, výjimky a upozornění by měly být zachyceny s dostatečnými daty pro jejich korelaci s požadavky, které je způsobily. Dalším užitečným zdrojem je protokol Internetové informační služby (IIS).

Pokud je to možné, měli byste také zaznamenávat údaje o výkonu pro všechny externí systémy, které aplikace používá. Tyto externí systémy můžou poskytovat vlastní čítače výkonu nebo jiné funkce pro vyžádání dat o výkonu. Pokud to není možné, zaznamenejte informace, jako je počáteční čas a koncový čas každého požadavku provedeného v externím systému, spolu se stavem (úspěch, selhání nebo upozornění) operace. Můžete například použít přístup stopek k časovým žádostem: spuštění časovače při spuštění požadavku a zastavení časovače po dokončení požadavku.

Data o nízké úrovni výkonu pro jednotlivé komponenty v systému můžou být dostupná prostřednictvím funkcí a služeb, jako jsou čítače výkonu Windows a Diagnostika Azure.

Analýza dat o výkonu

Velká část analýzy se skládá z agregace dat o výkonu podle typu požadavku uživatele nebo subsystému nebo služby, do které se každý požadavek odesílá. Příkladem žádosti uživatele je přidání položky do nákupního košíku nebo provedení procesu rezervace v systému elektronického obchodování.

Dalším běžným požadavkem je shrnutí údajů o výkonu ve vybraných percentilech. Operátor může například určit dobu odezvy 99 procent požadavků, 95 procent požadavků a 70 procent požadavků. Pro každý percentil můžou být nastavené cíle SLA nebo jiné cíle. Probíhající výsledky by měly být hlášeny téměř v reálném čase, aby se pomohly odhalit okamžité problémy. Výsledky by se také měly agregovat po delší dobu pro statistické účely.

V případě problémů s latencí ovlivňujících výkon by měl být operátor schopný rychle identifikovat příčinu kritického bodu prozkoumáním latence každého kroku, který každý požadavek provádí. Údaje o výkonu proto musí poskytovat způsob korelace měr výkonu pro každý krok, aby je svážel s konkrétní žádostí.

V závislosti na požadavcích vizualizace může být užitečné vygenerovat a uložit datovou krychli, která obsahuje zobrazení nezpracovaných dat. Tato datová krychle umožňuje komplexní ad hoc dotazování a analýzu informací o výkonu.

Monitorování zabezpečení

Všechny komerční systémy, které obsahují citlivá data, musí implementovat strukturu zabezpečení. Složitost mechanismu zabezpečení je obvykle funkcí citlivosti dat. V systému, který vyžaduje ověření uživatelů, byste měli zaznamenat:

• Všechny pokusy o přihlášení bez ohledu na to, jestli selžou nebo uspěly.
• Všechny operace prováděné ověřeným uživatelem a podrobnosti o všech prostředcích, ke které má přístup.
• Když uživatel ukončí relaci a odhlásí se.

Monitorování může pomoct odhalit útoky na systém. Například velký počet neúspěšných pokusů o přihlášení může znamenat útok hrubou silou. Neočekávaný nárůst požadavků může být výsledkem distribuovaného útoku DDoS (Denial-of-Service). Musíte být připraveni monitorovat všechny požadavky na všechny prostředky bez ohledu na zdroj těchto požadavků. Systém, který má ohrožení zabezpečení přihlašování, může neúmyslně vystavit prostředky vnějšímu světu, aniž by uživatel musel skutečně přihlásit.

Požadavky na monitorování zabezpečení

Nejdůležitější aspekty monitorování zabezpečení by měly operátorovi umožnit rychlé:

• Zjištění pokusů o neoprávněná vniknutí neověřenou entitou
• Identifikujte pokusy entit o provádění operací s daty, pro která nebyl udělen přístup.
• Určete, jestli je systém nebo některá část systému pod útokem zvenčí nebo uvnitř. (Například škodlivý ověřený uživatel se může pokoušet systém snížit.)

Pro podporu těchto požadavků by měl být operátor upozorněn, pokud:

• Jeden účet provádí opakované neúspěšné pokusy o přihlášení během zadaného období.
• Jeden ověřený účet se během zadaného období opakovaně pokouší získat přístup k zakázanému prostředku.
• Během zadaného období dochází k velkému počtu neověřených nebo neautorizovaných požadavků.

Informace poskytnuté operátorovi by měly obsahovat adresu hostitele zdroje pro každý požadavek. Pokud porušení zabezpečení pravidelně vznikají z určitého rozsahu adres, můžou být tito hostitelé zablokovaní.

Klíčovou součástí udržování zabezpečení systému je schopnost rychle zjišťovat akce, které se odchylují od obvyklého vzoru. Informace, jako je počet neúspěšných nebo úspěšných žádostí o přihlášení, se dají vizuálně zobrazit, aby bylo možné zjistit, jestli v neobvyklé době dochází k prudkému nárůstu aktivity. (Příkladem této aktivity je přihlášení uživatelů v 3:00 a provádění velkého počtu operací, když pracovní den začíná v 9:00). Tyto informace lze použít také ke konfiguraci automatického škálování založeného na čase. Pokud například operátor zjistí, že se v konkrétní denní době pravidelně přihlašuje velký počet uživatelů, může operátor uspořádat další ověřovací služby pro zpracování objemu práce a po uplynutí špičky tyto další služby vypnout.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Zabezpečení je všezahrnující aspekt většiny distribuovaných systémů. Příslušná data se pravděpodobně generují v několika bodech v celém systému. Měli byste zvážit přijetí přístupu pro správu informací o zabezpečení a událostí (SIEM) ke shromáždění informací souvisejících se zabezpečením, které vyplývají z událostí vyvolaných aplikací, síťovým vybavením, servery, branami firewall, antivirovým softwarem a dalšími prvky ochrany před neoprávněným vniknutím.

Monitorování zabezpečení může zahrnovat data z nástrojů, které nejsou součástí vaší aplikace. Tyto nástroje můžou zahrnovat nástroje, které identifikují aktivity prohledávání portů externími institucemi, nebo síťové filtry, které zjistí pokusy o získání neověřeného přístupu k vaší aplikaci a datům.

Ve všech případech musí shromážděná data správci umožnit určit povahu jakéhokoli útoku a provést příslušná protiopatření.

Analýza dat zabezpečení

Klíčovou funkcí monitorování zabezpečení je, že shromažďuje data z mnoha zdrojů. Různé formáty a úroveň podrobností často vyžadují komplexní analýzu zachycených dat, aby je spojily do koherentního vlákna informací. Kromě nejjednodušších případů (například zjištění velkého počtu neúspěšných přihlášení nebo opakovaných pokusů o získání neoprávněného přístupu k důležitým prostředkům) nemusí být možné provádět žádné složité automatizované zpracování dat zabezpečení. Místo toho může být vhodnější zapsat tato data, časové razítko, ale jinak v původní podobě, do zabezpečeného úložiště, aby bylo možné provést odbornou ruční analýzu.

Monitorování smluv SLA

Řada komerčních systémů, které podporují placení zákazníků, zaručuje výkon systému ve formě smluv SLA. Smlouvy SLA v podstatě uvádějí, že systém dokáže zpracovat definovaný objem práce v rámci schváleného časového rámce a bez ztráty důležitých informací. Monitorování smluv SLA se zabývá zajištěním, aby systém mohl splňovat měřitelné smlouvy SLA.

Poznámka:

Monitorování smlouvy SLA úzce souvisí s monitorováním výkonu. Vzhledem k tomu, že monitorování výkonu se zabývá optimálním fungováním systému, řídí se monitorování smluv SLA smluvní povinností, která definuje, co optimálně znamená.

Smlouvy SLA se často definují z těchto podmínek:

• Celková dostupnost systému. Organizace může například zaručit, že systém bude k dispozici po dobu 99,9 procenta času. To odpovídá ne více než 9 hodin výpadkům za rok nebo přibližně 10 minut týdně.
• Provozní propustnost. Tento aspekt se často vyjadřuje jako jedna nebo více horních vodných značek, jako je například záruka, že systém může podporovat až 100 000 souběžných uživatelských požadavků nebo zpracovat 10 000 souběžných obchodních transakcí.
• Provozní doba odezvy. Systém může také zaručit rychlost zpracování požadavků. Příkladem je, že 99 % všech obchodních transakcí se dokončí během dvou sekund a jedna transakce trvá déle než 10 sekund.

Poznámka:

Některé smlouvy o komerčních systémech můžou zahrnovat také smlouvy SLA pro zákaznickou podporu. Příkladem je, že všechny žádosti help-desku vyvolaly odpověď během pěti minut a že 99 procent všech problémů je plně vyřešeno během jednoho pracovního dne. Efektivní sledování problémů (popsané dále v této části) je klíčem ke splnění smluv SLA, jako jsou tyto.

Požadavky na monitorování smluv SLA

Na nejvyšší úrovni by měl být operátor schopen zjistit na první pohled, jestli systém splňuje schválené smlouvy SLA, nebo ne. Pokud ne, operátor by měl být schopný přejít k podrobnostem a prozkoumat podkladové faktory a určit důvody pro nestandardní výkon.

Mezi typické indikátory vysoké úrovně, které lze vizuálně znázornit, patří:

• Procento doby provozu služby.
• Propustnost aplikace (měřená z hlediska úspěšných transakcí nebo operací za sekundu)
• Počet úspěšných nebo neúspěšných požadavků aplikace.
• Počet chyb aplikací a systémů, výjimek a upozornění.

Všechny tyto indikátory by měly být schopné filtrovat podle zadaného časového období.

Cloudová aplikace pravděpodobně zahrnuje několik subsystémů a komponent. Operátor by měl být schopný vybrat ukazatel vysoké úrovně a zjistit, jak se skládá ze stavu podkladových prvků. Pokud například doba provozu celého systému klesne pod přijatelnou hodnotu, operátor by měl být schopný přiblížit a určit, které prvky přispívají k tomuto selhání.

Poznámka:

Dostupnost systému musí být definovaná pečlivě. V systému, který používá redundanci k zajištění maximální dostupnosti, může dojít k selhání jednotlivých instancí prvků, ale systém může zůstat funkční. Dostupnost systému, jak je prezentováno monitorováním stavu, by měla indikovat agregovanou dobu provozu jednotlivých prvků, a ne nutně to, jestli se systém skutečně zastavil. Kromě toho může být selhání izolovaná. Takže i když je určitý systém nedostupný, zbytek systému může zůstat dostupný, i když s nižší funkčností. (V systému elektronického obchodování může selhání systému bránit zákazníkovi v zadávání objednávek, ale zákazník může stále procházet katalog produktů.)

Pro účely upozorňování by systém měl být schopný vyvolat událost, pokud některý z indikátorů vysoké úrovně překročí zadanou prahovou hodnotu. Podrobnosti na nižší úrovni různých faktorů, které tvoří ukazatel vysoké úrovně, by měly být k dispozici jako kontextová data pro systém výstrah.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Nezpracovaná data potřebná k podpoře monitorování sla se podobají nezpracovaným datům potřebným pro monitorování výkonu spolu s některými aspekty monitorování stavu a dostupnosti. Další informace najdete v těchto částech. Tato data můžete zachytit takto:

• Provádění monitorování koncových bodů
• Protokolování výjimek, chyb a upozornění
• Trasování provádění uživatelských požadavků
• Monitorování dostupnosti všech služeb třetích stran, které systém používá.
• Použití metrik výkonu a čítačů

Všechna data musí být časovaná a časová razítka.

Analýza dat SLA

Data instrumentace musí být agregována, aby se vygeneroval obrázek celkového výkonu systému. Agregovaná data musí také podporovat přechod k podrobnostem, aby bylo možné zkoumat výkon základních subsystémů. Měli byste být například schopni:

• Vypočítejte celkový počet uživatelských požadavků během zadaného období a určete úspěšnost a míru selhání těchto požadavků.
• Zkombinujte doby odezvy uživatelských požadavků a vygenerujte celkový přehled doby odezvy systému.
• Analyzujte průběh uživatelských požadavků, abyste rozdělili celkovou dobu odezvy požadavku do doby odezvy jednotlivých pracovních položek v této žádosti.
• Určete celkovou dostupnost systému jako procento doby provozu pro každé konkrétní období.
• Analyzujte procento dostupnosti jednotlivých komponent a služeb v systému. To může zahrnovat analýzu protokolů, které vygenerovaly služby třetích stran.

Mnoho komerčních systémů je nutné hlásit skutečné údaje o výkonnosti s dohodnutými smlouvami SLA za určité období, obvykle za měsíc. Tyto informace lze použít k výpočtu kreditů nebo jiných forem splátek pro zákazníky, pokud během tohoto období nejsou splněny smlouvy SLA. Dostupnost služby můžete vypočítat pomocí techniky popsané v části Analýza dat dostupnosti.

Pro interní účely může organizace také sledovat počet a povahu incidentů, které způsobily selhání služeb. Když se naučíte, jak tyto problémy rychle vyřešit nebo je úplně odstranit, pomůžete snížit výpadky a splnit smlouvy SLA.

Kontrola

V závislosti na povaze aplikace může existovat zákonné nebo jiné právní předpisy, které určují požadavky na auditování operací uživatelů a zaznamenávání veškerého přístupu k datům. Auditování může poskytnout důkazy, které spojují zákazníky s konkrétními požadavky. Nererepudice je důležitým faktorem v mnoha e-obchodních systémech, které pomáhají udržovat důvěru mezi zákazníkem a organizací odpovědnou za aplikaci nebo službu.

Požadavky na auditování

Analytik musí být schopný sledovat posloupnost obchodních operací, které uživatelé provádějí, abyste mohli rekonstruovat akce uživatelů. To může být nezbytné jednoduše jako záznam nebo jako součást forenzního vyšetřování.

Informace o auditu jsou vysoce citlivé. Pravděpodobně obsahuje data, která identifikují uživatele systému spolu s úlohami, které provádějí. Z tohoto důvodu mají informace o auditu formu sestav dostupných pouze důvěryhodným analytikům, spíše než interaktivní systém podporující podrobné procházení grafických operací. Analytik by měl být schopný vygenerovat celou řadu sestav. Sestavy můžou například zobrazit seznam všech aktivit uživatelů, ke kterým dochází během zadaného časového rámce, podrobně zobrazit chronologii aktivity pro jednoho uživatele nebo zobrazit posloupnost operací provedených s jedním nebo více prostředky.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Mezi primární zdroje informací pro auditování patří:

• Systém zabezpečení, který spravuje ověřování uživatelů.
• Trasování protokolů, které zaznamenávají aktivity uživatelů.
• Protokoly zabezpečení, které sledují všechny identifikovatelné a neidentifikovatelné síťové požadavky.

Formát dat auditu a způsob, jakým jsou uložena, může být řízen zákonnými požadavky. Například nemusí být možné data žádným způsobem vyčistit. (Musí být zaznamenán v původním formátu.) Přístup k úložišti, kde se uchovává, musí být chráněný, aby se zabránilo manipulaci.

Analýza dat auditu

Analytik musí mít přístup k nezpracovaným datům v celé jeho původní podobě. Kromě požadavku na generování běžných sestav auditu budou nástroje pro analýzu těchto dat pravděpodobně specializované a budou se uchovávat mimo systém.

Monitorování využití

Monitorování využití sleduje, jak se používají funkce a součásti aplikace. Operátor může shromážděná data použít k:

• Určete, které funkce se silně používají, a určete případné hotspoty v systému. Prvky s vysokým provozem můžou těžit z funkčního dělení nebo dokonce replikace, aby se zatížení rovnoměrněji rozložily. Operátor může tyto informace použít také ke zjištění, které funkce se často používají a které jsou možné kandidáty na vyřazení nebo nahrazení v budoucí verzi systému.

• Získejte informace o provozních událostech systému v normálním použití. Například na webu elektronického obchodování můžete zaznamenávat statistické informace o počtu transakcí a objemu zákazníků, kteří za ně zodpovídají. Tyto informace je možné použít k plánování kapacity s rostoucím počtem zákazníků.

• Zjištění (pravděpodobně nepřímo) spokojenosti uživatele s výkonem nebo funkčností systému Pokud například velký počet zákazníků v systému elektronického obchodování pravidelně opouští své nákupní košíky, může to být způsobeno problémem s funkcí rezervace.

• Generování fakturačních údajů Komerční aplikace nebo víceklientová služba můžou zákazníkům účtovat poplatky za prostředky, které používají.

• Vynucujte kvóty. Pokud uživatel v systému s více tenanty překročí svou placenou kvótu času zpracování nebo využití prostředků během zadaného období, může být přístup omezený nebo může být omezen.

Požadavky na monitorování využití

K prozkoumání využití systému obvykle potřebuje operátor zobrazit informace, které zahrnují:

• Počet požadavků, které jsou zpracovány jednotlivými subsystémy a směrovány na každý prostředek.
• Práce, kterou každý uživatel provádí.
• Objem úložiště dat, které každý uživatel zabírá.
• Prostředky, ke kterým každý uživatel přistupuje.

Operátor by měl být také schopný generovat grafy. Graf může například zobrazovat nejvíce uživatelů, kteří mají hladový prostředky, nebo nejčastěji používané prostředky nebo systémové funkce.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Sledování využití je možné provádět na relativně vysoké úrovni. Může si všimnout počátečního a koncového času každého požadavku a povahy požadavku (čtení, zápis atd., v závislosti na příslušném prostředku). Tyto informace můžete získat takto:

• Trasování aktivity uživatelů
• Zaznamenávání čítačů výkonu, které měří využití jednotlivých prostředků.
• Monitorování spotřeby prostředků jednotlivými uživateli

Pro účely měření musíte být také schopni zjistit, kteří uživatelé zodpovídají za provádění operací a prostředků, které tyto operace používají. Shromážděné informace by měly být dostatečně podrobné, aby bylo možné povolit přesnou fakturaci.

Sledování problémů

Zákazníci a jiní uživatelé můžou nahlásit problémy, pokud v systému dojde k neočekávaným událostem nebo chováním. Sledování problémů se zabývá správou těchto problémů, jejich přidružením k řešení jakýchkoli hlubších problémů v systému a informováním zákazníků o možných řešeních.

Požadavky na sledování problémů

Operátoři často provádějí sledování problémů pomocí samostatného systému, který jim umožňuje zaznamenávat a hlásit podrobnosti o problémech, které uživatelé hlásí. Tyto podrobnosti mohou zahrnovat úlohy, které se uživatel pokusil provést, příznaky problému, posloupnost událostí a všechny chybové nebo výstražné zprávy, které byly vydány.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Počátečním zdrojem dat pro data sledování problémů je uživatel, který problém nahlásil na prvním místě. Uživatel může poskytnout další data, například:

• Výpis stavu systému (pokud aplikace obsahuje komponentu, která běží na počítači uživatele).
• Snímek obrazovky
• Datum a čas výskytu chyby spolu s dalšími informacemi o prostředí, jako je umístění uživatele.

Tyto informace lze použít k usnadnění ladění úsilí a vytvoření backlogu pro budoucí verze softwaru.

Analýza dat sledování problémů

Stejný problém můžou nahlásit různí uživatelé. Systém sledování problémů by měl přidružit běžné sestavy.

Průběh úsilí o ladění by se měl zaznamenávat do každé zprávy o problému. Po vyřešení problému může být zákazník o řešení informován.

Pokud uživatel hlásí problém se známým řešením v systému sledování problémů, operátor by měl být schopen uživatele o řešení informovat okamžitě.

Operace trasování a ladění vydaných verzí softwaru

Když uživatel hlásí problém, často si je vědom pouze okamžitého účinku, který má na své operace. Uživatel může hlásit pouze výsledky vlastního prostředí operátorovi, který je zodpovědný za údržbu systému. Tyto zkušenosti jsou obvykle jen viditelným příznakem jednoho nebo více základních problémů. V mnoha případech musí analytik prozkoumat chronologii základních operací, aby vytvořil hlavní příčinu problému. Tento proces se nazývá analýza původní příčiny.

Poznámka:

Analýza původní příčiny může odhalit nedostatky v návrhu aplikace. V těchto situacích může být možné přepracovat ovlivněné prvky a nasadit je jako součást následné verze. Tento proces vyžaduje pečlivou kontrolu a aktualizované komponenty by měly být pečlivě sledovány.

Požadavky na trasování a ladění

Pro trasování neočekávaných událostí a dalších problémů je důležité, aby data monitorování poskytovala dostatek informací, aby analytik mohl sledovat původ těchto problémů a rekonstruovat posloupnost událostí, ke kterým došlo. Tyto informace musí stačit k tomu, aby analytik mohl diagnostikovat původní příčinu jakýchkoli problémů. Vývojář pak může provést potřebné úpravy, aby se zabránilo jejich opakování.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Řešení potíží může zahrnovat trasování všech metod (a jejich parametrů) vyvolaných v rámci operace za účelem vytvoření stromu, který znázorňuje logický tok systémem, když zákazník provede konkrétní požadavek. Výjimky a upozornění, které systém generuje v důsledku tohoto toku, musí být zaznamenány a protokolovány.

Kvůli podpoře ladění může systém poskytovat háky, které operátorovi umožňují zaznamenávat informace o stavu v klíčových bodech systému. Systém může také poskytovat podrobné podrobné informace o průběhu vybraných operací. Zachytávání dat na této úrovni podrobností může znamenat dodatečné zatížení systému a mělo by se jednat o dočasný proces. Operátor tento proces používá hlavně v případě, že dojde k velmi neobvyklé řadě událostí a je obtížné je replikovat, nebo když nová verze jednoho nebo více prvků do systému vyžaduje pečlivé monitorování, aby se zajistilo, že prvky fungují podle očekávání.

Kanál monitorování a diagnostiky

Monitorování velkého distribuovaného systému je velkou výzvou. Každý ze scénářů popsaných v předchozí části by se neměl nutně považovat za izolovanou. V monitorování a diagnostických datech, která jsou nutná pro každou situaci, se pravděpodobně výrazně překrývají, i když tato data může být potřeba zpracovávat a prezentovat různými způsoby. Z těchto důvodů byste měli vzít holistický pohled na monitorování a diagnostiku.

Celý proces monitorování a diagnostiky si můžete představit jako kanál, který se skládá z fází zobrazených na obrázku 1.

Obrázek 1 – Fáze v kanálu monitorování a diagnostiky

Obrázek 1 zdůrazňuje, jak můžou data pro monitorování a diagnostiku pocházet z různých zdrojů dat. Fáze instrumentace a shromažďování se zabývají identifikací zdrojů, ze kterých je potřeba data zachytit, určit, která data se mají zachytit, jak je zachytit, jak je naformátovat, aby bylo možné je snadno prozkoumat. Fáze analýzy/diagnostiky přebírá nezpracovaná data a používá je k vygenerování smysluplných informací, které může operátor použít k určení stavu systému. Operátor může tyto informace použít k rozhodování o možných akcích, které se mají provést, a výsledky pak vrátit zpět do fází instrumentace a shromažďování. Fáze vizualizace/upozorňování představuje spotřební zobrazení stavu systému. Může zobrazovat informace téměř v reálném čase pomocí řady řídicích panelů. A může generovat sestavy, grafy a grafy, které poskytují historický pohled na data, která pomáhají identifikovat dlouhodobé trendy. Pokud informace naznačují, že klíčový ukazatel výkonu pravděpodobně překročí přijatelné hranice, může tato fáze také aktivovat upozornění na operátora. V některých případech lze výstrahu použít také k aktivaci automatizovaného procesu, který se pokusí provést opravné akce, jako je automatické škálování.

Tyto kroky představují proces průběžného toku, ve kterém se fáze provádějí paralelně. V ideálním případě by měly být všechny fáze dynamicky konfigurovatelné. V některých případech, zejména v případě, že je systém nově nasazený nebo dochází k problémům, může být nutné shromažďovat rozšířená data častěji. Jindy by mělo být možné vrátit se k zachycení základní úrovně základních informací, abyste ověřili, že systém funguje správně.

Kromě toho by se celý proces monitorování měl považovat za živé, probíhající řešení, které je předmětem vyladění a vylepšení v důsledku zpětné vazby. Můžete například začít měřením mnoha faktorů, které určují stav systému. Analýza v průběhu času může vést k vylepšení, protože zahodíte míry, které nejsou relevantní, a umožní vám přesněji zaměřit se na potřebná data a minimalizovat šum na pozadí.

Zdroje monitorovacích a diagnostických dat

Informace, které proces monitorování používá, mohou pocházet z několika zdrojů, jak je znázorněno na obrázku 1. Na úrovni aplikace pocházejí informace z protokolů trasování začleněných do kódu systému. Vývojáři by měli dodržovat standardní přístup ke sledování toku řízení prostřednictvím kódu. Například položka metody může generovat trasovací zprávu, která určuje název metody, aktuální čas, hodnotu každého parametru a všechny další relevantní informace. Záznam doby vstupu a ukončení může být také užitečný.

Měli byste protokolovat všechny výjimky a upozornění a zajistit, abyste zachovali úplné trasování všech vnořených výjimek a upozornění. V ideálním případě byste měli zaznamenávat také informace, které identifikují uživatele, který kód spouští, spolu s informacemi o korelaci aktivit (ke sledování požadavků při průchodu systémem). Měli byste také protokolovat pokusy o přístup ke všem prostředkům, jako jsou fronty zpráv, databáze, soubory a další závislé služby. Tyto informace lze použít pro účely měření a auditování.

Mnoho aplikací používá knihovny a architektury k provádění běžných úloh, jako je přístup k úložišti dat nebo komunikace přes síť. Tyto architektury můžou být konfigurovatelné tak, aby poskytovaly vlastní trasovací zprávy a nezpracované diagnostické informace, jako jsou rychlosti transakcí a úspěšnost přenosu dat a selhání.

Poznámka:

Mnoho moderních architektur automaticky publikuje události výkonu a trasování. Zachytávání těchto informací je jednoduše otázkou poskytnutí prostředků pro načtení a uložení, kde je lze zpracovávat a analyzovat.

Operační systém, na kterém je aplikace spuštěná, může být zdrojem informací na úrovni systému nízké úrovně, jako jsou čítače výkonu, které označují rychlost vstupně-výstupních operací, využití paměti a využití procesoru. Chyby operačního systému (například chyby při správném otevření souboru) mohou být hlášeny také.

Měli byste také zvážit základní infrastrukturu a komponenty, na kterých běží váš systém. Virtuální počítače, virtuální sítě a služby úložiště můžou být zdroji důležitých čítačů výkonu na úrovni infrastruktury a dalších diagnostických dat.

Pokud vaše aplikace používá jiné externí služby, jako je webový server nebo systém pro správu databází, můžou tyto služby publikovat vlastní informace o trasování, protokoly a čítače výkonu. Mezi příklady patří zobrazení dynamické správy SQL Serveru pro sledování operací provedených v databázi SQL Serveru a protokoly trasování služby IIS pro zaznamenávání požadavků provedených na webový server.

Při úpravě součástí systému a nasazení nových verzí je důležité mít možnost přiřazovat problémy, události a metriky pro každou verzi. Tyto informace by měly být svázané zpět s kanálem verze, aby bylo možné rychle a znovu sledovat problémy s konkrétní verzí komponenty.

K problémům se zabezpečením může dojít v jakémkoli okamžiku v systému. Uživatel se například může pokusit přihlásit pomocí neplatného ID uživatele nebo hesla. Ověřený uživatel se může pokusit získat neoprávněný přístup k prostředku. Nebo uživatel může poskytnout neplatný nebo zastaralý klíč pro přístup k šifrovaným informacím. Informace související se zabezpečením pro úspěšné a neúspěšné požadavky by se měly vždy protokolovat.

Část Instrumentace aplikace obsahuje další pokyny k informacím, které byste měli zaznamenat. K získání těchto informací ale můžete použít různé strategie:

• Monitorování aplikací a systémů. Tato strategie používá interní zdroje v rámci aplikace, aplikačních architektur, operačního systému a infrastruktury. Kód aplikace může během životního cyklu požadavku klienta vygenerovat vlastní data monitorování v kritických bodech. Aplikace může obsahovat příkazy trasování, které mohou být selektivně povoleny nebo zakázány při diktování okolností. Pomocí diagnostické architektury může být také možné dynamicky vkládat diagnostiku. Tyto architektury obvykle poskytují moduly plug-in, které se můžou připojit k různým bodům instrumentace v kódu a zachytávat data trasování v těchto bodech.

  Kromě toho může váš kód nebo základní infrastruktura vyvolat události v kritických bodech. Monitorovací agenti nakonfigurovaní tak, aby naslouchali těmto událostem, mohou zaznamenávat informace o událostech.

• Monitorování skutečných uživatelů Tento přístup zaznamenává interakce mezi uživatelem a aplikací a sleduje tok jednotlivých požadavků a odpovědí. Tyto informace můžou mít dvounásobný účel: dají se použít k měření využití jednotlivými uživateli a dají se použít k určení, jestli uživatelé dostávají vhodnou kvalitu služby (například rychlá doba odezvy, nízká latence a minimální chyby). Zachycená data můžete použít k identifikaci oblastí zájmu, ve kterých nejčastěji dochází k selháním. Data můžete také použít k identifikaci prvků, ve kterých se systém zpomalí, pravděpodobně kvůli hotspotům v aplikaci nebo nějaké jiné formě kritických bodů. Pokud tento přístup implementujete pečlivě, může být možné rekonstruovat toky uživatelů prostřednictvím aplikace pro účely ladění a testování.

  Důležité

  Měli byste zvážit data zachycená monitorováním skutečných uživatelů, aby byla vysoce citlivá, protože by mohla obsahovat důvěrné materiály. Pokud uložíte zachycená data, bezpečně je uložte. Pokud chcete data použít pro účely monitorování výkonu nebo ladění, nejprve odstraňte všechna osobní data.

• Syntetické monitorování uživatelů. V tomto přístupu napíšete vlastního testovacího klienta, který simuluje uživatele a provádí konfigurovatelnou, ale typickou řadu operací. Můžete sledovat výkon testovacího klienta, abyste mohli určit stav systému. V rámci operace zátěžového testování můžete také použít více instancí testovacího klienta, abyste určili, jak systém reaguje pod stresem a jaký druh výstupu monitorování se vygeneruje za těchto podmínek.

  Poznámka:

  Skutečné a syntetické monitorování uživatelů můžete implementovat tak, že zahrnete kód, který trasuje a krát provádění volání metod a dalších důležitých částí aplikace.

• Profilace. Tento přístup je primárně zaměřen na monitorování a zlepšení výkonu aplikace. Místo toho, aby fungoval na funkční úrovni skutečného a syntetického monitorování uživatelů, zachycuje informace na nižší úrovni při spuštění aplikace. Profilaci můžete implementovat pomocí pravidelného vzorkování stavu spuštění aplikace (určení, který kód aplikace běží v daném časovém okamžiku). Můžete také použít instrumentaci, která vloží sondy do kódu v důležitých juncturech (jako je začátek a konec volání metody) a záznamy, které metody byly vyvolány, v jaké době a jak dlouho každé volání trvalo. Pak můžete tato data analyzovat a určit, které části aplikace můžou způsobit problémy s výkonem.

• Monitorování koncových bodů Tato technika používá jeden nebo více diagnostických koncových bodů, které aplikace zveřejňuje speciálně k povolení monitorování. Koncový bod poskytuje cestu do kódu aplikace a může vracet informace o stavu systému. Různé koncové body se můžou zaměřit na různé aspekty funkčnosti. Můžete napsat vlastního diagnostického klienta, který odesílá pravidelné požadavky na tyto koncové body a assimilovat odpovědi. Další informace najdete v modelu monitorování koncových bodů stavu.

Pro maximální pokrytí byste měli použít kombinaci těchto technik.

Instrumentace aplikace

Instrumentace je důležitou součástí procesu monitorování. Smysluplná rozhodnutí o výkonu a stavu systému můžete provádět pouze v případě, že data, která vám umožní tato rozhodnutí provést, nejprve zachytíte. Informace, které shromažďujete pomocí instrumentace, by měly stačit k tomu, abyste mohli posoudit výkon, diagnostikovat problémy a rozhodovat se, aniž byste se museli přihlásit ke vzdálenému produkčnímu serveru, abyste mohli provádět trasování (a ladění) ručně. Data instrumentace obvykle zahrnují metriky a informace zapsané do protokolů trasování.

Obsah protokolu trasování může být výsledkem textových dat, která jsou napsána aplikací nebo binárními daty vytvořenými v důsledku události trasování, pokud aplikace používá trasování událostí pro Windows (ETW). Dají se také generovat ze systémových protokolů, které zaznamenávají události vyplývající z částí infrastruktury, jako je webový server. Zprávy textového protokolu jsou často navržené tak, aby byly čitelné pro člověka, ale měly by být napsané také ve formátu, který umožňuje automatizovanému systému snadno analyzovat je.

Měli byste také kategorizovat protokoly. Nezapisujte všechna data trasování do jednoho protokolu, ale použijte samostatné protokoly k zaznamenání výstupu trasování z různých provozních aspektů systému. Zprávy protokolu pak můžete rychle filtrovat čtením z příslušného protokolu a nemusíte zpracovávat jeden dlouhý soubor. Nikdy nezapisujte informace, které mají různé požadavky na zabezpečení (například informace o auditu a ladicí data) do stejného protokolu.

Poznámka:

Protokol může být implementován jako soubor v systému souborů nebo se může uchovávat v jiném formátu, například objekt blob v úložišti objektů blob. Informace protokolu se můžou uchovávat také ve strukturovanějším úložišti, například v řádcích v tabulce.

Metriky jsou obecně míra nebo počet některých aspektů nebo prostředků v systému v určitém okamžiku s jednou nebo více přidruženými značkami nebo dimenzemi (někdy označovanými jako ukázka). Jedna instance metriky obvykle není užitečná izolovaně. Místo toho je potřeba zaznamenávat metriky v průběhu času. Klíčovým problémem, který je potřeba vzít v úvahu, je to, které metriky byste měli zaznamenávat a jak často. Generování dat pro metriky může příliš často znamenat významné dodatečné zatížení systému, zatímco zachytávání metrik může způsobit, že vynecháte okolnosti, které vedou k významné události. Aspekty se liší od metriky po metriku. Například využití procesoru na serveru může kolísat od sekundy po sekundu, ale vysoké využití se stává starostí pouze v případě, že trvá několik minut.

Informace o korelaci dat

Můžete snadno monitorovat jednotlivé čítače výkonu na úrovni systému, zaznamenávat metriky pro prostředky a získávat informace o trasování aplikací z různých souborů protokolů. Některé formy monitorování ale vyžadují, aby fáze analýzy a diagnostiky v kanálu monitorování korelovala data načtená z několika zdrojů. Tato data mohou mít v nezpracovaných datech několik forem a proces analýzy musí být k dispozici s dostatečnými daty instrumentace, aby bylo možné tyto různé formuláře mapovat. Například na úrovni architektury aplikace může být úloha identifikována ID vlákna. V rámci aplikace může být stejná práce přidružená k ID uživatele, který tuto úlohu provádí.

Také není pravděpodobné, že by mezi vlákny a požadavky uživatelů bylo mapování 1:1, protože asynchronní operace můžou opakovaně používat stejná vlákna k provádění operací jménem více uživatelů. Kvůli dalšímu komplikování důležitých věcí může jeden požadavek zpracovat více než jedno vlákno, protože provádění prochází systémem. Pokud je to možné, přidružte každý požadavek k jedinečnému ID aktivity, které se šíří v systému jako součást kontextu požadavku. (Technika generování a zahrnutí ID aktivit v informacích o trasování závisí na technologii, která se používá k zachycení dat trasování.)

Všechna data monitorování by měla být časového razítka stejná. Pro konzistenci zaznamenejte všechna data a časy pomocí koordinovaného univerzálního času. To vám pomůže snadněji sledovat posloupnosti událostí.

Poznámka:

Počítače fungující v různých časových pásmech a sítích nemusí být synchronizované. Nespoléhejte na použití časových razítek pouze pro korelaci dat instrumentace, která pokrývají více počítačů.

Informace, které se mají zahrnout do dat instrumentace

Při rozhodování o tom, která data instrumentace potřebujete shromáždit, zvažte následující body:

• Ujistěte se, že informace zachycené událostmi trasování jsou strojově a lidské čitelné. K usnadnění automatizovaného zpracování dat protokolů napříč systémy a zajištění konzistence provozním a technickým pracovníkům, kteří protokoly čtou, osvojte si dobře definovaná schémata pro tyto informace. Uveďte informace o prostředí, jako je prostředí nasazení, počítač, na kterém je proces spuštěný, podrobnosti procesu a zásobník volání.

• Profilaci povolte pouze v případě potřeby, protože může v systému představovat významnou režii. Profilace pomocí instrumentace zaznamenává událost (například volání metody) při každém výskytu, zatímco vzorkování zaznamenává pouze vybrané události. Výběr může být založený na čase (jednou za n sekund) nebo na základě frekvence (jednou za každých n požadavků). Pokud dojde k událostem velmi často, může profilace instrumentací způsobit příliš velkou zátěž a sama o sobě ovlivnit celkový výkon. V takovém případě může být vhodnější přístup k vzorkování. Pokud je však frekvence událostí nízká, může je vzorkování vynechat. V tomto případě by instrumentace mohla být lepším přístupem.

• Poskytněte dostatečný kontext, který umožní vývojáři nebo správci určit zdroj jednotlivých požadavků. Může to zahrnovat určitou formu ID aktivity, která identifikuje konkrétní instanci požadavku. Může také obsahovat informace, které lze použít ke korelaci této aktivity s výpočetní prací provedenou a použitými prostředky. Tato práce může překračovat hranice procesů a počítačů. Pro měření by měl kontext zahrnovat (přímo nebo nepřímo prostřednictvím jiných korelovaných informací) odkaz na zákazníka, který žádost způsobil. Tento kontext poskytuje cenné informace o stavu aplikace v době zachycení dat monitorování.

• Zaznamenejte všechny požadavky a umístění nebo oblasti, ze kterých se tyto požadavky provádějí. Tyto informace vám můžou pomoct při určování, jestli existují nějaká aktivní místa specifická pro polohu. Tyto informace můžou být užitečné také při určování, jestli se má aplikace znovu rozdílit, nebo data, která používá.

• Zaznamenejte a pečlivě zaznamenejte podrobnosti o výjimkách. Důležité informace o ladění se často ztratí v důsledku špatného zpracování výjimek. Zachyťte úplné podrobnosti o výjimkách, které aplikace vyvolá, včetně jakýchkoli vnitřních výjimek a dalších kontextových informací. Pokud je to možné, zahrňte zásobník volání.

• Buďte konzistentní v datech, která zachycují různé prvky aplikace, protože to může pomoct při analýze událostí a jejich korelaci s požadavky uživatelů. Zvažte použití komplexního a konfigurovatelného balíčku protokolování ke shromažďování informací místo toho, aby vývojáři přijali stejný přístup jako implementovali různé části systému. Shromážděte data z klíčových čítačů výkonu, jako je objem provedených vstupně-výstupních operací, využití sítě, počet požadavků, využití paměti a využití procesoru. Některé služby infrastruktury mohou poskytovat vlastní specifické čítače výkonu, například počet připojení k databázi, rychlost provádění transakcí a počet transakcí, které jsou úspěšné nebo neúspěšné. Aplikace můžou také definovat vlastní specifické čítače výkonu.

• Protokolujte všechna volání externích služeb, jako jsou databázové systémy, webové služby nebo jiné služby na úrovni systému, které jsou součástí infrastruktury. Zaznamenává informace o době potřebné k provedení každého volání a o úspěchu nebo selhání hovoru. Pokud je to možné, zachyťte informace o všech pokusech o opakování a selháních všech přechodných chyb, ke kterým dochází.

Zajištění kompatibility se systémy telemetrie

V mnoha případech se informace, které instrumentace vytváří, generují jako řadu událostí a předávají se samostatnému systému telemetrie pro účely zpracování a analýzy. Telemetrický systém je obvykle nezávislý na jakékoli konkrétní aplikaci nebo technologii, ale očekává, že informace budou následovat podle konkrétního formátu, který je obvykle definován schématem. Schéma efektivně určuje kontrakt, který definuje datová pole a typy, které může ingestovat telemetrický systém. Schéma by mělo být generalizováno tak, aby umožňovalo data přicházející z celé řady platforem a zařízení.

Společné schéma by mělo obsahovat pole, která jsou společná pro všechny události instrumentace, jako je název události, čas události, IP adresa odesílatele a podrobnosti potřebné pro korelaci s jinými událostmi (například ID uživatele, ID zařízení a ID aplikace). Mějte na paměti, že jakýkoli počet zařízení může vyvolat události, takže schéma by nemělo záviset na typu zařízení. Kromě toho mohou různá zařízení vyvolat události pro stejnou aplikaci; aplikace může podporovat roaming nebo jinou formu distribuce mezi zařízeními.

Schéma může také zahrnovat pole domény, která jsou relevantní pro konkrétní scénář, který je společný v různých aplikacích. Může se jednat o informace o výjimkách, událostech spuštění a ukončení aplikace a o úspěchu nebo selhání volání rozhraní API webové služby. Všechny aplikace, které používají stejnou sadu polí domény, by měly generovat stejnou sadu událostí, což umožňuje sestavit sadu běžných sestav a analýz.

Schéma může nakonec obsahovat vlastní pole pro zaznamenání podrobností událostí specifických pro aplikaci.

Osvědčené postupy pro instrumentaci aplikací

Následující seznam shrnuje osvědčené postupy instrumentace distribuované aplikace spuštěné v cloudu.

• Usnadnit čtení a snadno analyzovat protokoly. Pokud je to možné, používejte strukturované protokolování. Buďte struční a popisní ve zprávách protokolu.

• Ve všech protokolech identifikujte zdroj a zadejte informace o kontextu a časování při zápisu každého záznamu protokolu.

• Pro všechna časová razítka použijte stejné časové pásmo a formát. To pomáhá korelovat události pro operace, které zahrnují hardware a služby spuštěné v různých geografických oblastech.

• Kategorizuje protokoly a zapisuje zprávy do příslušného souboru protokolu.

• Nezveřejňujte citlivé informace o systému nebo osobních údajích o uživatelích. Tyto informace před zaprotokolovanými daty vyčistíte, ale ujistěte se, že jsou zachovány příslušné podrobnosti. Odeberte například ID a heslo z libovolného připojovacího řetězce databáze, ale zapište zbývající informace do protokolu, aby analytik mohl určit, že systém přistupuje ke správné databázi. Protokolujte všechny kritické výjimky, ale povolte správci zapnout a vypnout protokolování pro nižší úrovně výjimek a upozornění. Zachyťte a zaznamenejte také všechny informace logiky opakování. Tato data můžou být užitečná při monitorování přechodného stavu systému.

• Trasování volání mimo proces, jako jsou požadavky na externí webové služby nebo databáze.

• Nekombinujte zprávy protokolu s různými požadavky na zabezpečení ve stejném souboru protokolu. Například do stejného protokolu nezapisujte informace o ladění a auditu.

• S výjimkou událostí auditování se ujistěte, že všechna volání protokolování jsou operace aktivované a zapomenuté, které neblokují průběh obchodních operací. Události auditování jsou výjimečné, protože jsou pro firmu klíčové a dají se klasifikovat jako základní součást obchodních operací.

• Ujistěte se, že je protokolování rozšiřitelné a nemá žádné přímé závislosti na konkrétním cíli. Například místo psaní informací pomocí System.Diagnostics.Trace definujte abstraktní rozhraní (například ILogger), které zveřejňuje metody protokolování a které je možné implementovat prostřednictvím libovolných vhodných prostředků.

• Ujistěte se, že veškeré protokolování je bezpečné a nikdy neaktivuje žádné kaskádové chyby. Protokolování nesmí vyvolat žádné výjimky.

• Zacházejte s instrumentací jako s probíhajícím iterativním procesem a pravidelně kontrolujte protokoly, nejen v případě problému.

Shromažďování a ukládání dat

Fáze shromažďování procesu monitorování se zabývá načtením informací, které instrumentace generuje, formátováním těchto dat, aby se usnadnila spotřeba fáze analýzy/diagnostiky a uložení transformovaných dat do spolehlivého úložiště. Data instrumentace shromážděná z různých částí distribuovaného systému se dají uchovávat v různých umístěních a s různými formáty. Kód aplikace může například generovat soubory protokolu trasování a generovat data protokolu událostí aplikace, zatímco čítače výkonu, které monitorují klíčové aspekty infrastruktury, kterou vaše aplikace používá, je možné zachytit prostřednictvím jiných technologií. Jakékoli komponenty a služby třetích stran, které vaše aplikace používá, můžou poskytovat informace instrumentace v různých formátech pomocí samostatných trasovacích souborů, úložiště objektů blob nebo dokonce vlastního úložiště dat.

Shromažďování dat se často provádí prostřednictvím služby shromažďování dat, která může běžet samostatně z aplikace, která generuje data instrumentace. Obrázek 2 znázorňuje příklad této architektury a zvýrazňuje subsystém shromažďování dat instrumentace.

Obrázek 2 – Shromažďování dat instrumentace

Toto je zjednodušené zobrazení. Služba sběru nemusí být nutně jediným procesem a může obsahovat mnoho komponent běžících na různých strojích, jak je popsáno v následujících částech. Kromě toho, pokud je potřeba rychle provést analýzu některých telemetrických dat (horká analýza, jak je popsáno v části Podpora horké, teplé a studené analýzy dále v tomto dokumentu), mohou místní komponenty, které pracují mimo službu shromažďování, provádět úlohy analýzy okamžitě. Obrázek 2 znázorňuje tuto situaci u vybraných událostí. Po analytickém zpracování je možné výsledky odeslat přímo do subsystému vizualizace a upozorňování. Data, která jsou předmětem teplé nebo studené analýzy, se uchovávají v úložišti, zatímco čeká na zpracování.

Pro aplikace a služby Azure poskytuje Azure Diagnostics jedno z možných řešení pro zachytávání dat. Azure Diagnostics shromažďuje data z následujících zdrojů pro každý výpočetní uzel, agreguje je a pak je nahraje do Služby Azure Storage:

• Protokoly služby IIS
• Protokoly neúspěšných žádostí služby IIS
• Protokoly událostí Windows
• Čítače výkonu
• Soubory se záznamem o selhání
• Protokolů infrastruktury Azure Diagnostics
• Vlastní protokoly chyb
• Zdroj událostí .NET
• Trasování událostí pro Windows na základě manifestu

Další informace najdete v článku Azure: Základy telemetrie a řešení potíží.

Strategie shromažďování dat instrumentace

Vzhledem k elastické povaze cloudu a abyste se vyhnuli nutnosti ručního načítání telemetrických dat z každého uzlu v systému, měli byste zajistit přenos dat do centrálního umístění a konsolidovat. V systému, který zahrnuje více datacenter, může být užitečné nejprve shromažďovat, konsolidovat a ukládat data v jednotlivých oblastech a pak agregovat regionální data do jednoho centrálního systému.

Pokud chcete optimalizovat využití šířky pásma, můžete se rozhodnout přenášet méně urgentní data v blocích jako dávky. Data však nesmí být zpožděna na neomezenou dobu, zejména pokud obsahují informace citlivé na čas.

Načítání a nabízení dat instrumentace

Subsystém shromažďování dat instrumentace může aktivně načítat data instrumentace z různých protokolů a dalších zdrojů pro každou instanci aplikace ( model vyžádání obsahu). Nebo může fungovat jako pasivní přijímač, který čeká na odeslání dat ze součástí, které tvoří každou instanci aplikace ( model push).

Jedním z přístupů k implementaci modelu vyžádání obsahu je použití agentů monitorování, které běží místně s každou instancí aplikace. Agent monitorování je samostatný proces, který pravidelně načítá telemetrická data shromážděná v místním uzlu a zapisuje tyto informace přímo do centralizovaného úložiště, které všechny instance sdílené aplikace. Jedná se o mechanismus, který Azure Diagnostics implementuje. Každou instanci webové role Azure nebo role pracovního procesu je možné nakonfigurovat tak, aby zaznamenávala diagnostické a další informace trasování, které jsou uložené místně. Agent monitorování, který běží společně s jednotlivými instancemi, kopíruje zadaná data do služby Azure Storage. Další podrobnosti o tomto procesu najdete v článku Povolení diagnostiky ve službách Azure Cloud Services a Virtual Machines . Některé prvky, jako jsou protokoly SLUŽBY IIS, výpisy stavu systému a vlastní protokoly chyb, se zapisují do úložiště objektů blob. Data z protokolu událostí Systému Windows, událostí pro Windows a čítačů výkonu se zaznamenávají v úložišti tabulek. Tento mechanismus znázorňuje obrázek 3.

Obrázek 3 – Použití monitorovacího agenta k vyžádání informací a zápisu do sdíleného úložiště

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. Příkladem jsou informace ze zobrazení dynamické správy SQL Serveru nebo délky fronty služby Azure Service Bus.

Je možné použít právě popsaný přístup k ukládání telemetrických dat pro malou aplikaci běžící na omezeném počtu uzlů v jednom umístění. Složitá, vysoce škálovatelná globální cloudová aplikace může generovat obrovské objemy dat ze stovek webových rolí a rolí pracovních procesů, horizontálních oddílů databáze a dalších služeb. Tato záplava dat může snadno zahltit šířku pásma vstupně-výstupních operací dostupnou v jediném centrálním umístění. Proto musí být vaše řešení telemetrie škálovatelné, aby nebylo možné ho při rozšiřování systému považovat za kritické body. V ideálním případě by vaše ř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 se část systému nezdaří.

Pokud chcete tyto problémy vyřešit, můžete implementovat řazení do front, jak je znázorněno na obrázku 4. V této architektuře místní agent monitorování (pokud je možné ho správně nakonfigurovat) nebo vlastní služba shromažďování dat (pokud ne) publikuje data do fronty. Samostatný proces spuštěný asynchronně (služba zápisu do úložiště na obrázku 4) přebírá data v této frontě a zapisuje je do sdíleného úložiště. Fronta zpráv je vhodná pro tento scénář, protože poskytuje sémantiku „alespoň jednou“, což pomáhá zajistit, aby se data zařazená do fronty po publikování neztratila. Službu zápisu do úložiště můžete implementovat pomocí samostatné role pracovního procesu.

Obrázek 4 – Použití fronty k ukládání dat instrumentace do vyrovnávací paměti

Místní služba shromažďování dat může přidávat data do fronty hned po přijetí. Fronta funguje jako vyrovnávací paměť a služba zápisu do úložiště může načítat a zapisovat data vlastním tempem. Fronta ve výchozím nastavení funguje jako první. Pokud ale zprávy obsahují data, která se musí zpracovávat rychleji, můžete je upřednostnit a urychlit je ve frontě. Další informace najdete v modelu Prioritní fronta. Případně můžete použít různé kanály (například témata služby Service Bus) k směrování dat do různých cílů v závislosti na požadované formě analytického zpracování.

Kvůli škálovatelnosti můžete spustit více instancí služby zápisu do úložiště. Pokud existuje velký objem událostí, můžete pomocí centra událostí odesílat data do různých výpočetních prostředků pro zpracování a úložiště.

Konsolidace dat instrumentace

Data instrumentace, která služba shromažďování dat načítá z jedné instance aplikace, poskytují lokalizované zobrazení stavu a výkonu dané instance. Aby bylo možné vyhodnotit celkový stav systému, je nutné konsolidovat některé aspekty dat v místních zobrazeních. Můžete to provést po uložení dat, ale v některých případech je můžete dosáhnout také při shromažďování dat. Místo přímého zápisu do sdíleného úložiště mohou data instrumentace projít samostatnou službou konsolidace dat, která kombinuje data a funguje jako proces filtrování a čištění. Například data instrumentace, která obsahují stejné informace o korelaci, jako je ID aktivity, mohou být amalgamated. (Je možné, že uživatel začne provádět obchodní operaci na jednom uzlu a pak se v případě selhání uzlu přenese do jiného uzlu nebo v závislosti na konfiguraci vyrovnávání zatížení.) Tento proces může také detekovat a odebírat duplicitní data (vždy možnost, pokud služba telemetrie používá fronty zpráv k odesílání dat instrumentace do úložiště). Obrázek 5 znázorňuje příklad této struktury.

Obrázek 5 – Konsolidace a vyčištění dat instrumentace pomocí samostatné služby

Ukládání dat instrumentace

Předchozí diskuze znázorňují spíše zjednodušený pohled na způsob ukládání dat instrumentace. Ve skutečnosti může dávat smysl ukládat různé typy informací pomocí technologií, které jsou nejvhodnější pro způsob, jakým bude každý typ pravděpodobně použit.

Úložiště objektů blob a tabulek Azure má například určité podobnosti v tom, jakým způsobem se k nim přistupuje. Mají ale omezení v operacích, které můžete provádět jejich použitím, a členitost uložených dat se liší. 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. Například:

• Data čítačů výkonu se dají uložit do SQL databáze, která umožňuje analýzu ad hoc.
• Protokoly trasování můžou být lépe uložené ve službě Azure Cosmos DB.
• Informace o zabezpečení se dají zapsat do HDFS.
• Informace, které vyžadují fulltextové vyhledávání, je možné ukládat prostřednictvím Elasticsearch (což může také urychlit vyhledávání pomocí bohatého indexování).

Můžete implementovat další službu, která pravidelně načítá data ze sdíleného úložiště, oddílů a filtruje data podle jejich účelu, a pak je zapíše do příslušné sady úložišť dat, jak je znázorněno na obrázku 6. 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 v případě potřeby umožňuje alespoň některé dělené data vygenerovat v případě potřeby (v závislosti na tom, kolik dat se uchovává ve sdíleném úložišti). Využívá ale 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.

Obrázek 6 – Dělení dat podle požadavků na analytické úložiště a úložiště

Stejná data instrumentace se můžou dát využít k více účelům. Čítače výkonu lze například použít 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 mohou být stejná data odeslána do více než jednoho cíle, jako je databáze dokumentů, která může fungovat jako dlouhodobé úložiště pro uchovávání fakturačních údajů, a multidimenzionální úložiště pro zpracování komplexní analýzy výkonu.

Měli byste také zvážit, jak jsou data naléhavě nutná. Data, která poskytují informace pro upozorňování, 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á za účelem optimalizace dotazů, které systém upozornění provádí. V některých případech může být nutné, aby služba telemetrie, která shromažďuje data v každém uzlu, aby data naformátovála a uložila místně, aby vás místní instance systému upozornění mohla rychle informovat o jakýchkoli problémech. 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.

Informace, které se používají pro více zvažované analýzy, vytváření sestav a zjišťování historických trendů, jsou méně naléhavé a mohou být uloženy způsobem, který podporuje dolování dat a ad hoc dotazy. Další informace najdete v části Podpora horké, teplé a studené analýzy dále v tomto dokumentu.

Obměně protokolů a uchovávání dat

Instrumentace může generovat značné objemy dat. Tato data se dají uchovávat na několika místech, počínaje nezpracovanými soubory protokolu, trasovacími soubory a dalšími informacemi zachycenými v každém uzlu do konsolidovaného, vyčištěného a děleného zobrazení těchto dat uložených ve sdíleném úložišti. V některých případech je možné po zpracování a přenosu dat z každého uzlu odebrat původní nezpracovaná zdrojová data. V jiných případech může být nutné nebo jednoduše užitečné uložit nezpracované informace. Například data generovaná pro účely ladění můžou být nejlépe ponechána v nezpracované podobě, ale pak je možné je rychle zahodit po opravě všech chyb.

Data o výkonu mají často delší životnost, aby je bylo možné 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. 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 účely auditování a zabezpečení musí být také archivovány a uloženy. Tato data jsou také citlivá a může být nutné je zašifrovat nebo jinak chránit, aby se zabránilo manipulaci. Nikdy byste neměli zaznamenávat hesla uživatelů ani jiné informace, které by mohly být použity k podvodu s identitou. Tyto podrobnosti by se měly před uložením vydržovat z dat.

Vzorkování mimo provoz

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ůže být možné data snížit tak, aby se snížila jejich rozlišení a ušetřily 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.

Osvědčené postupy pro shromažďování a ukládání informací o protokolování

Následující seznam shrnuje osvědčené postupy pro zachytávání a ukládání informací o protokolování:

• Agent monitorování nebo služba shromažďování dat by měly běžet jako služba mimo zpracování a měla by být jednoduchá k nasazení.

• Veškerý výstup z agenta monitorování nebo služby shromažďování dat by měl být nezávislý formát, 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. Použití standardního formátu umožňuje systému vytvářet kanály zpracování; komponenty, které čtou, transformují a odesílají data ve schváleném formátu, je možné snadno integrovat.

• Proces monitorování a shromažďování dat musí být bezpečný a nesmí aktivovat žádné kaskádové chybové podmínky.

• V případě přechodného selhání při odesílání informací do jímky dat by měl být agent monitorování nebo služba shromažďování dat připraveny změnit pořadí telemetrických dat tak, aby se nejdříve odesílaly nejnovější informace. (Agent monitorování nebo služba shromažďování dat se může rozhodnout, že starší data zahodí, nebo je uloží místně a později je přenese, aby se dohodila podle vlastního uvážení.)

Analýza dat a diagnostika problémů

Důležitou součástí procesu monitorování a diagnostiky je analýza shromážděných dat, aby získala přehled o celkové pohodě systému. Měli byste definovat vlastní klíčové ukazatele výkonu a metriky výkonu a je důležité pochopit, jak můžete strukturovat data shromážděná tak, aby splňovala vaše požadavky analýzy. Je také důležité pochopit, jak data zachycená v různých metrikách a souborech protokolů korelují, protože tyto informace můžou být klíčem ke sledování posloupnosti událostí a k diagnostice problémů, které nastanou.

Jak je popsáno v části Konsolidace dat instrumentace, data pro každou část systému se obvykle zaznamenávají místně, ale obvykle je potřeba je kombinovat s daty generovanými v jiných lokalitách, které se účastní systému. Tyto informace vyžadují pečlivou korelaci, aby bylo zajištěno, že se data zkombinují přesně. Například data o využití pro operaci můžou zahrnovat uzel, který je hostitelem webu, ke kterému se uživatel připojí, uzel, který spouští samostatnou službu, ke které se přistupuje v rámci této operace, a úložiště dat uchovávané na jiném uzlu. Tyto informace musí být svázané, aby poskytovaly celkový přehled o využití prostředků a zpracování operace. Některé předběžné zpracování a filtrování dat mohou na uzlu, na kterém jsou data zachycena, zatímco agregace a formátování se pravděpodobně vyskytují na centrálním uzlu.

Podpora horké, teplé a studené analýzy

Analýza a přeformátování dat pro účely vizualizace, vytváření sestav a upozorňování může být složitý proces, který využívá vlastní sadu prostředků. Některé formy monitorování jsou časově kritické a vyžadují okamžitou analýzu dat, aby byla efektivní. Tato analýza se označuje jako horká analýza. Mezi příklady patří analýzy, které jsou potřeba k upozorňování, a některé aspekty monitorování zabezpečení (například zjišťování útoku na systém). Data potřebná pro tyto účely musí být rychle dostupná a strukturovaná pro efektivní zpracování. V některých případech může být nutné přesunout zpracování analýzy do jednotlivých uzlů, kde se data uchovávají.

Jiné formy analýzy jsou méně časově kritické a můžou vyžadovat určité výpočty a agregaci po přijetí nezpracovaných dat. Tomu se říká teplá analýza. Analýza výkonu často spadá do této kategorie. V tomto případě izolovaná jedna událost výkonu pravděpodobně nebude statisticky významná. (Příčinou může být náhlé špičky nebo závada.) Data z řady událostí by měla poskytovat spolehlivější přehled o výkonu systému.

K diagnostice problémů se stavem je možné použít také teplou analýzu. Událost stavu se obvykle zpracovává prostřednictvím horké analýzy a může okamžitě vyvolat výstrahu. Operátor by měl být schopný přejít k podrobnostem důvodů události stavu prozkoumáním dat z teplé cesty. Tato data by měla obsahovat informace o událostech, které vedou k problému, který způsobil událost stavu.

Některé typy monitorování generují dlouhodobé data. Tuto analýzu je možné provést později, pravděpodobně podle předdefinovaného plánu. V některých případech může analýza potřebovat komplexní filtrování velkých objemů dat zachycených v určitém časovém období. To se nazývá studená analýza. Klíčovým požadavkem je, aby se data po zachycení bezpečně ukládaly. Například monitorování a auditování využití vyžaduje přesný přehled o stavu systému v pravidelných bodech v čase, ale tyto informace o stavu nemusí být k dispozici ke zpracování okamžitě po shromáždění.

Operátor může také použít studenou analýzu k poskytování dat pro prediktivní analýzu stavu. Operátor může shromažďovat historické informace za určité období a používat je ve spojení s aktuálními daty o stavu (načtenými z horké cesty) k zjišťování trendů, které by mohly brzy způsobit problémy se stavem. V těchto případech může být nutné vyvolat výstrahu, aby bylo možné provést nápravnou akci.

Korelace dat

Data, která instrumentace zachycuje, můžou poskytnout snímek stavu systému, ale účelem analýzy je zajistit, aby tato data byla užitečná. Například:

• Co způsobilo intenzivní načítání vstupně-výstupních operací na úrovni systému v určitém čase?
• Jedná se o výsledek velkého počtu databázových operací?
• Odráží se to v době odezvy databáze, počtu transakcí za sekundu a doby odezvy aplikace ve stejné době?

Pokud ano, může být jedním nápravnými akcemi, které by mohly snížit zatížení, horizontálním dělením dat na více serverů. Kromě toho může dojít k výjimkám v důsledku chyby v jakékoli úrovni systému. Výjimka na jedné úrovni často aktivuje jinou chybu na výše uvedené úrovni.

Z těchto důvodů musíte být schopni korelovat různé typy dat monitorování na jednotlivých úrovních, abyste vytvořili celkový přehled o stavu systému a aplikacích, které na nich běží. Tyto informace pak můžete použít k rozhodování o tom, jestli systém funguje přijatelně nebo ne, a určit, co se dá udělat, aby se zlepšila kvalita systému.

Jak je popsáno v části Informace o korelaci dat, musíte zajistit, aby nezpracovaná data instrumentace obsahovala dostatečné informace o kontextu a ID aktivity pro podporu požadovaných agregací pro korelace událostí. Tato data se navíc můžou uchovávat v různých formátech a může být nutné tyto informace analyzovat, aby byly převedeny do standardizovaného formátu pro analýzu.

Řešení potíží a diagnostika problémů

Diagnostika vyžaduje schopnost určit příčinu chyb nebo neočekávané chování, včetně provádění analýzy původní příčiny. Mezi požadované informace obvykle patří:

• Podrobné informace z protokolů událostí a trasování, a to buď pro celý systém, nebo pro zadaný subsystém během zadaného časového intervalu.
• Kompletní trasování zásobníku vyplývající z výjimek a chyb jakékoli zadané úrovně, ke které dochází v systému nebo zadaném subsystému během zadaného období.
• Výpisy stavu systému pro všechny neúspěšné procesy buď kdekoli v systému, nebo v zadaném subsystému během zadaného časového intervalu.
• Protokoly aktivit zaznamenávají operace prováděné všemi uživateli nebo pro vybrané uživatele během zadaného období.

Analýza dat pro účely řešení potíží často vyžaduje hluboké technické znalosti architektury systému a různých komponent, které řešení tvoří. V důsledku toho se často vyžaduje velký stupeň ručního zásahu k interpretaci dat, stanovení příčin problémů a doporučení vhodné strategie k jejich opravě. Může být vhodné jednoduše uložit kopii těchto informací v původním formátu a zpřístupnit ji pro studenou analýzu odborníkem.

Vizualizace dat a vyvolávání výstrah

Důležitým aspektem jakéhokoli monitorovacího systému je schopnost prezentovat data takovým způsobem, aby operátor mohl rychle odhalit trendy nebo problémy. Důležité je také schopnost rychle informovat operátora, pokud došlo k významné události, která může vyžadovat pozornost.

Prezentace dat může mít několik forem, včetně vizualizace pomocí řídicích panelů, upozorňování a vytváření sestav.

Vizualizace pomocí řídicích panelů

Nejběžnějším způsobem vizualizace dat je použití řídicích panelů, které můžou zobrazovat informace jako řadu grafů, grafů nebo jiné ilustrace. Tyto položky lze parametrizovat a analytik by měl mít možnost vybrat důležité parametry (například časové období) pro každou konkrétní situaci.

Řídicí panely je možné uspořádat hierarchicky. Řídicí panely nejvyšší úrovně můžou poskytnout celkový přehled o jednotlivých aspektech systému, ale operátor může přejít k podrobnostem. Například řídicí panel, který znázorňuje celkové vstupně-výstupní operace disku pro systém, by měl analytikům umožnit zobrazit sazby vstupně-výstupních operací pro každý jednotlivý disk a zjistit, jestli jedno nebo více konkrétních zařízení představuje nepřiměřený objem provozu. V ideálním případě by měl řídicí panel zobrazovat také související informace, jako je zdroj každého požadavku (uživatel nebo aktivita), který generuje tento vstupně-výstupní operace. Tyto informace se pak dají použít k určení, jestli (a jak) rovnoměrněji rozložit zatížení mezi zařízení a jestli by systém fungoval lépe, kdyby bylo přidáno více zařízení.

Řídicí panel může také použít barevné kódování nebo jiné vizuální pomůcky k označení hodnot, které se zobrazují neobvykle nebo které jsou mimo očekávaný rozsah. Použití předchozího příkladu:

• Disk s rychlostí vstupně-výstupních operací, která se blíží maximální kapacitě v delším období (horký disk), je možné zvýraznit červeně.
• Disk s rychlostí vstupně-výstupních operací, která se pravidelně spouští na maximálním limitu v krátkých obdobích (teplý disk), je možné zvýraznit žlutě.
• Disk, který vykazuje normální využití, se dá zobrazit zeleně.

Aby systém řídicího panelu fungoval efektivně, musí mít nezpracovaná data, se kterými může pracovat. Pokud vytváříte vlastní systém řídicích panelů nebo používáte řídicí panel vyvinutý jinou organizací, musíte pochopit, která data instrumentace potřebujete shromažďovat, na jaké úrovni členitosti a jak by měl řídicí panel využívat.

Kromě zobrazení informací také dobrý řídicí panel umožňuje analytikům klást otázky na tyto informace. Některé systémy poskytují nástroje pro správu, které může operátor použít k provádění těchto úloh a zkoumání podkladových dat. Případně v závislosti na úložišti, které se používají k uložení těchto informací, může být možné tato data dotazovat přímo nebo je importovat do nástrojů, jako je Microsoft Excel pro další analýzu a vytváření sestav.

Poznámka:

Přístup k řídicím panelům byste měli omezit na oprávněné pracovníky, protože tyto informace můžou být komerčně citlivé. Měli byste také chránit podkladová data pro řídicí panely, abyste uživatelům zabránili v jejich změně.

Vyvolávání výstrah

Upozorňování je proces analýzy dat monitorování a instrumentace a generování oznámení v případě zjištění významné události.

Upozorňování pomáhá zajistit, aby systém zůstal v pořádku, responzivní a zabezpečený. Je to důležitá součást každého systému, který uživatelům zaručuje výkon, dostupnost a ochranu osobních údajů, na kterých se data můžou okamžitě chovat. Operátor může být muset být upozorněn na událost, která výstrahu aktivovala. Výstrahy lze také použít k vyvolání systémových funkcí, jako je automatické škálování.

Upozorňování obvykle závisí na následujících datech instrumentace:

• Události zabezpečení. Pokud protokoly událostí naznačují, že dochází k opakovaným selháním ověřování nebo autorizace, může být systém napaden a operátor by měl být informován.
• Metriky výkonu: Systém musí rychle reagovat, pokud určitá metrika výkonu překročí zadanou prahovou hodnotu.
• Informace o dostupnosti Pokud se zjistí chyba, může být nutné rychle restartovat jeden nebo více subsystémů nebo provést převzetí služeb při selhání záložním prostředkem. Opakované chyby v subsystému můžou znamenat vážnější obavy.

Operátoři můžou dostávat informace o upozorněních pomocí mnoha kanálů doručování, jako jsou e-maily, zařízení se stránkovacím zařízením nebo sms textovou zprávou. Výstraha může také obsahovat informace o tom, jak kritická situace je. Řada systémů upozorňování podporuje skupiny odběratelů a všichni operátoři, kteří jsou členy stejné skupiny, můžou přijímat stejnou sadu výstrah.

Systém upozorňování by měl být přizpůsobitelný a příslušné hodnoty z podkladových dat instrumentace je možné zadat jako parametry. Tento přístup umožňuje operátorům filtrovat data a zaměřit se na tyto prahové hodnoty nebo kombinace hodnot, které jsou zajímavé. V některých případech je možné systému výstrah poskytnout nezpracovaná data instrumentace. V jiných situacích může být vhodnější zadat agregovaná data. (Upozornění se může aktivovat například v případě, že využití procesoru uzlu překročilo 90 procent za posledních 10 minut). Podrobnosti poskytované systému výstrah by také měly obsahovat všechny příslušné souhrnné a kontextové informace. Tato data můžou pomoct snížit možnost, že falešně pozitivní události zasílaly výstrahu.

Reportování

Reporting se používá ke generování celkového pohledu na systém. Kromě aktuálních informací může obsahovat historická data. Samotné požadavky na vytváření sestav spadají do dvou širokých kategorií: provozní vytváření sestav a generování sestav zabezpečení.

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

• Agregace statistik, které můžete použít k pochopení využití zdrojů celého systému nebo specifikovaných subsystémů během zadaného časového okna.
• Identifikace trendů ve využití zdrojů pro celý systém nebo specifikované 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 z hlediska nasazených prostředků 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í se zabývá sledováním využití systému zákazníky. Může zahrnovat:

• Auditování uživatelských operací To vyžaduje zaznamenávání jednotlivých požadavků, které každý uživatel provádí, spolu s daty a časy. Data by měla být strukturovaná tak, aby správce mohl rychle rekonstruovat posloupnost operací, které uživatel provádí v zadaném období.
• Sledování prostředků, které uživatel používá To vyžaduje zaznamenávání, jak každý požadavek pro uživatele přistupuje k různým prostředkům, které tvoří systém, a jak dlouho. Správce musí být schopen tato data použít k vygenerování sestavy využití uživatelem v zadaném 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.) V případě potřeby by ale měly být dostupné i pro generování ad hoc. 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.

Další kroky

• Přehled služby Azure Monitor
• Monitorování, diagnostika a řešení problémů s Microsoft Azure Storage
• Přehled upozornění v Microsoft Azure
• Zobrazení oznámení o stavu služby s využitím webu Azure Portal
• Co je Application Insights?
• Diagnostika výkonu pro virtuální počítače Azure
• Stáhněte a nainstalujte SQL Server Data Tools (SSDT) pro Visual Studio

Související prostředky

• Pokyny k automatickému škálování popisují, jak snížit režii správy snížením potřeby operátora průběžně monitorovat výkon systému a rozhodovat se o přidávání nebo odebírání prostředků.
• Model monitorování koncových bodů stavu popisuje, jak implementovat funkční kontroly v aplikaci, ke které mají externí nástroje přístup prostřednictvím vystavených koncových bodů v pravidelných intervalech.
• Model prioritní fronty ukazuje, jak určit prioritu zpráv zařazených do fronty, aby byly přijaté naléhavé žádosti a aby je bylo možné zpracovat před méně naléhavémi zprávami.

Distribuované aplikace a služby běžící v cloudu jsou podle své povahy komplexní části softwaru, které tvoří mnoho pohyblivých částí. V produkčním prostředí je důležité sledovat způsob, jakým uživatelé používají váš systém, sledovat využití prostředků a obecně monitorovat stav a výkon systému. Tyto informace můžete použít jako diagnostickou pomůcku k rozpoznání a opravě problémů a také k tomu, abyste si všimli potenciálních problémů a zabránili jejich výskytu.

Scénáře monitorování a diagnostiky

Monitorování můžete použít k získání přehledu o tom, jak dobře systém funguje. Monitorování je klíčovou součástí udržování cílů kvality služeb. Mezi běžné scénáře shromažďování dat monitorování patří:

• Zajištění, aby systém zůstal v pořádku.
• Sledování dostupnosti systému a jeho součástí
• Udržování výkonu, aby se zajistila neočekávaná propustnost systému při nárůstu objemu práce.
• Záruka, že systém splňuje všechny smlouvy o úrovni služeb (SLA) vytvořené se zákazníky.
• Ochrana soukromí a zabezpečení systému, uživatelů a jejich dat.
• Sledování operací prováděných pro účely auditování nebo právních předpisů
• Monitorování každodenního používání systému a sledování trendů, které můžou vést k problémům, pokud nejsou vyřešené.
• Sledování problémů, ke kterým dochází, od počátečních zpráv až po analýzu možných příčin, nápravy, následných aktualizací softwaru a nasazení.
• Operace trasování a ladění vydaných verzí softwaru

Poznámka:

Tento seznam není určen k tomu, aby byl vyčerpávající. Tento dokument se zaměřuje na tyto scénáře jako nejčastější situace pro provádění monitorování. Můžou existovat i jiné, které jsou méně časté nebo jsou specifické pro vaše prostředí.

Následující části popisují tyto scénáře podrobněji. Informace pro jednotlivé scénáře jsou popsány v následujícím formátu:

1. Stručný přehled scénáře
2. Typické požadavky tohoto scénáře.
3. Nezpracovaná data instrumentace, která jsou nutná k podpoře scénáře, a možné zdroje těchto informací.
4. Způsob analýzy a kombinování těchto nezpracovaných dat za účelem generování smysluplných diagnostických informací

Monitorování stavu

Systém je v pořádku, pokud je spuštěný a schopný zpracovávat požadavky. Účelem monitorování stavu je vygenerovat snímek aktuálního stavu systému, abyste mohli ověřit, že všechny součásti systému fungují podle očekávání.

Požadavky na monitorování stavu

Operátor by měl být rychle upozorněn (během několika sekund), pokud je některá část systému považována za špatnou. Operátor by měl být schopen zjistit, které části systému fungují normálně a které části mají problémy. Stav systému je možné zvýraznit prostřednictvím systému semaforu:

• Červená pro stav není v pořádku (systém se zastavil)
• Žlutá pro částečně v pořádku (systém běží se sníženou funkčností)
• Zelená pro zcela zdravé

Komplexní systém pro monitorování stavu umožňuje operátorovi přejít k podrobnostem systému a zobrazit stav subsystémů a komponent. Pokud je například celkový systém znázorněný jako částečně v pořádku, měl by být operátor schopný přiblížit a určit, které funkce jsou aktuálně nedostupné.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Nezpracovaná data potřebná k podpoře monitorování stavu se dají vygenerovat v důsledku:

• Trasování provádění uživatelských požadavků Tyto informace lze použít k určení, které požadavky byly úspěšné, které selhaly a jak dlouho trvá jednotlivé požadavky.
• Syntetické monitorování uživatelů. Tento proces simuluje kroky prováděné uživatelem a řídí se předdefinovanou řadou kroků. Výsledky jednotlivých kroků by se měly zachytit.
• Protokolování výjimek, chyb a upozornění Tyto informace je možné zachytit v důsledku příkazů trasování vložených do kódu aplikace a také načtení informací z protokolů událostí všech služeb, na které systém odkazuje.
• Monitorování stavu všech služeb třetích stran, které systém používá. Toto monitorování může vyžadovat načtení a analýzu dat o stavu, která tyto služby poskytují. Tyto informace můžou mít různé formáty.
• Monitorování koncových bodů Tento mechanismus je podrobněji popsán v části Monitorování dostupnosti.
• Shromažďování informací o okolním výkonu, jako je využití procesoru na pozadí nebo vstupně-výstupní aktivita (včetně sítě).

Analýza dat o stavu

Hlavním cílem monitorování stavu je rychle indikovat, jestli je systém spuštěný. Horká analýza okamžitých dat může aktivovat výstrahu, pokud se zjistí, že kritická komponenta není v pořádku. (Například nereaguje na po sobě jdoucí řadu příkazů ping.) Operátor pak může provést příslušnou nápravnou akci.

Pokročilejší systém může zahrnovat prediktivní prvek, který provádí studenou analýzu za posledních a aktuálních úloh. Studená analýza dokáže odhalit trendy a určit, jestli systém pravděpodobně zůstane v pořádku nebo jestli systém potřebuje další prostředky. Tento prediktivní prvek by měl být založený na důležitých metrikách výkonu, například:

• Rychlost požadavků směrovaných na každou službu nebo subsystém.
• Doby odezvy těchto požadavků.
• Objem dat, která se přetékají do a z každé služby.

Pokud hodnota jakékoli metriky překročí definovanou prahovou hodnotu, může systém vyvolat výstrahu, která operátorovi nebo automatickému škálování (pokud je k dispozici) umožnit provedení preventivních akcí nezbytných k zachování stavu systému. Tyto akce můžou zahrnovat přidání prostředků, restartování jedné nebo více služeb, které selhávají, nebo omezení požadavků s nižší prioritou.

Monitorování dostupnosti

Skutečně zdravý systém vyžaduje, aby byly dostupné komponenty a subsystémy, které systém tvoří. Monitorování dostupnosti úzce souvisí s monitorováním stavu. Zatímco monitorování stavu poskytuje okamžitý přehled o aktuálním stavu systému, monitorování dostupnosti se zabývá sledováním dostupnosti systému a jeho součástí za účelem generování statistik o době provozu systému.

V mnoha systémech jsou některé komponenty (například databáze) nakonfigurované s integrovanou redundancí, která umožňuje rychlé převzetí služeb při selhání v případě závažné chyby nebo ztráty připojení. V ideálním případě by uživatelé neměli vědět, že k takové chybě došlo. Z hlediska monitorování dostupnosti je ale nutné shromáždit co nejvíce informací o takových selháních, abyste zjistili příčinu a podnikli nápravné akce, aby se zabránilo jejich opakovanému opakování.

Data potřebná ke sledování dostupnosti můžou záviset na několika faktorech nižší úrovně. Mnoho z těchto faktorů může být specifické pro aplikaci, systém a prostředí. Efektivní monitorovací systém zaznamenává data o dostupnosti, která odpovídají těmto faktorům nízké úrovně, a pak je agreguje, aby získal celkový přehled o systému. Například v systému elektronického obchodování můžou obchodní funkce, které zákazníkovi umožňují zadávat objednávky, záviset na úložišti, kde jsou uloženy podrobnosti objednávky, a platební systém, který zpracovává peněžní transakce za platbu za tyto objednávky. Dostupnost části systému pro umísťování objednávek je proto funkcí dostupnosti úložiště a subsystému plateb.

Požadavky na monitorování dostupnosti

Operátor by měl mít také možnost zobrazit historickou dostupnost jednotlivých systémů a subsystémů a tyto informace použít ke sledování trendů, které by mohly způsobit pravidelné selhání jednoho nebo více subsystémů. (Začnou služby selhávat v konkrétní denní době, která odpovídá hodině zpracování ve špičce?)

Řešení monitorování by mělo poskytnout okamžitý a historický přehled o dostupnosti nebo nedostupnosti jednotlivých subsystémů. Měl by také být schopný rychle upozornit operátora, když jedna nebo více služeb selže nebo když se uživatelé nemůžou připojit ke službám. Jedná se nejen o monitorování jednotlivých služeb, ale také zkoumání akcí, které každý uživatel provede, pokud tyto akce selžou při pokusu o komunikaci se službou. V určitém rozsahu je míra selhání připojení normální a může být způsobená přechodnými chybami. Může ale být užitečné, aby systém mohl vyvolat upozornění na počet selhání připojení k zadanému subsystému, ke kterému dochází během určitého období.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Stejně jako u monitorování stavu je možné nezpracovaná data požadovaná k podpoře monitorování dostupnosti vygenerovat v důsledku syntetického monitorování uživatelů a protokolování všech výjimek, chyb a upozornění, ke kterým může dojít. Kromě toho je možné získat data o dostupnosti z monitorování koncových bodů. Aplikace může zveřejnit jeden nebo více koncových bodů stavu, přičemž každý testuje přístup k funkční oblasti v rámci systému. Monitorovací systém může každý koncový bod otestovat příkazem ping podle definovaného plánu a shromáždit výsledky (úspěch nebo selhání).

Všechny časové limity, chyby připojení k síti a pokusy o opakování připojení se musí zaznamenávat. Všechna data by měla být časová razítka.

Analýza dat o dostupnosti

Data instrumentace musí být agregovaná a korelovaná, aby podporovala následující typy analýz:

• Okamžitá dostupnost systému a subsystémů.
• Míra selhání dostupnosti systému a subsystémů. V ideálním případě by měl být operátor schopný korelovat selhání s konkrétními aktivitami: co se stalo, když došlo k selhání systému?
• Historický pohled na míru selhání systému nebo všech subsystémů v jakémkoli zadaném období a zatížení systému (například počet uživatelských požadavků), když došlo k selhání.
• Důvody nedostupnosti systému nebo jakýchkoli subsystémů Důvodem může být například neběžení služby, ztráta připojení, ztráta připojení, časový limit připojení a připojení, ale vrácení chyb.

Procentuální dostupnost služby můžete vypočítat v určitém časovém období pomocí následujícího vzorce:

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

To je užitečné pro účely smlouvy SLA. (Monitorování smluv SLA je podrobněji popsáno dále v těchto doprovodných materiálech.) Definice výpadků závisí na službě. Například Visual Studio Team Services Build Service definuje výpadek jako období (celkové kumulované minuty), během kterého je služba buildu nedostupná. Minuta se považuje za nedostupnou, pokud všechny průběžné požadavky HTTP na službu sestavení za účelem provádění operací iniciovaných zákazníkem během této minuty buď způsobí kód chyby, nebo nevrátí odpověď.

Monitorování výkonu

Vzhledem k tomu, že je systém více a více stresů (zvýšením objemu uživatelů), velikost datových sad, ke kterým tito uživatelé přistupují, roste a pravděpodobnost selhání jedné nebo více součástí bude pravděpodobnější. Často se selhání komponent předchází snížením výkonu. Pokud takové snížení dokážete zjistit, můžete proaktivně provést kroky k nápravě situace.

Výkon systému závisí na několika faktorech. Každý faktor se obvykle měří prostřednictvím klíčových ukazatelů výkonu (KPI), jako je počet databázových transakcí za sekundu nebo objem síťových požadavků, které se úspěšně obsluhují v zadaném časovém rámci. Některé z těchto klíčových ukazatelů výkonu můžou být k dispozici jako konkrétní míry výkonu, zatímco jiné můžou být odvozené z kombinace metrik.

Poznámka:

Určení špatného nebo dobrého výkonu vyžaduje, abyste pochopili úroveň výkonu, při které by měl být systém schopný běžet. To vyžaduje sledování systému, zatímco funguje v typickém zatížení a zaznamenává data pro každý klíčový ukazatel výkonu v určitém časovém období. To může zahrnovat spuštění systému pod simulovaným zatížením v testovacím prostředí a shromáždění příslušných dat před nasazením systému do produkčního prostředí.

Měli byste také zajistit, aby monitorování pro účely výkonu nezatěžuje systém. Možná budete moct dynamicky upravit úroveň podrobností pro data, která proces monitorování výkonu shromažďuje.

Požadavky na monitorování výkonu

Aby operátor prozkoumal výkon systému, obvykle potřebuje zobrazit informace, které zahrnují:

• Míra odpovědí pro požadavky uživatelů.
• Počet souběžných uživatelských požadavků.
• Objem síťového provozu.
• Sazby, za které jsou obchodní transakce dokončeny.
• Průměrná doba zpracování požadavků.

Může být také užitečné poskytnout nástroje, které operátorovi umožňují odhalit korelace, například:

• Počet souběžných uživatelů oproti latenci požadavků (jak dlouho trvá zahájení zpracování požadavku po odeslání žádosti).
• Počet souběžných uživatelů oproti průměrné době odezvy (jak dlouho trvá dokončení požadavku po zahájení zpracování).
• Objem požadavků versus počet chyb zpracování.

Kromě těchto informací o funkcích vysoké úrovně by měl být operátor schopný získat podrobné zobrazení výkonu pro každou komponentu v systému. Tato data se obvykle poskytují prostřednictvím čítačů výkonu nízké úrovně, které sledují informace, jako jsou:

• Využití paměti.
• Počet vláken
• Doba zpracování procesoru.
• Délka fronty požadavku.
• Rychlost a chyby vstupně-výstupních operací disku nebo sítě.
• Počet zapsaných nebo přečtených bajtů
• Indikátory middlewaru, jako je délka fronty.

Všechny vizualizace by měly operátorovi umožnit zadat časové období. Zobrazená data můžou být snímkem aktuální situace nebo historickým zobrazením výkonu.

Operátor by měl být schopen vyvolat výstrahu na základě jakékoli míry výkonu pro libovolnou zadanou hodnotu během libovolného zadaného časového intervalu.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Můžete shromažďovat data o výkonu vysoké úrovně (propustnost, počet souběžných uživatelů, počet obchodních transakcí, chybovosti atd.) monitorováním průběhu požadavků uživatelů při jejich doručení a průchodu systémem. To zahrnuje zahrnutí příkazů trasování v klíčových bodech kódu aplikace spolu s informacemi o načasování. Všechny chyby, výjimky a upozornění by měly být zachyceny s dostatečnými daty pro jejich korelaci s požadavky, které je způsobily. Dalším užitečným zdrojem je protokol Internetové informační služby (IIS).

Pokud je to možné, měli byste také zaznamenávat údaje o výkonu pro všechny externí systémy, které aplikace používá. Tyto externí systémy můžou poskytovat vlastní čítače výkonu nebo jiné funkce pro vyžádání dat o výkonu. Pokud to není možné, zaznamenejte informace, jako je počáteční čas a koncový čas každého požadavku provedeného v externím systému, spolu se stavem (úspěch, selhání nebo upozornění) operace. Můžete například použít přístup stopek k časovým žádostem: spuštění časovače při spuštění požadavku a zastavení časovače po dokončení požadavku.

Data o nízké úrovni výkonu pro jednotlivé komponenty v systému můžou být dostupná prostřednictvím funkcí a služeb, jako jsou čítače výkonu Windows a Diagnostika Azure.

Analýza dat o výkonu

Velká část analýzy se skládá z agregace dat o výkonu podle typu požadavku uživatele nebo subsystému nebo služby, do které se každý požadavek odesílá. Příkladem žádosti uživatele je přidání položky do nákupního košíku nebo provedení procesu rezervace v systému elektronického obchodování.

Dalším běžným požadavkem je shrnutí údajů o výkonu ve vybraných percentilech. Operátor může například určit dobu odezvy 99 procent požadavků, 95 procent požadavků a 70 procent požadavků. Pro každý percentil můžou být nastavené cíle SLA nebo jiné cíle. Probíhající výsledky by měly být hlášeny téměř v reálném čase, aby se pomohly odhalit okamžité problémy. Výsledky by se také měly agregovat po delší dobu pro statistické účely.

V případě problémů s latencí ovlivňujících výkon by měl být operátor schopný rychle identifikovat příčinu kritického bodu prozkoumáním latence každého kroku, který každý požadavek provádí. Údaje o výkonu proto musí poskytovat způsob korelace měr výkonu pro každý krok, aby je svážel s konkrétní žádostí.

V závislosti na požadavcích vizualizace může být užitečné vygenerovat a uložit datovou krychli, která obsahuje zobrazení nezpracovaných dat. Tato datová krychle umožňuje komplexní ad hoc dotazování a analýzu informací o výkonu.

Monitorování zabezpečení

Všechny komerční systémy, které obsahují citlivá data, musí implementovat strukturu zabezpečení. Složitost mechanismu zabezpečení je obvykle funkcí citlivosti dat. V systému, který vyžaduje ověření uživatelů, byste měli zaznamenat:

• Všechny pokusy o přihlášení bez ohledu na to, jestli selžou nebo uspěly.
• Všechny operace prováděné ověřeným uživatelem a podrobnosti o všech prostředcích, ke které má přístup.
• Když uživatel ukončí relaci a odhlásí se.

Monitorování může pomoct odhalit útoky na systém. Například velký počet neúspěšných pokusů o přihlášení může znamenat útok hrubou silou. Neočekávaný nárůst požadavků může být výsledkem distribuovaného útoku DDoS (Denial-of-Service). Musíte být připraveni monitorovat všechny požadavky na všechny prostředky bez ohledu na zdroj těchto požadavků. Systém, který má ohrožení zabezpečení přihlašování, může neúmyslně vystavit prostředky vnějšímu světu, aniž by uživatel musel skutečně přihlásit.

Požadavky na monitorování zabezpečení

Nejdůležitější aspekty monitorování zabezpečení by měly operátorovi umožnit rychlé:

• Zjištění pokusů o neoprávněná vniknutí neověřenou entitou
• Identifikujte pokusy entit o provádění operací s daty, pro která nebyl udělen přístup.
• Určete, jestli je systém nebo některá část systému pod útokem zvenčí nebo uvnitř. (Například škodlivý ověřený uživatel se může pokoušet systém snížit.)

Pro podporu těchto požadavků by měl být operátor upozorněn, pokud:

• Jeden účet provádí opakované neúspěšné pokusy o přihlášení během zadaného období.
• Jeden ověřený účet se během zadaného období opakovaně pokouší získat přístup k zakázanému prostředku.
• Během zadaného období dochází k velkému počtu neověřených nebo neautorizovaných požadavků.

Informace poskytnuté operátorovi by měly obsahovat adresu hostitele zdroje pro každý požadavek. Pokud porušení zabezpečení pravidelně vznikají z určitého rozsahu adres, můžou být tito hostitelé zablokovaní.

Klíčovou součástí udržování zabezpečení systému je schopnost rychle zjišťovat akce, které se odchylují od obvyklého vzoru. Informace, jako je počet neúspěšných nebo úspěšných žádostí o přihlášení, se dají vizuálně zobrazit, aby bylo možné zjistit, jestli v neobvyklé době dochází k prudkému nárůstu aktivity. (Příkladem této aktivity je přihlášení uživatelů v 3:00 a provádění velkého počtu operací, když pracovní den začíná v 9:00). Tyto informace lze použít také ke konfiguraci automatického škálování založeného na čase. Pokud například operátor zjistí, že se v konkrétní denní době pravidelně přihlašuje velký počet uživatelů, může operátor uspořádat další ověřovací služby pro zpracování objemu práce a po uplynutí špičky tyto další služby vypnout.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Zabezpečení je všezahrnující aspekt většiny distribuovaných systémů. Příslušná data se pravděpodobně generují v několika bodech v celém systému. Měli byste zvážit přijetí přístupu pro správu informací o zabezpečení a událostí (SIEM) ke shromáždění informací souvisejících se zabezpečením, které vyplývají z událostí vyvolaných aplikací, síťovým vybavením, servery, branami firewall, antivirovým softwarem a dalšími prvky ochrany před neoprávněným vniknutím.

Monitorování zabezpečení může zahrnovat data z nástrojů, které nejsou součástí vaší aplikace. Tyto nástroje můžou zahrnovat nástroje, které identifikují aktivity prohledávání portů externími institucemi, nebo síťové filtry, které zjistí pokusy o získání neověřeného přístupu k vaší aplikaci a datům.

Ve všech případech musí shromážděná data správci umožnit určit povahu jakéhokoli útoku a provést příslušná protiopatření.

Analýza dat zabezpečení

Klíčovou funkcí monitorování zabezpečení je, že shromažďuje data z mnoha zdrojů. Různé formáty a úroveň podrobností často vyžadují komplexní analýzu zachycených dat, aby je spojily do koherentního vlákna informací. Kromě nejjednodušších případů (například zjištění velkého počtu neúspěšných přihlášení nebo opakovaných pokusů o získání neoprávněného přístupu k důležitým prostředkům) nemusí být možné provádět žádné složité automatizované zpracování dat zabezpečení. Místo toho může být vhodnější zapsat tato data, časové razítko, ale jinak v původní podobě, do zabezpečeného úložiště, aby bylo možné provést odbornou ruční analýzu.

Monitorování smluv SLA

Řada komerčních systémů, které podporují placení zákazníků, zaručuje výkon systému ve formě smluv SLA. Smlouvy SLA v podstatě uvádějí, že systém dokáže zpracovat definovaný objem práce v rámci schváleného časového rámce a bez ztráty důležitých informací. Monitorování smluv SLA se zabývá zajištěním, aby systém mohl splňovat měřitelné smlouvy SLA.

Poznámka:

Monitorování smlouvy SLA úzce souvisí s monitorováním výkonu. Vzhledem k tomu, že monitorování výkonu se zabývá optimálním fungováním systému, řídí se monitorování smluv SLA smluvní povinností, která definuje, co optimálně znamená.

Smlouvy SLA se často definují z těchto podmínek:

• Celková dostupnost systému. Organizace může například zaručit, že systém bude k dispozici po dobu 99,9 procenta času. To odpovídá ne více než 9 hodin výpadkům za rok nebo přibližně 10 minut týdně.
• Provozní propustnost. Tento aspekt se často vyjadřuje jako jedna nebo více horních vodných značek, jako je například záruka, že systém může podporovat až 100 000 souběžných uživatelských požadavků nebo zpracovat 10 000 souběžných obchodních transakcí.
• Provozní doba odezvy. Systém může také zaručit rychlost zpracování požadavků. Příkladem je, že 99 % všech obchodních transakcí se dokončí během dvou sekund a jedna transakce trvá déle než 10 sekund.

Poznámka:

Některé smlouvy o komerčních systémech můžou zahrnovat také smlouvy SLA pro zákaznickou podporu. Příkladem je, že všechny žádosti help-desku vyvolaly odpověď během pěti minut a že 99 procent všech problémů je plně vyřešeno během jednoho pracovního dne. Efektivní sledování problémů (popsané dále v této části) je klíčem ke splnění smluv SLA, jako jsou tyto.

Požadavky na monitorování smluv SLA

Na nejvyšší úrovni by měl být operátor schopen zjistit na první pohled, jestli systém splňuje schválené smlouvy SLA, nebo ne. Pokud ne, operátor by měl být schopný přejít k podrobnostem a prozkoumat podkladové faktory a určit důvody pro nestandardní výkon.

Mezi typické indikátory vysoké úrovně, které lze vizuálně znázornit, patří:

• Procento doby provozu služby.
• Propustnost aplikace (měřená z hlediska úspěšných transakcí nebo operací za sekundu)
• Počet úspěšných nebo neúspěšných požadavků aplikace.
• Počet chyb aplikací a systémů, výjimek a upozornění.

Všechny tyto indikátory by měly být schopné filtrovat podle zadaného časového období.

Cloudová aplikace pravděpodobně zahrnuje několik subsystémů a komponent. Operátor by měl být schopný vybrat ukazatel vysoké úrovně a zjistit, jak se skládá ze stavu podkladových prvků. Pokud například doba provozu celého systému klesne pod přijatelnou hodnotu, operátor by měl být schopný přiblížit a určit, které prvky přispívají k tomuto selhání.

Poznámka:

Dostupnost systému musí být definovaná pečlivě. V systému, který používá redundanci k zajištění maximální dostupnosti, může dojít k selhání jednotlivých instancí prvků, ale systém může zůstat funkční. Dostupnost systému, jak je prezentováno monitorováním stavu, by měla indikovat agregovanou dobu provozu jednotlivých prvků, a ne nutně to, jestli se systém skutečně zastavil. Kromě toho může být selhání izolovaná. Takže i když je určitý systém nedostupný, zbytek systému může zůstat dostupný, i když s nižší funkčností. (V systému elektronického obchodování může selhání systému bránit zákazníkovi v zadávání objednávek, ale zákazník může stále procházet katalog produktů.)

Pro účely upozorňování by systém měl být schopný vyvolat událost, pokud některý z indikátorů vysoké úrovně překročí zadanou prahovou hodnotu. Podrobnosti na nižší úrovni různých faktorů, které tvoří ukazatel vysoké úrovně, by měly být k dispozici jako kontextová data pro systém výstrah.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Nezpracovaná data potřebná k podpoře monitorování sla se podobají nezpracovaným datům potřebným pro monitorování výkonu spolu s některými aspekty monitorování stavu a dostupnosti. Další informace najdete v těchto částech. Tato data můžete zachytit takto:

• Provádění monitorování koncových bodů
• Protokolování výjimek, chyb a upozornění
• Trasování provádění uživatelských požadavků
• Monitorování dostupnosti všech služeb třetích stran, které systém používá.
• Použití metrik výkonu a čítačů

Všechna data musí být časovaná a časová razítka.

Analýza dat SLA

Data instrumentace musí být agregována, aby se vygeneroval obrázek celkového výkonu systému. Agregovaná data musí také podporovat přechod k podrobnostem, aby bylo možné zkoumat výkon základních subsystémů. Měli byste být například schopni:

• Vypočítejte celkový počet uživatelských požadavků během zadaného období a určete úspěšnost a míru selhání těchto požadavků.
• Zkombinujte doby odezvy uživatelských požadavků a vygenerujte celkový přehled doby odezvy systému.
• Analyzujte průběh uživatelských požadavků, abyste rozdělili celkovou dobu odezvy požadavku do doby odezvy jednotlivých pracovních položek v této žádosti.
• Určete celkovou dostupnost systému jako procento doby provozu pro každé konkrétní období.
• Analyzujte procento dostupnosti jednotlivých komponent a služeb v systému. To může zahrnovat analýzu protokolů, které vygenerovaly služby třetích stran.

Mnoho komerčních systémů je nutné hlásit skutečné údaje o výkonnosti s dohodnutými smlouvami SLA za určité období, obvykle za měsíc. Tyto informace lze použít k výpočtu kreditů nebo jiných forem splátek pro zákazníky, pokud během tohoto období nejsou splněny smlouvy SLA. Dostupnost služby můžete vypočítat pomocí techniky popsané v části Analýza dat dostupnosti.

Pro interní účely může organizace také sledovat počet a povahu incidentů, které způsobily selhání služeb. Když se naučíte, jak tyto problémy rychle vyřešit nebo je úplně odstranit, pomůžete snížit výpadky a splnit smlouvy SLA.

Kontrola

V závislosti na povaze aplikace může existovat zákonné nebo jiné právní předpisy, které určují požadavky na auditování operací uživatelů a zaznamenávání veškerého přístupu k datům. Auditování může poskytnout důkazy, které spojují zákazníky s konkrétními požadavky. Nererepudice je důležitým faktorem v mnoha e-obchodních systémech, které pomáhají udržovat důvěru mezi zákazníkem a organizací odpovědnou za aplikaci nebo službu.

Požadavky na auditování

Analytik musí být schopný sledovat posloupnost obchodních operací, které uživatelé provádějí, abyste mohli rekonstruovat akce uživatelů. To může být nezbytné jednoduše jako záznam nebo jako součást forenzního vyšetřování.

Informace o auditu jsou vysoce citlivé. Pravděpodobně obsahuje data, která identifikují uživatele systému spolu s úlohami, které provádějí. Z tohoto důvodu mají informace o auditu formu sestav dostupných pouze důvěryhodným analytikům, spíše než interaktivní systém podporující podrobné procházení grafických operací. Analytik by měl být schopný vygenerovat celou řadu sestav. Sestavy můžou například zobrazit seznam všech aktivit uživatelů, ke kterým dochází během zadaného časového rámce, podrobně zobrazit chronologii aktivity pro jednoho uživatele nebo zobrazit posloupnost operací provedených s jedním nebo více prostředky.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Mezi primární zdroje informací pro auditování patří:

• Systém zabezpečení, který spravuje ověřování uživatelů.
• Trasování protokolů, které zaznamenávají aktivity uživatelů.
• Protokoly zabezpečení, které sledují všechny identifikovatelné a neidentifikovatelné síťové požadavky.

Formát dat auditu a způsob, jakým jsou uložena, může být řízen zákonnými požadavky. Například nemusí být možné data žádným způsobem vyčistit. (Musí být zaznamenán v původním formátu.) Přístup k úložišti, kde se uchovává, musí být chráněný, aby se zabránilo manipulaci.

Analýza dat auditu

Analytik musí mít přístup k nezpracovaným datům v celé jeho původní podobě. Kromě požadavku na generování běžných sestav auditu budou nástroje pro analýzu těchto dat pravděpodobně specializované a budou se uchovávat mimo systém.

Monitorování využití

Monitorování využití sleduje, jak se používají funkce a součásti aplikace. Operátor může shromážděná data použít k:

• Určete, které funkce se silně používají, a určete případné hotspoty v systému. Prvky s vysokým provozem můžou těžit z funkčního dělení nebo dokonce replikace, aby se zatížení rovnoměrněji rozložily. Operátor může tyto informace použít také ke zjištění, které funkce se často používají a které jsou možné kandidáty na vyřazení nebo nahrazení v budoucí verzi systému.

• Získejte informace o provozních událostech systému v normálním použití. Například na webu elektronického obchodování můžete zaznamenávat statistické informace o počtu transakcí a objemu zákazníků, kteří za ně zodpovídají. Tyto informace je možné použít k plánování kapacity s rostoucím počtem zákazníků.

• Zjištění (pravděpodobně nepřímo) spokojenosti uživatele s výkonem nebo funkčností systému Pokud například velký počet zákazníků v systému elektronického obchodování pravidelně opouští své nákupní košíky, může to být způsobeno problémem s funkcí rezervace.

• Generování fakturačních údajů Komerční aplikace nebo víceklientová služba můžou zákazníkům účtovat poplatky za prostředky, které používají.

• Vynucujte kvóty. Pokud uživatel v systému s více tenanty překročí svou placenou kvótu času zpracování nebo využití prostředků během zadaného období, může být přístup omezený nebo může být omezen.

Požadavky na monitorování využití

K prozkoumání využití systému obvykle potřebuje operátor zobrazit informace, které zahrnují:

• Počet požadavků, které jsou zpracovány jednotlivými subsystémy a směrovány na každý prostředek.
• Práce, kterou každý uživatel provádí.
• Objem úložiště dat, které každý uživatel zabírá.
• Prostředky, ke kterým každý uživatel přistupuje.

Operátor by měl být také schopný generovat grafy. Graf může například zobrazovat nejvíce uživatelů, kteří mají hladový prostředky, nebo nejčastěji používané prostředky nebo systémové funkce.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Sledování využití je možné provádět na relativně vysoké úrovni. Může si všimnout počátečního a koncového času každého požadavku a povahy požadavku (čtení, zápis atd., v závislosti na příslušném prostředku). Tyto informace můžete získat takto:

• Trasování aktivity uživatelů
• Zaznamenávání čítačů výkonu, které měří využití jednotlivých prostředků.
• Monitorování spotřeby prostředků jednotlivými uživateli

Pro účely měření musíte být také schopni zjistit, kteří uživatelé zodpovídají za provádění operací a prostředků, které tyto operace používají. Shromážděné informace by měly být dostatečně podrobné, aby bylo možné povolit přesnou fakturaci.

Sledování problémů

Zákazníci a jiní uživatelé můžou nahlásit problémy, pokud v systému dojde k neočekávaným událostem nebo chováním. Sledování problémů se zabývá správou těchto problémů, jejich přidružením k řešení jakýchkoli hlubších problémů v systému a informováním zákazníků o možných řešeních.

Požadavky na sledování problémů

Operátoři často provádějí sledování problémů pomocí samostatného systému, který jim umožňuje zaznamenávat a hlásit podrobnosti o problémech, které uživatelé hlásí. Tyto podrobnosti mohou zahrnovat úlohy, které se uživatel pokusil provést, příznaky problému, posloupnost událostí a všechny chybové nebo výstražné zprávy, které byly vydány.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Počátečním zdrojem dat pro data sledování problémů je uživatel, který problém nahlásil na prvním místě. Uživatel může poskytnout další data, například:

• Výpis stavu systému (pokud aplikace obsahuje komponentu, která běží na počítači uživatele).
• Snímek obrazovky
• Datum a čas výskytu chyby spolu s dalšími informacemi o prostředí, jako je umístění uživatele.

Tyto informace lze použít k usnadnění ladění úsilí a vytvoření backlogu pro budoucí verze softwaru.

Analýza dat sledování problémů

Stejný problém můžou nahlásit různí uživatelé. Systém sledování problémů by měl přidružit běžné sestavy.

Průběh úsilí o ladění by se měl zaznamenávat do každé zprávy o problému. Po vyřešení problému může být zákazník o řešení informován.

Pokud uživatel hlásí problém se známým řešením v systému sledování problémů, operátor by měl být schopen uživatele o řešení informovat okamžitě.

Operace trasování a ladění vydaných verzí softwaru

Když uživatel hlásí problém, často si je vědom pouze okamžitého účinku, který má na své operace. Uživatel může hlásit pouze výsledky vlastního prostředí operátorovi, který je zodpovědný za údržbu systému. Tyto zkušenosti jsou obvykle jen viditelným příznakem jednoho nebo více základních problémů. V mnoha případech musí analytik prozkoumat chronologii základních operací, aby vytvořil hlavní příčinu problému. Tento proces se nazývá analýza původní příčiny.

Poznámka:

Analýza původní příčiny může odhalit nedostatky v návrhu aplikace. V těchto situacích může být možné přepracovat ovlivněné prvky a nasadit je jako součást následné verze. Tento proces vyžaduje pečlivou kontrolu a aktualizované komponenty by měly být pečlivě sledovány.

Požadavky na trasování a ladění

Pro trasování neočekávaných událostí a dalších problémů je důležité, aby data monitorování poskytovala dostatek informací, aby analytik mohl sledovat původ těchto problémů a rekonstruovat posloupnost událostí, ke kterým došlo. Tyto informace musí stačit k tomu, aby analytik mohl diagnostikovat původní příčinu jakýchkoli problémů. Vývojář pak může provést potřebné úpravy, aby se zabránilo jejich opakování.

Požadavky na zdroje dat, instrumentaci a shromažďování dat

Řešení potíží může zahrnovat trasování všech metod (a jejich parametrů) vyvolaných v rámci operace za účelem vytvoření stromu, který znázorňuje logický tok systémem, když zákazník provede konkrétní požadavek. Výjimky a upozornění, které systém generuje v důsledku tohoto toku, musí být zaznamenány a protokolovány.

Kvůli podpoře ladění může systém poskytovat háky, které operátorovi umožňují zaznamenávat informace o stavu v klíčových bodech systému. Systém může také poskytovat podrobné podrobné informace o průběhu vybraných operací. Zachytávání dat na této úrovni podrobností může znamenat dodatečné zatížení systému a mělo by se jednat o dočasný proces. Operátor tento proces používá hlavně v případě, že dojde k velmi neobvyklé řadě událostí a je obtížné je replikovat, nebo když nová verze jednoho nebo více prvků do systému vyžaduje pečlivé monitorování, aby se zajistilo, že prvky fungují podle očekávání.

Kanál monitorování a diagnostiky

Monitorování velkého distribuovaného systému je velkou výzvou. Každý ze scénářů popsaných v předchozí části by se neměl nutně považovat za izolovanou. V monitorování a diagnostických datech, která jsou nutná pro každou situaci, se pravděpodobně výrazně překrývají, i když tato data může být potřeba zpracovávat a prezentovat různými způsoby. Z těchto důvodů byste měli vzít holistický pohled na monitorování a diagnostiku.

Celý proces monitorování a diagnostiky si můžete představit jako kanál, který se skládá z fází zobrazených na obrázku 1.

Obrázek 1 – Fáze v kanálu monitorování a diagnostiky

Obrázek 1 zdůrazňuje, jak můžou data pro monitorování a diagnostiku pocházet z různých zdrojů dat. Fáze instrumentace a shromažďování se zabývají identifikací zdrojů, ze kterých je potřeba data zachytit, určit, která data se mají zachytit, jak je zachytit, jak je naformátovat, aby bylo možné je snadno prozkoumat. Fáze analýzy/diagnostiky přebírá nezpracovaná data a používá je k vygenerování smysluplných informací, které může operátor použít k určení stavu systému. Operátor může tyto informace použít k rozhodování o možných akcích, které se mají provést, a výsledky pak vrátit zpět do fází instrumentace a shromažďování. Fáze vizualizace/upozorňování představuje spotřební zobrazení stavu systému. Může zobrazovat informace téměř v reálném čase pomocí řady řídicích panelů. A může generovat sestavy, grafy a grafy, které poskytují historický pohled na data, která pomáhají identifikovat dlouhodobé trendy. Pokud informace naznačují, že klíčový ukazatel výkonu pravděpodobně překročí přijatelné hranice, může tato fáze také aktivovat upozornění na operátora. V některých případech lze výstrahu použít také k aktivaci automatizovaného procesu, který se pokusí provést opravné akce, jako je automatické škálování.

Tyto kroky představují proces průběžného toku, ve kterém se fáze provádějí paralelně. V ideálním případě by měly být všechny fáze dynamicky konfigurovatelné. V některých případech, zejména v případě, že je systém nově nasazený nebo dochází k problémům, může být nutné shromažďovat rozšířená data častěji. Jindy by mělo být možné vrátit se k zachycení základní úrovně základních informací, abyste ověřili, že systém funguje správně.

Kromě toho by se celý proces monitorování měl považovat za živé, probíhající řešení, které je předmětem vyladění a vylepšení v důsledku zpětné vazby. Můžete například začít měřením mnoha faktorů, které určují stav systému. Analýza v průběhu času může vést k vylepšení, protože zahodíte míry, které nejsou relevantní, a umožní vám přesněji zaměřit se na potřebná data a minimalizovat šum na pozadí.

Zdroje monitorovacích a diagnostických dat

Informace, které proces monitorování používá, mohou pocházet z několika zdrojů, jak je znázorněno na obrázku 1. Na úrovni aplikace pocházejí informace z protokolů trasování začleněných do kódu systému. Vývojáři by měli dodržovat standardní přístup ke sledování toku řízení prostřednictvím kódu. Například položka metody může generovat trasovací zprávu, která určuje název metody, aktuální čas, hodnotu každého parametru a všechny další relevantní informace. Záznam doby vstupu a ukončení může být také užitečný.

Měli byste protokolovat všechny výjimky a upozornění a zajistit, abyste zachovali úplné trasování všech vnořených výjimek a upozornění. V ideálním případě byste měli zaznamenávat také informace, které identifikují uživatele, který kód spouští, spolu s informacemi o korelaci aktivit (ke sledování požadavků při průchodu systémem). Měli byste také protokolovat pokusy o přístup ke všem prostředkům, jako jsou fronty zpráv, databáze, soubory a další závislé služby. Tyto informace lze použít pro účely měření a auditování.

Mnoho aplikací používá knihovny a architektury k provádění běžných úloh, jako je přístup k úložišti dat nebo komunikace přes síť. Tyto architektury můžou být konfigurovatelné tak, aby poskytovaly vlastní trasovací zprávy a nezpracované diagnostické informace, jako jsou rychlosti transakcí a úspěšnost přenosu dat a selhání.

Poznámka:

Mnoho moderních architektur automaticky publikuje události výkonu a trasování. Zachytávání těchto informací je jednoduše otázkou poskytnutí prostředků pro načtení a uložení, kde je lze zpracovávat a analyzovat.

Operační systém, na kterém je aplikace spuštěná, může být zdrojem informací na úrovni systému nízké úrovně, jako jsou čítače výkonu, které označují rychlost vstupně-výstupních operací, využití paměti a využití procesoru. Chyby operačního systému (například chyby při správném otevření souboru) mohou být hlášeny také.

Měli byste také zvážit základní infrastrukturu a komponenty, na kterých běží váš systém. Virtuální počítače, virtuální sítě a služby úložiště můžou být zdroji důležitých čítačů výkonu na úrovni infrastruktury a dalších diagnostických dat.

Pokud vaše aplikace používá jiné externí služby, jako je webový server nebo systém pro správu databází, můžou tyto služby publikovat vlastní informace o trasování, protokoly a čítače výkonu. Mezi příklady patří zobrazení dynamické správy SQL Serveru pro sledování operací provedených v databázi SQL Serveru a protokoly trasování služby IIS pro zaznamenávání požadavků provedených na webový server.

Při úpravě součástí systému a nasazení nových verzí je důležité mít možnost přiřazovat problémy, události a metriky pro každou verzi. Tyto informace by měly být svázané zpět s kanálem verze, aby bylo možné rychle a znovu sledovat problémy s konkrétní verzí komponenty.

K problémům se zabezpečením může dojít v jakémkoli okamžiku v systému. Uživatel se například může pokusit přihlásit pomocí neplatného ID uživatele nebo hesla. Ověřený uživatel se může pokusit získat neoprávněný přístup k prostředku. Nebo uživatel může poskytnout neplatný nebo zastaralý klíč pro přístup k šifrovaným informacím. Informace související se zabezpečením pro úspěšné a neúspěšné požadavky by se měly vždy protokolovat.

Část Instrumentace aplikace obsahuje další pokyny k informacím, které byste měli zaznamenat. K získání těchto informací ale můžete použít různé strategie:

• Monitorování aplikací a systémů. Tato strategie používá interní zdroje v rámci aplikace, aplikačních architektur, operačního systému a infrastruktury. Kód aplikace může během životního cyklu požadavku klienta vygenerovat vlastní data monitorování v kritických bodech. Aplikace může obsahovat příkazy trasování, které mohou být selektivně povoleny nebo zakázány při diktování okolností. Pomocí diagnostické architektury může být také možné dynamicky vkládat diagnostiku. Tyto architektury obvykle poskytují moduly plug-in, které se můžou připojit k různým bodům instrumentace v kódu a zachytávat data trasování v těchto bodech.

  Kromě toho může váš kód nebo základní infrastruktura vyvolat události v kritických bodech. Monitorovací agenti nakonfigurovaní tak, aby naslouchali těmto událostem, mohou zaznamenávat informace o událostech.

• Monitorování skutečných uživatelů Tento přístup zaznamenává interakce mezi uživatelem a aplikací a sleduje tok jednotlivých požadavků a odpovědí. Tyto informace můžou mít dvounásobný účel: dají se použít k měření využití jednotlivými uživateli a dají se použít k určení, jestli uživatelé dostávají vhodnou kvalitu služby (například rychlá doba odezvy, nízká latence a minimální chyby). Zachycená data můžete použít k identifikaci oblastí zájmu, ve kterých nejčastěji dochází k selháním. Data můžete také použít k identifikaci prvků, ve kterých se systém zpomalí, pravděpodobně kvůli hotspotům v aplikaci nebo nějaké jiné formě kritických bodů. Pokud tento přístup implementujete pečlivě, může být možné rekonstruovat toky uživatelů prostřednictvím aplikace pro účely ladění a testování.

  Důležité

  Měli byste zvážit data zachycená monitorováním skutečných uživatelů, aby byla vysoce citlivá, protože by mohla obsahovat důvěrné materiály. Pokud uložíte zachycená data, bezpečně je uložte. Pokud chcete data použít pro účely monitorování výkonu nebo ladění, nejprve odstraňte všechna osobní data.

• Syntetické monitorování uživatelů. V tomto přístupu napíšete vlastního testovacího klienta, který simuluje uživatele a provádí konfigurovatelnou, ale typickou řadu operací. Můžete sledovat výkon testovacího klienta, abyste mohli určit stav systému. V rámci operace zátěžového testování můžete také použít více instancí testovacího klienta, abyste určili, jak systém reaguje pod stresem a jaký druh výstupu monitorování se vygeneruje za těchto podmínek.

  Poznámka:

  Skutečné a syntetické monitorování uživatelů můžete implementovat tak, že zahrnete kód, který trasuje a krát provádění volání metod a dalších důležitých částí aplikace.

• Profilace. Tento přístup je primárně zaměřen na monitorování a zlepšení výkonu aplikace. Místo toho, aby fungoval na funkční úrovni skutečného a syntetického monitorování uživatelů, zachycuje informace na nižší úrovni při spuštění aplikace. Profilaci můžete implementovat pomocí pravidelného vzorkování stavu spuštění aplikace (určení, který kód aplikace běží v daném časovém okamžiku). Můžete také použít instrumentaci, která vloží sondy do kódu v důležitých juncturech (jako je začátek a konec volání metody) a záznamy, které metody byly vyvolány, v jaké době a jak dlouho každé volání trvalo. Pak můžete tato data analyzovat a určit, které části aplikace můžou způsobit problémy s výkonem.

• Monitorování koncových bodů Tato technika používá jeden nebo více diagnostických koncových bodů, které aplikace zveřejňuje speciálně k povolení monitorování. Koncový bod poskytuje cestu do kódu aplikace a může vracet informace o stavu systému. Různé koncové body se můžou zaměřit na různé aspekty funkčnosti. Můžete napsat vlastního diagnostického klienta, který odesílá pravidelné požadavky na tyto koncové body a assimilovat odpovědi. Další informace najdete v modelu monitorování koncových bodů stavu.

Pro maximální pokrytí byste měli použít kombinaci těchto technik.

Instrumentace aplikace

Instrumentace je důležitou součástí procesu monitorování. Smysluplná rozhodnutí o výkonu a stavu systému můžete provádět pouze v případě, že data, která vám umožní tato rozhodnutí provést, nejprve zachytíte. Informace, které shromažďujete pomocí instrumentace, by měly stačit k tomu, abyste mohli posoudit výkon, diagnostikovat problémy a rozhodovat se, aniž byste se museli přihlásit ke vzdálenému produkčnímu serveru, abyste mohli provádět trasování (a ladění) ručně. Data instrumentace obvykle zahrnují metriky a informace zapsané do protokolů trasování.

Obsah protokolu trasování může být výsledkem textových dat, která jsou napsána aplikací nebo binárními daty vytvořenými v důsledku události trasování, pokud aplikace používá trasování událostí pro Windows (ETW). Dají se také generovat ze systémových protokolů, které zaznamenávají události vyplývající z částí infrastruktury, jako je webový server. Zprávy textového protokolu jsou často navržené tak, aby byly čitelné pro člověka, ale měly by být napsané také ve formátu, který umožňuje automatizovanému systému snadno analyzovat je.

Měli byste také kategorizovat protokoly. Nezapisujte všechna data trasování do jednoho protokolu, ale použijte samostatné protokoly k zaznamenání výstupu trasování z různých provozních aspektů systému. Zprávy protokolu pak můžete rychle filtrovat čtením z příslušného protokolu a nemusíte zpracovávat jeden dlouhý soubor. Nikdy nezapisujte informace, které mají různé požadavky na zabezpečení (například informace o auditu a ladicí data) do stejného protokolu.

Poznámka:

Protokol může být implementován jako soubor v systému souborů nebo se může uchovávat v jiném formátu, například objekt blob v úložišti objektů blob. Informace protokolu se můžou uchovávat také ve strukturovanějším úložišti, například v řádcích v tabulce.

Metriky jsou obecně míra nebo počet některých aspektů nebo prostředků v systému v určitém okamžiku s jednou nebo více přidruženými značkami nebo dimenzemi (někdy označovanými jako ukázka). Jedna instance metriky obvykle není užitečná izolovaně. Místo toho je potřeba zaznamenávat metriky v průběhu času. Klíčovým problémem, který je potřeba vzít v úvahu, je to, které metriky byste měli zaznamenávat a jak často. Generování dat pro metriky může příliš často znamenat významné dodatečné zatížení systému, zatímco zachytávání metrik může způsobit, že vynecháte okolnosti, které vedou k významné události. Aspekty se liší od metriky po metriku. Například využití procesoru na serveru může kolísat od sekundy po sekundu, ale vysoké využití se stává starostí pouze v případě, že trvá několik minut.

Informace o korelaci dat

Můžete snadno monitorovat jednotlivé čítače výkonu na úrovni systému, zaznamenávat metriky pro prostředky a získávat informace o trasování aplikací z různých souborů protokolů. Některé formy monitorování ale vyžadují, aby fáze analýzy a diagnostiky v kanálu monitorování korelovala data načtená z několika zdrojů. Tato data mohou mít v nezpracovaných datech několik forem a proces analýzy musí být k dispozici s dostatečnými daty instrumentace, aby bylo možné tyto různé formuláře mapovat. Například na úrovni architektury aplikace může být úloha identifikována ID vlákna. V rámci aplikace může být stejná práce přidružená k ID uživatele, který tuto úlohu provádí.

Také není pravděpodobné, že by mezi vlákny a požadavky uživatelů bylo mapování 1:1, protože asynchronní operace můžou opakovaně používat stejná vlákna k provádění operací jménem více uživatelů. Kvůli dalšímu komplikování důležitých věcí může jeden požadavek zpracovat více než jedno vlákno, protože provádění prochází systémem. Pokud je to možné, přidružte každý požadavek k jedinečnému ID aktivity, které se šíří v systému jako součást kontextu požadavku. (Technika generování a zahrnutí ID aktivit v informacích o trasování závisí na technologii, která se používá k zachycení dat trasování.)

Všechna data monitorování by měla být časového razítka stejná. Pro konzistenci zaznamenejte všechna data a časy pomocí koordinovaného univerzálního času. To vám pomůže snadněji sledovat posloupnosti událostí.

Poznámka:

Počítače fungující v různých časových pásmech a sítích nemusí být synchronizované. Nespoléhejte na použití časových razítek pouze pro korelaci dat instrumentace, která pokrývají více počítačů.

Informace, které se mají zahrnout do dat instrumentace

Při rozhodování o tom, která data instrumentace potřebujete shromáždit, zvažte následující body:

• Ujistěte se, že informace zachycené událostmi trasování jsou strojově a lidské čitelné. K usnadnění automatizovaného zpracování dat protokolů napříč systémy a zajištění konzistence provozním a technickým pracovníkům, kteří protokoly čtou, osvojte si dobře definovaná schémata pro tyto informace. Uveďte informace o prostředí, jako je prostředí nasazení, počítač, na kterém je proces spuštěný, podrobnosti procesu a zásobník volání.

• Profilaci povolte pouze v případě potřeby, protože může v systému představovat významnou režii. Profilace pomocí instrumentace zaznamenává událost (například volání metody) při každém výskytu, zatímco vzorkování zaznamenává pouze vybrané události. Výběr může být založený na čase (jednou za n sekund) nebo na základě frekvence (jednou za každých n požadavků). Pokud dojde k událostem velmi často, může profilace instrumentací způsobit příliš velkou zátěž a sama o sobě ovlivnit celkový výkon. V takovém případě může být vhodnější přístup k vzorkování. Pokud je však frekvence událostí nízká, může je vzorkování vynechat. V tomto případě by instrumentace mohla být lepším přístupem.

• Poskytněte dostatečný kontext, který umožní vývojáři nebo správci určit zdroj jednotlivých požadavků. Může to zahrnovat určitou formu ID aktivity, která identifikuje konkrétní instanci požadavku. Může také obsahovat informace, které lze použít ke korelaci této aktivity s výpočetní prací provedenou a použitými prostředky. Tato práce může překračovat hranice procesů a počítačů. Pro měření by měl kontext zahrnovat (přímo nebo nepřímo prostřednictvím jiných korelovaných informací) odkaz na zákazníka, který žádost způsobil. Tento kontext poskytuje cenné informace o stavu aplikace v době zachycení dat monitorování.

• Zaznamenejte všechny požadavky a umístění nebo oblasti, ze kterých se tyto požadavky provádějí. Tyto informace vám můžou pomoct při určování, jestli existují nějaká aktivní místa specifická pro polohu. Tyto informace můžou být užitečné také při určování, jestli se má aplikace znovu rozdílit, nebo data, která používá.

• Zaznamenejte a pečlivě zaznamenejte podrobnosti o výjimkách. Důležité informace o ladění se často ztratí v důsledku špatného zpracování výjimek. Zachyťte úplné podrobnosti o výjimkách, které aplikace vyvolá, včetně jakýchkoli vnitřních výjimek a dalších kontextových informací. Pokud je to možné, zahrňte zásobník volání.

• Buďte konzistentní v datech, která zachycují různé prvky aplikace, protože to může pomoct při analýze událostí a jejich korelaci s požadavky uživatelů. Zvažte použití komplexního a konfigurovatelného balíčku protokolování ke shromažďování informací místo toho, aby vývojáři přijali stejný přístup jako implementovali různé části systému. Shromážděte data z klíčových čítačů výkonu, jako je objem provedených vstupně-výstupních operací, využití sítě, počet požadavků, využití paměti a využití procesoru. Některé služby infrastruktury mohou poskytovat vlastní specifické čítače výkonu, například počet připojení k databázi, rychlost provádění transakcí a počet transakcí, které jsou úspěšné nebo neúspěšné. Aplikace můžou také definovat vlastní specifické čítače výkonu.

• Protokolujte všechna volání externích služeb, jako jsou databázové systémy, webové služby nebo jiné služby na úrovni systému, které jsou součástí infrastruktury. Zaznamenává informace o době potřebné k provedení každého volání a o úspěchu nebo selhání hovoru. Pokud je to možné, zachyťte informace o všech pokusech o opakování a selháních všech přechodných chyb, ke kterým dochází.

Zajištění kompatibility se systémy telemetrie

V mnoha případech se informace, které instrumentace vytváří, generují jako řadu událostí a předávají se samostatnému systému telemetrie pro účely zpracování a analýzy. Telemetrický systém je obvykle nezávislý na jakékoli konkrétní aplikaci nebo technologii, ale očekává, že informace budou následovat podle konkrétního formátu, který je obvykle definován schématem. Schéma efektivně určuje kontrakt, který definuje datová pole a typy, které může ingestovat telemetrický systém. Schéma by mělo být generalizováno tak, aby umožňovalo data přicházející z celé řady platforem a zařízení.

Společné schéma by mělo obsahovat pole, která jsou společná pro všechny události instrumentace, jako je název události, čas události, IP adresa odesílatele a podrobnosti potřebné pro korelaci s jinými událostmi (například ID uživatele, ID zařízení a ID aplikace). Mějte na paměti, že jakýkoli počet zařízení může vyvolat události, takže schéma by nemělo záviset na typu zařízení. Kromě toho mohou různá zařízení vyvolat události pro stejnou aplikaci; aplikace může podporovat roaming nebo jinou formu distribuce mezi zařízeními.

Schéma může také zahrnovat pole domény, která jsou relevantní pro konkrétní scénář, který je společný v různých aplikacích. Může se jednat o informace o výjimkách, událostech spuštění a ukončení aplikace a o úspěchu nebo selhání volání rozhraní API webové služby. Všechny aplikace, které používají stejnou sadu polí domény, by měly generovat stejnou sadu událostí, což umožňuje sestavit sadu běžných sestav a analýz.

Schéma může nakonec obsahovat vlastní pole pro zaznamenání podrobností událostí specifických pro aplikaci.

Osvědčené postupy pro instrumentaci aplikací

Následující seznam shrnuje osvědčené postupy instrumentace distribuované aplikace spuštěné v cloudu.

• Usnadnit čtení a snadno analyzovat protokoly. Pokud je to možné, používejte strukturované protokolování. Buďte struční a popisní ve zprávách protokolu.

• Ve všech protokolech identifikujte zdroj a zadejte informace o kontextu a časování při zápisu každého záznamu protokolu.

• Pro všechna časová razítka použijte stejné časové pásmo a formát. To pomáhá korelovat události pro operace, které zahrnují hardware a služby spuštěné v různých geografických oblastech.

• Kategorizuje protokoly a zapisuje zprávy do příslušného souboru protokolu.

• Nezveřejňujte citlivé informace o systému nebo osobních údajích o uživatelích. Tyto informace před zaprotokolovanými daty vyčistíte, ale ujistěte se, že jsou zachovány příslušné podrobnosti. Odeberte například ID a heslo z libovolného připojovacího řetězce databáze, ale zapište zbývající informace do protokolu, aby analytik mohl určit, že systém přistupuje ke správné databázi. Protokolujte všechny kritické výjimky, ale povolte správci zapnout a vypnout protokolování pro nižší úrovně výjimek a upozornění. Zachyťte a zaznamenejte také všechny informace logiky opakování. Tato data můžou být užitečná při monitorování přechodného stavu systému.

• Trasování volání mimo proces, jako jsou požadavky na externí webové služby nebo databáze.

• Nekombinujte zprávy protokolu s různými požadavky na zabezpečení ve stejném souboru protokolu. Například do stejného protokolu nezapisujte informace o ladění a auditu.

• S výjimkou událostí auditování se ujistěte, že všechna volání protokolování jsou operace aktivované a zapomenuté, které neblokují průběh obchodních operací. Události auditování jsou výjimečné, protože jsou pro firmu klíčové a dají se klasifikovat jako základní součást obchodních operací.

• Ujistěte se, že je protokolování rozšiřitelné a nemá žádné přímé závislosti na konkrétním cíli. Například místo psaní informací pomocí System.Diagnostics.Trace definujte abstraktní rozhraní (například ILogger), které zveřejňuje metody protokolování a které je možné implementovat prostřednictvím libovolných vhodných prostředků.

• Ujistěte se, že veškeré protokolování je bezpečné a nikdy neaktivuje žádné kaskádové chyby. Protokolování nesmí vyvolat žádné výjimky.

• Zacházejte s instrumentací jako s probíhajícím iterativním procesem a pravidelně kontrolujte protokoly, nejen v případě problému.

Shromažďování a ukládání dat

Fáze shromažďování procesu monitorování se zabývá načtením informací, které instrumentace generuje, formátováním těchto dat, aby se usnadnila spotřeba fáze analýzy/diagnostiky a uložení transformovaných dat do spolehlivého úložiště. Data instrumentace shromážděná z různých částí distribuovaného systému se dají uchovávat v různých umístěních a s různými formáty. Kód aplikace může například generovat soubory protokolu trasování a generovat data protokolu událostí aplikace, zatímco čítače výkonu, které monitorují klíčové aspekty infrastruktury, kterou vaše aplikace používá, je možné zachytit prostřednictvím jiných technologií. Jakékoli komponenty a služby třetích stran, které vaše aplikace používá, můžou poskytovat informace instrumentace v různých formátech pomocí samostatných trasovacích souborů, úložiště objektů blob nebo dokonce vlastního úložiště dat.

Shromažďování dat se často provádí prostřednictvím služby shromažďování dat, která může běžet samostatně z aplikace, která generuje data instrumentace. Obrázek 2 znázorňuje příklad této architektury a zvýrazňuje subsystém shromažďování dat instrumentace.

Obrázek 2 – Shromažďování dat instrumentace

Toto je zjednodušené zobrazení. Služba sběru nemusí být nutně jediným procesem a může obsahovat mnoho komponent běžících na různých strojích, jak je popsáno v následujících částech. Kromě toho, pokud je potřeba rychle provést analýzu některých telemetrických dat (horká analýza, jak je popsáno v části Podpora horké, teplé a studené analýzy dále v tomto dokumentu), mohou místní komponenty, které pracují mimo službu shromažďování, provádět úlohy analýzy okamžitě. Obrázek 2 znázorňuje tuto situaci u vybraných událostí. Po analytickém zpracování je možné výsledky odeslat přímo do subsystému vizualizace a upozorňování. Data, která jsou předmětem teplé nebo studené analýzy, se uchovávají v úložišti, zatímco čeká na zpracování.

Pro aplikace a služby Azure poskytuje Azure Diagnostics jedno z možných řešení pro zachytávání dat. Azure Diagnostics shromažďuje data z následujících zdrojů pro každý výpočetní uzel, agreguje je a pak je nahraje do Služby Azure Storage:

• Protokoly služby IIS
• Protokoly neúspěšných žádostí služby IIS
• Protokoly událostí Windows
• Čítače výkonu
• Soubory se záznamem o selhání
• Protokolů infrastruktury Azure Diagnostics
• Vlastní protokoly chyb
• Zdroj událostí .NET
• Trasování událostí pro Windows na základě manifestu

Další informace najdete v článku Azure: Základy telemetrie a řešení potíží.

Strategie shromažďování dat instrumentace

Vzhledem k elastické povaze cloudu a abyste se vyhnuli nutnosti ručního načítání telemetrických dat z každého uzlu v systému, měli byste zajistit přenos dat do centrálního umístění a konsolidovat. V systému, který zahrnuje více datacenter, může být užitečné nejprve shromažďovat, konsolidovat a ukládat data v jednotlivých oblastech a pak agregovat regionální data do jednoho centrálního systému.

Pokud chcete optimalizovat využití šířky pásma, můžete se rozhodnout přenášet méně urgentní data v blocích jako dávky. Data však nesmí být zpožděna na neomezenou dobu, zejména pokud obsahují informace citlivé na čas.

Načítání a nabízení dat instrumentace

Subsystém shromažďování dat instrumentace může aktivně načítat data instrumentace z různých protokolů a dalších zdrojů pro každou instanci aplikace ( model vyžádání obsahu). Nebo může fungovat jako pasivní přijímač, který čeká na odeslání dat ze součástí, které tvoří každou instanci aplikace ( model push).

Jedním z přístupů k implementaci modelu vyžádání obsahu je použití agentů monitorování, které běží místně s každou instancí aplikace. Agent monitorování je samostatný proces, který pravidelně načítá telemetrická data shromážděná v místním uzlu a zapisuje tyto informace přímo do centralizovaného úložiště, které všechny instance sdílené aplikace. Jedná se o mechanismus, který Azure Diagnostics implementuje. Každou instanci webové role Azure nebo role pracovního procesu je možné nakonfigurovat tak, aby zaznamenávala diagnostické a další informace trasování, které jsou uložené místně. Agent monitorování, který běží společně s jednotlivými instancemi, kopíruje zadaná data do služby Azure Storage. Další podrobnosti o tomto procesu najdete v článku Povolení diagnostiky ve službách Azure Cloud Services a Virtual Machines . Některé prvky, jako jsou protokoly SLUŽBY IIS, výpisy stavu systému a vlastní protokoly chyb, se zapisují do úložiště objektů blob. Data z protokolu událostí Systému Windows, událostí pro Windows a čítačů výkonu se zaznamenávají v úložišti tabulek. Tento mechanismus znázorňuje obrázek 3.

Obrázek 3 – Použití monitorovacího agenta k vyžádání informací a zápisu do sdíleného úložiště

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. Příkladem jsou informace ze zobrazení dynamické správy SQL Serveru nebo délky fronty služby Azure Service Bus.

Je možné použít právě popsaný přístup k ukládání telemetrických dat pro malou aplikaci běžící na omezeném počtu uzlů v jednom umístění. Složitá, vysoce škálovatelná globální cloudová aplikace může generovat obrovské objemy dat ze stovek webových rolí a rolí pracovních procesů, horizontálních oddílů databáze a dalších služeb. Tato záplava dat může snadno zahltit šířku pásma vstupně-výstupních operací dostupnou v jediném centrálním umístění. Proto musí být vaše řešení telemetrie škálovatelné, aby nebylo možné ho při rozšiřování systému považovat za kritické body. V ideálním případě by vaše ř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 se část systému nezdaří.

Pokud chcete tyto problémy vyřešit, můžete implementovat řazení do front, jak je znázorněno na obrázku 4. V této architektuře místní agent monitorování (pokud je možné ho správně nakonfigurovat) nebo vlastní služba shromažďování dat (pokud ne) publikuje data do fronty. Samostatný proces spuštěný asynchronně (služba zápisu do úložiště na obrázku 4) přebírá data v této frontě a zapisuje je do sdíleného úložiště. Fronta zpráv je vhodná pro tento scénář, protože poskytuje sémantiku „alespoň jednou“, což pomáhá zajistit, aby se data zařazená do fronty po publikování neztratila. Službu zápisu do úložiště můžete implementovat pomocí samostatné role pracovního procesu.

Obrázek 4 – Použití fronty k ukládání dat instrumentace do vyrovnávací paměti

Místní služba shromažďování dat může přidávat data do fronty hned po přijetí. Fronta funguje jako vyrovnávací paměť a služba zápisu do úložiště může načítat a zapisovat data vlastním tempem. Fronta ve výchozím nastavení funguje jako první. Pokud ale zprávy obsahují data, která se musí zpracovávat rychleji, můžete je upřednostnit a urychlit je ve frontě. Další informace najdete v modelu Prioritní fronta. Případně můžete použít různé kanály (například témata služby Service Bus) k směrování dat do různých cílů v závislosti na požadované formě analytického zpracování.

Kvůli škálovatelnosti můžete spustit více instancí služby zápisu do úložiště. Pokud existuje velký objem událostí, můžete pomocí centra událostí odesílat data do různých výpočetních prostředků pro zpracování a úložiště.

Konsolidace dat instrumentace

Data instrumentace, která služba shromažďování dat načítá z jedné instance aplikace, poskytují lokalizované zobrazení stavu a výkonu dané instance. Aby bylo možné vyhodnotit celkový stav systému, je nutné konsolidovat některé aspekty dat v místních zobrazeních. Můžete to provést po uložení dat, ale v některých případech je můžete dosáhnout také při shromažďování dat. Místo přímého zápisu do sdíleného úložiště mohou data instrumentace projít samostatnou službou konsolidace dat, která kombinuje data a funguje jako proces filtrování a čištění. Například data instrumentace, která obsahují stejné informace o korelaci, jako je ID aktivity, mohou být amalgamated. (Je možné, že uživatel začne provádět obchodní operaci na jednom uzlu a pak se v případě selhání uzlu přenese do jiného uzlu nebo v závislosti na konfiguraci vyrovnávání zatížení.) Tento proces může také detekovat a odebírat duplicitní data (vždy možnost, pokud služba telemetrie používá fronty zpráv k odesílání dat instrumentace do úložiště). Obrázek 5 znázorňuje příklad této struktury.

Obrázek 5 – Konsolidace a vyčištění dat instrumentace pomocí samostatné služby

Ukládání dat instrumentace

Předchozí diskuze znázorňují spíše zjednodušený pohled na způsob ukládání dat instrumentace. Ve skutečnosti může dávat smysl ukládat různé typy informací pomocí technologií, které jsou nejvhodnější pro způsob, jakým bude každý typ pravděpodobně použit.

Úložiště objektů blob a tabulek Azure má například určité podobnosti v tom, jakým způsobem se k nim přistupuje. Mají ale omezení v operacích, které můžete provádět jejich použitím, a členitost uložených dat se liší. 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. Například:

• Data čítačů výkonu se dají uložit do SQL databáze, která umožňuje analýzu ad hoc.
• Protokoly trasování můžou být lépe uložené ve službě Azure Cosmos DB.
• Informace o zabezpečení se dají zapsat do HDFS.
• Informace, které vyžadují fulltextové vyhledávání, je možné ukládat prostřednictvím Elasticsearch (což může také urychlit vyhledávání pomocí bohatého indexování).

Můžete implementovat další službu, která pravidelně načítá data ze sdíleného úložiště, oddílů a filtruje data podle jejich účelu, a pak je zapíše do příslušné sady úložišť dat, jak je znázorněno na obrázku 6. 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 v případě potřeby umožňuje alespoň některé dělené data vygenerovat v případě potřeby (v závislosti na tom, kolik dat se uchovává ve sdíleném úložišti). Využívá ale 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.

Obrázek 6 – Dělení dat podle požadavků na analytické úložiště a úložiště

Stejná data instrumentace se můžou dát využít k více účelům. Čítače výkonu lze například použít 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 mohou být stejná data odeslána do více než jednoho cíle, jako je databáze dokumentů, která může fungovat jako dlouhodobé úložiště pro uchovávání fakturačních údajů, a multidimenzionální úložiště pro zpracování komplexní analýzy výkonu.

Měli byste také zvážit, jak jsou data naléhavě nutná. Data, která poskytují informace pro upozorňování, 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á za účelem optimalizace dotazů, které systém upozornění provádí. V některých případech může být nutné, aby služba telemetrie, která shromažďuje data v každém uzlu, aby data naformátovála a uložila místně, aby vás místní instance systému upozornění mohla rychle informovat o jakýchkoli problémech. 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.

Informace, které se používají pro více zvažované analýzy, vytváření sestav a zjišťování historických trendů, jsou méně naléhavé a mohou být uloženy způsobem, který podporuje dolování dat a ad hoc dotazy. Další informace najdete v části Podpora horké, teplé a studené analýzy dále v tomto dokumentu.

Obměně protokolů a uchovávání dat

Instrumentace může generovat značné objemy dat. Tato data se dají uchovávat na několika místech, počínaje nezpracovanými soubory protokolu, trasovacími soubory a dalšími informacemi zachycenými v každém uzlu do konsolidovaného, vyčištěného a děleného zobrazení těchto dat uložených ve sdíleném úložišti. V některých případech je možné po zpracování a přenosu dat z každého uzlu odebrat původní nezpracovaná zdrojová data. V jiných případech může být nutné nebo jednoduše užitečné uložit nezpracované informace. Například data generovaná pro účely ladění můžou být nejlépe ponechána v nezpracované podobě, ale pak je možné je rychle zahodit po opravě všech chyb.

Data o výkonu mají často delší životnost, aby je bylo možné 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. 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 účely auditování a zabezpečení musí být také archivovány a uloženy. Tato data jsou také citlivá a může být nutné je zašifrovat nebo jinak chránit, aby se zabránilo manipulaci. Nikdy byste neměli zaznamenávat hesla uživatelů ani jiné informace, které by mohly být použity k podvodu s identitou. Tyto podrobnosti by se měly před uložením vydržovat z dat.

Vzorkování mimo provoz

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ůže být možné data snížit tak, aby se snížila jejich rozlišení a ušetřily 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.

Osvědčené postupy pro shromažďování a ukládání informací o protokolování

Následující seznam shrnuje osvědčené postupy pro zachytávání a ukládání informací o protokolování:

• Agent monitorování nebo služba shromažďování dat by měly běžet jako služba mimo zpracování a měla by být jednoduchá k nasazení.

• Veškerý výstup z agenta monitorování nebo služby shromažďování dat by měl být nezávislý formát, 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. Použití standardního formátu umožňuje systému vytvářet kanály zpracování; komponenty, které čtou, transformují a odesílají data ve schváleném formátu, je možné snadno integrovat.

• Proces monitorování a shromažďování dat musí být bezpečný a nesmí aktivovat žádné kaskádové chybové podmínky.

• V případě přechodného selhání při odesílání informací do jímky dat by měl být agent monitorování nebo služba shromažďování dat připraveny změnit pořadí telemetrických dat tak, aby se nejdříve odesílaly nejnovější informace. (Agent monitorování nebo služba shromažďování dat se může rozhodnout, že starší data zahodí, nebo je uloží místně a později je přenese, aby se dohodila podle vlastního uvážení.)

Analýza dat a diagnostika problémů

Důležitou součástí procesu monitorování a diagnostiky je analýza shromážděných dat, aby získala přehled o celkové pohodě systému. Měli byste definovat vlastní klíčové ukazatele výkonu a metriky výkonu a je důležité pochopit, jak můžete strukturovat data shromážděná tak, aby splňovala vaše požadavky analýzy. Je také důležité pochopit, jak data zachycená v různých metrikách a souborech protokolů korelují, protože tyto informace můžou být klíčem ke sledování posloupnosti událostí a k diagnostice problémů, které nastanou.

Jak je popsáno v části Konsolidace dat instrumentace, data pro každou část systému se obvykle zaznamenávají místně, ale obvykle je potřeba je kombinovat s daty generovanými v jiných lokalitách, které se účastní systému. Tyto informace vyžadují pečlivou korelaci, aby bylo zajištěno, že se data zkombinují přesně. Například data o využití pro operaci můžou zahrnovat uzel, který je hostitelem webu, ke kterému se uživatel připojí, uzel, který spouští samostatnou službu, ke které se přistupuje v rámci této operace, a úložiště dat uchovávané na jiném uzlu. Tyto informace musí být svázané, aby poskytovaly celkový přehled o využití prostředků a zpracování operace. Některé předběžné zpracování a filtrování dat mohou na uzlu, na kterém jsou data zachycena, zatímco agregace a formátování se pravděpodobně vyskytují na centrálním uzlu.

Podpora horké, teplé a studené analýzy

Analýza a přeformátování dat pro účely vizualizace, vytváření sestav a upozorňování může být složitý proces, který využívá vlastní sadu prostředků. Některé formy monitorování jsou časově kritické a vyžadují okamžitou analýzu dat, aby byla efektivní. Tato analýza se označuje jako horká analýza. Mezi příklady patří analýzy, které jsou potřeba k upozorňování, a některé aspekty monitorování zabezpečení (například zjišťování útoku na systém). Data potřebná pro tyto účely musí být rychle dostupná a strukturovaná pro efektivní zpracování. V některých případech může být nutné přesunout zpracování analýzy do jednotlivých uzlů, kde se data uchovávají.

Jiné formy analýzy jsou méně časově kritické a můžou vyžadovat určité výpočty a agregaci po přijetí nezpracovaných dat. Tomu se říká teplá analýza. Analýza výkonu často spadá do této kategorie. V tomto případě izolovaná jedna událost výkonu pravděpodobně nebude statisticky významná. (Příčinou může být náhlé špičky nebo závada.) Data z řady událostí by měla poskytovat spolehlivější přehled o výkonu systému.

K diagnostice problémů se stavem je možné použít také teplou analýzu. Událost stavu se obvykle zpracovává prostřednictvím horké analýzy a může okamžitě vyvolat výstrahu. Operátor by měl být schopný přejít k podrobnostem důvodů události stavu prozkoumáním dat z teplé cesty. Tato data by měla obsahovat informace o událostech, které vedou k problému, který způsobil událost stavu.

Některé typy monitorování generují dlouhodobé data. Tuto analýzu je možné provést později, pravděpodobně podle předdefinovaného plánu. V některých případech může analýza potřebovat komplexní filtrování velkých objemů dat zachycených v určitém časovém období. To se nazývá studená analýza. Klíčovým požadavkem je, aby se data po zachycení bezpečně ukládaly. Například monitorování a auditování využití vyžaduje přesný přehled o stavu systému v pravidelných bodech v čase, ale tyto informace o stavu nemusí být k dispozici ke zpracování okamžitě po shromáždění.

Operátor může také použít studenou analýzu k poskytování dat pro prediktivní analýzu stavu. Operátor může shromažďovat historické informace za určité období a používat je ve spojení s aktuálními daty o stavu (načtenými z horké cesty) k zjišťování trendů, které by mohly brzy způsobit problémy se stavem. V těchto případech může být nutné vyvolat výstrahu, aby bylo možné provést nápravnou akci.

Korelace dat

Data, která instrumentace zachycuje, můžou poskytnout snímek stavu systému, ale účelem analýzy je zajistit, aby tato data byla užitečná. Například:

• Co způsobilo intenzivní načítání vstupně-výstupních operací na úrovni systému v určitém čase?
• Jedná se o výsledek velkého počtu databázových operací?
• Odráží se to v době odezvy databáze, počtu transakcí za sekundu a doby odezvy aplikace ve stejné době?

Pokud ano, může být jedním nápravnými akcemi, které by mohly snížit zatížení, horizontálním dělením dat na více serverů. Kromě toho může dojít k výjimkám v důsledku chyby v jakékoli úrovni systému. Výjimka na jedné úrovni často aktivuje jinou chybu na výše uvedené úrovni.

Z těchto důvodů musíte být schopni korelovat různé typy dat monitorování na jednotlivých úrovních, abyste vytvořili celkový přehled o stavu systému a aplikacích, které na nich běží. Tyto informace pak můžete použít k rozhodování o tom, jestli systém funguje přijatelně nebo ne, a určit, co se dá udělat, aby se zlepšila kvalita systému.

Jak je popsáno v části Informace o korelaci dat, musíte zajistit, aby nezpracovaná data instrumentace obsahovala dostatečné informace o kontextu a ID aktivity pro podporu požadovaných agregací pro korelace událostí. Tato data se navíc můžou uchovávat v různých formátech a může být nutné tyto informace analyzovat, aby byly převedeny do standardizovaného formátu pro analýzu.

Řešení potíží a diagnostika problémů

Diagnostika vyžaduje schopnost určit příčinu chyb nebo neočekávané chování, včetně provádění analýzy původní příčiny. Mezi požadované informace obvykle patří:

• Podrobné informace z protokolů událostí a trasování, a to buď pro celý systém, nebo pro zadaný subsystém během zadaného časového intervalu.
• Kompletní trasování zásobníku vyplývající z výjimek a chyb jakékoli zadané úrovně, ke které dochází v systému nebo zadaném subsystému během zadaného období.
• Výpisy stavu systému pro všechny neúspěšné procesy buď kdekoli v systému, nebo v zadaném subsystému během zadaného časového intervalu.
• Protokoly aktivit zaznamenávají operace prováděné všemi uživateli nebo pro vybrané uživatele během zadaného období.

Analýza dat pro účely řešení potíží často vyžaduje hluboké technické znalosti architektury systému a různých komponent, které řešení tvoří. V důsledku toho se často vyžaduje velký stupeň ručního zásahu k interpretaci dat, stanovení příčin problémů a doporučení vhodné strategie k jejich opravě. Může být vhodné jednoduše uložit kopii těchto informací v původním formátu a zpřístupnit ji pro studenou analýzu odborníkem.

Vizualizace dat a vyvolávání výstrah

Důležitým aspektem jakéhokoli monitorovacího systému je schopnost prezentovat data takovým způsobem, aby operátor mohl rychle odhalit trendy nebo problémy. Důležité je také schopnost rychle informovat operátora, pokud došlo k významné události, která může vyžadovat pozornost.

Prezentace dat může mít několik forem, včetně vizualizace pomocí řídicích panelů, upozorňování a vytváření sestav.

Vizualizace pomocí řídicích panelů

Nejběžnějším způsobem vizualizace dat je použití řídicích panelů, které můžou zobrazovat informace jako řadu grafů, grafů nebo jiné ilustrace. Tyto položky lze parametrizovat a analytik by měl mít možnost vybrat důležité parametry (například časové období) pro každou konkrétní situaci.

Řídicí panely je možné uspořádat hierarchicky. Řídicí panely nejvyšší úrovně můžou poskytnout celkový přehled o jednotlivých aspektech systému, ale operátor může přejít k podrobnostem. Například řídicí panel, který znázorňuje celkové vstupně-výstupní operace disku pro systém, by měl analytikům umožnit zobrazit sazby vstupně-výstupních operací pro každý jednotlivý disk a zjistit, jestli jedno nebo více konkrétních zařízení představuje nepřiměřený objem provozu. V ideálním případě by měl řídicí panel zobrazovat také související informace, jako je zdroj každého požadavku (uživatel nebo aktivita), který generuje tento vstupně-výstupní operace. Tyto informace se pak dají použít k určení, jestli (a jak) rovnoměrněji rozložit zatížení mezi zařízení a jestli by systém fungoval lépe, kdyby bylo přidáno více zařízení.

Řídicí panel může také použít barevné kódování nebo jiné vizuální pomůcky k označení hodnot, které se zobrazují neobvykle nebo které jsou mimo očekávaný rozsah. Použití předchozího příkladu:

• Disk s rychlostí vstupně-výstupních operací, která se blíží maximální kapacitě v delším období (horký disk), je možné zvýraznit červeně.
• Disk s rychlostí vstupně-výstupních operací, která se pravidelně spouští na maximálním limitu v krátkých obdobích (teplý disk), je možné zvýraznit žlutě.
• Disk, který vykazuje normální využití, se dá zobrazit zeleně.

Aby systém řídicího panelu fungoval efektivně, musí mít nezpracovaná data, se kterými může pracovat. Pokud vytváříte vlastní systém řídicích panelů nebo používáte řídicí panel vyvinutý jinou organizací, musíte pochopit, která data instrumentace potřebujete shromažďovat, na jaké úrovni členitosti a jak by měl řídicí panel využívat.

Kromě zobrazení informací také dobrý řídicí panel umožňuje analytikům klást otázky na tyto informace. Některé systémy poskytují nástroje pro správu, které může operátor použít k provádění těchto úloh a zkoumání podkladových dat. Případně v závislosti na úložišti, které se používají k uložení těchto informací, může být možné tato data dotazovat přímo nebo je importovat do nástrojů, jako je Microsoft Excel pro další analýzu a vytváření sestav.

Poznámka:

Přístup k řídicím panelům byste měli omezit na oprávněné pracovníky, protože tyto informace můžou být komerčně citlivé. Měli byste také chránit podkladová data pro řídicí panely, abyste uživatelům zabránili v jejich změně.

Vyvolávání výstrah

Upozorňování je proces analýzy dat monitorování a instrumentace a generování oznámení v případě zjištění významné události.

Upozorňování pomáhá zajistit, aby systém zůstal v pořádku, responzivní a zabezpečený. Je to důležitá součást každého systému, který uživatelům zaručuje výkon, dostupnost a ochranu osobních údajů, na kterých se data můžou okamžitě chovat. Operátor může být muset být upozorněn na událost, která výstrahu aktivovala. Výstrahy lze také použít k vyvolání systémových funkcí, jako je automatické škálování.

Upozorňování obvykle závisí na následujících datech instrumentace:

• Události zabezpečení. Pokud protokoly událostí naznačují, že dochází k opakovaným selháním ověřování nebo autorizace, může být systém napaden a operátor by měl být informován.
• Metriky výkonu: Systém musí rychle reagovat, pokud určitá metrika výkonu překročí zadanou prahovou hodnotu.
• Informace o dostupnosti Pokud se zjistí chyba, může být nutné rychle restartovat jeden nebo více subsystémů nebo provést převzetí služeb při selhání záložním prostředkem. Opakované chyby v subsystému můžou znamenat vážnější obavy.

Operátoři můžou dostávat informace o upozorněních pomocí mnoha kanálů doručování, jako jsou e-maily, zařízení se stránkovacím zařízením nebo sms textovou zprávou. Výstraha může také obsahovat informace o tom, jak kritická situace je. Řada systémů upozorňování podporuje skupiny odběratelů a všichni operátoři, kteří jsou členy stejné skupiny, můžou přijímat stejnou sadu výstrah.

Systém upozorňování by měl být přizpůsobitelný a příslušné hodnoty z podkladových dat instrumentace je možné zadat jako parametry. Tento přístup umožňuje operátorům filtrovat data a zaměřit se na tyto prahové hodnoty nebo kombinace hodnot, které jsou zajímavé. V některých případech je možné systému výstrah poskytnout nezpracovaná data instrumentace. V jiných situacích může být vhodnější zadat agregovaná data. (Upozornění se může aktivovat například v případě, že využití procesoru uzlu překročilo 90 procent za posledních 10 minut). Podrobnosti poskytované systému výstrah by také měly obsahovat všechny příslušné souhrnné a kontextové informace. Tato data můžou pomoct snížit možnost, že falešně pozitivní události zasílaly výstrahu.

Reportování

Reporting se používá ke generování celkového pohledu na systém. Kromě aktuálních informací může obsahovat historická data. Samotné požadavky na vytváření sestav spadají do dvou širokých kategorií: provozní vytváření sestav a generování sestav zabezpečení.

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

• Agregace statistik, které můžete použít k pochopení využití zdrojů celého systému nebo specifikovaných subsystémů během zadaného časového okna.
• Identifikace trendů ve využití zdrojů pro celý systém nebo specifikované 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 z hlediska nasazených prostředků 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í se zabývá sledováním využití systému zákazníky. Může zahrnovat:

• Auditování uživatelských operací To vyžaduje zaznamenávání jednotlivých požadavků, které každý uživatel provádí, spolu s daty a časy. Data by měla být strukturovaná tak, aby správce mohl rychle rekonstruovat posloupnost operací, které uživatel provádí v zadaném období.
• Sledování prostředků, které uživatel používá To vyžaduje zaznamenávání, jak každý požadavek pro uživatele přistupuje k různým prostředkům, které tvoří systém, a jak dlouho. Správce musí být schopen tato data použít k vygenerování sestavy využití uživatelem v zadaném 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.) V případě potřeby by ale měly být dostupné i pro generování ad hoc. 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.

Další kroky

• Přehled služby Azure Monitor
• Monitorování, diagnostika a řešení problémů s Microsoft Azure Storage
• Přehled upozornění v Microsoft Azure
• Zobrazení oznámení o stavu služby s využitím webu Azure Portal
• Co je Application Insights?
• Diagnostika výkonu pro virtuální počítače Azure
• Stáhněte a nainstalujte SQL Server Data Tools (SSDT) pro Visual Studio

Související prostředky

• Pokyny k automatickému škálování popisují, jak snížit režii správy snížením potřeby operátora průběžně monitorovat výkon systému a rozhodovat se o přidávání nebo odebírání prostředků.
• Model monitorování koncových bodů stavu popisuje, jak implementovat funkční kontroly v aplikaci, ke které mají externí nástroje přístup prostřednictvím vystavených koncových bodů v pravidelných intervalech.
• Model prioritní fronty ukazuje, jak určit prioritu zpráv zařazených do fronty, aby byly přijaté naléhavé žádosti a aby je bylo možné zpracovat před méně naléhavémi zprávami.