Monitorování a telemetrie (vytváření Real-World cloudových aplikací v Azure)

Rick Anderson, Tom Dykstra

Stáhnout projekt Fix It nebo Stáhnout elektronickou knihu

Elektronická kniha Building Real World Cloud Apps with Azure je založená na prezentaci vyvinuté Scottem Guthriem. Vysvětluje 13 vzorů a postupů, které vám můžou pomoct s úspěšným vývojem webových aplikací pro cloud. Informace o elektronické knize najdete v první kapitole.

Mnoho lidí spoléhá na zákazníky, kteří jim dají vědět, když je jejich aplikace mimo provoz. To není ve skutečnosti osvědčený postup nikde, a hlavně ne v cloudu. Neexistuje žádná záruka rychlého oznámení, a když dostanete oznámení, často získáte minimální nebo zavádějící data o tom, co se stalo. Díky dobrým telemetrickým a protokolovacím systémům můžete vědět, co se s vaší aplikací děje, a když se něco nepovede, okamžitě to zjistíte a budete mít užitečné informace o řešení potíží, se kterými můžete pracovat.

Nákup nebo pronájem řešení telemetrie

Poznámka

Tento článek byl napsán před vydáním Application Insights . Application Insights je upřednostňovaný přístup pro telemetrická řešení v Azure. Další informace najdete v tématu Nastavení Application Insights pro web ASP.NET .

Jedna z věcí, která je na cloudovém prostředí skvělá, je, že je opravdu snadné si koupit nebo pronajmout cestu k vítězství. Příkladem je telemetrie. Bez velkého úsilí můžete zprovoznění a zprovoznění opravdu dobrého telemetrických systémů, které jsou velmi nákladově efektivní. Existuje spousta skvělých partnerů, kteří se integrují s Azure, a někteří z nich mají úrovně Free, takže můžete získat základní telemetrii k ničemu. Tady je jen několik z nich, které jsou aktuálně dostupné v Azure:

• New Relic
• AppDynamics
• Dynatrace

Microsoft System Center obsahuje také funkce monitorování.

Rychle si projdeme nastavení New Relic, abychom ukázali, jak snadné může být použití telemetrického systému.

Na portálu pro správu Azure se zaregistrujte ke službě. Klikněte na Nový a potom na Store. Zobrazí se dialogové okno Zvolit doplněk . Posuňte se dolů a klikněte na Nový relikvii.

Klikněte na šipku doprava a zvolte požadovanou úroveň služby. Pro tuto ukázku použijeme úroveň Free.

Klikněte na šipku doprava, potvrďte "nákup" a New Relic se teď na portálu zobrazí jako doplněk.

Klikněte na Informace o připojení a zkopírujte licenční klíč.

Na portálu přejděte na kartu Konfigurovat pro vaši webovou aplikaci, nastavte Sledování výkonu na Doplněk a nastavte rozevírací seznam Zvolit doplněk na New Relic. Potom klikněte na Uložit.

V sadě Visual Studio nainstalujte do aplikace balíček NuGet New Relic.

Nasaďte aplikaci do Azure a začněte ji používat. Vytvořte několik úloh Fix It, které zajistí nějakou aktivitu pro New Relic k monitorování.

Pak se vraťte na stránku New Relic na kartě Doplňky na portálu a klikněte na Spravovat. Portál vás pošle na portál pro správu New Relic s použitím jednotného přihlašování pro ověřování, takže nemusíte znovu zadávat svoje přihlašovací údaje. Na stránce Přehled najdete různé statistiky výkonu. (Kliknutím na obrázek zobrazíte úplnou velikost stránky přehledu.)

Tady je jenom pár statistik, které můžete vidět:

• Průměrná doba odezvy v různých denních časech

  

• Propustnost (v požadavcích za minutu) v různých denních časech

  

• Čas procesoru serveru strávený zpracováním různých požadavků HTTP.

  

• Čas procesoru strávený v různých částech kódu aplikace:

  

• Historická statistika výkonu.

  

• Volání externích služeb, jako je služba Blob Service, a statistiky o tom, jak spolehlivá a responzivní služba byla.

  

  

  

• Informace o tom, kde na světě nebo odkud pochází provoz webových aplikací v USA

  

Můžete také nastavit sestavy a události. Můžete například kdykoliv, když se vám začnou zobrazovat chyby, poslat e-mail s upozorněním na problém pracovníky podpory.

