Pokyny k monitorování a diagnostice

Distribuované aplikace a služby běžící v cloudu jsou ze své podstaty složité softwary obsahující řadu 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í vám může poskytnout přehled o tom, jak dobře váš systém funguje. Monitorování je zásadní pro dosahování cílů kvality služeb. Toto jsou některé obvyklé scénáře shromažďování dat monitorování:

• Zajištění dobrého stavu systému
• Sledování dostupnosti systému a jeho komponent
• Zachování výkonu, aby při zvýšení objemu práce nedošlo k neočekávanému snížení propustnosti systému
• Zajištění toho, aby systém plnil smlouvy o úrovni služeb (SLA) uzavřené se zákazníky
• Ochrana osobních údajů a zabezpečení systému, uživatelů a jejich dat
• Sledování operací prováděných pro účely auditu nebo zákonné účely
• Sledování každodenního využití systému a zjišťování trendů, které by mohly vést k potížím, pokud se nebudou řešit
• Sledování vzniklých problémů od počátečního hlášení po analýzu možných příčin, nápravu, následné aktualizace softwaru a nasazení
• Trasování operací a ladění vydaných verzí softwaru

V následujících částech najdete podrobnější popis uvedených scénářů. Informace ke každému scénáři mají následující strukturu:

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 dobrém stavu, pokud je spuštěný a schopný zpracovávat požadavky. Cílem monitorování stavu je vytvořit snímek aktuálního stavu systému, abyste si mohli ověřit, že všechny komponenty systému fungují podle očekávání.

Požadavky při monitorování stavu

Pokud se zjistí, že některá část systému není v dobrém stavu, operátor by měl rychle dostat výstrahu (v řádu sekund). Operátor by měl být schopný zjistit, které části systému fungují normálně a ve kterých došlo k potížím. Stav systému je možné znázornit barvami jako na semaforu:

• Červená značí špatný stav (systém se zastavil).
• Žlutá značí částečně dobrý stav (systém běží s omezenými funkcemi)
• Zelená značí zcela dobrý stav.

Komplexní systém monitorování stavu umožňuje obsluze přejít na nižší úrovně systému a zobrazit stav subsystémů a komponent. Pokud je například celkový stav systému hlášený jako částečně dobrý, operátor by měl mít možnost přejít na nižší úroveň a zjistit, 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 těmito způsoby:

• Trasování provádění uživatelských požadavků. Pomocí těchto informací je možné určit, které požadavky byly úspěšné, které se nezdařily a jak dlouho každý požadavek trvá.
• Monitorování syntetických uživatelů. Tento proces simuluje kroky prováděné uživatelem a řídí se předem určeným sledem kroků. Výsledky jednotlivých kroků by se měly zachytávat.
• Protokolování výjimek, chyb a upozornění. Tyto informace se dají zachytit pomocí příkazů trasování vložených do kódu aplikace nebo načtením informací z protokolů událostí 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čítání a analýzu dat o stavu poskytovaných těmito službami. Tyto informace můžou být v různých formátech.
• Monitorování koncových bodů. Tento mechanismus je podrobněji popsaný v části „Monitorování dostupnosti“.
• Shromažďování vedlejších informací o výkonu, třeba o využití CPU na pozadí nebo aktivitě vstupů/výstupů (včetně sítě).

Analýza dat o stavu

