Diagnostika výjimek ve webových aplikacích pomocí Application Insights
Výjimky ve webových aplikacích je možné hlásit pomocí Application Insights. Neúspěšné požadavky můžete korelovat s výjimkami a dalšími událostmi na klientovi i serveru, abyste mohli rychle diagnostikovat příčiny. V tomto článku se dozvíte, jak nastavit generování sestav výjimek, explicitně hlásit výjimky, diagnostikovat selhání a další.
Nastavení generování sestav výjimek
Application Insights můžete nastavit tak, aby hlásily výjimky, ke kterým dochází na serveru nebo v klientovi. V závislosti na platformě, na které aplikaci pracujete, budete potřebovat příslušné rozšíření nebo sadu SDK.
Serverová strana
Pokud chcete mít výjimky hlášené z aplikace na straně serveru, zvažte následující scénáře:
- Webové aplikace Azure: Přidání rozšíření Application Insights
- Virtuální počítače Azure a aplikace hostované službou IIS virtuálních počítačů Azure: Přidání rozšíření monitorování aplikací
- Instalace sady Application Insights SDK do kódu aplikace nebo
- Webové servery SLUŽBY IIS: Spuštění agenta Application Insights nebo
- Webové aplikace v Javě: Povolení agenta Java
Klientská strana
Sada JavaScript SDK poskytuje možnost generování sestav výjimek na straně klienta, ke kterým dochází ve webových prohlížečích. Pokud chcete nastavit generování sestav výjimek v klientovi, podívejte se na Application Insights pro webové stránky.
Aplikační architektury
U některých aplikačních architektur je potřeba trochu více konfigurace, zvažte následující technologie:
Důležité
Tento článek se konkrétně zaměřuje na aplikace rozhraní .NET Framework z pohledu příkladu kódu. Některé metody, které fungují pro rozhraní .NET Framework, jsou zastaralé v sadě .NET Core SDK. Další informace najdete v dokumentaci k sadě .NET Core SDK při vytváření aplikací pomocí .NET Core.
Diagnostika výjimek pomocí sady Visual Studio
Otevřete řešení aplikace v sadě Visual Studio. Spusťte aplikaci na serveru nebo na vývojovém počítači pomocí klávesy F5. Znovu vytvořte výjimku.
Otevřete okno telemetrie vyhledávání Application Insights v sadě Visual Studio. Při ladění vyberte rozevírací seznam Application Insights .
Vyberte sestavu výjimek, která zobrazí trasování zásobníku. Pokud chcete otevřít příslušný soubor kódu, vyberte v trasování zásobníku odkaz na řádek.
Pokud je CodeLens povolený, zobrazí se data o výjimkách:
Diagnostika selhání pomocí webu Azure Portal
Application Insights nabízí kurátorované prostředí správy výkonu aplikací (APM), které vám pomůže diagnostikovat selhání v monitorovaných aplikacích. Začněte tak, že v nabídce prostředků Application Insights v části Prošetření vyberete možnost Selhání. Zobrazí se trendy četnosti selhání pro vaše požadavky, kolik z nich selhává a kolik uživatelů má vliv. V celkovém zobrazení uvidíte některé z nejužitečnějších distribucí specifických pro vybranou neúspěšnou operaci, včetně prvních tří kódů odpovědí, prvních tří typů výjimek a prvních tří typů závislostí, které selhávají.
Pokud chcete zkontrolovat reprezentativní ukázky pro každou z těchto podmnožinu operací, vyberte odpovídající odkaz. Pokud chcete například diagnostikovat výjimky, můžete vybrat počet konkrétní výjimky, která se má zobrazit na kartě Podrobnosti o celé transakci :
Alternativně můžete místo zobrazení výjimek konkrétní neúspěšné operace začít z celkového zobrazení výjimek přepnutím na kartu Výjimky v horní části. Tady uvidíte všechny výjimky shromážděné pro vaši monitorovanou aplikaci.
Vlastní trasování a data protokolu
Pokud chcete získat diagnostická data specifická pro vaši aplikaci, můžete vložit kód pro odesílání vlastních telemetrických dat. Vaše vlastní telemetrická data nebo data protokolu se zobrazují v diagnostickém vyhledávání společně s požadavkem, zobrazením stránky a dalšími automaticky shromážděnými daty.
Pomocí rozhraní Microsoft.VisualStudio.ApplicationInsights.TelemetryClientAPI máte k dispozici několik rozhraní API:
- TelemetryClient.TrackEvent se obvykle používá pro monitorování vzorů využití, ale data, která odesílá, se také zobrazují v části Vlastní události v diagnostickém vyhledávání. Události jsou pojmenované a můžou obsahovat vlastnosti řetězců a číselné metriky, na kterých můžete filtrovat diagnostické vyhledávání.
- TelemetryClient.TrackTrace umožňuje odesílat delší data, například informace POST.
- TelemetryClient.TrackException odesílá podrobnosti o výjimce, jako jsou trasování zásobníku do Application Insights.
Pokud chcete tyto události zobrazit, otevřete v nabídce vlevo hledání , vyberte rozevírací nabídku Typy událostí a pak zvolte Vlastní událost, Trasování nebo Výjimka.
Poznámka
Pokud vaše aplikace generuje mnoho telemetrických dat, sníží modul adaptivního vzorkování automaticky objem dat odesílaných na portál tím, že budou odesílány pouze reprezentativní vzorky událostí. Události, které jsou součástí stejné operace, budou vybrány nebo zrušeny jako skupina, abyste mohli přecházet mezi souvisejícími událostmi. Další informace najdete v tématu Vzorkování v Application Insights.
Jak zobrazit data POST žádosti
Podrobnosti žádosti nezahrnují data odeslaná do vaší aplikace do volání POST. Pokud chcete, aby se tato data nahlásila:
- Nainstalujte sadu SDK do projektu aplikace.
- Vložte do aplikace kód pro volání Microsoft.ApplicationInsights.TrackTrace(). Odešlete data POST v parametru zprávy. Povolená velikost je omezena, takže byste se měli pokusit odeslat jenom základní data.
- Při prošetření neúspěšného požadavku vyhledejte přidružené trasování.
Zaznamenávání výjimek a souvisejících diagnostických dat
Zpočátku se na portálu nezobrazí všechny výjimky, které způsobují chyby ve vaší aplikaci. Zobrazí se všechny výjimky prohlížeče (pokud na webových stránkách používáte sadu JavaScript SDK ). Většina výjimek serveru je ale zachycena službou IIS a abyste je viděli, musíte napsat trochu kódu.
Další možnosti:
- Výjimky protokolu explicitně vložením kódu do obslužných rutin výjimek pro hlášení výjimek.
- Automatické zachytávání výjimek konfigurací architektury ASP.NET Nezbytné dodatky se liší pro různé typy architektury.
Explicitně se hlásí výjimky
Nejjednodušší způsob je vložit volání do trackException()
obslužné rutiny výjimky.
try
{
// ...
}
catch (ex)
{
appInsights.trackException(ex, "handler loc",
{
Game: currentGame.Name,
State: currentGame.State.ToString()
});
}
var telemetry = new TelemetryClient();
try
{
// ...
}
catch (Exception ex)
{
var properties = new Dictionary<string, string>
{
["Game"] = currentGame.Name
};
var measurements = new Dictionary<string, double>
{
["Users"] = currentGame.Users.Count
};
// Send the exception telemetry:
telemetry.TrackException(ex, properties, measurements);
}
Dim telemetry = New TelemetryClient
Try
' ...
Catch ex as Exception
' Set up some properties:
Dim properties = New Dictionary (Of String, String)
properties.Add("Game", currentGame.Name)
Dim measurements = New Dictionary (Of String, Double)
measurements.Add("Users", currentGame.Users.Count)
' Send the exception telemetry:
telemetry.TrackException(ex, properties, measurements)
End Try
Parametry vlastností a měření jsou volitelné, ale jsou užitečné pro filtrování a přidávání dalších informací. Pokud máte například aplikaci, která může spouštět několik her, můžete najít všechny sestavy výjimek související s konkrétní hrou. Do každého slovníku můžete přidat libovolný počet položek.
Výjimky prohlížečů
Většina výjimek prohlížeče se hlásí.
Pokud vaše webová stránka obsahuje soubory skriptů ze sítí pro doručování obsahu nebo jiných domén, ujistěte se, že má značka skriptu atribut crossorigin="anonymous"
a že server odesílá hlavičky CORS. To vám umožní získat trasování zásobníku a podrobnosti pro neošetřené výjimky JavaScriptu z těchto prostředků.
Opakované použití klienta telemetrie
Poznámka
Doporučuje TelemetryClient
se vytvořit instanci jednou a znovu použít po celou dobu životnosti aplikace.
Pomocí injektáže závislostí (DI) v .NET, příslušné sadě .NET SDK a správné konfiguraci Application Insights pro DI můžete vyžadovat TelemetryClient jako parametr konstruktoru.
public class ExampleController : ApiController
{
private readonly TelemetryClient _telemetryClient;
public ExampleController(TelemetryClient telemetryClient)
{
_telemetryClient = telemetryClient;
}
}
V předchozím příkladu TelemetryClient
se vloží do ExampleController
třídy.
Webové formuláře
U webových formulářů bude modul HTTP moct shromažďovat výjimky, pokud nejsou nakonfigurované žádné přesměrování .CustomErrors
Pokud však máte aktivní přesměrování, přidejte následující řádky do Application_Error
funkce v Global.asax.cs.
void Application_Error(object sender, EventArgs e)
{
if (HttpContext.Current.IsCustomErrorEnabled &&
Server.GetLastError () != null)
{
_telemetryClient.TrackException(Server.GetLastError());
}
}
V předchozím příkladu _telemetryClient
je proměnná TelemetryClienttypu s oborem třídy .
MVC
Počínaje sadou Application Insights Web SDK verze 2.6 (beta3 a novější) application Insights shromažďuje neošetřené výjimky vyvolané metodami kontrolerů MVC 5 a novější. Pokud jste dříve přidali vlastní obslužnou rutinu pro sledování takových výjimek, můžete ji odebrat, abyste zabránili dvojitému sledování výjimek.
Existuje řada scénářů, kdy filtr výjimek nemůže správně zpracovat chyby, když dojde k vyvolání výjimek:
- Z konstruktorů kontroleru.
- Z obslužných rutin zpráv.
- Během směrování.
- Během serializace obsahu odpovědi.
- Během spuštění aplikace.
- V úkolech na pozadí.
Všechny výjimky zpracovávané aplikací je stále potřeba sledovat ručně.
Neošetřené výjimky pocházející z kontrolerů obvykle způsobí odpověď 500 Vnitřní chyba serveru. Pokud je taková odpověď ručně vytvořena jako výsledek zpracovávané výjimky (nebo vůbec žádné výjimky), sleduje se v odpovídající telemetrii požadavku s ResultCode
500, ale sada Application Insights SDK nemůže sledovat odpovídající výjimku.
Podpora předchozích verzí
Pokud používáte MVC 4 (a předchozí) sady Application Insights Web SDK 2.5 (a předchozí), projděte si následující příklady sledování výjimek.
Pokud je Off
konfigurace CustomErrors , budou výjimky k dispozici pro shromažďování modulu HTTP. Pokud je RemoteOnly
to ale (výchozí) nebo On
, výjimka se vymaže a nebude dostupná pro Application Insights, aby se automaticky shromažďovala. Můžete to vyřešit přepsáním třídy System.Web.Mvc.HandleErrorAttribute a použitím přepsáné třídy, jak je znázorněno pro různé verze MVC níže (zdroj GitHubu):
using System;
using System.Web.Mvc;
using Microsoft.ApplicationInsights;
namespace MVC2App.Controllers
{
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
public class AiHandleErrorAttribute : HandleErrorAttribute
{
public override void OnException(ExceptionContext filterContext)
{
if (filterContext != null && filterContext.HttpContext != null && filterContext.Exception != null)
{
//If customError is Off, then AI HTTPModule will report the exception
if (filterContext.HttpContext.IsCustomErrorEnabled)
{ //or reuse instance (recommended!). see note above
var ai = new TelemetryClient();
ai.TrackException(filterContext.Exception);
}
}
base.OnException(filterContext);
}
}
}
MVC 2
Nahraďte atribut HandleError novým atributem v řadičích.
namespace MVC2App.Controllers
{
[AiHandleError]
public class HomeController : Controller
{
// Omitted for brevity
}
}
MVC 3
Zaregistrujte AiHandleErrorAttribute
se jako globální filtr v souboru Global.asax.cs:
public class MyMvcApplication : System.Web.HttpApplication
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new AiHandleErrorAttribute());
}
}
MVC 4, MVC5
Zaregistrujte AiHandleErrorAttribute
se jako globální filtr ve službě FilterConfig.cs:
public class FilterConfig
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
// Default replaced with the override to track unhandled exceptions
filters.Add(new AiHandleErrorAttribute());
}
}
Webové rozhraní API
Počínaje sadou Application Insights Web SDK verze 2.6 (beta3 a novější) application Insights shromažďuje neošetřené výjimky vyvolané metodami kontroleru automaticky pro WebAPI 2+. Pokud jste dříve přidali vlastní obslužnou rutinu pro sledování takových výjimek (jak je popsáno v následujících příkladech), můžete ji odebrat, abyste zabránili dvojitému sledování výjimek.
Existuje několik případů, které filtry výjimek nemůžou zpracovat. Příklad:
- Výjimky vyvolané konstruktory kontrolerů
- Výjimky vyvolané obslužnými rutinami zpráv
- Výjimky vyvolané během směrování
- Výjimky vyvolané během serializace obsahu odpovědi
- Výjimky vyvolané během spouštění aplikace
- Výjimky vyvolané úlohami na pozadí
Všechny výjimky zpracovávané aplikací je stále potřeba sledovat ručně.
Neošetřené výjimky pocházející z kontrolerů obvykle způsobí odpověď 500 Vnitřní chyba serveru. Pokud je taková odpověď ručně vytvořena jako výsledek zpracovávané výjimky (nebo vůbec žádné výjimky), sleduje se v odpovídající telemetrii požadavku s ResultCode
500, ale sada Application Insights SDK nemůže sledovat odpovídající výjimku.
Podpora předchozích verzí
Pokud používáte WebAPI 1 (a předchozí) sady Application Insights Web SDK 2.5 (a předchozí), projděte si následující příklady sledování výjimek.
Webové rozhraní API 1.x
Přepsání System.Web.Http.Filters.ExceptionFilterAttribute
:
using System.Web.Http.Filters;
using Microsoft.ApplicationInsights;
namespace WebAPI.App_Start
{
public class AiExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext actionExecutedContext)
{
if (actionExecutedContext != null && actionExecutedContext.Exception != null)
{ //or reuse instance (recommended!). see note above
var ai = new TelemetryClient();
ai.TrackException(actionExecutedContext.Exception);
}
base.OnException(actionExecutedContext);
}
}
}
Tento přepsaný atribut můžete přidat do konkrétních kontrolerů nebo ho přidat do globální konfigurace filtru ve WebApiConfig
třídě:
using System.Web.Http;
using WebApi1.x.App_Start;
namespace WebApi1.x
{
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional });
// ...
config.EnableSystemDiagnosticsTracing();
// Capture exceptions for Application Insights:
config.Filters.Add(new AiExceptionFilterAttribute());
}
}
}
Webové rozhraní API 2.x
Přidejte implementaci IExceptionLogger
:
using System.Web.Http.ExceptionHandling;
using Microsoft.ApplicationInsights;
namespace ProductsAppPureWebAPI.App_Start
{
public class AiExceptionLogger : ExceptionLogger
{
public override void Log(ExceptionLoggerContext context)
{
if (context != null && context.Exception != null)
{
//or reuse instance (recommended!). see note above
var ai = new TelemetryClient();
ai.TrackException(context.Exception);
}
base.Log(context);
}
}
}
Přidejte toto do služeb ve službě WebApiConfig:
using System.Web.Http;
using System.Web.Http.ExceptionHandling;
using ProductsAppPureWebAPI.App_Start;
namespace WebApi2WithMVC
{
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
// Web API configuration and services
// Web API routes
config.MapHttpAttributeRoutes();
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional });
config.Services.Add(typeof(IExceptionLogger), new AiExceptionLogger());
}
}
}
Jako alternativy můžete:
- Nahraďte jedinou obslužnou rutinu výjimky vlastní implementací IExceptionHandler. To se volá pouze v případě, že architektura stále dokáže zvolit, která zpráva odpovědi se má odeslat (ne když je připojení přerušeno například).
- Filtry výjimek (jak je popsáno v části o řadičích webového rozhraní API 1.x výše) – nevolá se ve všech případech.
WCF
Přidejte třídu, která rozšiřuje atribut a implementuje IErrorHandler a IServiceBehavior.
using System;
using System.Collections.Generic;
using System.Linq;
using System.ServiceModel.Description;
using System.ServiceModel.Dispatcher;
using System.Web;
using Microsoft.ApplicationInsights;
namespace WcfService4.ErrorHandling
{
public class AiLogExceptionAttribute : Attribute, IErrorHandler, IServiceBehavior
{
public void AddBindingParameters(ServiceDescription serviceDescription,
System.ServiceModel.ServiceHostBase serviceHostBase,
System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints,
System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
{
}
public void ApplyDispatchBehavior(ServiceDescription serviceDescription,
System.ServiceModel.ServiceHostBase serviceHostBase)
{
foreach (ChannelDispatcher disp in serviceHostBase.ChannelDispatchers)
{
disp.ErrorHandlers.Add(this);
}
}
public void Validate(ServiceDescription serviceDescription,
System.ServiceModel.ServiceHostBase serviceHostBase)
{
}
bool IErrorHandler.HandleError(Exception error)
{//or reuse instance (recommended!). see note above
var ai = new TelemetryClient();
ai.TrackException(error);
return false;
}
void IErrorHandler.ProvideFault(Exception error,
System.ServiceModel.Channels.MessageVersion version,
ref System.ServiceModel.Channels.Message fault)
{
}
}
}
Přidejte atribut do implementací služby:
namespace WcfService4
{
[AiLogException]
public class Service1 : IService1
{
// Omitted for brevity
}
}
Čítače výkonu výjimek
Pokud jste na server nainstalovali agenta Azure Monitor Application Insights , můžete získat graf míry výjimek měřené rozhraním .NET. To zahrnuje zpracovávané i neošetřené výjimky .NET.
Otevřete kartu Průzkumníka metrik, přidejte nový graf a vyberte Rychlost výjimek uvedená v části Čítače výkonu.
Rozhraní .NET Framework vypočítá rychlost tím, že spočítá počet výjimek v intervalu a vydělí se délkou intervalu.
To se liší od počtu výjimek vypočítaných portálem Application Insights, který počítá sestavy TrackException. Intervaly vzorkování se liší a sada SDK neodesílá sestavy TrackException pro všechny zpracovávané a neošetřené výjimky.