Diagnostisera undantag i webbappar med Application Insights
Kommentar
Följande dokumentation förlitar sig på det klassiska API:et Application Insights. Den långsiktiga planen för Application Insights är att samla in data med OpenTelemetry. Mer information finns i Aktivera Azure Monitor OpenTelemetry för .NET-, Node.js-, Python- och Java-program och vår OpenTelemetry-översikt. Migreringsvägledning är tillgänglig för .NET, Node.js och Python.
Undantag i webbprogram kan rapporteras med Application Insights. Du kan korrelera misslyckade begäranden med undantag och andra händelser på såväl klienten som servern, vilket innebär att du snabbt kan diagnostisera orsakerna. I den här artikeln får du lära dig hur du konfigurerar undantagsrapportering, rapporterar undantag explicit, diagnostiserar fel med mera.
Konfigurera undantagsrapportering
Du kan konfigurera Application Insights för att rapportera undantag som inträffar på antingen servern eller klienten. Beroende på vilken plattform ditt program är beroende av behöver du rätt tillägg eller SDK.
Serversidan
Om du vill att undantag ska rapporteras från ditt program på serversidan bör du överväga följande scenarier:
- Lägg till Application Insights-tillägget för Azure-webbappar.
- Lägg till programövervakningstillägget för Azure Virtual Machines och Azure Virtual Machine Scale Sets IIS-värdbaserade appar.
- Installera Application Insights SDK i din appkod, kör Application Insights Agent för IIS-webbservrar eller aktivera Java-agenten för Java-webbappar.
Kundsidan
JavaScript SDK ger möjlighet att rapportera undantag på klientsidan som inträffar i webbläsare. Information om hur du konfigurerar undantagsrapportering på klienten finns i Application Insights för webbsidor.
Programramverk
Med vissa programramverk krävs mer konfiguration. Tänk på följande tekniker:
Viktigt!
Den här artikeln fokuserar specifikt på .NET Framework-appar ur ett kodexempelperspektiv. Några av metoderna som fungerar för .NET Framework är föråldrade i .NET Core SDK. Mer information finns i .NET Core SDK-dokumentationen när du skapar appar med .NET Core.
Diagnostisera undantag med hjälp av Visual Studio
Öppna applösningen i Visual Studio. Kör appen, antingen på servern eller på utvecklingsdatorn med hjälp av F5. Återskapa undantaget.
Öppna telemetrifönstret Application Insights Search i Visual Studio. När du felsöker väljer du listrutan Application Insights .
Välj en undantagsrapport för att visa stackspårningen. Om du vill öppna relevant kodfil väljer du en radreferens i stackspårningen.
Om CodeLens är aktiverat visas data om undantagen:
Diagnostisera fel med hjälp av Azure Portal
Application Insights har en hanterad programprestandahantering som hjälper dig att diagnostisera fel i dina övervakade program. Börja genom att gå till resursmenyn Application Insights till vänster under Undersök och välj alternativet Fel .
Du ser trender för felfrekvens för dina begäranden, hur många av dem som misslyckas och hur många användare som påverkas. Vyn Övergripande visar några av de mest användbara distributionerna som är specifika för den valda misslyckade åtgärden. Du ser de tre vanligaste svarskoderna, de tre vanligaste undantagstyperna och de tre vanligaste beroendetyperna som misslyckas.
Om du vill granska representativa exempel för var och en av dessa delmängder av åtgärder väljer du motsvarande länk. Om du till exempel vill diagnostisera undantag kan du välja antalet undantag som ska visas på fliken Transaktionsinformation från slutpunkt till slutpunkt.
I stället för att titta på undantag för en specifik misslyckad åtgärd kan du också börja från den övergripande vyn av undantag genom att växla till fliken Undantag överst . Här kan du se alla undantag som samlas in för din övervakade app.
Anpassad spårning och loggdata
För att få diagnostikdata som är specifika för din app kan du infoga kod för att skicka egna telemetridata. Dina anpassade telemetri- eller loggdata visas i diagnostiksökningen tillsammans med begäran, sidvyn och andra automatiskt insamlade data.
Med hjälp av Microsoft.VisualStudio.ApplicationInsights.TelemetryClienthar du flera TILLGÄNGLIGA API:er:
- TelemetryClient.TrackEvent används vanligtvis för att övervaka användningsmönster, men de data som skickas visas också under Anpassade händelser i diagnostiksökningen. Händelser namnges och kan innehålla strängegenskaper och numeriska mått som du kan filtrera dina diagnostiksökningar på.
- TelemetryClient.TrackTrace låter dig skicka längre data, till exempel POST-information.
- TelemetryClient.TrackException skickar undantagsinformation, till exempel stackspårningar till Application Insights.
Om du vill se dessa händelser öppnar du Sök på den vänstra menyn. Välj den nedrullningsbara menyn Händelsetyper och välj sedan Anpassad händelse, Spårning eller Undantag.
Kommentar
Om din app genererar mycket telemetri minskar modulen för anpassningsbar sampling automatiskt volymen som skickas till portalen genom att endast skicka en representativ del av händelserna. Händelser som ingår i samma åtgärd väljs eller avmarkeras som en grupp så att du kan navigera mellan relaterade händelser. Mer information finns i Sampling i Application Insights.
Se POST-begärandedata
Information om begäran inkluderar inte de data som skickas till din app i ett POST-anrop. Så här rapporterar du dessa data:
- Installera SDK :et i programprojektet.
- Infoga kod i programmet för att anropa Microsoft.ApplicationInsights.TrackTrace(). Skicka POST-data i meddelandeparametern. Det finns en gräns för den tillåtna storleken, så du bör bara försöka skicka viktiga data.
- När du undersöker en misslyckad begäran letar du upp de associerade spårningarna.
Samla in undantag och relaterade diagnostikdata
Först ser du inte alla undantag som orsakar fel i appen i portalen. Du ser eventuella webbläsarfel om du använder JavaScript SDK på dina webbsidor. Men de flesta serverfel fångas av IIS och du måste skriva lite kod för att se dem.
Du kan:
- Logga undantag explicit genom att infoga kod i undantagshanterare för att rapportera undantagen.
- Samla in undantag automatiskt genom att konfigurera ditt ASP.NET ramverk. De nödvändiga tilläggen skiljer sig åt för olika typer av ramverk.
Rapportera undantag explicit
Det enklaste sättet att rapportera är att infoga ett anrop till trackException()
i en undantagshanterare.
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
Parametrarna för egenskaper och mått är valfria, men de är användbara för att filtrera och lägga till extra information. Om du till exempel har en app som kan köra flera spel kan du hitta alla undantagsrapporter som är relaterade till ett visst spel. Du kan lägga till så många objekt som du vill i varje ordlista.
Webbläsarundantag
De flesta webbläsarfel rapporteras.
Om din webbsida innehåller skriptfiler från nätverk för innehållsleverans eller andra domäner kontrollerar du att skripttaggen har attributet crossorigin="anonymous"
och att servern skickar CORS-huvuden. Med det här beteendet kan du hämta en stackspårning och information för ohanterade JavaScript-undantag från dessa resurser.
Återanvänd din telemetriklient
Kommentar
Vi rekommenderar att du instansierar en TelemetryClient
gång och återanvänder den under hela programmets livslängd.
Med Dependency Injection (DI) i .NET, lämplig .NET SDK och korrekt konfiguration av Application Insights för DI, kan du kräva TelemetryClient som en konstruktorparameter.
public class ExampleController : ApiController
{
private readonly TelemetryClient _telemetryClient;
public ExampleController(TelemetryClient telemetryClient)
{
_telemetryClient = telemetryClient;
}
}
I föregående exempel TelemetryClient
matas ExampleController
in i klassen.
Webbformulär
För webbformulär kan HTTP-modulen samla in undantagen när inga omdirigeringar har konfigurerats med CustomErrors
. Men när du har aktiva omdirigeringar lägger du till följande rader i Application_Error
funktionen i Global.asax.cs.
void Application_Error(object sender, EventArgs e)
{
if (HttpContext.Current.IsCustomErrorEnabled &&
Server.GetLastError () != null)
{
_telemetryClient.TrackException(Server.GetLastError());
}
}
I föregående exempel _telemetryClient
är en variabel med klassomfattning av typen TelemetryClient.
MVC
Från och med Application Insights Web SDK version 2.6 (beta 3 och senare) samlar Application Insights in ohanterade undantag som genereras automatiskt i MVC 5+-kontrollantmetoderna. Om du tidigare har lagt till en anpassad hanterare för att spåra sådana undantag kan du ta bort den för att förhindra dubbel spårning av undantag.
Det finns flera scenarier när ett undantagsfilter inte kan hantera fel korrekt när undantag utlöses:
- Från styrenhetskonstruktorer
- Från meddelandehanterare
- Under routning
- Under svarsinnehålls serialisering
- Under programstart
- I bakgrundsaktiviteter
Alla undantag som hanteras av programmet måste fortfarande spåras manuellt. Ohanterade undantag från kontrollanter resulterar vanligtvis i ett svar på 500 "internt serverfel". Om ett sådant svar konstrueras manuellt till följd av ett hanterat undantag, eller inget undantag alls, spåras det i motsvarande telemetri för begäran med ResultCode
500. Application Insights SDK kan dock inte spåra ett motsvarande undantag.
Stöd för tidigare versioner
Om du använder MVC 4 (och tidigare) av Application Insights Web SDK 2.5 (och tidigare) läser du följande exempel för att spåra undantag.
Om CustomErrors-konfigurationen är Off
är undantag tillgängliga för HTTP-modulen att samla in. Men om det är RemoteOnly
(standard) eller On
kommer undantaget att rensas och inte vara tillgängligt för Application Insights att samla in automatiskt. Du kan åtgärda det beteendet genom att åsidosätta klassen System.Web.Mvc.HandleErrorAttribute och tillämpa den åsidosatta klassen enligt de olika MVC-versionerna här (se GitHub-källan):
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)
{
//The attribute should track exceptions only when CustomErrors setting is On
//if CustomErrors is Off, exceptions will be caught by AI HTTP Module
if (filterContext.HttpContext.IsCustomErrorEnabled)
{ //Or reuse instance (recommended!). See note above.
var ai = new TelemetryClient();
ai.TrackException(filterContext.Exception);
}
}
base.OnException(filterContext);
}
}
}
MVC 2
Ersätt Attributet HandleError med det nya attributet i dina kontrollanter:
namespace MVC2App.Controllers
{
[AiHandleError]
public class HomeController : Controller
{
// Omitted for brevity
}
}
MVC 3
Registrera dig AiHandleErrorAttribute
som ett globalt filter i Global.asax.cs:
public class MyMvcApplication : System.Web.HttpApplication
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new AiHandleErrorAttribute());
}
}
MVC 4, MVC 5
Registrera dig AiHandleErrorAttribute
som ett globalt filter i FilterConfig.cs:
public class FilterConfig
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
// Default replaced with the override to track unhandled exceptions
filters.Add(new AiHandleErrorAttribute());
}
}
Webb-API
Från och med Application Insights Web SDK version 2.6 (beta 3 och senare) samlar Application Insights in ohanterade undantag som genereras i kontrollantmetoderna automatiskt för Web API 2+. Om du tidigare har lagt till en anpassad hanterare för att spåra sådana undantag, enligt beskrivningen i följande exempel, kan du ta bort den för att förhindra dubbel spårning av undantag.
Det finns flera fall som undantagsfiltren inte kan hantera. Till exempel:
- Undantag som utlöses från styrenhetskonstruktörer.
- Undantag som utlöses av meddelandehanterare.
- Undantag som utlöses under routning.
- Undantag som utlöses under serialisering av svarsinnehåll.
- Undantag som utlöses när programmet startas.
- Undantag som utlöses i bakgrundsaktiviteter.
Alla undantag som hanteras av programmet måste fortfarande spåras manuellt. Ohanterade undantag från kontrollanter resulterar vanligtvis i ett svar på 500 "internt serverfel". Om ett sådant svar konstrueras manuellt till följd av ett hanterat undantag, eller inget undantag alls, spåras det i en motsvarande telemetri för begäran med ResultCode
500. Application Insights SDK kan dock inte spåra ett motsvarande undantag.
Stöd för tidigare versioner
Om du använder Web API 1 (och tidigare) av Application Insights Web SDK 2.5 (och tidigare) läser du följande exempel för att spåra undantag.
Webb-API 1.x
Åsidosätt 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);
}
}
}
Du kan lägga till det här åsidosatta attributet till specifika kontrollanter eller lägga till det i den globala filterkonfigurationen WebApiConfig
i klassen:
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());
}
}
}
Webb-API 2.x
Lägg till en implementering av 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);
}
}
}
Lägg till det här kodfragmentet i tjänsterna i 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());
}
}
}
Som alternativ kan du:
- Ersätt den enda
ExceptionHandler
instansen med en anpassad implementering avIExceptionHandler
. Den här undantagshanteraren anropas bara när ramverket fortfarande kan välja vilket svarsmeddelande som ska skickas, inte när anslutningen avbryts, till exempel. - Använd undantagsfilter enligt beskrivningen i föregående avsnitt på Web API 1.x-kontrollanter, som inte anropas i alla fall.
WCF
Lägg till en klass som utökar Attribute
och implementerar IErrorHandler
och 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)
{
}
}
}
Lägg till attributet i tjänstimplementeringarna:
namespace WcfService4
{
[AiLogException]
public class Service1 : IService1
{
// Omitted for brevity
}
}
Prestandaräknare för undantag
Om du har installerat Azure Monitor Application Insights-agenten på servern kan du få ett diagram över undantagsfrekvensen, mätt med .NET. Både hanterade och ohanterade .NET-undantag ingår.
Öppna fliken metrics explorer och lägg till ett nytt diagram. Under Prestandaräknare väljer du Undantagsfrekvens.
.NET Framework beräknar frekvensen genom att räkna antalet undantag i ett intervall och dividera med intervallets längd.
Det här antalet skiljer sig från antalet undantag som beräknas av Application Insights-portalens inventeringsrapporter TrackException
. Samplingsintervallen skiljer sig åt och SDK skickar TrackException
inte rapporter för alla hanterade och ohanterade undantag.