New Relic je jen jedním z příkladů telemetrického systému. to vše můžete získat i z jiných služeb. Krása cloudu spočívá v tom, že bez nutnosti psát kód a s minimálními nebo žádnými náklady můžete najednou získat mnohem více informací o tom, jak se vaše aplikace používá a s čím se vaši zákazníci skutečně setkávají.

Protokolování pro přehled

Balíček telemetrie je dobrým prvním krokem, ale stále musíte instrumentovat vlastní kód. Služba telemetrie vám řekne, když dojde k problému, a řekne vám, s čím se zákazníci setkávají, ale nemusí vám poskytnout velký přehled o tom, co se děje ve vašem kódu.

Nechcete, abyste museli vzdáleně používat produkční server, abyste viděli, co vaše aplikace dělá. To může být praktické, když máte jeden server, ale co když jste škálovali na stovky serverů a nevíte, ke kterým serverům je potřeba vzdáleně připojit? Protokolování by mělo poskytovat dostatek informací, abyste nikdy nemuseli vzdáleně zacházet s produkčními servery, abyste mohli analyzovat a ladit problémy. Měli byste protokolovat dostatek informací, abyste mohli problémy izolovat výhradně prostřednictvím protokolů.

Přihlášení do produkčního prostředí

Spousta lidí zapne trasování v produkčním prostředí jenom v případech, kdy dojde k problému a chtějí ladit. To může způsobovat značné zpoždění mezi časem, kdy o problému víte, a časem, kdy získáte užitečné informace o řešení potíží. A informace, které získáte, nemusí být užitečné pro občasné chyby.

V cloudovém prostředí, kde je úložiště levné, doporučujeme vždy nechat přihlášení v produkčním prostředí. Když dojde k chybám, máte je už zaprotokolované a máte historická data, která vám můžou pomoct analyzovat problémy, které se vyvíjejí v průběhu času nebo k nim dochází pravidelně v různých časech. Proces vymazání můžete automatizovat a odstranit staré protokoly, ale možná zjistíte, že nastavení takového procesu je nákladnější než uchovávání protokolů.

Další náklady na protokolování jsou triviální v porovnání s časem a penězi, které můžete ušetřit tím, že budete mít všechny potřebné informace už k dispozici, když se něco nepovede. Když vám někdo řekne, že měl náhodnou chybu někdy kolem 8:00 včera večer, ale nepamatuje si ji, můžete snadno zjistit, v čem byl problém.

Za méně než 4 USD měsíčně můžete mít po ruce 50 gigabajtů protokolů a dopad protokolování na výkon je triviální, pokud máte na paměti jednu věc – abyste se vyhnuli kritickým bodům výkonu, ujistěte se, že je vaše knihovna protokolování asynchronní.

Odlišení protokolů, které informují o protokolech, které vyžadují akci

Protokoly mají informovat (chci, abyste něco věděli) nebo ACT (chci, abyste něco udělali). Dávejte pozor, abyste psali protokoly ACT pouze pro problémy, které skutečně vyžadují, aby osoba nebo automatizovaný proces podnikl nějakou akci. Příliš mnoho protokolů ACT bude vytvářet šum, což vyžaduje příliš mnoho práce na to, aby bylo možné projít všechno, aby bylo možné najít skutečné problémy. A pokud vaše protokoly ACT automaticky aktivují nějakou akci, jako je odesílání e-mailů pracovníkům podpory, vyhněte se aktivaci tisíců takových akcí jediným problémem.

V trasování .NET System.Diagnostics je možné protokolům přiřadit úroveň Chyba, Upozornění, Informace a Ladění/Podrobné ladění. Protokoly ACT můžete odlišit od protokolů INFORM tím, že si pro protokoly ACT zarezervujete úroveň chyb a použijete nižší úrovně pro protokoly INFORM.

Konfigurace úrovní protokolování za běhu

I když je vhodné mít protokolování vždy zapnuté v produkčním prostředí, dalším osvědčeným postupem je implementace protokolovací architektury, která vám umožní upravit úroveň podrobností, které protokolujete, za běhu, aniž byste museli aplikaci znovu nasadit nebo restartovat. Když například použijete trasovací zařízení v System.Diagnostics nástroji , můžete vytvořit protokoly Chyb, Upozornění, Informace a Ladění/Podrobné. Doporučujeme, abyste vždy protokolovali protokoly chyb, upozornění a informací v produkčním prostředí a měli byste mít možnost dynamicky přidávat ladění nebo podrobné protokolování pro řešení potíží pro případ od případu.