Hlavním cílem monitorování stavu je rychle informovat o tom, zda je systém spuštěný. Pokud se při horké analýze bezprostředních dat ukáže, že je některá kritická komponenta ve špatném stavu, může se aktivovat výstraha. (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ý provede studenou analýzu nedávných a aktuálních úloh. Studená analýza může upozornit na určité trendy a určit, jestli je pravděpodobné, že systém zůstane v dobrém stavu, nebo jestli bude systém potřebovat další prostředky. Tento prediktivní prvek by měl vycházet z kritických metrik výkonu, jako jsou třeba tyto:

• Počet požadavků zaslaných do jednotlivých služeb nebo subsystémů
• Doba odezvy na tyto požadavky
• Objem dat přijímaný a odesílaný jednotlivými službami

Pokud hodnota některé metriky překročí stanovenou prahovou hodnotu, může systém vydat výstrahu, aby mohl operátor nebo automatické škálování (pokud je dostupné) provést preventivní kroky nutné k udržení systému v dobrém stavu. Mezi tyto kroky může patřit přidání prostředků, restartování jedné nebo více selhávajících služeb nebo omezení šířky pásma pro požadavky s nižší prioritou.

Monitorování dostupnosti

Ke skutečně dobrému stavu systému je nutné, aby byly dostupné komponenty a subsystémy, ze kterých se systém skládá. Monitorování dostupnosti úzce souvisí s monitorováním stavu. Zatímco ale 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 komponent, aby bylo možné vygenerovat statistické informace o době provozu systému.

V řadě systémů mají některé komponenty (třeba databáze) nakonfigurovanou vestavěnou redundanci, která umožňuje rychlé převzetí služeb při závažné chybě nebo ztrátě připojení. V ideálním případě by se uživatelé vůbec neměli dozvědět, že k takové chybě došlo. Z hlediska monitorování dostupnosti je ale potřeba shromáždit o těchto chybách co nejvíce informací, aby se mohla zjistit příčina a mohly se provést opravné akce, které zabrání v tom, aby se chyby opakovaly.

To, jaká data jsou ke sledování dostupnosti zapotřebí, může záviset na řadě faktorů nižší úrovně. Mnohé z těchto faktorů můžou být specifické pro danou aplikaci, systém a prostředí. Efektivní systém monitorování zachytává údaje o dostupnosti odpovídající těmto faktorům nižší úrovně a potom je agreguje, aby vznikl celkový obraz systému. Třeba v systému elektronického obchodování může obchodní funkce, která zákazníkům umožňuje zadávat objednávky, záviset na úložišti, ve kterém jsou uložené podrobnosti o objednávkách, a na platebním systému, který zpracovává peněžní transakce plateb za tyto objednávky. Dostupnost té části systému, která zodpovídá za příjem objednávek, tedy závisí na dostupnosti úložiště a platebního subsystému.

Požadavky při monitorování dostupnosti

Operátor by měl být schopný zobrazit historickou dostupnost každého systému a subsystému a na základě těchto informací vysledovat trendy, které by mohly způsobovat pravidelné selhání jednoho nebo více subsystémů. (Selhávají služby v určitou denní dobu, která odpovídá dobám špičky ve zpracování?)

Řešení pro monitorování by mělo poskytovat okamžitý a historický přehled dostupnosti nebo nedostupnosti každého subsystému. Také by mělo umět rychle upozornit operátora na selhání jedné nebo více služeb nebo na to, že se uživatelé nemůžou ke službám připojit. Není to jenom záležitost monitorování každé služby, ale také zkoumání akcí jednotlivých uživatelů, které skončí chybou, když se uživatelé pokusí komunikovat s určitou službou. Do určité míry je jistý stupeň chyb připojení normální a můžou ho způsobovat přechodné chyby. Přesto může být užitečné umožnit systému vydání výstrahy při určitém počtu selhání připojení ke konkrétnímu subsystému, ke kterým dojde v určité době.

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

Stejně jako u monitorování stavu se můžou nezpracovaná data nutná k podpoře monitorování dostupnosti generovat pomocí monitorování syntetických uživatelů a protokolování veškerých výjimek, chyb a varování, ke kterým dojde. Vedle toho se dají údaje o dostupnosti získat taky monitorováním koncových bodů. Aplikace může zpřístupnit jeden nebo více koncových bodů stavu, z nichž každý bude testovat přístup k určité funkční oblasti systému. Systém monitorování může do každého koncového bodu zasílat příkaz ping podle definovaného časového plánu a shromažďovat výsledky (úspěch nebo neúspěch).

Je potřeba zaznamenat všechna vypršení časového limitu, selhání připojení k síti a opakované pokusy o připojení. Všechna data by měla být časová razítka.

Analýza údajů o dostupnosti

Je potřeba agregovat a korelovat data instrumentace, aby bylo možné provést následující druhy analýzy:

• Okamžitá dostupnost systému a subsystémů.
• Míry selhání dostupnosti systému a subsystémů. V ideálním případě by měl být operátor schopný přiřadit selhání ke konkrétním aktivitám: co se dělo ve chvíli, kdy systém selhal?
• Historický přehled počtů selhání systému a subsystémů v zadaném období a zatížení systému (například počet uživatelských požadavků) ve chvíli, kdy došlo k selhání.
• Příčiny nedostupnosti systému nebo subsystémů. K příčinám může patřit třeba nespuštěná služba, ztráta připojení, vypršení časového limitu připojení nebo připojení s chybami.

Procento dostupnosti určité služby ve vybraném období můžete vypočítat pomocí tohoto vzorce:

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

To je užitečné pro účely smluv 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ě. Třeba sestavovací služba řešení Visual Studio Team Services definuje výpadek jako dobu (souhrnný počet minut), po kterou je sestavovací služba nedostupná. Minuta se považuje za nedostupnou, pokud všechny průběžné požadavky HTTP na sestavovací službu na provedení operací iniciovaných zákazníkem během dané minuty vyústí v chybový kód nebo nevrátí odpověď.

Monitorování výkonu

S tím, jak se na systém vyvíjí stále větší tlak (zvyšováním počtu uživatelů), roste velikost datových sad, ke kterým tito uživatelé získávají přístup, a zvyšuje se pravděpodobnost selhání jedné nebo více komponent. Před selháním komponent často dochází ke snížení výkonu. Pokud takové snížení dokážete rozpoznat, můžete situaci pomocí proaktivních kroků napravit.

Výkon systému závisí na řadě faktorů. Každý faktor se většinou měří prostřednictvím klíčových ukazatelů výkonu (KPI), jako je třeba počet transakcí databáze za sekundu nebo objem síťových požadavků úspěšně odbavených během určité doby. Některé z těchto klíčových ukazatelů výkonu můžou tvořit konkrétní měřítka výkonu, jiné zase můžou být odvozené z kombinace metrik.

Požadavky při monitorování výkonu

Pokud chce operátor prozkoumat výkon systému, obvykle potřebuje zobrazit informace, jako jsou třeba tyto:

• Míra odezvy na uživatelské požadavky
• Počet souběžných uživatelských požadavků
• Objem přenosů v síti
• Míra dokončování obchodních transakcí
• Průměrná doba zpracování požadavků

Může být také užitečné poskytnout nástroje, které obsluze pomůžou všimnout si určitých korelací, jako jsou tyto:

• Počet souběžných uživatelů a doba latence požadavků (jak dlouho trvá zahájení zpracování požadavku poté, co ho uživatel odešle)
• Počet souběžných uživatelů a průměrná doba odezvy (jak dlouho trvá dokončení požadavku po zahájení jeho zpracování)
• Objem požadavků a počet chyb zpracování

Vedle těchto obecných informací o fungování by měl mít operátor možnost získat podrobné zobrazení výkonu jednotlivých komponent systému. Tato data většinou poskytují čítače výkonu na nízké úrovni, které sledují například tyto údaje:

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

Všechny vizualizace by měly obsluze umožňovat zadání časového období. Zobrazená data můžou být snímkem aktuální situace nebo historickým zobrazením výkonu.

Operátor by měl mít možnost vydat výstrahu na základě kteréhokoli měřítka výkonu a jakékoli zadané hodnoty během libovolného časového intervalu.

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

Údaje o výkonu na vysoké úrovni (propustnost, počet souběžných uživatelů, počet obchodních transakcí, míra chyb atd.) je možné shromažďovat prostřednictvím monitorování uživatelských požadavků, které přicházejí a pohybují se systémem. K tomu je potřeba začlenit do klíčových bodů kódu aplikace příkazy trasování s časovými informacemi. Všechny chyby, výjimky a upozornění by se měly zachytávat s dostatečným množstvím dat, která umožní 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 zachytávat také údaje o výkonu všech externích systémů, které aplikace využívá. Tyto externí systémy můžou poskytovat vlastní čítače výkonu nebo jiné funkce umožňující získat údaje o výkonu. Pokud to možné není, zaznamenejte informace, jako je čas zahájení a ukončení každého požadavku na externí systém a také stav operace (úspěch, chyba, varování). Můžete třeba dobu trvání požadavků stopovat: při zahájení požadavku spusťte čítač a zastavte jej, když se požadavek dokončí.

Údaje o výkonu na nízké úrovni týkající se jednotlivých komponent systému můžou být dostupná prostřednictvím funkcí, jako jsou čítače výkonu Windows nebo Azure Diagnostics.

Analýza údajů 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 uživatelského požadavku je přidání položky do nákupního košíku nebo zaplacení na pokladně v systému elektronického obchodování.

Mezi další běžné požadavky patří shrnutí údajů o výkonu ve vybraných percentilech. Operátor může například určit dobu odezvy u 99 % požadavků, 95 % požadavků a 70 % požadavků. Pro každý percentil můžou být nastavené určité cíle smluv SLA nebo jiné cíle. Průběžné výsledky by se měly hlásit v reálném čase, aby se na jejich základě mohly rozeznávat bezprostřední problémy. Také by měla probíhat agregace výsledků v delším časovém období pro statistické účely.

V případě problémů s latencí, které mají vliv na výkon, by měl být operátor schopný rychle určit příčinu kritického bodu tím, že zjistí latenci každého kroku prováděného jednotlivými požadavky. Údaje o výkonu proto musí poskytovat možnost korelace měřítek výkonu každého kroku a jejich spárování s konkrétním požadavkem.

V závislosti na požadavcích vizualizace může být užitečné vygenerovat a uložit datovou krychli obsahující zobrazení nezpracovaných dat. Tato datová krychle může umožnit složité dotazy ad hoc a analýzu informací o výkonu.

Monitorování zabezpečení

Veškeré obchodní systémy, které obsahují důvěrné osobní údaje, musí mít zavedenou strukturu zabezpečení. Složitost mechanismu zabezpečení většinou závisí na míře důvěrnosti těchto dat. V systému, který vyžaduje ověření uživatelů, byste měli zaznamenávat tyto informace:

• Všechny úspěšné i neúspěšné pokusy o přihlášení
• Všechny operace prováděné ověřeným uživatelem a podrobnosti o všech prostředcích, ke které má přístup.
• Čas ukončení relace uživatelem a jeho odhlášení

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 ukazovat na útok hrubou silou. Neočekávaný nárůst počtu požadavků může být výsledkem distribuovaného útoku na dostupnost služby (DDoS). Musíte být připravení monitorovat všechny požadavky na všechny prostředky bez ohledu na zdroj těchto požadavků. Systém, u kterého se projevuje ohrožení zabezpečení při přihlašování, může nechtěně vystavit prostředky vnějšímu světu, aniž by po uživateli požadoval přihlášení.

Požadavky při monitorování zabezpečení

Nejdůležitější aspekty monitorování zabezpečení by měly obsluze umožnit rychlé provedení těchto kroků:

• Zjištění pokusů o vniknutí neověřené entity
• Zjištění pokusů entit o provádění operací s daty, ke kterým nemají udělený přístup
• Zjištění toho, jestli probíhá útok na systém z vnějšího nebo vnitřního prostředí (Například ověřený uživatel se zlými úmysly se může pokoušet o vyřazení systému z provozu.)

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ů.

Mezi informace, které operátor dostane, by měla patřit adresa hostitele zdroje jednotlivých požadavků. Pokud z určitého rozsahu adres opakovaně přicházejí narušení zabezpečení, je možné tyto hostitele zablokovat.

Klíčovou součástí zabezpečení systému je schopnost rychle rozpoznat akce, které se liší od obvyklého vzorce chování. 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 takové aktivity může být to, když se ve 3 hodiny ráno přihlásí velké množství uživatelů a ti provádějí velký počet operací, přestože pracovní den začíná v 9 hodin ráno). Tyto informace se dají zužitkovat také při konfiguraci automatického škálování založeného na čase. Například pokud si operátor všimne, že se v určitou denní dobu pravidelně přihlašuje velký počet uživatelů, může nastavit spuštění doplňkových ověřovacích služeb, které tuto zátěž zpracují, a po odeznění špičky tyto doplňkové služby zase vypnout.

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

Zabezpečení zasahuje do všech částí většiny distribuovaných systémů. Potřebná data se pravděpodobně budou generovat v několika bodech rozprostřených po celém systému. Měli byste zvážit přístup založený na správě akcí a informací zabezpečení (SIEM), pomocí kterého budete shromažďovat informace o zabezpečení vyplývající z událostí vytvořených aplikací, síťovým vybavením, servery, branami firewall, antivirovým softwarem a dalšími prvky pro prevenci vniknutí.

Monitorování zabezpečení může využívat data z nástrojů, které nejsou součástí vaší aplikace. Tyto nástroje můžou zahrnovat programy, které rozeznávají aktivity prohledávání portů externími entitami, nebo síťové filtry, které zaznamenávají pokusy o získání neověřeného přístupu k vašim aplikacím a datům.

Shromážděná data musí v každém případě umožňovat správci zjištění povahy každého útoku a provedení příslušných protiopatření.

Analýza dat zabezpečení