Web Apps v Azure App Service mají integrovanou podporu zápisu System.Diagnostics protokolů do systému souborů, služby Table Storage nebo úložiště objektů blob. Pro každý cíl úložiště můžete vybrat různé úrovně protokolování a úroveň protokolování můžete průběžně měnit bez restartování aplikace. Podpora úložiště objektů blob usnadňuje spouštění analytických úloh HDInsight v protokolech aplikací, protože HDInsight ví, jak pracovat s úložištěm objektů blob přímo.

Protokolování výjimek

Nepokládejte jen výjimky. ToString() v kódu protokolování. To vynechává kontextové informace. V případě chyb SQL vynechá číslo chyby SQL. U všech výjimek uveďte informace o kontextu, samotnou výjimku a vnitřní výjimky, abyste měli jistotu, že poskytujete vše, co bude potřeba pro řešení potíží. Kontextové informace můžou například zahrnovat název serveru, identifikátor transakce a uživatelské jméno (ale ne heslo nebo tajné kódy!).

Pokud spoléháte na to, že každý vývojář udělá správnou věc s protokolováním výjimek, některé z nich ne. Aby se zajistilo, že se to provede správným způsobem pokaždé, zabudujte zpracování výjimek přímo do rozhraní protokolovacího nástroje: předejte objekt výjimky samotný do třídy protokolovacího nástroje a protokolujte data výjimky správně do třídy protokolovacího nástroje.

Protokolování volání služeb

Důrazně doporučujeme zapsat protokol pokaždé, když vaše aplikace zavolá do služby, ať už se jedná o databázi, rozhraní REST API nebo jakoukoli externí službu. Do protokolů zahrňte nejen údaj o úspěchu nebo neúspěchu, ale také o tom, jak dlouho jednotlivé požadavky trvaly. V cloudovém prostředí se často setkáte s problémy souvisejícími se zpomalením než úplnými výpadky. Něco, co normálně trvá 10 milisekund, může najednou začít trvat sekundu. Když vám někdo řekne, že je vaše aplikace pomalá, chcete mít možnost podívat se na New Relic nebo jinou telemetrickou službu, kterou máte, a ověřit jeho zkušenosti. Pak chcete mít možnost podívat se na vlastní protokoly, abyste se mohli podívat na podrobnosti o tom, proč je pomalá.

Použití rozhraní ILogger

Při vytváření produkční aplikace doporučujeme vytvořit jednoduché rozhraní ILogger a nalepit do něj některé metody. To usnadňuje pozdější změnu implementace protokolování a nemusí k tomu projít veškerý kód. Třídu bychom mohli používat System.Diagnostics.Trace v celé aplikaci Fix It, ale místo toho ji používáme pod stříškou ve třídě protokolování, která implementuje ILogger, a v celé aplikaci provádíme volání metody ILogger .

Pokud tak budete chtít, aby vaše protokolování bylo bohatší, můžete nahradit System.Diagnostics.Trace libovolným požadovaným mechanismem protokolování. Například s růstem vaší aplikace se můžete rozhodnout, že chcete použít komplexnější protokolovací balíček, jako je NLog nebo Blok aplikace protokolování podnikové knihovny. (Log4Net je další oblíbená protokolovací architektura, ale neprovádí asynchronní protokolování.)

Jedním z možných důvodů pro použití architektury, jako je NLog, je usnadnit rozdělení výstupu protokolování do samostatných úložišť dat s velkým objemem a vysokou hodnotou. To vám pomůže efektivně ukládat velké objemy dat INFORM, na která nepotřebujete provádět rychlé dotazy, a přitom zachovat rychlý přístup k datům ACT.

Sémantické protokolování

Relativně nový způsob protokolování, který může generovat užitečnější diagnostické informace, najdete v tématu Blok aplikací sémantického protokolování podnikové knihovny. Slab používá trasování událostí pro Windows (ETW) a podporu EventSource v .NET 4.5, aby vám umožnila vytvářet strukturovanější protokoly s možností dotazování. Pro každý typ události, kterou protokolujete, definujete jinou metodu, která umožňuje přizpůsobit informace, které zadáváte. Pokud chcete například zaznamenat chybu SQL Database, můžete volat metodu LogSQLDatabaseError . U tohoto typu výjimky víte, že klíčovou informací je číslo chyby, takže můžete do podpisu metody zahrnout parametr čísla chyby a zaznamenat číslo chyby jako samostatné pole v záznamu protokolu, který napíšete. Vzhledem k tomu, že je číslo v samostatném poli, můžete snadněji a spolehlivěji získat sestavy založené na číslech chyb SQL, než kdybyste číslo chyby zřetězovali do řetězce zprávy.