K typickým rysům monitorování zabezpečení patří rozmanitost zdrojů, ze kterých se čerpají data. Vzhledem k různým formátům a úrovni podrobností je často zapotřebí zachycená data složitě analyzovat, aby z nich bylo možné získat koherentní informace. Kromě nejjednodušších případů (jako je zjištění vysoké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é zpracovat data zabezpečení pomocí složitého automatizovaného procesu. 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 obchodních systémů, které podporují platby zákazníků, zaručují výkon systému pomocí smluv o úrovni služeb (SLA). Smlouvy SLA v podstatě uvádějí, že systém dokáže v dohodnutém časovém rámci a bez ztráty důležitých informací zpracovat stanovený objem práce. Monitorování smluv SLA dbá na zajištění toho, aby systém měřitelným smlouvám SLA vyhověl.

Smlouvy SLA často stanovují následující požadavky:

• Celková dostupnost systému. Organizace se může například zaručit, že bude její systém dostupný 99,9 % času. To znamená pouhých 9 hodin výpadků ročně nebo přibližně 10 minut týdně.
• Propustnost operací. Tento aspekt se často vyjadřuje v podobě jedné nebo více horních mezí, například záruky, že systém bude schopný zpracovat až 100 000 souběžných požadavků uživatelů nebo 10 000 souběžných obchodních transakcí.
• Provozní doba odezvy. Systém také může poskytovat záruku rychlosti zpracování požadavků. Může například zaručit, že se 99 procent všech obchodních transakcí dokončí do 2 sekund a žádná jednotlivá transakce nebude trvat déle než 10 sekund.

Požadavky při monitorování smluv SLA

Na nejvyšší úrovni by měl mít operátor možnost jedním pohledem zjistit, jestli systém vyhovuje uzavřeným smlouvám SLA, nebo ne. Pokud ne, operátor by měl být schopný přejít na nižší úroveň a prozkoumat podrobné faktory, aby mohl určit příčiny nedostatečného výkonu.

Mezi typické ukazatele vysoké úrovně, které se dají vizuálně znázornit, patří tyto:

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

Všechny tyto ukazatele by mělo být možné filtrovat podle vybraného časového období.

Cloudová aplikace se bude pravděpodobně skládat z řady subsystémů a komponent. Operátor by měl mít možnost vybrat ukazatel vysoké úrovně a podívat se, jakým způsobem se na něm podílejí stavy jednotlivých prvků. Například pokud doba provozu celkového systému klesne pod přijatelnou hodnotu, operátor by měl mít možnost přejít na podrobnější zobrazení a zjistit, které prvky k tomuto selhání přispívají.

Pro účely výstrah by systém měl být schopný vyvolat událost v případě, že ukazatele vysoké úrovně překročí zadanou prahovou hodnotu. Podrobné informace nižší úrovně o různých faktorech, ze kterých se ukazatel vyšší úrovně skládá, by měl mít systém výstrah k dispozici ve formě kontextových dat.

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

Nezpracovaná data potřebná k podpoře monitorování smluv SLA se podobají nezpracovaným datům nutným k monitorování výkonu, a navíc vykazují i některé aspekty monitorování stavu a dostupnosti. (Další podrobnosti najdete v těchto částech.) Tato data můžete zachytit takto:

• 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žívání metrik a čítačů výkonu

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

Analýza údajů o smlouvách SLA

K získání přehledu o celkovém výkonu systému je potřeba data instrumentace agregovat. Agregovaná data musí také podporovat přechod na podrobné zobrazení, aby bylo možné zkoumat výkon dílčích subsystémů. Měli byste mít například tyto možnosti:

• Vypočítat celkový počet uživatelských požadavků v zadaném období a určit míru úspěchu a neúspěchu těchto požadavků.
• Zkombinovat doby odezvy na uživatelské požadavky a vygenerovat celkový přehled dob odezvy systému.
• Analyzovat průběh uživatelských požadavků a rozdělit celkovou dobu odezvy na určitý požadavek na doby odezvy jednotlivých pracovních položek v rámci požadavku.
• Určit celkovou dostupnost systému v podobě procenta doby provozu za určité časové období.
• Analyzovat procento časové dostupnosti jednotlivých komponent a služeb v systému. To může zahrnovat analýzu protokolů vygenerovaných službami třetích stran.

Řada obchodních systémů má v souvislosti s uzavřenými smlouvami SLA povinnost vykazovat skutečné údaje o výkonu za určité období, obvykle měsíčně. Tyto informace je možné využít k výpočtu kreditů nebo jiné formy odškodnění zákazníků v případě, že během tohoto období nedojde ke splnění smluv SLA. Dostupnost služby je možné vypočítat pomocí postupu popsaného v části Analýza údajů o dostupnosti.

Pro interní účely může organizace sledovat také počet a povahu incidentů, které způsobily selhání služeb. Osvojení rychlého řešení těchto problémů nebo jejich úplné odstranění pomáhá zkrátit výpadky a dodržet podmínky smluv SLA.

Auditování

V závislosti na povaze aplikace mohou existovat zákonné nebo jiné právní požadavky, které stanovují povinnost auditovat operace uživatelů a zaznamenávat veškeré přístupy k datům. Auditování může poskytnout důkazy, které přiřazují zákazníky ke konkrétním požadavkům. 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 při auditování

Analytik musí mít možnost vysledovat sekvenci obchodních operací prováděných uživateli, aby mohl rekonstruovat jejich kroky. To může být zapotřebí jak pro účely prostého zaznamenávání využití, tak v rámci úředního vyšetřování.

Informace o auditování jsou vysoce citlivé. Pravděpodobně budou zahrnovat údaje, které identifikují uživatele systému, a úlohy, které provádějí. Z toho důvodu budou mít informace o auditování pravděpodobně formu sestav dostupných jenom důvěryhodným analytikům, nikoli interaktivního systému s podporou přechodu na podrobnou úroveň zobrazení grafických operací. Analytik by měl mít možnost generovat různé sestavy. Tyto sestavy můžou obsahovat například seznam aktivit všech uživatelů během zadaného časového období, podrobnosti o chronologii aktivit jednoho uživatele nebo seznam sekvence operací provedených v jednom nebo více prostředcích.

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

Mezi primární zdroje informací pro auditování můžou patřit tyto systémy:

• Systém zabezpečení, který spravuje ověřování uživatelů
• Protokoly trasování, které zaznamenávají aktivity uživatelů
• Protokoly zabezpečení, které sledují všechny síťové požadavky umožňující i neumožňující osobní identifikaci

Na formát dat auditování i způsob jejich uložení se můžou vztahovat zákonné požadavky. Například nemusí být možné tato data žádným způsobem promazat. (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 možnost získat přístup k veškerým nezpracovaným datům v jejich původní podobě. Vedle požadavku na generování běžných sestav auditu je pravděpodobné, že nástroje pro analýzu těchto dat budou specializované a budou se nacházet mimo systém.

Monitorování využití

Monitorování využití sleduje způsob využití funkcí a komponent aplikace. Získaná data může operátor využít k těmto účelům:

• Zjištění toho, které funkce se hojně využívají, a odhalení potenciálních problematických míst systému. Prvkům s vysokým provozem by mohlo prospět funkční rozdělení nebo i replikace, které zajistí rovnoměrnější rozložení zátěže. Operátor může na základě těchto informací zjistit, které funkce se využívají jen zřídka a představují možné kandidáty na vyřazení nebo náhradu v budoucí verzi systému.

• Získání informací o provozních událostech systému při normálním využití. Například na webu elektronického obchodování můžete zaznamenávat statistické informace o řadě transakcí a počtu zákazníků, kteří jsou za tyto transakce zodpovědní. Tyto informace se dají využít při plánování kapacity z důvodu nárůstu počtu zákazníků.

• Zjišťování (pravděpodobně nepřímé) spokojenosti uživatelů s výkonem nebo funkcemi systému. Pokud například velký počet zákazníků systému elektronického obchodování pravidelně opouští své nákupní košíky, může to být způsobeno potížemi s funkcemi při placení.

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

• Vynucování kvót. Pokud uživatel ve víceklientském systému překročí během stanoveného období zaplacenou kvótu doby zpracování nebo využití prostředků, je možné omezit jeho přístup nebo zpracování.

Požadavky při monitorování využití

Pokud chce operátor prozkoumat využití systému, obvykle potřebuje zobrazit informace, jako jsou třeba tyto:

• Počet požadavků zpracovávaných jednotlivými subsystémy a mířících do jednotlivých prostředků
• Práce prováděná jednotlivými uživateli
• Velikost úložiště dat, které zabírají jednotliví uživatelé
• Prostředky, ke kterým získávají jednotliví uživatelé přístup

Operátor by taky měl mít možnost generovat grafy. Graf například může zobrazovat uživatele spotřebovávající nejvíce prostředků nebo prostředky nebo systémové funkce s nejčastějším přístupem.

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

Sledování využití se dá provádět na poměrně vysoké úrovni. Může se při něm zaznamenávat čas spuštění a dokončení každého požadavku a povaha požadavku (čtení, zápis atd., v závislosti na příslušném prostředku). Tyto informace můžete získat těmito způsoby:

• Trasování aktivity uživatelů
• Zachytá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í. Získané informace by měly být natolik podrobné, aby umožnily přesnou fakturaci.

Sledování problémů

Pokud v systému dojde k neočekávaným událostem nebo chování, můžou zákazníci a ostatní uživatelé hlásit problémy. Sledování problémů se zaměřuje na správu těchto problémů, na úsilí o vyřešení potíží v systému, které jsou jejich příčinou, a na informování zákazníků o možných řešeních.

Požadavky při 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 podrobné údaje o potížích hlášených uživateli a vytvářet z nich sestavy. Mezi tyto podrobné údaje můžou patřit úlohy, které se uživatel snažil provést, příznaky problému, posloupnost událostí a veškeré chybové zprávy nebo upozornění, které se zobrazily.

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

Počátečním zdrojem dat pro sledování problémů je uživatel, který příslušný problém nahlásil. Uživatel může být schopný poskytnout i další data, jako jsou tato:

• Výpis stavu systému (pokud aplikace obsahuje komponentu, která běží v počítači uživatele)
• Snímek obrazovky
• Datum a čas chyby a případné další informace o okolnostech, jako je například umístění uživatele

Tyto informace můžou být užitečné při ladění a můžou posloužit k 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 běžná hlášení sdružovat.

U každého hlášení problémů by se měl zaznamenávat průběh ladění. Po vyřešení problému je možné informovat zákazníka.

Pokud uživatel nahlásí problém, jehož řešení už v systému sledování problémů existuje, operátor by měl být schopný uživatele o tomto řešení ihned informovat.

Trasování operací 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 jenom nahlásit to, co se mu děje, operátorovi, který zodpovídá za údržbu systému. Tyto zkušenosti jsou většinou jenom viditelným projevem jednoho nebo více základních problémů. V mnoha případech se bude muset analytik prokousat chronologií základních operací, aby mohl stanovit hlavní příčinu problému. Tento proces se označuje jako analýza hlavní příčiny.

Požadavky při trasování a ladění

Při trasování neočekávaných událostí a jiných problémů je zásadně důležité, aby data monitorování poskytovala dostatek informací, které analytikovi pomůžou dobrat se příčiny těchto problémů a rekonstruovat sled událostí, ke kterým došlo. Tyto informace musí být dostatečně podrobné, aby analytikovi umožnily diagnostikovat základní příčinu případných problémů. Vývojář potom může provést potřebné změny, které zabrání tomu, aby se problémy opakovaly.

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

Při řešení potíží se může uplatnit trasování všech metod (a jejich parametrů) volaných v rámci operace. To poslouží k sestavení stromu znázorňujícího logický tok systémem, když zákazník zadá určitý požadavek. Je potřeba zachytit a uložit do protokolu výjimky a upozornění, které systém v důsledku tohoto toku generuje.

V zájmu podpory ladění může systém operátorovi umožnit zachycení informací o stavu v klíčových bodech systému. Případně může systém poskytovat podrobné informace o průběhu vybraných operací. Zachytávání dat na této úrovni podrobností může pro systém znamenat značnou zátěž a mělo by se provádět jenom dočasně. Operátor tento proces použije hlavně tehdy, když dojde k velmi neobvyklému sledu událostí, který je těžké replikovat, nebo když přidání jednoho nebo více prvků do systému vyžaduje pečlivé monitorování, aby se ověřilo, jestli tyto 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. Jednotlivé scénáře popsané v předchozí části by se neměly zvažovat izolovaně. Data monitorování a diagnostiky vyžadovaná v různých situacích se pravděpodobně budou výrazně překrývat, i když je možná bude potřeba zpracovávat a prezentovat různými způsoby. Z těchto důvodů je potřeba se na monitorování a diagnostiku dívat jako na celek.

Celý proces monitorování a diagnostiky si můžete představit jako kanál, který zahrnuje fáze znázorněné na obrázku 1.

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

Obrázek 1 poukazuje na to, že data monitorování a diagnostiky můžou pocházet z nejrůznějších zdrojů dat. Na identifikaci zdrojů, ze kterých je potřeba data zachytit, a určení toho, jaká data jsou potřeba, jak se mají zachytávat a jak je naformátovat za účelem snadného zkoumání, se soustředí fáze instrumentace a shromažďování. Ve fázi analýzy/diagnostiky se nezpracovaná data využití k vygenerování smysluplných informací, ze kterých může operátor zjistit stav systému. Operátor se může na základě těchto informací rozhodnout o možných krocích a potom vrátit výsledky zpátky do fází instrumentace a shromažďování. Fáze vizualizace/výstrahy představuje využitelné zobrazení stavu systému. To může pomocí řady řídicích panelů zobrazovat informace skoro v reálném čase. Může také generovat sestavy, grafy a diagramy s historickým přehledem dat, které můžou pomoct určit dlouhodobé trendy. Pokud z informací vyplyne, že určitý klíčový ukazatel výkonu může potenciálně překročit přijatelné meze, může tato fáze také aktivovat výstrahu pro operátora. V některých případech se dá výstraha také použít k aktivaci automatizovaného procesu, který se pokusí o opravné akce, například automatického škálování.

Upozorňujeme, že tyto kroky tvoří nepřetržitý proces, ve kterém jednotlivé fáze probíhají současně. V ideálním případě by se měly dát všechny fáze dynamicky konfigurovat. V některých případech, hlavně při novém nasazení systému nebo problémech se systémem, může být potřeba shromažďovat více dat a dělat to častěji. Jindy by zase mělo být možné vrátit se k zachytávání základní úrovně důležitých informací, aby se ověřilo správné fungování systému.

Kromě toho by se měl celý proces monitorování považovat živé, průběžné řešení, které se dá ladit a zlepšovat na základě zpětné vazby. Například můžete začít tím, že budete stav systému určovat na základě měření mnoha faktorů. Na základě dlouhodobé analýzy můžete měření zpřesňovat a vyřazovat měřítka, která nejsou relevantní, abyste se mohli lépe soustředit na potřebná data a nezabývat se podružnostmi.

Zdroje dat monitorování a diagnostiky

Informace využívané procesem monitorování můžou pocházet z několika zdrojů, jak ukazuje obrázek 1. Na úrovni aplikace pocházejí informace z protokolů trasování zabudovaných do kódu systému. Vývojáři by měli při sledování toku ve svém kódy dodržovat standardní postup. Například vstup do určité metody může vydat zprávu trasování, která udává název metody, aktuální čas, hodnotu každého parametru a veškeré další důležité informace. Jako užitečné se může ukázat také zaznamenání času vstupu a ukončení.

Doporučujeme protokolovat všechny výjimky a upozornění, abyste měli jistotu, že máte úplný přehled o všech vnořených výjimkách a upozorněních. V ideálním případě byste měli zachytávat také informace identifikující uživatele, který daný kód spouští, a informace o korelaci aktivit (za účelem sledování požadavků procházejících systémem). Je také dobré 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 se dají využít při 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 umožňovat konfiguraci poskytování vlastních zpráv trasování a nezpracovaných údajů o diagnostice, jako je počet transakcí nebo úspěšné a neúspěšné přenosy dat.

Operační systém, ve kterém je aplikace spuštěná, může posloužit jako zdroj celosystémových informací nízké úrovně, jako jsou čítače výkonu udávající rychlost vstupně-výstupních operací, využití paměti a využití CPU. Můžou se hlásit také chyby operačního systému (například nesprávné otevření souboru).

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

Pokud vaše aplikace používá jiné externí služby, třeba webový server nebo správce databáze, 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 záznam požadavků na určitý webový server.

V případě úprav komponent systému a nasazování nových verzí je důležité moct přiřadit problémy, události a metriky k jednotlivým verzím. Tyto informace by měl být svázané s kanálem verze, aby bylo možné rychle najít problémy s určitou verzí nebo komponentou a napravit je.

V kterémkoli bodě systému můžou nastat problémy se zabezpečením. Například se některý uživatel 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 určitému prostředku. Případně se může uživatel pokusit o přístup k šifrovaným informacím pomocí neplatného nebo zastaralého klíče. Doporučujeme vždy protokolovat informace o úspěšných a neúspěšných požadavcích souvisejících se zabezpečením.

V části Instrumentace aplikace najdete další pokyny týkající se toho, jaké informace byste měli zachytávat. Ke shromažďování těchto informací ale můžete použít různé strategie:

• Monitorování aplikace nebo systému. Tato strategie využívá interní zdroje v rámci aplikace, architektury aplikace, operačního systému a infrastruktury. Kód aplikace může ve významných bodech v průběhu životního cyklu klientského požadavku generovat vlastní data monitorování. Aplikace může zahrnovat příkazy trasování, které se dají podle okolností jednotlivě povolit nebo zakázat. Diagnostika se taky může dát vložit dynamicky pomocí diagnostické architektury. Tyto architektury většinou poskytují moduly plug-in, které se dají v kódu připojit k různým bodům instrumentace a můžou v těchto bodech zachytávat data trasování.

  Kromě toho může váš kód nebo základní infrastruktura vyvolat události v kritických bodech. Informace o těchto událostech můžou zaznamenávat agenti monitorování, kteří jsou nastavení tak, aby těmto událostem naslouchali.

• Monitorování skutečných uživatelů. Tento přístup zaznamenává interakce mezi uživatelem a aplikací a pozoruje tok jednotlivých požadavků a odpovědí. Tyto informace můžou mít dvojí účel: dají se použít k měření využití jednotlivými uživateli nebo k určení toho, jestli se uživatelům dostává patřičné kvality služeb (třeba krátkých dob odezvy, nízké latence a minimálního počtu chyb). Na základě zachycených dat můžete určit problematické oblasti, ve kterých nejčastěji dochází k selhání. Data taky můžete použít ke zjištění toho, které prvky zpomalují systém, třeba v důsledku přetížených míst v aplikaci nebo jiného druhu kritických bodů. Při pečlivém zavedení tohoto přístupu možná budete moct rekonstruovat postup uživatelů aplikací pro účely ladění a testování.

  Důležité

  Data zachytávaná prostřednictvím monitorování skutečných uživatelů byste měli považovat za vysoce citlivá, protože můžou obsahovat důvěrné informace. Pokud zachycená data ukládáte, dělejte to bezpečně. Pokud chcete data použít pro účely monitorování výkonu nebo ladění, nejprve odstraňte všechna osobní data.

• Monitorování syntetických uživatelů. V rámci tohoto přístupu si napíšete vlastního testovacího klienta, který simuluje uživatele a provádí konfigurovatelné, ale typické sledy operací. Výkon testovacího klienta můžete sledovat, což vám pomůže zjistit stav systému. V rámci operace testování zátěže můžete taky použít několik instancí testovacího klienta, abyste zjistili, jak systém reaguje při větší zátěži a jaký výstup monitorování se v takovým podmínkách generuje.

  Poznámka:

  Monitorování skutečných a syntetických uživatelů můžete implementovat přidáním kódu, který sleduje a časuje volání metod a další kritické části aplikace.

• Profilace. Tento přístup je primárně určený k monitorování a zlepšování výkonu aplikace. Nepracuje na funkční úrovni monitorování skutečných a syntetických uživatelů, ale za běhu aplikace zachytává informace na nižší úrovni. Profilaci můžete implementovat prostřednictvím periodického vzorkování stavu spuštění aplikace (určení toho, jaký kód je v aplikaci v danou chvíli spuštěný). Můžete taky použít instrumentaci, která do kódu v důležitých bodech (třeba při spuštění a ukončení volání metody) vloží funkce pro sběr dat a zaznamenává, jaké metody se volaly, kdy k tomu došlo a jak dlouho jednotlivá volání trvala. Potom můžete na základě analýzy těchto dat zjistit, které části aplikace by mohly způsobit problémy s výkonem.

• Monitorování koncových bodů. Tato technika pracuje s jedním nebo více diagnostickými koncovými body, které aplikace jednotlivě vystavuje pro účely 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ěřovat na různé aspekty funkcí. Můžete si napsat vlastního diagnostického klienta, který bude do těchto koncových bodů pravidelně odesílat požadavky a bude dostávat příslušné odpovědi. Další informace najdete v modelu monitorování koncových bodů stavu.

V zájmu maximálního pokrytí doporučujeme používat kombinaci uvedených postupů.

Instrumentace aplikace

Zásadní součástí procesu monitorování je instrumentace. K informovanému rozhodování ohledně výkonu a stavu systému nejdřív potřebujete zachytit data, která vám tato rozhodnutí umožní. Informace shromážděné pomocí instrumentace by měla stačit k vyhodnocení výkonu, diagnostice potíží a rozhodnutí, aniž byste se museli přihlašovat k produkčnímu serveru a provádět ruční trasování (a ladění). Data instrumentace obvykle zahrnují metriky a informace, které se zaznamenávají 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). Data můžou být taky vygenerovaná ze systémových protokolů, které zaznamenávají události vytvoření částmi infrastruktury, jako je třeba webový server. Textové zprávy v protokolu jsou často určené k lidskému čtení, ale měly by být zároveň zapsané ve formátu, který umožňuje snadnou analýzu pomocí automatizovaného systému.

Protokoly byste navíc měli kategorizovat. Nezapisujte všechna data trasování do jednoho protokolu, ale použijte k zaznamenání výstupu trasování oddělené protokoly podle různých provozních aspektů systému. Potom můžete rychle filtrovat zprávy protokolu čtením z příslušného protokolu a nemusíte zpracovávat jeden dlouhý soubor. Informace, které mají různé požadavky na zabezpečení (třeba informace auditu a data ladění), nikdy nezapisujte do stejného protokolu.

Metriky většinou představují měření nebo počet určitého aspektu nebo prostředku v systému v určitou dobu a mají přidruženou jednu nebo víc značek nebo dimenzí (někdy se označují jako ukázka). Jedna izolovaná instance metriky většinou není moc užitečná. Metriky je totiž potřeba zachytávat po určitou dobu. Je velmi důležité zamyslet se nad tím, jaké metriky byste měli zaznamenávat a jak často je to potřeba dělat. Příliš časté generování dat pro metriky může často znamenat výrazný nárůst zatížení systému, jenže pokud se zase metriky zachytávají moc zřídka, možná vám budou chybět informace o okolnostech, které vedou k důležité události. Požadavky se liší podle jednotlivých metrik. Třeba využití CPU serveru se může každou sekundu výrazně měnit, ale vysoké využití se stává problémem jenom v případě, že trvá několik minut.

Informace pro korelaci dat

Můžete snadno monitorovat jednotlivé čítače výkonu na systémové úrovni, zachytávat metriky týkající se prostředků a získávat informace o trasování aplikace z různých souborů protokolu. Některé formy monitorování ale vyžadují, aby ve fázi analýzy a diagnostiky v kanálu monitorování proběhla korelace dat načtených z různých zdrojů. Tato data můžou mít v nezpracovaném stavu různé podoby, takže je potřeba poskytnout proces analýzy s dostatkem dat instrumentace, aby se dalo zajistit mapování těchto různých podob. Třeba na úrovni architektury aplikace může být úloha identifikovaná pomocí ID vlákna. V rámci aplikace může být stejná úloha přiřazená k ID uživatele, který ji provádí.

Navíc není pravděpodobné, aby mezi vlákny a uživatelskými požadavky existovalo mapování 1 : 1, protože asynchronní operace můžou stejná vlákna opakované využívat k provádění operací pro větší počet uživatelů. Všechno se ještě komplikuje tím, že jeden požadavek může být během toho, jak provádění postupuje systémem, zpracovávaný víc než jedním vláknem. Pokud je to možné, přidružte ke každému požadavku jedinečné ID aktivity, které se bude v systému předávat v rámci kontextu požadavku. (Postup generování a přiřazování ID aktivit do informací o trasování závisí na tom, jaká technologie se použije k zachytávání dat trasování.)

Všechna data monitorování by měla být časového razítka stejná. V zájmu konzistence zaznamenávejte data a časy pomocí standardu UTC (Coordinated Universal Time). To vám usnadní trasování sledů událostí.

Informace, které mají být součástí dat instrumentace

Při rozhodování o tom, jaká data instrumentace potřebujete shromažďovat, zvažte následující body:

• Dbejte na to, aby byly informace zachytávané událostmi trasování strojově i lidsky čitelné. Použijte pro tyto informace dobře definovaná schémata, abyste usnadnili automatizované zpracování dat protokolů v různých systémech a zároveň zajistili konzistenci pro provozní a technické pracovníky, kteří budou protokoly číst. Zahrňte do nich informace o prostředí, jako je třeba prostředí nasazení, počítače, ve kterém je proces spuštěný, podrobnosti o procesu a zásobník volání.

• Profilaci povolte jenom v nezbytném případě, protože může výrazně zatížit systém. Profilace využívající instrumentaci zaznamená událost (třeba volání metody) pokaždé, když k ní dojde, kdežto při vzorkování se zaznamenávají jenom 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 se události velmi často opakují, profilace na základě instrumentace může znamenat příliš velkou zátěž a ovlivnit celkový výkon. V takovém případě může být vhodnější zvolit přístup založený na vzorkování. Pokud je ale frekvence událostí nízká, vzorkování je nemusí zaznamenat. V takovém případě bude vhodnější instrumentace.

• Zajistěte dostatečný kontext, aby mohl vývojář nebo správce zjistit zdroj každého požadavku. K tomu může být potřeba nějaký druh ID aktivity, které určuje konkrétní instanci požadavku. Může taky obsahovat informace, které se dají využít ke korelaci dané aktivity s provedenou výpočetní prací a použitými prostředky. Vezměte na vědomí, že tato práce může překračovat hranice procesů a jednotlivých počítačů. V případě měření by měl kontext taky obsahovat (a to buď přímo, nebo nepřímo prostřednictvím jiných korelovaných informací) odkaz na zákazníka, který způsobil zadání příslušného požadavku. Tento kontext poskytuje cenné informace o stavu aplikace v době zachycení dat monitorování.

• Zaznamenávejte všechny požadavky a umístění nebo oblasti, ze kterých požadavky přicházejí. Tyto informace můžou pomoct zjistit, jestli existují nějaká problematická místa závislá na umístění. Tyto informace se dají taky použít při určování toho, jestli se má určitá aplikace nebo data, která používá, rozdělit.

• Pečlivě zaznamenávejte podrobnosti o výjimkách. Kvůli špatnému zpracování výjimek často dochází ke ztrátě důležitých informací o ladění. Zachytávejte všechny podrobnosti o výjimkách, které aplikace vygeneruje, včetně všech vnitřních výjimek a dalších informací o kontextu. Pokud je to možné, zahrňte i zásobník volání.

• Buďte konzistentní v tom, jaká data různé prvky vaší aplikace zachytávají, protože vám to může pomoct při analýze událostí a jejich korelaci s uživatelskými požadavky. Zvažte, jestli není vhodnější použít ke shromažďování informací ucelený balíček protokolování s možností konfigurace, místo aby museli vývojáři uplatňovat stejný přístup během implementace různých součástí systému. Shromažďujte data z klíčových čítačů výkonu, jako je třeba objem provedených vstupně-výstupních operací, využití sítě, počet požadavků, využití paměti a využití CPU. Některé služby infrastruktury můžou poskytovat vlastní čítače výkonu, jako třeba počet připojení k databázi, rychlost provádění transakcí a počet úspěšných nebo neúspěšných transakcí. Aplikace taky můžou definovat vlastní specifické čítače výkonu.

• Zaznamenávejte do protokolu všechna volání externích služeb, jako jsou databázové systémy, webové služby nebo jiné služby na systémové úrovni, které jsou součástí infrastruktury. Zaznamenávejte informace o tom, jak dlouho trvá každé volání, a o úspěchu nebo neúspěchu volání. Pokud je to možné, zachytávejte informace o přechodných chybách, ke kterým dojde při všech opakovaných a neúspěšných pokusech.

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

V mnoha případech se informace vygenerované pomocí instrumentace generují v podobě sledu událostí a ke zpracování a analýze se předávají do samostatného systému telemetrie. Systémy telemetrie většinou nezávisí na žádné konkrétní aplikace ani technologii, ale očekávají, že budou informace dodržovat určitý formát, většinou definovaný pomocí schématu. Schéma určuje kontrakt, který definuje datová pole a typy ingestované systémem telemetrie. Schéma by mělo být obecné, aby se dalo použít pro data z nejrůznějších platforem a zařízení.

Společné schéma by mělo obsahovat pole společná všem událostem instrumentace, jako je název události, čas události, IP adresa odesilatele a podrobnosti nutné ke korelaci s jinými událostmi (třeba ID uživatele, ID zařízení a ID aplikace). Pamatujte si, že události můžou vyvolávat nejrůznější zařízení, takže by schéma nemělo záviset na typu zařízení. Kromě toho můžou události pro stejnou aplikaci vyvolávat různá zařízení. Aplikace může podporovat roaming nebo jiný typ distribuce do různých zařízení.

Schéma může taky obsahovat pole domény relevantní pro určitý scénář, který mají různé aplikace společný. 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 využívající stejnou sadu polí domény by měly vydávat stejnou sadu událostí, aby bylo možné vytvořit sadu společných sestav a analýz.

Nakonec by mělo schéma obsahovat ještě vlastní pole pro zachytávání informací o událostech specifických pro jednotlivé aplikace.

Osvědčené postupy instrumentace aplikací

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

• Dbejte na to, aby protokoly umožňovaly snadné čtení a analýzu. Pokud je to možné, použijte strukturované protokolování. Zprávy protokolu by měly být stručné a popisné.

• Ve všech protokolech identifikujte zdroj a pro každý zapsaný záznam protokolu poskytněte informace o kontextu a čase.

• Pro všechna časová razítka použijte stejné časové pásmo a formát. Usnadní to korelaci událostí u operací, které využívají různý hardware a služby spuštěné v různých geografických oblastech.

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

• Nezveřejňujte citlivé informace o systému ani osobní údaje uživatelů. Tyto informace před zaznamenáním protokolu odstraňte, ale tak, aby zůstaly zachované relevantní podrobnosti. Z připojovacích řetězců databáze třeba odeberte ID a heslo a zbylé informace zapište do protokolu, aby pak mohli analytici určit, jestli systém získává přístup ke správné databázi. Zaznamenávejte do protokolu všechny kritické výjimky, ale umožněte správci zapnout a vypnout protokolování výjimek a upozornění na nižších úrovních. Zachytávejte a zapisujte do protokolu taky všechny informace o logice opakovaných pokusů. Tato data můžou být užitečná při monitorování okamžitého stavu systému.

• Trasujte volání mimo procesy, třeba požadavky na externí webové služby nebo databáze.

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

• Ujistěte se, že jsou všechna volání protokolů s výjimkou událostí auditu jednorázové operace, které neblokují průběh obchodních operací. Události auditu jsou výjimečné v tom, že jsou pro organizaci zásadně důležité a dají považovat za zásadní součást provozu podniku.

• Ujistěte se, že je protokolování rozšiřitelné a nemá žádné přímé závislosti týkající se konkrétního cíle. Například místo zápisu informací pomocí metody System.Diagnostics.Trace definujte abstraktní rozhraní (třeba ILogger), které zveřejňuje metody protokolování a dá se implementovat jakýmkoli vhodným způsobem.

• Ujistěte se, že je veškeré protokolování odolné vůči selhání a nezpůsobuje žádné kaskádové chyby. Protokolování nesmí generovat žádné výjimky.

• Přistupujte k instrumentaci jako k průběžnému procesu, který se stále opakuje, a protokoly kontrolujte pravidelně, nejen tehdy, když dojde k potížím.

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

Fáze shromažďování v procesu monitorování zahrnuje načtení informací vygenerovaných instrumentací, jejich zformátování, aby se daly snáz využít ve fázi analýzy/diagnostiky, a uložení transformovaných dat do spolehlivého úložiště. Data instrumentace, která získáte z různých částí distribuovaného systému, se dají uchovávat v různých umístěních a formátech. Kód aplikace třeba může generovat soubory protokolu trasování a data protokolu událostí aplikace, zatímco čítače výkonu monitorující klíčové aspekty infrastruktury využívané vaší aplikací můžou být zachytávané jinými technologiemi. Komponenty a služby třetích stran, které vaše aplikace využívá, můžou poskytovat informace o instrumentaci v různých formátech a můžou používat oddělené soubory trasování, úložiště objektů blob, nebo dokonce vlastní úložiště dat.

Shromažďování dat často probíhá prostřednictvím služby shromažďování, která může běžet nezávisle na aplikaci generující data instrumentace. Na obrázku 2 najdete příklad takové architektury se zvýrazněným subsystémem pro shromažďování dat instrumentace.

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

Upozorňujeme, že toto zobrazení je zjednodušené. Službu shromažďování nemusí tvořit jenom jeden proces a může se skládat z řady součástí spuštěných v různých počítačích, jak popisují následující části. Pokud je navíc potřeba rychle provést analýzu některých telemetrických dat (horká analýza popsaná v části Podpora horké, teplé a studené analýzy níže v tomto dokumentu), můžou úlohy analýzy okamžitě provést místní komponenty, které se nacházejí mimo službu shromažďování. Na obrázku 2 je tato situace znázorněná pro vybrané události. Po analytickém zpracování se můžou výsledky odeslat přímo do subsystému vizualizace a generování výstrah. Data podléhající teplé nebo studené analýze čekají v úložišti na zpracování.

Jedním z možných řešení zachytávání dat pro aplikace a služby Azure je služba Azure Diagnostics. Azure Diagnostics pro každý výpočetní uzel shromáždí data z následujících zdrojů, provede jejich agregaci a potom je odešle do Azure Storage:

• Protokoly IIS
• Protokoly neúspěšných požadavků služby IIS
• Protokoly událostí Windows
• Čítače výkonu
• Výpisy stavu systému
• Protokolů infrastruktury Azure Diagnostics
• Vlastní protokoly chyb
• Rozhraní .NET EventSource
• Trasování událostí pro Windows na základě manifestu

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

Strategie shromažďování dat instrumentace

Vzhledem k elastické povaze cloudu a z toho důvodu, aby se nemusela telemetrická data ručně načítat z každého uzlu v systému, je vhodné zajistit přenos dat do centrálního umístění a jejich konsolidaci. V systému, který zahrnuje několik datových center, může být dobré data nejdřív shromáždit, konsolidovat a uložit na úrovni oblastí a data z oblastí potom agregovat do jednoho centrálního systému.

V zájmu optimalizace využití šířky pásma můžete nastavit přenos méně naléhavých dat po částech, tedy v dávkách. Přenos dat se ale nedá odkládat donekonečna, zvlášť pokud data obsahují informace, které závisejí na čase.

Aktivní a pasivní získávání dat instrumentace

Subsystém shromažďování dat instrumentace může aktivně načítat data instrumentace z různých protokolů a jiných zdrojů pro každou instanci aplikace (model aktivního získávání). Může ale taky fungovat jako pasivní přijímač, který čeká na odeslání dat z komponent tvořících jednotlivé instance aplikace (model pasivního získávání).

Jeden ze způsobů implementace modelu aktivního získávání spočívá v použití agentů monitorování spuštěných lokálně v každé instanci aplikace. Agent monitorování je samostatný proces, který pravidelně načítá (aktivně získává) telemetrická data shromážděná v místním uzlu a tyto informace zapisuje přímo do centrálního úložiště sdíleného všemi instancemi aplikace. Tento mechanismus implementuje služba Azure Diagnostics. Každou instanci webu nebo role pracovního procesu Azure je možné nakonfigurovat pro zachytávání diagnostických informací a jiných informací trasování uložených v místním prostředí. Agent monitorování spuštěný souběžně s každou instancí kopíruje určená data do služby Azure Storage. Podrobnější informace o tomto procesu najdete v článku Povolení diagnostiky v 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 protokolu událostí Windows, událostí Trasování událostí pro Windows a čítače výkonu se ukládají do služby Table Storage. Tento mechanismus je znázorněný na obrázku 3.

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

Právě popsaný přístup se dá použít k ukládání telemetrických dat v případě menší aplikace spuštěné v omezeném počtu uzlů v jednom umístění. Složité, vysoce škálovatelné a globální cloudové aplikace ale můžou generovat obrovské objemy dat ze stovek webů a pracovních procesů, horizontálních oddílů databáze a dalších služeb. Takové množství dat může snadno zaplnit celou šířku pásma vstupně-výstupních operací, které je dostupné v jednom centrálním umístění. Proto musí být řešení telemetrie škálovatelné, aby při rozšiřování systému nevytvářelo kritický bod. V ideálním případě by mělo vaše řešení obsahovat určitý stupeň redundance, aby se snížilo riziko ztráty důležitých údajů o monitorování (třeba dat auditování nebo fakturace), pokud by došlo k selhání systému.

V zájmu řešení těchto problémů můžete implementovat řazení do front, jak ukazuje obrázek 4. V této architektuře místní agent monitorování (pokud se dá správně nakonfigurovat) nebo vlastní služba shromažďování dat (v ostatních případech) odesílá data do fronty. Samostatný, asynchronně spuštěný proces (služba zápisu do úložiště na obrázku 4) bere z této fronty data a zapisuje je do sdíleného úložiště. Fronta zpráv je pro tento scénář vhodná, protože poskytuje sémantiku typu „alespoň jednou“, která pomáhá zajistit, aby po odeslání nedošlo ke ztrátě dat ve frontě. 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 data ihned po přijetí přidat do fronty. Fronta funguje jako vyrovnávací paměť a služba zápisu do úložiště může data načítat a zapisovat vlastním tempem. Ve výchozím nastavení fronta jako první zpracovává nejstarší data. Pokud ale některé zprávy obsahují data, která je potřeba zpracovat rychleji, můžete jim přidělit vyšší prioritu. Další informace najdete v článku Model prioritní fronty. Případně můžete použít různé kanály (třeba témata služby Service Bus), které budou data přesměrovávat do různých cílů v závislosti na tom, jaké analytické zpracování vyžadují.

V zájmu škálovatelnosti můžete spustit víc instancí služby zápisu do úložiště. Při velkém objemu událostí můžete použít centrum událostí, které bude data odesílat ke zpracování a uložení do různých výpočetních prostředků.

Konsolidace dat instrumentace

Data instrumentace, která služba shromažďování dat načte z jedné instance aplikace, poskytují místní přehled o stavu a výkonu dané instance. K posouzení celkového stavu systému je potřeba některé aspekty dat v místních zobrazeních konsolidovat. To můžete provést po uložení dat, ale v některých případech se to dá provádět i v průběhu shromažďování dat. Místo toho, aby se data instrumentace zapisovala přímo do sdíleného úložiště, můžou procházet samostatnou službou konsolidace dat, která data zkombinuje a funguje jako filtr a čisticí proces. Dají se třeba sloučit data instrumentace, která obsahují stejné informace pro korelaci, jako je ID aktivity. (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ě). Příklad takové struktury je znázorněný na obrázku 5.

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

Ukládání dat instrumentace

Předchozí výklad přinesl trochu zjednodušený pohled na ukládání dat instrumentace. Ve skutečnosti může být vhodné ukládat různé typy informací pomocí technologií nejlépe vyhovujících pravděpodobnému způsobu využití těchto jednotlivých typů.

Třeba služby Azure Blob a Table Storage mají některé podobné rysy z hlediska způsobu přístupu. Zároveň ale umožňují provádět jen omezené typy operací a nabízejí výrazně odlišnou členitost uložených dat. Pokud potřebujete provádět analytičtější operace nebo vyžadujete funkce fulltextového vyhledávání dat, může být vhodnější použít úložiště dat, které poskytuje funkce optimalizované pro konkrétní typy dotazů a přístupu k datům. Příklad:

• Data čítačů výkonu se dají uložit do SQL databáze, která umožňuje analýzu ad hoc.
• Protokoly trasování může být vhodnější ukládat do databáze Azure Cosmos DB.
• Informace o zabezpečení se dají zapisovat do rozhraní HDFS.
• Informace vyžadující fulltextové vyhledávání se dají ukládat prostřednictvím nástroje Elasticsearch (který může také urychlit práci díky použití bohatého indexování).

Můžete implementovat další službu, která bude pravidelně načítat data ze sdíleného úložiště, provede jejich rozdělení a filtrování podle účelu a potom je zapíše do příslušné sady úložišť dat, jak znázorňuje obrázek 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 aspoň částečné obnovení rozdělených dat (podle toho, kolik dat se uchovává ve sdíleném úložišti). Na druhou stranu ale spotřebovává víc prostředků. 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. Například čítače výkonu se dají použít k získání historického přehledu 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 takových případech může probíhat odesílání stejných dat do víc cílů, třeba do databáze dokumentů, která může fungovat jako dlouhodobé úložiště fakturačních informací, a do vícedimenzionálního úložiště pro zpracování složitých analýz výkonu.

Měli byste taky zvážit to, jak moc jsou data naléhavě potřebná. Data poskytující informace pro generování výstrah musejí umožňovat rychlý přístup, takže by měla být uložená v rychlém úložišti a navíc by měla být indexovaná nebo strukturovaná za účelem optimalizace dotazů prováděných systémem výstrah. V některých případech může být nezbytné, aby služba telemetrie shromažďující data v jednotlivých uzlech data formátovala a ukládala v místním prostředí. Díky tomu vás může místní instance systému výstrah rychle upozornit na případné problémy. 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 určené k promyšlenější analýze, tvorbě sestav a hledání historických trendů jsou méně naléhavé a dají se uložit způsobem, který podporuje dolování dat a dotazy ad hoc. Další informace najdete v části Podpora horké, teplé a studené analýzy níže v tomto dokumentu.

Rotace protokolů a uchovávání dat

Instrumentace může generovat značný objem dat. Tato data se můžou uchovávat na různých místech od nezpracovaných souborů protokolu, souborů trasování a dalších informací zachytávaných v každém uzlu po konsolidované, vyčištěné a rozdělené zobrazení těchto dat uložené ve sdíleném úložišti. V některých případech je možné po zpracování a přenosu dat odebrat z jednotlivých uzlů původní nezpracovaná zdrojová data. V jiných případech může být nezbytné nebo prostě užitečné si nezpracované informace uložit. Třeba data generovaná pro účely ladění může být vhodné ponechat v nezpracované podobě, ale po vyřešení případných chyb se dají rychle zahodit.

Údaje o výkonu často mají delší životnost, takže se dají použít k hledání trendů výkonu a plánování kapacity. Konsolidované zobrazení těchto dat se většinou po omezené období uchovává online, aby se k němu dal rychle získat přístup. Potom je můžete archivovat nebo zahodit. Data shromažďovaná za účelem měření a fakturace zákazníkům může být potřeba nechat uložené bez omezení. Na základě zákonných požadavků může být taky nutné archivovat a uchovávat data shromažďovaná pro účely auditu a zabezpečení. Tato data jsou navíc citlivá a můžou vyžadovat šifrování nebo jinou ochranu, aby se s nimi nedalo manipulovat. Nikdy byste neměli zaznamenávat hesla uživatelů nebo jiné informace, které se dají zneužít k podvodům s identitami. Tyto podrobnosti je třeba z dat před uložením odstranit.

Převzorkování na nižší úroveň

Je užitečné ukládat historická data, která umožňují vysledovat dlouhodobé trendy. Místo uchovávání všech starých dat ale můžete data převzorkovat na nižší úroveň, čímž snížíte jejich rozlišení a náklady na úložiště. Například místo ukládání ukazatelů výkonu po jednotlivých minutách můžete data starší jeden měsíc konsolidovat tak, aby poskytovala přehled po hodinách.

Osvědčené postupy 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 se měly spouštět jako služby mimo procesy a měly by umožňovat snadné nasazení.

• Veškerý výstup agenta monitorování nebo služby shromažďování dat by měl být ve formátu nezávislém na počítači, operačním systému a síťovém protokolu. Informace se třeba dají místo formátu ETL / Trasování událostí pro Windows poskytovat v samostatném formátu, jako je JSON, MessagePack nebo Protobuf. Použití standardního formátu umožňuje systému vytvořit kanály zpracování a snadno integrovat komponenty sloužící ke čtení, transformaci a odesílání dat v dohodnutém formátu.

• Proces monitorování a shromažďování dat musí být odolný proti selhání a nesmí aktivovat žádné kaskádové chyby.

• V případě přechodné chyby odesílání informací do jímky dat by měly být agent monitorování nebo služba shromažďování dat připravené změnit uspořádání telemetrických dat, aby se jako první odesílaly nejnovější informace. (Agent monitorování nebo služba shromažďování dat se může rozhodnout, jestli starší data odstraní nebo uloží do místního prostředí a předá je později.)

Analýza dat a diagnostika problémů

Důležitou součástí procesu monitorování a diagnostiky je analýza získaných dat, která poskytuje přehled o celkovém stavu systému. Měli byste mít definované vlastní klíčové ukazatele výkonu a metriky výkonu a je důležité pochopit možnosti strukturování získaných dat, aby vyhovovala požadavkům na analýzu. Kromě toho je důležité pochopit souvislost mezi daty zachycenými v různých metrikách a souborech protokolu, protože tyto informace mohou být klíčové při sledování posloupnosti událostí a diagnostice vzniklých potíží.

Jak je popsané v části Konsolidace dat instrumentace, data z různých částí systému se většinou zachytávají v místním prostředí, ale je potřeba je zkombinovat s daty vygenerovanými v jiných sítích, které jsou součástí systému. Tyto informace vyžadují pečlivou korelaci, která zajistí jejich přesné zkombinování. Například údaje o využití určité operace se můžou týkat uzlu hostujícího web, ke kterému se připojuje určitý uživatel, uzlu spouštějícího samostatnou službu, ke které se v rámci této operace získává přístup, a úložiště dat umístěného v jiném uzlu. Aby mohly tyto informace poskytnout celkový přehled prostředku a využití zpracování pro danou operaci, je potřeba je svázat dohromady. 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 výstrah může být složitý proces, který využívá vlastní sadu prostředků. Některé formy monitorování jsou závislé na čase a vyžadují okamžitou analýzu, aby mohly být účinné. To se označuje jako horká analýza. Mezi příklady patří analýzy nutné k vydávání výstrah a některým aspektům monitorování zabezpečení (třeba ke zjištění útoku na systém). Data vyžadovaná k těmto účelům musejí být rychle dostupná a strukturovaná, aby umožňovala efektivní zpracování. V některých případech může být potřeba přesunout zpracování analýzy do jednotlivých uzlů, kde jsou data uložená.

Další formy analýzy jsou méně závislé na čase a po přijetí nezpracovaných dat můžou vyžadovat určité výpočetní úkony a agregaci. Označují se jako teplá analýza. Do této kategorie se často řadí analýza výkonu. V tomto případě není pravděpodobné, že by měla jedna izolovaná událost výkonu statistický význam. (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.

Teplá analýza se dá používat taky k diagnostice problémů v oblasti stavu. Událost stavu se většinou zpracovává prostřednictvím horké analýza a může okamžitě aktivovat výstrahu. Operátor by měl mít možnost zjistit z dat v cestě podrobné informace o příčinách události stavu. Tato data by měla obsahovat informace o událostech vedoucích k problému, který způsobil danou událost stavu.

Některé typy monitorování generují více dlouhodobých dat. Tato analýza se dá provést později, třeba na základě předdefinovaného plánu. V některých případech může být při analýze potřeba provádět složité filtrování velkých objemů dat zachytávaných v průběhu určité doby. To se označuje jako studená analýza. Klíčovým požadavkem je, aby po zachycení dat došlo k jejich bezpečnému uložení. Například monitorování využití a auditování vyžaduje v pravidelných okamžicích přesný přehled o stavu systému, ale tyto informace o stavu nemusejí být hned po získání dostupné ke zpracování.

Operátor může studenou analýzu využít taky k získání dat pro prediktivní analýzu stavu. Operátor může po určitou dobu shromažďovat historické informace a v kombinaci s aktuálními údaji o stavu (načtenými z kritické cesty) je použít ke zjištění trendů, které můžou brzy způsobit problémy v oblasti stavu. V těchto případech může být potřeba vygenerovat výstrahu, aby bylo možné provést opravnou akci.

Korelace dat

Data zachycená pomocí instrumentace můžou poskytnout snímek stavu systému, ale cílem analýzy je to, aby byla tato data využitelná. Příklad:

• Co v určitou chvíli způsobilo velké zatížení vstupně-výstupních operací na systémové úrovni?
• Bylo to výsledkem velkého počtu operací databáze?
• Projevuje se to v době odezvy databáze, počtu transakcí za sekundu a době odezvy aplikací ve stejné situaci?

Pokud ano, ke snížení zátěže můžete třeba rozdělit data mezi více serverů. Kromě toho může chyba na jiné úrovni systému způsobit výjimky. Výjimka na jedné úrovni často aktivuje jinou chybu na vyšší úrovni.

Z těchto důvodů potřebujete mít možnost provést korelaci různých typů údajů o monitorování na jednotlivých úrovních, abyste získali celkový přehled o stavu systému a aplikací, které jsou v něm spuštěné. Na základě těchto informací se potom můžete rozhodnout, jestli systém funguje přijatelně, nebo ne, a určit, jak kvalitu systému zlepšit.

Jak si můžete přečíst v části Informace pro korelaci dat, je potřeba se ujistit, že nezpracovaná data instrumentace obsahují dostatečný kontext a informace o ID aktivity, aby bylo možné provést požadovanou agregaci nutnou ke korelaci událostí. Kromě toho můžou být tato data uložená v různých formátech, takže může být potřeba informace parsovat a převést do standardizovaného formátu za účelem analýzy.

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

Diagnóza vyžaduje schopnost určit příčinu chyb nebo neočekávaného chování včetně provedení analýzy hlavní příčiny. Obvykle jsou nutné tyto informace:

• Podrobné informace z protokolů událostí a trasování pro celý systém nebo určitý subsystém v určitém časovém období
• Kompletní trasování zásobníků vyplývajících z výjimek a chyb na jakékoli zadané úrovni, ke kterým došlo v systému nebo určitém subsystému v určitém časovém období
• Výpisy stavu systému pro všechny neúspěšné procesy kdekoli v systému nebo v určitém subsystému v určitém časovém období
• Protokoly aktivity obsahující záznamy operací provedených všemi uživateli nebo vybranými uživateli v určitém časovém období

Analýza dat pro účely řešení potíží často vyžaduje důkladné technické znalosti architektury systému a různých komponent, které jsou součástí daného řešení. V důsledku toho je k interpretaci dat, určení příčiny problémů a doporučení vhodné strategie jejich opravy často potřeba provést značné ruční zásahy. Vzhledem k tomu může být vhodné jednoduše uložit kopii těchto informací v původním formátu a předat ji odborníkovi, který provede studenou analýzu.

Vizualizace dat a generování výstrah

K důležitým aspektům každého systému monitorování patří schopnost prezentovat data takovým způsobem, aby mohl operátor rychle odhalit trendy nebo případné potíže. Důležitá je také schopnost rychle informovat operátora, pokud dojde k významné události, která může vyžadovat pozornost.

Prezentace dat může mít různé podoby včetně vizualizace pomocí řídicích panelů, generování výstrah a vytváření sestav.

Vizualizace pomocí řídicích panelů

Nejběžnější způsob vizualizace dat spočívá v použití řídicích panelů, které mohou zobrazovat informace v řadě grafů, diagramů nebo jiných znázornění. Tyto položky můžou vycházet z parametrů, takže analytik potom může vybrat parametry (třeba časové období) důležité pro konkrétní situaci.

Řídicí panely můžou být hierarchicky uspořádané. Řídicí panely nejvyšší úrovně můžou poskytovat celkový přehled o jednotlivých aspektech systému, ale zároveň umožňovat operátorovi přejít k podrobnostem. Třeba řídicí panel, který znázorňuje celkový přehled vstupně-výstupních operací disků v systému, by měl analytikovi umožňovat zobrazit objemy vstupně-výstupních operací pro každý jednotlivý disk, aby bylo možné zjistit, jestli jedno nebo několik konkrétních zařízení nevytváří neúměrný objem provozu. Řídicí panel by měl v ideálním případě obsahovat související informace, jako je zdroj každého požadavku (uživatel nebo aktivita), který danou vstupně-výstupní operaci vygeneroval. Na základě těchto informací se potom dá určit, jestli by nebylo vhodné rovnoměrněji rozložit zátěž mezi zařízení (a jak to udělat) a jestli by systém fungoval lépe, kdyby se do něj přidalo více zařízení.

Řídicí panel taky může pomocí barevných kódů nebo jiných vizuálních pomůcek upozorňovat na hodnoty, které se zdají nezvyklé nebo jsou mimo očekávaný rozsah. Když použijeme předchozí příklad:

• Disk s objemem vstupně-výstupních operací, který se po delší dobu blíží maximální kapacitě (horký disk), může být zvýrazněný červenou barvou.
• Disk s objemem vstupně-výstupních operací, který v krátkých časových úsecích pracuje na maximálním limitu (teplý disk), může být zvýrazněný žlutě.
• Disk, který je využívaný normálním způsobem, může být označený zelenou barvou.

Upozorňujeme, že pokud má být systém řídicích panelů účinný, potřebuje nezpracovaná data, se kterými bude pracovat. Pokud si vytváříte vlastní systém řídicích panelů nebo používáte řídicí panel vyvinutý jinou organizací, potřebujete pochopit, jaká data instrumentace máte shromažďovat, na jaké úrovni členitosti to máte dělat a jak mají být data naformátovaná, aby je mohl řídicí panel využívat.

Dobrý řídicí panel nejen zobrazuje informace, ale taky umožňuje analytikovi klást si relevantní otázky týkající se těchto informací. Některé systémy poskytují nástroje pro správu, které může operátor k těmto úkonům používat a které slouží ke zkoumání zdrojových dat. Případně může být podle toho, v jakém úložišti se tyto informace nacházejí, možné zadávat dotazy na tato data přímo nebo data importovat k další analýze a vytváření sestav do nástrojů jako Microsoft Excel.

Výstrahy

Vytváření výstrah je proces, který zahrnuje analýzu dat monitorování a instrumentace a generování oznámení v případě zjištění významné události.

Výstrahy pomáhají zajistit udržení dobrého stavu, reakcí a zabezpečení systému. Představují důležitou součást každého systému, který poskytuje uživatelům záruky v oblasti výkonu, dostupnosti a ochrany osobních údajů a může vyžadovat okamžitou práci s daty. Může být nutné upozornit operátora na událost, která danou výstrahu aktivovala. Výstrahy se taky dají použít k vyvolání systémových funkcí, jako je automatické škálování.

Výstrahy většinou 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: Pokud určitá metrika výkonu překročí zadanou prahovou hodnotu, musí systém rychle zareagovat.
• Informace o dostupnosti V případě zjištění chyby může být potřeba rychle restartovat jeden nebo víc subsystémů nebo zajistit převzetí služeb záložním prostředkem. Opakované chyby v subsystému můžou znamenat závažnější potíže.

Operátoři můžou dostávat informace o výstrahách prostřednictvím řady kanálů, třeba e-mailem, na pager nebo ve zprávě SMS. Výstraha může taky obsahovat informaci o tom, jak moc je situace kritická. Řada systémů výstrah podporuje skupiny odběratelů, takže všichni operátoři, kteří jsou členy určité skupiny, dostanou stejnou sadu výstrah.

Systém výstrah by měl být přizpůsobitelný a může poskytovat příslušné hodnoty ze zdrojových dat instrumentace jako parametry. Díky tomu může operátor filtrovat data a zaměřit se jenom na relevantní prahové hodnoty nebo kombinace hodnot. Vezměte na vědomí, že v některých případech je možné poskytnout systému výstrah nezpracovaná data instrumentace. V jiných situacích ale může být vhodnější poskytovat agregovaná data. (Výstraha se může například aktivovat v případě, že využití CPU určitým uzlem překračovalo po dobu posledních 10 minut hodnotu 90 procent). Podrobné údaje poskytované do systému výstrah by měly zahrnovat taky příslušné souhrnné informace a informace o kontextu. Tato data můžou pomoct omezit riziko aktivování výstrahy falešně pozitivní událostí.

Sestavy

Vytváření sestav se používá k vygenerování celkového přehledu o systému. Ten může vedle aktuálních informací obsahovat i historická data. Vytváření sestav se dá rozdělit do dvou rozsáhlých kategorií: vytváření provozních sestav a vytváření sestav zabezpečení.

Vytváření provozních sestav většinou zahrnuje následující aspekty:

• Agregace statistik, které můžete použít k pochopení využití prostředků celkového systému nebo zadaných subsystémů během zadaného časového intervalu.
• Identifikace trendů využití prostředků pro celkový systém nebo zadané subsystémy během zadaného období
• Monitorování výjimek, ke kterým došlo v celém systému nebo v zadaných subsystémech během zadaného období
• Určení efektivity aplikace 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.

Vytváření sestav zabezpečení se zabývá sledováním využívání systému ze strany zákazníků. Může zahrnovat tyto úkony:

• Auditování uživatelských operací Ty vyžadují zaznamenávání jednotlivých požadavků všech uživatelů včetně jejich data a času. Data by měla být strukturovaná, aby mohl správce rychle rekonstruovat sled operací, který uživatel v zadaném období provedl.
• Sledování prostředků, které uživatel používá K tomu je potřeba zaznamenávat to, jak každý požadavek určitého uživatele získává přístup k různým prostředkům tvořícím systém a jak dlouho je využívá. Správce musí mít možnost na základě těchto dat vygenerovat sestavu využití podle uživatele za určité období, pravděpodobné za účelem 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. Například pokud ukládáte data do relační databáze, jako je Azure SQL Database, můžete pomocí nástroje jako SQL Server Reporting Services extrahovat data, formátovat je a prezentovat je ve formě sady 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
• Stažení a instalace NÁSTROJŮ SQL Server Data Tools (SSDT) pro Visual Studio

Související prostředky

• Článek Pokyny k automatickému škálování popisuje, jak snížit náročnost správy díky tomu, že operátor nebude muset soustavně monitorovat výkon systému a rozhodovat se, jestli je potřeba přidat nebo odebrat prostředky.
• 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.