Protokolování v aplikaci Fix It

Rozhraní ILogger

Zde je ILogger rozhraní v aplikaci Fix It.

public interface ILogger
{
    void Information(string message);
    void Information(string fmt, params object[] vars);
    void Information(Exception exception, string fmt, params object[] vars);

    void Warning(string message);
    void Warning(string fmt, params object[] vars);
    void Warning(Exception exception, string fmt, params object[] vars);

    void Error(string message);
    void Error(string fmt, params object[] vars);
    void Error(Exception exception, string fmt, params object[] vars);

    void TraceApi(string componentName, string method, TimeSpan timespan);
    void TraceApi(string componentName, string method, TimeSpan timespan, string properties);
    void TraceApi(string componentName, string method, TimeSpan timespan, string fmt, params object[] vars);
}

Tyto metody umožňují psát protokoly na stejných čtyřech úrovních, které podporuje System.Diagnostics. Metody TraceApi slouží k protokolování volání externí služby s informacemi o latenci. Můžete také přidat sadu metod pro úroveň Debug/Verbose.

Protokolovací implementace rozhraní ILogger

Implementace rozhraní je opravdu jednoduchá. V podstatě jen volá standardní metody System.Diagnostics . Následující fragment kódu ukazuje všechny tři metody Information a každou z nich jednu.

public class Logger : ILogger
{
    public void Information(string message)
    {
        Trace.TraceInformation(message);
    }

    public void Information(string fmt, params object[] vars)
    {
        Trace.TraceInformation(fmt, vars);
    }

    public void Information(Exception exception, string fmt, params object[] vars)
    {
        var msg = String.Format(fmt, vars);
        Trace.TraceInformation(string.Format(fmt, vars) + ";Exception Details={0}", exception.ToString());
    }

    public void Warning(string message)
    {
        Trace.TraceWarning(message);
    }

    public void Error(string message)
    {
        Trace.TraceError(message);
    }

    public void TraceApi(string componentName, string method, TimeSpan timespan, string properties)
    {
        string message = String.Concat("component:", componentName, ";method:", method, ";timespan:", timespan.ToString(), ";properties:", properties);
        Trace.TraceInformation(message);
    }
}

Volání metod ILogger

Pokaždé, když kód v aplikaci Fix It zachytí výjimku, volá metodu ILogger k protokolování podrobností o výjimce. A pokaždé, když volá databázi, službu Blob service nebo rozhraní REST API, spustí před voláním stopky, zastaví stopky, když se služba vrátí, a zaznamená uplynulý čas spolu s informacemi o úspěchu nebo neúspěchu.

Všimněte si, že zpráva protokolu obsahuje název třídy a název metody. Je vhodné zajistit, aby zprávy protokolu identifikovaly, jaká část kódu aplikace je napsala.

public class FixItTaskRepository : IFixItTaskRepository
{
    private MyFixItContext db = new MyFixItContext();
    private ILogger log = null;

    public FixItTaskRepository(ILogger logger)
    {
        log = logger;
    }

    public async Task<FixItTask> FindTaskByIdAsync(int id)
    {
        FixItTask fixItTask = null;
        Stopwatch timespan = Stopwatch.StartNew();

        try
        {
            fixItTask = await db.FixItTasks.FindAsync(id);
            
            timespan.Stop();
            log.TraceApi("SQL Database", "FixItTaskRepository.FindTaskByIdAsync", timespan.Elapsed, "id={0}", id);
        }
        catch(Exception e)
        {
            log.Error(e, "Error in FixItTaskRepository.FindTaskByIdAsynx(id={0})", id);
        }

        return fixItTask;
    }

Teď, když aplikace Fix It provede volání SQL Database, uvidíte volání, metodu, která ji volala, a přesně, kolik času trvalo.

Pokud procházíte protokoly, uvidíte, že doba potřebná k volání databáze je proměnlivá. Tyto informace by mohly být užitečné: protože aplikace toto všechno protokoluje, můžete analyzovat historické trendy výkonu databázové služby v průběhu času. Například služba může být většinu času rychlá, ale požadavky můžou selhat nebo se v určitých denních časech zpomalit odpovědi.

Totéž můžete udělat pro službu Blob Service – pokaždé, když aplikace nahraje nový soubor, zobrazí se protokol a vy můžete přesně vidět, jak dlouho trvalo nahrání jednotlivých souborů.

Je to jen pár řádků kódu navíc, které je potřeba napsat při každém volání služby, a když teď někdo řekne, že narazil na problém, víte přesně, v čem byl problém, jestli se jednalo o chybu, nebo dokonce i o to, jestli byla jen pomalá. Můžete určit zdroj problému, aniž byste se museli vzdáleně připojit k serveru nebo zapnout protokolování po výskytu chyby a doufat, že ho znovu vytvoříte.

Injektáž závislostí v aplikaci Fix It

Může vás zajímat, jak konstruktor úložiště ve výše uvedeném příkladu získá implementaci rozhraní protokolovacího nástroje:

public class FixItTaskRepository : IFixItTaskRepository
{
    private MyFixItContext db = new MyFixItContext();
    private ILogger log = null;

    public FixItTaskRepository(ILogger logger)
    {
        log = logger;
    }

K připojení rozhraní k implementaci aplikace používá injektáž závislostí (DI) s aplikací AutoFac. DI umožňuje použít objekt založený na rozhraní na mnoha místech v celém kódu a musí zadat pouze na jednom místě implementace, která se použije při vytvoření instance rozhraní. To usnadňuje změnu implementace: například můžete chtít nahradit protokolovací nástroj System.Diagnostics protokolovacím nástrojem NLog. Nebo pro automatizované testování můžete chtít nahradit napodobenou verzi protokolovacího nástroje.

Aplikace Fix It používá di ve všech úložištích a všech kontrolerů. Konstruktory tříd kontroleru získají rozhraní ITaskRepository stejným způsobem, jakým úložiště získá protokolovací rozhraní:

public class DashboardController : Controller
{
    private IFixItTaskRepository fixItRepository = null;

    public DashboardController(IFixItTaskRepository repository)
    {
        fixItRepository = repository;
    }

Aplikace používá knihovnu AutoFac DI k automatickému poskytování instancí TaskRepository a Logger pro tyto konstruktory.

public class DependenciesConfig
{
    public static void RegisterDependencies()
    {
        var builder = new ContainerBuilder();

        builder.RegisterControllers(typeof(MvcApplication).Assembly);
        builder.RegisterType<Logger>().As<ILogger>().SingleInstance();

        builder.RegisterType<FixItTaskRepository>().As<IFixItTaskRepository>();
        builder.RegisterType<PhotoService>().As<IPhotoService>().SingleInstance();
        builder.RegisterType<FixItQueueManager>().As<IFixItQueueManager>();

        var container = builder.Build();
        DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
    }
}

Tento kód v podstatě říká, že kdekoli konstruktor potřebuje ILogger rozhraní, předat instanci Třídy Logger , a kdykoli potřebuje IFixItTaskRepository rozhraní, předat instanci FixItTaskRepository třídy.

AutoFac je jednou z mnoha architektur pro injektáž závislostí, které můžete použít. Další oblíbenou možností je Unity, kterou doporučuje a podporuje Microsoft Patterns and Practices.

Integrovaná podpora protokolování v Azure

Azure podporuje pro Web Apps v Azure App Service následující typy protokolování:

• Trasování System.Diagnostics (můžete zapínat a vypínat a nastavovat úrovně za běhu bez restartování webu).
• Události Windows.
• Protokoly služby IIS (HTTP/FREB).

Azure podporuje v Cloud Services následující typy protokolování:

• Trasování System.Diagnostics.
• Čítače výkonu.
• Události Windows.
• Protokoly služby IIS (HTTP/FREB).
• Monitorování vlastních adresářů.

Aplikace Fix It používá trasování System.Diagnostics. K povolení protokolování System.Diagnostics ve webové aplikaci stačí přepnout přepínač na portálu nebo volat rozhraní REST API. Na portálu klikněte na kartu Konfigurace pro váš web a posuňte se dolů, abyste viděli část Application Diagnostics . Protokolování můžete zapnout nebo vypnout a vybrat požadovanou úroveň protokolování. Azure může protokoly zapsat do systému souborů nebo do účtu úložiště.

Po povolení protokolování v Azure se protokoly zobrazí v okně Výstup sady Visual Studio při jejich vytváření.

Můžete si také nechat protokoly zapsat do účtu úložiště a zobrazit je pomocí libovolného nástroje, který má přístup ke službě Azure Storage Table, jako je Průzkumník serveru v sadě Visual Studio nebo Průzkumník služby Azure Storage.

Souhrn

Je velmi jednoduché implementovat předem nastavený telemetrický systém, instrumentovat protokolování ve vlastním kódu a nakonfigurovat protokolování v Azure. A když máte produkční problémy, pomůže vám kombinace telemetrických systémů a vlastních protokolů rychle vyřešit problémy, než se stanou hlavními problémy pro vaše zákazníky.

V další kapitole se podíváme na to, jak zpracovávat přechodné chyby, aby se nestaly produkčními problémy, které musíte prozkoumat.

Zdroje informací

Další informace najdete v následujících materiálech.

Dokumentace hlavně o telemetrii:

• Vzory a postupy Microsoftu – Pokyny k Azure Viz Pokyny k instrumentaci a telemetrii, Pokyny k měření služeb, Model monitorování stavu koncového bodu a Model rekonfigurace modulu runtime.
• Penny Pinching in the Cloud: Povolení funkce New Relic Performance Monitoring na webech Azure.
• Osvědčené postupy pro návrh služeb Large-Scale v Azure Cloud Services White paper od Marka Simmse a Michaela Thomassyho. Viz část Telemetrie a diagnostika.
• Vývoj nové generace s využitím Application Insights Článek msdn Magazine.

Dokumentace týkající se protokolování:

• Sémantický blok aplikace protokolování (SLAB) Neil Mackenzie představuje případ sémantického protokolování pomocí SLAB.
• Vytváření strukturovaných a smysluplných protokolů pomocí sémantického protokolování (Video) Julian Dominguez představuje případ sémantického protokolování pomocí SLAB.
• Protokolování EF6 SQL – část 1: Jednoduché protokolování Arthur Vickers ukazuje, jak protokolovat dotazy spuštěné rozhraním Entity Framework v EF 6.
• Odolnost připojení a zachycování příkazů pomocí Entity Frameworku v aplikaci ASP.NET MVC. Čtvrtý z devítidílné série kurzů ukazuje, jak pomocí funkce zachycování příkazů EF 6 protokolovat příkazy SQL odeslané do databáze rozhraním Entity Framework.
• Vylepšení protokolování pomocí atributů informací o volajícím V jazyce C# 5.0 Jak snadno protokolovat název volací metody bez pevného kódování do literálů nebo použití reflexe k ručnímu získání.

Dokumentace týkající se řešení potíží:

• Blog o řešení potíží s Azure & ladění
• AzureTools – diagnostický nástroj používaný týmem podpory pro vývojáře Azure. Představuje a poskytuje odkaz ke stažení nástroje, který je možné použít na virtuálním počítači Azure ke stažení a spuštění široké škály diagnostických a monitorovacích nástrojů. Užitečné, když potřebujete diagnostikovat problém na konkrétním virtuálním počítači.
• Řešení potíží s webovou aplikací v Azure App Service pomocí sady Visual Studio Podrobný kurz pro zahájení práce s trasováním System.Diagnostics a vzdáleným laděním

Videa:

• FailSafe: Vytváření škálovatelných a odolných Cloud Services. Devítidílné série od Ulricha Homanna, Marca Mercuriho a Marka Simmse. Prezentuje koncepty a architektonické principy vysoké úrovně velmi přístupným a zajímavým způsobem, a to díky příběhům ze zkušeností týmu CAT (Customer Advisory Team) Microsoftu se skutečnými zákazníky. Epizody 4 a 9 se vztahují k monitorování a telemetrii. Epizoda 9 obsahuje přehled služeb monitorování MetricsHub, AppDynamics, New Relic a PagerDuty.
• Budování ve velkém: Poznatky získané od zákazníků Azure – část II. Mark Simms hovoří o návrhu pro selhání a instrumentaci všeho. Podobá se sérii Failsafe, ale obsahuje další podrobnosti o postupu.

Ukázka kódu:

• Základy cloudových služeb v Azure Ukázková aplikace vytvořená poradním týmem pro zákazníky Microsoft Azure Demonstruje postupy telemetrie i protokolování, jak je vysvětleno v následujících článcích. Ukázka implementuje protokolování aplikace pomocí protokolu NLog. Související dokumentaci najdete v sérii čtyř článků na wikiwebu TechNet o telemetrii a protokolování.

PředchozíDalší