Application Insights für ASP.NET und ASP.NET Core-Anwendungen

In diesem Artikel wird erläutert, wie Sie Application Insights für ASP.NET und ASP.NET Core-Anwendungen zum Senden von Telemetrie aktivieren und konfigurieren. Application Insights kann die folgende Telemetrie aus Ihren Apps sammeln:

Unterstützte Szenarien

Hinzufügen von Anwendungserkenntnissen

Voraussetzungen

Erstellen einer einfachen Web-App

Wenn Sie noch keine funktionierende Webanwendung haben, können Sie die folgenden Anleitungen verwenden, um eine Webanwendung zu erstellen.

Automatisches Hinzufügen von Application Insights (Visual Studio)

Dieser Abschnitt führt Sie durch das automatische Hinzufügen von Application Insights zu einer vorlagenbasierten Web-App.

Manuelles Hinzufügen von Application Insights (ohne Visual Studio)

Dieser Abschnitt führt Sie durch das manuelle Hinzufügen von Application Insights zu einer vorlagenbasierten Web-App.

Überprüfen, ob Application Insights Telemetrie erhält

Führen Sie Ihre Anwendung aus, und senden Sie Anforderungen an diese. Nun sollten Telemetriedaten an Application Insights übermittelt werden. Mit dem Application Insights SDK werden eingehende Webanforderungen an die Anwendung sowie die folgenden Telemetriedaten automatisch erfasst.

Konfigurieren von Telemetrie

In diesem Abschnitt

• Livemetriken
• Ablaufverfolgungen (Protokolle)
• Abhängigkeiten
• Ausnahmen
• Benutzerdefinierte Metriken
• Benutzerdefinierte Vorgänge

Livemetriken

Mit Livemetriken kann schnell überprüft werden, ob die Anwendungsüberwachung mit Application Insights ordnungsgemäß konfiguriert ist. Es kann einige Minuten dauern, bis Telemetriedaten im Azure-Portal angezeigt werden. Im Bereich „Livemetriken“ wird jedoch die CPU-Auslastung des laufenden Prozesses nahezu in Echtzeit angezeigt. Außerdem können andere Telemetriedaten wie z. B. Anforderungen, Abhängigkeiten und Ablaufverfolgungen angezeigt werden.

Aktivieren von Livemetriken für beliebige .NET-Anwendungen mithilfe von Code

using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse;
using System;
using System.Threading.Tasks;

namespace LiveMetricsDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            // Create a TelemetryConfiguration instance.
            TelemetryConfiguration config = TelemetryConfiguration.CreateDefault();
            config.InstrumentationKey = "INSTRUMENTATION-KEY-HERE";
            QuickPulseTelemetryProcessor quickPulseProcessor = null;
            config.DefaultTelemetrySink.TelemetryProcessorChainBuilder
                .Use((next) =>
                {
                    quickPulseProcessor = new QuickPulseTelemetryProcessor(next);
                    return quickPulseProcessor;
                })
                .Build();

            var quickPulseModule = new QuickPulseTelemetryModule();

            // Secure the control channel.
            // This is optional, but recommended.
            quickPulseModule.AuthenticationApiKey = "YOUR-API-KEY-HERE";
            quickPulseModule.Initialize(config);
            quickPulseModule.RegisterTelemetryProcessor(quickPulseProcessor);

            // Create a TelemetryClient instance. It is important
            // to use the same TelemetryConfiguration here as the one
            // used to set up live metrics.
            TelemetryClient client = new TelemetryClient(config);

            // This sample runs indefinitely. Replace with actual application logic.
            while (true)
            {
                // Send dependency and request telemetry.
                // These will be shown in live metrics.
                // CPU/Memory Performance counter is also shown
                // automatically without any additional steps.
                client.TrackDependency("My dependency", "target", "http://sample",
                    DateTimeOffset.Now, TimeSpan.FromMilliseconds(300), true);
                client.TrackRequest("My Request", DateTimeOffset.Now,
                    TimeSpan.FromMilliseconds(230), "200", true);
                Task.Delay(1000).Wait();
            }
        }
    }
}

using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse;

// Create a TelemetryConfiguration instance.
TelemetryConfiguration config = TelemetryConfiguration.CreateDefault();
config.ConnectionString = "InstrumentationKey=00000000-0000-0000-0000-000000000000";
QuickPulseTelemetryProcessor quickPulseProcessor = null;
config.DefaultTelemetrySink.TelemetryProcessorChainBuilder
    .Use((next) =>
    {
        quickPulseProcessor = new QuickPulseTelemetryProcessor(next);
        return quickPulseProcessor;
    })
    .Build();

var quickPulseModule = new QuickPulseTelemetryModule();

// Secure the control channel.
// This is optional, but recommended.
quickPulseModule.AuthenticationApiKey = "YOUR-API-KEY-HERE";
quickPulseModule.Initialize(config);
quickPulseModule.RegisterTelemetryProcessor(quickPulseProcessor);

// Create a TelemetryClient instance. It is important
// to use the same TelemetryConfiguration here as the one
// used to set up live metrics.
TelemetryClient client = new TelemetryClient(config);

// This sample runs indefinitely. Replace with actual application logic.
while (true)
{
    // Send dependency and request telemetry.
    // These will be shown in live metrics.
    // CPU/Memory Performance counter is also shown
    // automatically without any additional steps.
    client.TrackDependency("My dependency", "target", "http://sample",
        DateTimeOffset.Now, TimeSpan.FromMilliseconds(300), true);
    client.TrackRequest("My Request", DateTimeOffset.Now,
        TimeSpan.FromMilliseconds(230), "200", true);
    Task.Delay(1000).Wait();
}

Ablaufverfolgungen (Protokolle)

Application Insights erfasst Protokolle von ASP.NET Core und anderen .NET-Apps über ILogger und von klassischen ASP.NET (.NET Framework) über das klassische SDK und die Adapter.

using Microsoft.Extensions.Logging.ApplicationInsights;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

builder.Logging.AddApplicationInsights(
        configureTelemetryConfiguration: (config) => 
            config.ConnectionString = builder.Configuration.GetConnectionString("APPLICATIONINSIGHTS_CONNECTION_STRING"),
            configureApplicationInsightsLoggerOptions: (options) => { }
    );

builder.Logging.AddFilter<ApplicationInsightsLoggerProvider>("your-category", LogLevel.Trace);

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

public class ValuesController : ControllerBase
{
    private readonly ILogger _logger;

    public ValuesController(ILogger<ValuesController> logger)
    {
        _logger = logger;
    }

    [HttpGet]
    public ActionResult<IEnumerable<string>> Get()
    {
        _logger.LogWarning("An example of a Warning trace..");
        _logger.LogError("An example of an Error level message");

        return new string[] { "value1", "value2" };
    }
}

Konsolenanwendung

Um die Application Insights-Protokollierung zu Konsolenanwendungen hinzuzufügen, installieren Sie zuerst die folgenden NuGet-Pakete:

• Microsoft.Extensions.Logging.ApplicationInsights
• Microsoft.Extensions.DependencyInjection

Im folgenden Beispiel wird das Microsoft.Extensions.Logging.ApplicationInsights Paket verwendet und das Standardverhalten für eine Konsolenanwendung veranschaulicht. Das Microsoft.Extensions.Logging.ApplicationInsights Paket sollte in einer Konsolenanwendung verwendet werden oder wann immer Sie eine minimale Mindestimplementierung von Application Insights ohne den vollständigen Funktionssatz benötigen, z. B. Metriken, verteilte Ablaufverfolgung, Sampling und Telemetrieinitialisierer.

using Microsoft.ApplicationInsights.Channel;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;

using var channel = new InMemoryChannel();

try
{
    IServiceCollection services = new ServiceCollection();
    services.Configure<TelemetryConfiguration>(config => config.TelemetryChannel = channel);
    services.AddLogging(builder =>
    {
        // Only Application Insights is registered as a logger provider
        builder.AddApplicationInsights(
            configureTelemetryConfiguration: (config) => config.ConnectionString = "<YourConnectionString>",
            configureApplicationInsightsLoggerOptions: (options) => { }
        );
    });

    IServiceProvider serviceProvider = services.BuildServiceProvider();
    ILogger<Program> logger = serviceProvider.GetRequiredService<ILogger<Program>>();

    logger.LogInformation("Logger is working...");
}
finally
{
    // Explicitly call Flush() followed by Delay, as required in console apps.
    // This ensures that even if the application terminates, telemetry is sent to the back end.
    channel.Flush();

    await Task.Delay(TimeSpan.FromMilliseconds(1000));
}

Weitere Informationen finden Sie unter Welchen Telemetrietyp "Application Insights" werden aus ILogger-Protokollen erstellt? Wo kann ich ILogger-Protokolle in Application Insights anzeigen?.

Protokollierungsbereiche

ApplicationInsightsLoggingProvider unterstützt Protokollbereiche, die standardmäßig aktiviert sind.

Wenn der Bereich vom Typ IReadOnlyCollection<KeyValuePair<string,object>>ist, wird jedes Schlüssel-Wert-Paar in der Auflistung der Application Insights-Telemetrie als benutzerdefinierte Eigenschaften hinzugefügt. Im folgenden Beispiel werden Protokolle als TraceTelemetry eigenschaften erfasst.("MyKey", "MyValue")

using (_logger.BeginScope(new Dictionary<string, object> { ["MyKey"] = "MyValue" }))
{
    _logger.LogError("An example of an Error level message");
}

Wenn ein anderer Typ als Bereich verwendet wird, wird er unter der Eigenschaft Scope in der Application Insights-Telemetrie gespeichert. Im folgenden Beispiel wird eine Eigenschaft aufgerufenTraceTelemetry, Scope die den Bereich enthält.

using (_logger.BeginScope("hello scope"))
{
    _logger.LogError("An example of an Error level message");
}

Suchen ihrer Protokolle

ILogger-Protokolle werden als Ablaufverfolgungs-Telemetrie (Tabelle traces in Application Insights und AppTraces in Log Analytics) angezeigt.

Beispiel

Wechseln Sie im Azure-Portal zu Application Insights, und führen Sie Folgendes aus:

traces
| where severityLevel >= 2 // 2=Warning, 1=Information, 0=Verbose
| take 50

Abhängigkeiten

Automatisch nachverfolgte Abhängigkeiten

Application Insights-SDKs für .NET und .NET Core werden mit DependencyTrackingTelemetryModule ausgeliefert, einem Telemetriemodul, das Abhängigkeiten automatisch erfasst. Das Modul DependencyTrackingTelemetryModule wird als Microsoft.ApplicationInsights.DependencyCollector NuGet-Paket ausgeliefert und automatisch bereitgestellt, wenn Sie entweder das Microsoft.ApplicationInsights.Web NuGet-Paket oder das Microsoft.ApplicationInsights.AspNetCore NuGet-Paket verwenden.

Derzeit verfolgt DependencyTrackingTelemetryModule automatisch die folgenden Abhängigkeiten:

Wenn die Abhängigkeit nicht automatisch erfasst wird, können Sie sie manuell mit einem Track-Abhängigkeitsaufruf nachverfolgen.

Weitere Informationen zur Funktionsweise der Abhängigkeitsnachverfolgung finden Sie unter Dependency Tracking in Application Insights.

Richten Sie die automatische Abhängigkeitsverfolgung in Konsolen-Apps ein

    DependencyTrackingTelemetryModule depModule = new DependencyTrackingTelemetryModule();
    depModule.Initialize(TelemetryConfiguration.Active);

Manuelle Nachverfolgung von Abhängigkeiten

Die folgenden Beispiele für Abhängigkeiten, die nicht automatisch erfasst werden, erfordern eine manuelle Nachverfolgung:

• Azure Cosmos DB wird nur dann automatisch nachverfolgt, wenn HTTP/HTTPS verwendet wird. Der TCP-Modus wird von Application Insights für ältere 2.22.0-Beta1SDK-Versionen nicht automatisch erfasst.
• Redis

Abhängigkeiten, die nicht automatisch vom SDK erfasst werden, können Sie manuell nachverfolgen, indem Sie dieTrackDependency-API verwenden, die von den standardmäßigen automatischen Erfassungsmodulen verwendet wird.

Beispiel

Wenn Sie Ihren Code mit einer Assembly erstellen, die Sie nicht selbst geschrieben haben, können Sie alle Aufrufe zeitlich festlegen. In diesem Szenario könnten Sie herausfinden, welche Beiträge sie zu Ihren Reaktionszeiten leisten.

Damit diese Daten in den Abhängigkeitsdiagrammen in Application Insights angezeigt werden, senden Sie sie mit TrackDependency:

    var startTime = DateTime.UtcNow;
    var timer = System.Diagnostics.Stopwatch.StartNew();
    try
    {
        // making dependency call
        success = dependency.Call();
    }
    finally
    {
        timer.Stop();
        telemetryClient.TrackDependency("myDependencyType", "myDependencyCall", "myDependencyData", startTime, timer.Elapsed, success);
    }

Alternativ stellt TelemetryClient die Erweiterungsmethoden StartOperation and StopOperationbereit, die zum manuellen Verfolgen von Abhängigkeiten verwendet werden können, wie in Verfolgung ausgehender Abhängigkeiten gezeigt.

Deaktivieren des Standardmäßigen Abhängigkeitsnachverfolgungsmoduls

Weitere Informationen finden Sie in Telemetriemodulen.

Erweitertes SQL-Tracking, um eine vollständige SQL-Abfrage zu erhalten

Bei SQL-Aufrufen wird immer der Name des Servers und der Datenbank gesammelt und als Name des gesammelten DependencyTelemetry gespeichert. Ein weiteres Feld namens data kann den vollständigen SQL-Abfragetext enthalten.

<TelemetryModules>
  <Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule, Microsoft.AI.DependencyCollector">
    <EnableSqlCommandTextInstrumentation>true</EnableSqlCommandTextInstrumentation>
  </Add>

services.ConfigureTelemetryModule<DependencyTrackingTelemetryModule>((module, o) => { module. EnableSqlCommandTextInstrumentation = true; });

In den vorstehenden Fällen besteht die ordnungsgemäße Methode zum Überprüfen, ob die Instrumentierungs-Engine korrekt installiert ist, darin, zu überprüfen, ob die SDK-Version des erfassten DependencyTelemetryrddp ist. Die Verwendung oder rdddsdrddf gibt an, dass Abhängigkeiten über DiagnosticSource oder EventSource Rückrufe erfasst werden, sodass die vollständige SQL-Abfrage nicht erfasst wird.

Ausnahmen

Ausnahmen in Webanwendungen können mit Application Insights gemeldet werden. Sie können fehlgeschlagene Anforderungen mit Ausnahmen und anderen Ereignissen sowohl auf dem Client als auch auf dem Server korrelieren, damit Sie die Ursachen schnell diagnostizieren können. In diesem Abschnitt erfahren Sie, wie Sie Ausnahmeberichte einrichten, Ausnahmen explizit melden, Fehler diagnostizieren und vieles mehr.

Einrichten der Ausnahmeberichterstattung

Sie können Application Insights einrichten, um Ausnahmen zu melden, die entweder auf dem Server oder dem Client auftreten. Abhängig von der Plattform, von der Ihre Anwendung abhängig ist, benötigen Sie die entsprechende Erweiterung oder das ENTSPRECHENDE SDK.

Diagnostizieren von Fehlern und Ausnahmen

Benutzerdefinierte Ablaufverfolgungs- und Protokolldaten

Um Diagnosedaten speziell für Ihre App abzurufen, können Sie Code einfügen, um Ihre eigenen Telemetriedaten zu senden. Ihre benutzerdefinierten Telemetrie- oder Protokolldaten werden zusammen mit der Anforderung, der Seitenansicht und anderen automatisch gesammelten Daten in der Diagnosesuche angezeigt.

Mit dem Microsoft.VisualStudio.ApplicationInsights.TelemetryClientFolgenden stehen ihnen mehrere APIs zur Verfügung:

• TelemetryClient.TrackEvent wird in der Regel für die Überwachung von Verwendungsmustern verwendet, aber die gesendeten Daten werden auch unter benutzerdefinierten Ereignissen in der Diagnosesuche angezeigt. Ereignisse werden benannt und können Zeichenfolgeneigenschaften und numerische Metriken enthalten, nach denen Sie Ihre Diagnosesuchen filtern können.
• TelemetryClient.TrackTrace Ermöglicht das Senden längerer Daten wie POST-Informationen.
• TelemetryClient.TrackException sendet Ausnahmedetails, z. B. Stapelablaufverfolgungen an Application Insights.

Um diese Ereignisse anzuzeigen, öffnen Sie im linken Menü die Suche. Wählen Sie das Dropdownmenü "Ereignistypen" und dann " Benutzerdefiniertes Ereignis", " Ablaufverfolgung" oder "Ausnahme" aus.

Siehe AnforderungS-POST-Daten

Anforderungsdetails enthalten nicht die Daten, die in einem POST-Anruf an Ihre App gesendet werden. So haben Sie diese Daten gemeldet:

• Fügen Sie dem App-Code das Application Insights SDK hinzu.
• Fügen Sie Code in Ihre Anwendung ein, um Microsoft.ApplicationInsights.TrackTrace()) aufzurufen. Senden Sie die POST-Daten im Nachrichtenparameter. Es gibt eine Beschränkung auf die zulässige Größe, daher sollten Sie versuchen, nur die wesentlichen Daten zu senden.
• Wenn Sie eine fehlgeschlagene Anforderung untersuchen, suchen Sie die zugeordneten Ablaufverfolgungen.

Erfassen von Ausnahmen und zugehörigen Diagnosedaten

Standardmäßig werden nicht alle Ausnahmen, die zu Fehlern in Ihrer App führen, im Portal angezeigt. Wenn Sie das JavaScript SDK in Ihren Webseiten verwenden, werden Browser-Ausnahmen angezeigt. Die meisten serverseitigen Ausnahmen werden jedoch von IIS abgefangen, daher müssen Sie code hinzufügen, um sie zu erfassen und zu melden.

Sie haben folgende Möglichkeiten:

• Protokollieren Sie Ausnahmen explizit , indem Sie Code in Ausnahmehandler einfügen, um die Ausnahmen zu melden.
• Erfassen Sie Ausnahmen automatisch , indem Sie Ihr ASP.NET Framework konfigurieren. Die erforderlichen Ergänzungen sind für verschiedene Frameworktypen unterschiedlich.

Explizites Melden von Ausnahmen

Die einfachste Möglichkeit zum Melden besteht darin, einen Aufruf trackException() in einen Ausnahmehandler einzufügen.

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);
}

try
{
    // ...
}
catch (ex)
{
    appInsights.trackException(ex, "handler loc",
    {
        Game: currentGame.Name,
        State: currentGame.State.ToString()
    });
}

Die Eigenschaften und Maßparameter sind optional, eignen sich jedoch zum Filtern und Hinzufügen zusätzlicher Informationen. Wenn Sie beispielsweise über eine App verfügen, die mehrere Spiele ausführen kann, können Sie alle Ausnahmeberichte zu einem bestimmten Spiel finden. Sie können jedem Wörterbuch beliebig viele Elemente hinzufügen.

Browser-Ausnahmen

Die meisten Browser-Ausnahmen werden gemeldet.

Wenn Ihre Webseite Skriptdateien aus Inhaltsübermittlungsnetzwerken oder anderen Domänen enthält, stellen Sie sicher, dass Ihr Skripttag über das Attribut crossorigin="anonymous" verfügt und der Server CORS-Header sendet. Mit diesem Verhalten können Sie eine Stapelablaufverfolgung und Details für unbehandelte JavaScript-Ausnahmen von diesen Ressourcen abrufen.

Wiederverwenden ihres Telemetrieclients

Mit Dependency Injection (DI) in .NET, dem entsprechenden .NET SDK und der korrekten Konfiguration von Application Insights for DI können Sie den TelemetryClient als Konstruktorparameter benötigen.

public class ExampleController : ApiController
{
    private readonly TelemetryClient _telemetryClient;

    public ExampleController(TelemetryClient telemetryClient)
    {
        _telemetryClient = telemetryClient;
    }
}

Im vorherigen Beispiel wird die TelemetryClient Klasse in die Klasse eingefügt ExampleController .

Webformulare

Bei Webformularen kann das HTTP-Modul die Ausnahmen sammeln, wenn keine Umleitungen konfiguriert CustomErrorssind. Wenn Sie jedoch aktive Umleitungen haben, fügen Sie der Funktion in Application_Error die folgenden Zeilen hinzu.

void Application_Error(object sender, EventArgs e)
{
    if (HttpContext.Current.IsCustomErrorEnabled &&
        Server.GetLastError () != null)
    {
        _telemetryClient.TrackException(Server.GetLastError());
    }
}

Im vorherigen Beispiel handelt es _telemetryClient sich um eine Klassenbereichsvariable vom Typ TelemetryClient.

MVC

Ab Application Insights Web SDK Version 2.6 (Beta 3 und höher) sammelt Application Insights unbehandelte Ausnahmen, die in den MVC 5+-Controllermethoden automatisch ausgelöst werden. Wenn Sie zuvor einen benutzerdefinierten Handler zum Nachverfolgen solcher Ausnahmen hinzugefügt haben, können Sie ihn entfernen, um die doppelte Nachverfolgung von Ausnahmen zu verhindern.

Es gibt mehrere Szenarien, in denen ein Ausnahmefilter Fehler nicht ordnungsgemäß behandeln kann, wenn Ausnahmen ausgelöst werden:

• Von Controllerkonstruktoren
• Von Nachrichtenhandlern
• Während des Routings
• Während der Serialisierung von Antwortinhalten
• Während des Anwendungsstarts
• In Hintergrundaufgaben

Alle von der Anwendung behandelten Ausnahmen müssen weiterhin manuell nachverfolgt werden. Unbehandelte Ausnahmen, die von Controllern stammen, führen in der Regel zu einer Antwort von 500 "Interner Serverfehler". Wenn diese Antwort manuell als Ergebnis einer behandelten Ausnahme oder gar keine Ausnahme erstellt wird, wird sie in der entsprechenden Anforderungs-Telemetrie mit ResultCode 500 nachverfolgt. Das Application Insights SDK kann jedoch keine entsprechende Ausnahme nachverfolgen.

Unterstützung früherer Versionen

Wenn Sie MVC 4 (und früher) von Application Insights Web SDK 2.5 (und früher) verwenden, lesen Sie die folgenden Beispiele zum Nachverfolgen von Ausnahmen.

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);
        }
    }
}

    namespace MVC2App.Controllers
    {
        [AiHandleError]
        public class HomeController : Controller
        {
            // Omitted for brevity
        }
    }

public class MyMvcApplication : System.Web.HttpApplication
{
    public static void RegisterGlobalFilters(GlobalFilterCollection filters)
    {
        filters.Add(new AiHandleErrorAttribute());
    }
}

public class FilterConfig
{
    public static void RegisterGlobalFilters(GlobalFilterCollection filters)
    {
        // Default replaced with the override to track unhandled exceptions
        filters.Add(new AiHandleErrorAttribute());
    }
}

Web-API

Ab Application Insights Web SDK Version 2.6 (Beta 3 und höher) sammelt Application Insights unbehandelte Ausnahmen, die in den Controllermethoden automatisch für Web-API 2+ ausgelöst werden. Wenn Sie zuvor einen benutzerdefinierten Handler zum Nachverfolgen solcher Ausnahmen hinzugefügt haben, wie in den folgenden Beispielen beschrieben, können Sie ihn entfernen, um die doppelte Nachverfolgung von Ausnahmen zu verhindern.

Es gibt mehrere Fälle, die die Ausnahmefilter nicht verarbeiten können. Beispiel:

• Ausnahmen, die von Controllerkonstruktoren ausgelöst werden.
• Ausnahmen, die von Nachrichtenhandlern ausgelöst werden.
• Ausnahmen, die während des Routings ausgelöst werden.
• Ausnahmen, die während der Serialisierung von Antwortinhalten ausgelöst werden.
• Ausnahme beim Starten der Anwendung ausgelöst.
• Ausnahme in Hintergrundaufgaben ausgelöst.

Alle von der Anwendung behandelten Ausnahmen müssen weiterhin manuell nachverfolgt werden. Unbehandelte Ausnahmen, die von Controllern stammen, führen in der Regel zu einer Antwort von 500 "Interner Serverfehler". Wenn eine solche Antwort manuell als Ergebnis einer behandelten Ausnahme oder gar keine Ausnahme erstellt wird, wird sie in einer entsprechenden Anforderungs-Telemetrie mit ResultCode 500 nachverfolgt. Das Application Insights SDK kann jedoch keine entsprechende Ausnahme nachverfolgen.

Unterstützung früherer Versionen

Wenn Sie Web-API 1 (und früher) von Application Insights Web SDK 2.5 (und früher) verwenden, lesen Sie die folgenden Beispiele zum Nachverfolgen von Ausnahmen.

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);
    }
    }
}

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());
        }
    }
}

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);
        }
    }
}

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());
        }
    }
}

WCF

Fügen Sie eine Klasse hinzu, die erweitert Attribute und implementiert und implementiert IErrorHandler und 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)
        {
        }
      }
    }

Fügen Sie das Attribut zu den Dienstimplementierungen hinzu:

namespace WcfService4
{
    [AiLogException]
    public class Service1 : IService1
    {
        // Omitted for brevity
    }
}

Beispiel

Leistungsindikatoren für Ausnahmen

Wenn Sie den Azure Monitor Application Insights Agent auf Ihrem Server installiert haben, können Sie ein Diagramm der Von .NET gemessenen Ausnahmenrate abrufen. Sowohl behandelte als auch unbehandelte .NET-Ausnahmen sind enthalten.

Öffnen Sie eine Registerkarte "Metrik-Explorer", und fügen Sie ein neues Diagramm hinzu. Wählen Sie unter Leistungsindikatorendie Ausnahmerate aus.

.NET Framework berechnet die Rate, indem die Anzahl der Ausnahmen in einem Intervall gezählt und durch die Länge des Intervalls dividiert wird.

Diese Anzahl unterscheidet sich von der Vom Application Insights-Portal TrackException berechneten Ausnahmenzählungsberichte. Die Samplingintervalle unterscheiden sich, und das SDK sendet TrackException keine Berichte für alle behandelten und nicht behandelten Ausnahmen.

Benutzerdefinierte Metriksammlung

Die Azure Monitor Application Insights .NET- und .NET Core-SDKs verfügen über zwei verschiedene Methoden zum Sammeln von benutzerdefinierten Metriken:

• Die TrackMetric() Methode, die keine Voraggregation aufweist.
• Die GetMetric() Methode, die eine Voraggregation aufweist.

Wir empfehlen die Verwendung der Aggregation. TrackMetric(). Dieser Artikel führt Sie durch die Verwendung der GetMetric() Methode und einige der Gründe für die Funktionsweise.

Erste Schritte mit GetMetric

Für unsere Beispiele verwenden wir eine einfache .NET Core 3.1-Workerdienstanwendung. Wenn Sie die mit diesen Beispielen verwendete Testumgebung replizieren möchten, führen Sie die Schritte 1 bis 6 im Artikel "Monitoring Worker Service" aus. Diese Schritte fügen Application Insights zu einer projektbasierten Arbeitsdienstvorlage hinzu. Die Konzepte gelten für jede allgemeine Anwendung, in der das SDK verwendet werden kann, einschließlich Web-Apps und Konsolen-Apps.

Metriken senden

Ersetzen Sie den Inhalt der worker.cs Datei durch den folgenden Code:

using System;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Microsoft.ApplicationInsights;

namespace WorkerService3
{
    public class Worker : BackgroundService
    {
        private readonly ILogger<Worker> _logger;
        private TelemetryClient _telemetryClient;

        public Worker(ILogger<Worker> logger, TelemetryClient tc)
        {
            _logger = logger;
            _telemetryClient = tc;
        }

        protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {   // The following line demonstrates usages of GetMetric API.
            // Here "computersSold", a custom metric name, is being tracked with a value of 42 every second.
            while (!stoppingToken.IsCancellationRequested)
            {
                _telemetryClient.GetMetric("ComputersSold").TrackValue(42);

                _logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
                await Task.Delay(1000, stoppingToken);
            }
        }
    }
}

Wenn Sie den Beispielcode ausführen, wird die while Schleife wiederholt ausgeführt, ohne dass Telemetrie im Visual Studio-Ausgabefenster gesendet wird. Ein einzelnes Telemetrieelement wird um die 60-Sekunden-Marke gesendet, die in unserem Test wie folgt aussieht:

Application Insights Telemetry: {"name":"Microsoft.ApplicationInsights.Dev.00000000-0000-0000-0000-000000000000.Metric", "time":"2019-12-28T00:54:19.0000000Z",
"ikey":"00000000-0000-0000-0000-000000000000",
"tags":{"ai.application.ver":"1.0.0.0",
"ai.cloud.roleInstance":"Test-Computer-Name",
"ai.internal.sdkVersion":"m-agg2c:2.12.0-21496",
"ai.internal.nodeName":"Test-Computer-Name"},
"data":{"baseType":"MetricData",
"baseData":{"ver":2,"metrics":[{"name":"ComputersSold",
"kind":"Aggregation",
"value":1722,
"count":41,
"min":42,
"max":42,
"stdDev":0}],
"properties":{"_MS.AggregationIntervalMs":"42000",
"DeveloperMode":"true"}}}}

Dieses einzelne Telemetrieelement stellt ein Aggregat von 41 unterschiedlichen Metriken dar. Da wir denselben Wert immer wieder senden, haben wir eine Standardabweichung (stDev) von 0 identischen () maximalen (max) und minimalen (min) Werten. Die value Eigenschaft stellt eine Summe aller einzelnen Werte dar, die aggregiert wurden.

Wenn wir unsere Application Insights-Ressource in der Protokollumgebung (Analyse) untersuchen, würde das einzelne Telemetrieelement wie der folgende Screenshot aussehen.

Sie können auch auf Ihre benutzerdefinierte Metrik-Telemetrie im Abschnitt "Metriken " des Portals als protokollbasierte und benutzerdefinierte Metrik zugreifen. Der folgende Screenshot ist ein Beispiel für eine protokollbasierte Metrik.

Cachemetrikverweis für die Verwendung mit hohem Durchsatz

Metrikwerte können in einigen Fällen häufig beobachtet werden. Beispielsweise kann ein Dienst mit hohem Durchsatz, der 500 Anforderungen pro Sekunde verarbeitet, 20 Telemetriemetriken für jede Anforderung ausgeben. Das Ergebnis bedeutet, dass 10.000 Werte pro Sekunde nachverfolgt werden. In solchen Szenarien mit hohem Durchsatz müssen Benutzer das SDK möglicherweise unterstützen, indem sie einige Nachschlagevorgänge vermeiden.

Im vorherigen Beispiel wurde beispielsweise ein Nachschlagevorgang für ein Handle für die Metrik ComputersSold ausgeführt und dann ein beobachteter Wert von 42. Stattdessen kann das Handle für mehrere Nachverfolgaufrufe zwischengespeichert werden:

//...

        protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {
            // This is where the cache is stored to handle faster lookup
            Metric computersSold = _telemetryClient.GetMetric("ComputersSold");
            while (!stoppingToken.IsCancellationRequested)
            {

                computersSold.TrackValue(42);

                computersSold.TrackValue(142);

                _logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
                await Task.Delay(50, stoppingToken);
            }
        }

Zusätzlich zum Zwischenspeichern des metrischen Handles verringert Task.Delay sich das vorangehende Beispiel auch auf 50 Millisekunden, sodass die Schleife häufiger ausgeführt wird. Das Ergebnis ist 772 TrackValue() Aufrufe.

Multidimensionale Metriken

Die Beispiele im vorherigen Abschnitt zeigen nulldimensionale Metriken. Metriken können auch multidimensional sein. Wir unterstützen derzeit bis zu 10 Dimensionen.

Hier ist ein Beispiel zum Erstellen einer eindimensionalen Metrik:

//...

        protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {
            // This is an example of a metric with a single dimension.
            // FormFactor is the name of the dimension.
            Metric computersSold= _telemetryClient.GetMetric("ComputersSold", "FormFactor");

            while (!stoppingToken.IsCancellationRequested)
            {
                // The number of arguments (dimension values)
                // must match the number of dimensions specified while GetMetric.
                // Laptop, Tablet, etc are values for the dimension "FormFactor"
                computersSold.TrackValue(42, "Laptop");
                computersSold.TrackValue(20, "Tablet");
                computersSold.TrackValue(126, "Desktop");


                _logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
                await Task.Delay(50, stoppingToken);
            }
        }

Das Ausführen des Beispielcodes für mindestens 60 Sekunden führt zu drei unterschiedlichen Telemetrieelementen, die an Azure gesendet werden. Jedes Element stellt die Aggregation eines der drei Formfaktoren dar. Wie zuvor können Sie die Protokollansicht (Analytics) weiter untersuchen.

Im Metrik-Explorer:

Beachten Sie, dass Sie die Metrik nicht durch Ihre neue benutzerdefinierte Dimension aufteilen oder Ihre benutzerdefinierte Dimension mit der Metrikansicht anzeigen können.

Standardmäßig sind multidimensionale Metriken im Metrik-Explorer in Application Insights-Ressourcen nicht aktiviert.

Aktivieren von mehrdimensionalen Metriken

Um multidimensionale Metriken für eine Application Insights-Ressource zu aktivieren, wählen Sie "Nutzung" und "Geschätzte Kosten>" aus, um benutzerdefinierte Metriken> zu aktivieren,aktivieren Sie warnungen für benutzerdefinierte Metriken>OK. Weitere Informationen finden Sie unter Benutzerdefinierte Metrikdimensionen und Präaggregation.

Nachdem Sie diese Änderung vorgenommen und neue mehrdimensionale Telemetrie gesendet haben, können Sie " Aufteilen anwenden" auswählen.

Zeigen Sie Die Metrikaggregationen für jede FormFactor Dimension an.

Verwenden von MetricIdentifier, wenn mehr als drei Dimensionen vorhanden sind

Derzeit werden 10 Dimensionen unterstützt. Mehr als drei Dimensionen erfordern die Verwendung von MetricIdentifier:

// Add "using Microsoft.ApplicationInsights.Metrics;" to use MetricIdentifier
// MetricIdentifier id = new MetricIdentifier("[metricNamespace]","[metricId],"[dim1]","[dim2]","[dim3]","[dim4]","[dim5]");
MetricIdentifier id = new MetricIdentifier("CustomMetricNamespace","ComputerSold", "FormFactor", "GraphicsCard", "MemorySpeed", "BatteryCapacity", "StorageCapacity");
Metric computersSold = _telemetryClient.GetMetric(id);
computersSold.TrackValue(110,"Laptop", "Nvidia", "DDR4", "39Wh", "1TB");

Benutzerdefinierte Metrikkonfiguration

Wenn Sie die Metrikkonfiguration ändern möchten, müssen Sie Änderungen an der Stelle vornehmen, an der die Metrik initialisiert wird.

Spezielle Bemaßungsnamen

Metriken verwenden nicht den Telemetriekontext des TelemetryClient verwendeten Zugriffs. Die Verwendung spezieller Dimensionsnamen, die als Konstanten in der MetricDimensionNames Klasse verfügbar sind, ist die beste Problemumgehung für diese Einschränkung.

Metrikaggregate, die von der folgenden Special Operation Request Size Metrik gesendet werden, müssen Context.Operation.Name auf Special Operation. Die TrackMetric() Methode oder eine andere TrackXXX() Methode wurde OperationName ordnungsgemäß auf .Special Operation

        //...
        TelemetryClient specialClient;
        private static int GetCurrentRequestSize()
        {
            // Do stuff
            return 1100;
        }
        int requestSize = GetCurrentRequestSize()

        protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {
            while (!stoppingToken.IsCancellationRequested)
            {
                //...
                specialClient.Context.Operation.Name = "Special Operation";
                specialClient.GetMetric("Special Operation Request Size").TrackValue(requestSize);
                //...
            }
                   
        }

Verwenden Sie in diesem Fall die in der MetricDimensionNames Klasse aufgeführten speziellen Dimensionsnamen, um die TelemetryContext Werte anzugeben.

Wenn beispielsweise das metrikbasierte Aggregat, das sich aus der nächsten Anweisung ergibt, an den Application Insights-Cloudendpunkt gesendet wird, wird das Context.Operation.Name Datenfeld auf :Special Operation

_telemetryClient.GetMetric("Request Size", MetricDimensionNames.TelemetryContext.Operation.Name).TrackValue(requestSize, "Special Operation");

Der Wert dieser speziellen Dimension wird in TelemetryContext eine normale Dimension kopiert und wird nicht als normale Dimension verwendet. Wenn Sie auch eine Betriebsdimension für die normale Metrikerkundung beibehalten möchten, müssen Sie für diesen Zweck eine separate Dimension erstellen:

_telemetryClient.GetMetric("Request Size", "Operation Name", MetricDimensionNames.TelemetryContext.Operation.Name).TrackValue(requestSize, "Special Operation", "Special Operation");

Bemaßung und Zeitreihenkapping

Um zu verhindern, dass das Telemetrie-Subsystem Ihre Ressourcen versehentlich verwendet, können Sie die maximale Anzahl von Datenreihen pro Metrik steuern. Die Standardgrenzwerte sind nicht mehr als 1.000 Datenreihen pro Metrik und nicht mehr als 100 verschiedene Werte pro Dimension.

Im Kontext der Begrenzung von Dimension- und Zeitreihen wird Metric.TrackValue(..) sichergestellt, dass die Grenzwerte eingehalten werden. Wenn die Grenzwerte bereits erreicht sind, Metric.TrackValue(..) wird der False Wert nicht nachverfolgt. Andernfalls wird der Wert zurückgegeben True. Dieses Verhalten ist nützlich, wenn die Daten für eine Metrik aus der Benutzereingabe stammen.

Der MetricConfiguration Konstruktor verwendet einige Optionen zum Verwalten verschiedener Datenreihen innerhalb der jeweiligen Metrik und eines Objekts einer Klasse IMetricSeriesConfiguration , die das Aggregationsverhalten für jede einzelne Datenreihe der Metrik angibt:

var metConfig = new MetricConfiguration(seriesCountLimit: 100, valuesPerDimensionLimit:2,
                new MetricSeriesConfigurationForMeasurement(restrictToUInt32Values: false));

Metric computersSold = _telemetryClient.GetMetric("ComputersSold", "Dimension1", "Dimension2", metConfig);

// Start tracking.
computersSold.TrackValue(100, "Dim1Value1", "Dim2Value1");
computersSold.TrackValue(100, "Dim1Value1", "Dim2Value2");

// The following call gives 3rd unique value for dimension2, which is above the limit of 2.
computersSold.TrackValue(100, "Dim1Value1", "Dim2Value3");
// The above call does not track the metric, and returns false.

• seriesCountLimit ist die maximale Anzahl von Datenzeitreihen, die eine Metrik enthalten kann. Wenn dieser Grenzwert erreicht ist, führen Aufrufe dazu TrackValue() , dass normalerweise eine neue Datenreihe zurückgegeben falsewird.
• valuesPerDimensionLimit begrenzt die Anzahl unterschiedlicher Werte pro Dimension auf ähnliche Weise.
• restrictToUInt32Values bestimmt, ob nur nicht negative ganzzahlige Werte nachverfolgt werden sollen.

Hier ist ein Beispiel für das Senden einer Nachricht, um zu wissen, ob Die Obergrenze überschritten wird:

if (! computersSold.TrackValue(100, "Dim1Value1", "Dim2Value3"))
{
// Add "using Microsoft.ApplicationInsights.DataContract;" to use SeverityLevel.Error
_telemetryClient.TrackTrace("Metric value not tracked as value of one of the dimension exceeded the cap. Revisit the dimensions to ensure they are within the limits",
SeverityLevel.Error);
}

Nachverfolgen von benutzerdefinierten Vorgängen

Application Insights-SDKs verfolgen eingehende HTTP-Anforderungen und Aufrufe abhängiger Dienste wie HTTP-Anforderungen und SQL-Abfragen automatisch. Die Nachverfolgung und Korrelation von Anforderungen und Abhängigkeiten bieten Ihnen Einblicke in die Reaktionsfähigkeit und Zuverlässigkeit der gesamten Anwendung in allen Microservices, die diese Anwendung kombinieren.

Es gibt eine Klasse von Anwendungsmustern, die nicht generisch unterstützt werden können. Eine ordnungsgemäße Überwachung solcher Muster erfordert manuelle Codeinstrumentation. In diesem Artikel werden einige Muster behandelt, die möglicherweise eine manuelle Instrumentierung erfordern, z. B. die benutzerdefinierte Warteschlangenverarbeitung und das Ausführen langer Hintergrundaufgaben.

Dieser Abschnitt enthält Anleitungen zum Nachverfolgen von benutzerdefinierten Vorgängen mit dem Application Insights SDK.

Überblick

Ein Vorgang ist eine logische Arbeit, die von einer Anwendung ausgeführt wird. Er verfügt über einen Namen, eine Startzeit, eine Dauer, ein Ergebnis und einen Kontext der Ausführung wie Benutzername, Eigenschaften und Ergebnis. Wenn der Vorgang A durch Operation B initiiert wurde, wird der Vorgang B als übergeordnetes Element für A festgelegt. Ein Vorgang kann nur ein übergeordnetes Element haben, aber er kann viele untergeordnete Vorgänge haben. Weitere Informationen zu Vorgängen und Telemetriekorrelationen finden Sie unter Application Insights Telemetriekorrelation.

Im Application Insights .NET SDK wird der Vorgang von der abstrakten Klasse "OperationTelemetry " und den nachfolgern "RequestTelemetry " und "DependencyTelemetry" beschrieben.

Nachverfolgung eingehender Vorgänge

Das Application Insights-Web-SDK sammelt automatisch HTTP-Anforderungen für ASP.NET Anwendungen, die in einer IIS-Pipeline und allen ASP.NET Core-Anwendungen ausgeführt werden. Es gibt communitygestützte Lösungen für andere Plattformen und Frameworks. Wenn die Anwendung von keiner der Standard- oder Community-unterstützten Lösungen unterstützt wird, können Sie sie manuell instrumentieren.

Ein weiteres Beispiel für die benutzerdefinierte Nachverfolgung ist der Worker, der Elemente aus der Warteschlange empfängt. Bei einigen Warteschlangen wird der Aufruf zum Hinzufügen einer Nachricht zu dieser Warteschlange als Abhängigkeit nachverfolgt. Der allgemeine Vorgang, der die Nachrichtenverarbeitung beschreibt, wird nicht automatisch erfasst.

Sehen wir uns an, wie solche Vorgänge nachverfolgt werden können.

Auf hoher Ebene besteht die Aufgabe darin, bekannte Eigenschaften zu erstellen RequestTelemetry und festzulegen. Nach Abschluss des Vorgangs verfolgen Sie die Telemetrie. Im folgenden Beispiel wird diese Aufgabe veranschaulicht.

HTTP-Anforderung in selbst gehosteter Owin-App

In diesem Beispiel wird der Ablaufverfolgungskontext gemäß dem HTTP-Protokoll für Korrelation verteilt. Sie sollten davon ausgehen, dass Sie Kopfzeilen empfangen, die dort beschrieben werden.

public class ApplicationInsightsMiddleware : OwinMiddleware
{
    // You may create a new TelemetryConfiguration instance, reuse one you already have,
    // or fetch the instance created by Application Insights SDK.
    private readonly TelemetryConfiguration telemetryConfiguration = TelemetryConfiguration.CreateDefault();
    private readonly TelemetryClient telemetryClient = new TelemetryClient(telemetryConfiguration);
    
    public ApplicationInsightsMiddleware(OwinMiddleware next) : base(next) {}

    public override async Task Invoke(IOwinContext context)
    {
        // Let's create and start RequestTelemetry.
        var requestTelemetry = new RequestTelemetry
        {
            Name = $"{context.Request.Method} {context.Request.Uri.GetLeftPart(UriPartial.Path)}"
        };

        // If there is a Request-Id received from the upstream service, set the telemetry context accordingly.
        if (context.Request.Headers.ContainsKey("Request-Id"))
        {
            var requestId = context.Request.Headers.Get("Request-Id");
            // Get the operation ID from the Request-Id (if you follow the HTTP Protocol for Correlation).
            requestTelemetry.Context.Operation.Id = GetOperationId(requestId);
            requestTelemetry.Context.Operation.ParentId = requestId;
        }

        // StartOperation is a helper method that allows correlation of 
        // current operations with nested operations/telemetry
        // and initializes start time and duration on telemetry items.
        var operation = telemetryClient.StartOperation(requestTelemetry);

        // Process the request.
        try
        {
            await Next.Invoke(context);
        }
        catch (Exception e)
        {
            requestTelemetry.Success = false;
            requestTelemetry.ResponseCode;
            telemetryClient.TrackException(e);
            throw;
        }
        finally
        {
            // Update status code and success as appropriate.
            if (context.Response != null)
            {
                requestTelemetry.ResponseCode = context.Response.StatusCode.ToString();
                requestTelemetry.Success = context.Response.StatusCode >= 200 && context.Response.StatusCode <= 299;
            }
            else
            {
                requestTelemetry.Success = false;
            }

            // Now it's time to stop the operation (and track telemetry).
            telemetryClient.StopOperation(operation);
        }
    }
    
    public static string GetOperationId(string id)
    {
        // Returns the root ID from the '|' to the first '.' if any.
        int rootEnd = id.IndexOf('.');
        if (rootEnd < 0)
            rootEnd = id.Length;

        int rootStart = id[0] == '|' ? 1 : 0;
        return id.Substring(rootStart, rootEnd - rootStart);
    }
}

Das HTTP-Protokoll für Korrelation deklariert auch den Correlation-Context Header. Es wird hier aus Gründen der Einfachheit weggelassen.

Warteschlangeninstrumentation

Der W3C-Ablaufverfolgungskontext und das HTTP-Protokoll für Korrelationsdurchlauf-Korrelationsdetails mit HTTP-Anforderungen, aber jedes Warteschlangenprotokoll muss definieren, wie die gleichen Details entlang der Warteschlangennachricht übergeben werden. Einige Warteschlangenprotokolle, z. B. AMQP, ermöglichen das Übergeben weiterer Metadaten. Andere Protokolle, z. B. Azure Storage Queue, erfordern, dass der Kontext in die Nachrichtennutzlast codiert wird.

Service Bus-Warteschlange

Informationen zur Ablaufverfolgung finden Sie unter Verteilte Ablaufverfolgung und Korrelation über Azure Service Bus Messaging.

Azure Storage-Warteschlange

Das folgende Beispiel zeigt, wie Sie die Azure Storage-Warteschlangenvorgänge nachverfolgen und Telemetrie zwischen dem Produzenten, dem Consumer und Azure Storage korrelieren.

Die Speicherwarteschlange verfügt über eine HTTP-API. Alle Aufrufe der Warteschlange werden vom Application Insights Dependency Collector für HTTP-Anforderungen nachverfolgt. Sie ist standardmäßig für ASP.NET- und ASP.NET Core-Anwendungen konfiguriert. Weitere Arten von Anwendungen finden Sie in der Dokumentation zu Konsolenanwendungen.

Sie können auch die Anwendungseinblick-Vorgangs-ID mit der Speicheranforderungs-ID korrelieren. Informationen zum Festlegen und Abrufen eines Speicheranforderungsclients und einer Serveranforderungs-ID finden Sie unter Überwachen, Diagnostizieren und Problembehandlung von Azure Storage.

public async Task Enqueue(CloudQueue queue, string message)
{
    var operation = telemetryClient.StartOperation<DependencyTelemetry>("enqueue " + queue.Name);
    operation.Telemetry.Type = "Azure queue";
    operation.Telemetry.Data = "Enqueue " + queue.Name;

    // MessagePayload represents your custom message and also serializes correlation identifiers into payload.
    // For example, if you choose to pass payload serialized to JSON, it might look like
    // {'RootId' : 'some-id', 'ParentId' : '|some-id.1.2.3.', 'message' : 'your message to process'}
    var jsonPayload = JsonConvert.SerializeObject(new MessagePayload
    {
        RootId = operation.Telemetry.Context.Operation.Id,
        ParentId = operation.Telemetry.Id,
        Payload = message
    });
    
    CloudQueueMessage queueMessage = new CloudQueueMessage(jsonPayload);

    // Add operation.Telemetry.Id to the OperationContext to correlate Storage logs and Application Insights telemetry.
    OperationContext context = new OperationContext { ClientRequestID = operation.Telemetry.Id};

    try
    {
        await queue.AddMessageAsync(queueMessage, null, null, new QueueRequestOptions(), context);
    }
    catch (StorageException e)
    {
        operation.Telemetry.Properties.Add("AzureServiceRequestID", e.RequestInformation.ServiceRequestID);
        operation.Telemetry.Success = false;
        operation.Telemetry.ResultCode = e.RequestInformation.HttpStatusCode.ToString();
        telemetryClient.TrackException(e);
    }
    finally
    {
        // Update status code and success as appropriate.
        telemetryClient.StopOperation(operation);
    }
}  

public async Task<MessagePayload> Dequeue(CloudQueue queue)
{
    var operation = telemetryClient.StartOperation<DependencyTelemetry>("dequeue " + queue.Name);
    operation.Telemetry.Type = "Azure queue";
    operation.Telemetry.Data = "Dequeue " + queue.Name;

    try
    {
        var message = await queue.GetMessageAsync();
    }
    catch (StorageException e)
    {
        operation.telemetry.Properties.Add("AzureServiceRequestID", e.RequestInformation.ServiceRequestID);
        operation.telemetry.Success = false;
        operation.telemetry.ResultCode = e.RequestInformation.HttpStatusCode.ToString();
        telemetryClient.TrackException(e);
    }
    finally
    {
        // Update status code and success as appropriate.
        telemetryClient.StopOperation(operation);
    }

    return null;
}

public async Task Process(MessagePayload message)
{
    // After the message is dequeued from the queue, create RequestTelemetry to track its processing.
    RequestTelemetry requestTelemetry = new RequestTelemetry { Name = "process " + queueName };
    
    // It might also make sense to get the name from the message.
    requestTelemetry.Context.Operation.Id = message.RootId;
    requestTelemetry.Context.Operation.ParentId = message.ParentId;

    var operation = telemetryClient.StartOperation(requestTelemetry);

    try
    {
        await ProcessMessage();
    }
    catch (Exception e)
    {
        telemetryClient.TrackException(e);
        throw;
    }
    finally
    {
        // Update status code and success as appropriate.
        telemetryClient.StopOperation(operation);
    }
}

Ebenso können andere Warteschlangenvorgänge instrumentiert werden. Ein Vorschauvorgang sollte auf ähnliche Weise wie eine Dequeue-Operation instrumentiert werden. Die Instrumentierung von Warteschlangenverwaltungsvorgängen ist nicht erforderlich. Application Insights verfolgt Vorgänge wie HTTP und in den meisten Fällen reicht es aus.

Stellen Sie beim Löschen von Nachrichten sicher, dass Sie die Bezeichner für den Vorgang (Korrelation) festlegen. Alternativ können Sie die Activity API verwenden. Dann müssen Sie keine Vorgangsbezeichner für die Telemetrieelemente festlegen, da das Application Insights SDK dies für Sie erledigt:

• Erstellen Sie ein neues Activity Element, nachdem Sie ein Element aus der Warteschlange erhalten haben.
• Wird verwendet Activity.SetParentId(message.ParentId) , um Verbraucher- und Produzentenprotokolle zu korrelieren.
• Starten Sie das Activity.
• Nachverfolgen von Dequeue-, Prozess- und Löschvorgängen mithilfe von Start/StopOperation Hilfsern. Führen Sie dies aus demselben asynchronen Steuerungsfluss (Ausführungskontext) aus. Auf diese Weise werden sie korrekt korreliert.
• Beenden Sie die Activity.
• Manuelles Verwenden Start/StopOperation oder Anrufen der Track Telemetrie.

Abhängigkeitstypen

Application Insights verwendet Abhängigkeitstyp zum Anpassen von Ui-Oberflächen. Bei Warteschlangen erkennt sie die folgenden Typen, DependencyTelemetry die die Transaktionsdiagnose verbessern:

• Azure queue für Azure Storage-Warteschlangen
• Azure Event Hubs für Azure Event Hubs
• Azure Service Bus für Azure Service Bus

Batchverarbeitung

Bei einigen Warteschlangen können Sie mehrere Nachrichten mit einer Anforderung aufheben. Die Verarbeitung solcher Nachrichten ist vermutlich unabhängig und gehört zu den verschiedenen logischen Vorgängen. Es ist nicht möglich, den Dequeue Vorgang mit einer bestimmten Nachricht zu korrelieren, die verarbeitet wird.

Jede Nachricht sollte in einem eigenen asynchronen Kontrollfluss verarbeitet werden. Weitere Informationen finden Sie im Abschnitt " Nachverfolgung ausgehender Abhängigkeiten ".

Lang ausgeführte Hintergrundaufgaben

Einige Anwendungen starten lang ausgeführte Vorgänge, die möglicherweise durch Benutzeranforderungen verursacht werden. Aus der Sicht der Ablaufverfolgung/Instrumentierung unterscheidet sich dies nicht von der Anforderungs- oder Abhängigkeitsinstrumentation:

async Task BackgroundTask()
{
    var operation = telemetryClient.StartOperation<DependencyTelemetry>(taskName);
    operation.Telemetry.Type = "Background";
    try
    {
        int progress = 0;
        while (progress < 100)
        {
            // Process the task.
            telemetryClient.TrackTrace($"done {progress++}%");
        }
        // Update status code and success as appropriate.
    }
    catch (Exception e)
    {
        telemetryClient.TrackException(e);
        // Update status code and success as appropriate.
        throw;
    }
    finally
    {
        telemetryClient.StopOperation(operation);
    }
}

In diesem Beispiel telemetryClient.StartOperation wird der Korrelationskontext erstellt DependencyTelemetry und gefüllt. Angenommen, Sie haben einen übergeordneten Vorgang, der von eingehenden Anforderungen erstellt wurde, die den Vorgang geplant haben. BackgroundTask Solange derselbe asynchrone Kontrollfluss wie eine eingehende Anforderung beginnt, wird er mit diesem übergeordneten Vorgang korreliert. BackgroundTask und alle geschachtelten Telemetrieelemente werden automatisch mit der Anforderung korreliert, die dies verursacht hat, auch nachdem die Anforderung beendet wurde.

Wenn die Aufgabe mit dem Hintergrundthread beginnt, dem kein Vorgang (Activity) zugeordnet ist, BackgroundTask hat er kein übergeordnetes Element. Es kann jedoch geschachtelte Vorgänge haben. Alle telemetrieelemente, die von der Aufgabe gemeldet wurden, werden mit der DependencyTelemetry erstellten BackgroundTaskin korreliert.

Nachverfolgung ausgehender Abhängigkeiten

Sie können Ihre eigene Abhängigkeitsart oder einen Vorgang nachverfolgen, der von Application Insights nicht unterstützt wird.

Die Enqueue Methode in der Servicebus-Warteschlange oder die Speicherwarteschlange kann als Beispiele für eine solche benutzerdefinierte Nachverfolgung dienen.

Der allgemeine Ansatz für die benutzerdefinierte Abhängigkeitsnachverfolgung lautet:

• Rufen Sie die TelemetryClient.StartOperation (Erweiterungs)-Methode auf, die die eigenschaften ausfüllt, die DependencyTelemetry für die Korrelation und einige andere Eigenschaften erforderlich sind, z. B. Start, Zeitstempel und Dauer.
• Legen Sie weitere benutzerdefinierte Eigenschaften für den DependencyTelemetryNamen und einen anderen benötigten Kontext fest.
• Führen Sie einen Abhängigkeitsaufruf aus, und warten Sie darauf.
• Beenden Sie den Vorgang, StopOperation wenn er abgeschlossen ist.
• Behandeln von Ausnahmen.

public async Task RunMyTaskAsync()
{
    using (var operation = telemetryClient.StartOperation<DependencyTelemetry>("task 1"))
    {
        try 
        {
            var myTask = await StartMyTaskAsync();
            // Update status code and success as appropriate.
        }
        catch(...) 
        {
            // Update status code and success as appropriate.
        }
    }
}

Durch das Löschen eines Vorgangs wird der Vorgang beendet, sodass Sie den Vorgang möglicherweise anstelle eines Aufrufs StopOperationausführen.

Parallele Verarbeitung und Nachverfolgung von Vorgängen

Durch Das Aufrufen StopOperation wird nur der Vorgang beendet, der gestartet wurde. Wenn der aktuelle ausgeführte Vorgang nicht mit dem Vorgang übereinstimmt, den Sie beenden möchten, StopOperation führt nichts aus. Diese Situation kann auftreten, wenn Sie mehrere Vorgänge parallel im gleichen Ausführungskontext starten.

var firstOperation = telemetryClient.StartOperation<DependencyTelemetry>("task 1");
var firstTask = RunMyTaskAsync();

var secondOperation = telemetryClient.StartOperation<DependencyTelemetry>("task 2");
var secondTask = RunMyTaskAsync();

await firstTask;

// FAILURE!!! This will do nothing and will not report telemetry for the first operation
// as currently secondOperation is active.
telemetryClient.StopOperation(firstOperation); 

await secondTask;

Stellen Sie sicher, dass Sie den Vorgang immer in derselben asynchronen Methode aufrufen StartOperation und verarbeiten, um Vorgänge zu isolieren, die parallel ausgeführt werden. Wenn der Vorgang synchron (oder nicht asynchron) ist, schließen Sie den Prozess um und verfolgen sie mit Task.Run.

public void RunMyTask(string name)
{
    using (var operation = telemetryClient.StartOperation<DependencyTelemetry>(name))
    {
        Process();
        // Update status code and success as appropriate.
    }
}

public async Task RunAllTasks()
{
    var task1 = Task.Run(() => RunMyTask("task 1"));
    var task2 = Task.Run(() => RunMyTask("task 2"));
    
    await Task.WhenAll(task1, task2);
}

ApplicationInsights-Vorgänge vs. System.Diagnostics.Activity

System.Diagnostics.Activity stellt den Kontext der verteilten Ablaufverfolgung dar und wird von Frameworks und Bibliotheken verwendet, um Kontext innerhalb und außerhalb des Prozesses zu erstellen und zu verteilen und Telemetrieelemente zu korrelieren. Activity arbeitet zusammen mit System.Diagnostics.DiagnosticSource dem Benachrichtigungsmechanismus zwischen dem Framework/der Bibliothek, um interessante Ereignisse wie eingehende oder ausgehende Anforderungen und Ausnahmen zu benachrichtigen.

Aktivitäten sind erstklassige Bürger in Application Insights. Automatische Abhängigkeit und Anforderungssammlung basieren stark auf sie zusammen mit DiagnosticSource Ereignissen. Wenn Sie in Ihrer Anwendung erstellt haben Activity , würde dies nicht dazu führen, dass Application Insights-Telemetrie erstellt wird. Application Insights muss Ereignisse empfangen DiagnosticSource und die Ereignisnamen und Nutzlasten kennen, die in Telemetrie übersetzt werden Activity .

Jeder Application Insights-Vorgang (Anforderung oder Abhängigkeit) umfasst Activity. Wenn StartOperation sie aufgerufen wird, wird sie darunter erstellt Activity . StartOperation ist die empfohlene Methode zum manuellen Nachverfolgen von Anforderungs- oder Abhängigkeits-Telemetriedaten und sicherstellen, dass alles korreliert ist.

Indikatoren in Application Insights

Application Insights unterstützt Leistungsindikatoren und Ereigniszähler. Dieses Handbuch bietet eine Übersicht über beide Anwendungen, einschließlich Zweck, Konfiguration und Verwendung in .NET-Anwendungen.

Überblick

Leistungsindikatoren

Windows stellt verschiedene Leistungsindikatoren bereit, z. B. zum Sammeln von Prozessor-, Arbeitsspeicher- und Datenträgernutzungsstatistiken. Sie können auch eigene Leistungsindikatoren definieren.

Ihre Anwendung unterstützt die Leistungsindikatorsammlung, wenn sie unter Internetinformationsserver (IIS) auf einem lokalen Host oder einem virtuellen Computer mit Administratorzugriff ausgeführt wird. Anwendungen, die als Azure Web Apps ausgeführt werden, können nicht direkt auf Leistungsindikatoren zugreifen, aber Application Insights sammelt eine Teilmenge der verfügbaren Leistungsindikatoren.

Voraussetzungen

Gewähren Sie dem App-Pooldienstkonto die Berechtigung zum Überwachen von Leistungsindikatoren, indem Sie es der Gruppe "Benutzer überwachen" hinzufügen.

net localgroup "Performance Monitor Users" /add "IIS APPPOOL\NameOfYourPool"

Anzeigen von Leistungsindikatoren

Der Bereich "Metriken " zeigt den Standardsatz von Leistungsindikatoren an.

Hinzufügen von Leistungsindikatoren

Wenn der gewünschte Leistungsindikator nicht in der Liste der Metriken enthalten ist, können Sie ihn hinzufügen.

using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddApplicationInsightsTelemetry();

// The following configures PerformanceCollectorModule.

builder.Services.ConfigureTelemetryModule<PerformanceCollectorModule>((module, o) =>
    {
        // The application process name could be "dotnet" for ASP.NET Core self-hosted applications.
        module.Counters.Add(new PerformanceCounterCollectionRequest(@"\Process([replace-with-application-process-name])\Page Faults/sec", "DotnetPageFaultsPerfSec"));
    });

var app = builder.Build();

Erfassen von Leistungsindikatoren im Code für ASP.NET Webanwendungen oder .NET/.NET Core-Konsolenanwendungen

Um Systemleistungsindikatoren zu sammeln und an Application Insights zu senden, können Sie den folgenden Codeausschnitt anpassen:

    var perfCollectorModule = new PerformanceCollectorModule();
    perfCollectorModule.Counters.Add(new PerformanceCounterCollectionRequest(
      @"\Process([replace-with-application-process-name])\Page Faults/sec", "PageFaultsPerfSec"));
    perfCollectorModule.Initialize(TelemetryConfiguration.Active);

Oder Sie können dasselbe mit benutzerdefinierten Metriken tun, die Sie erstellt haben:

    var perfCollectorModule = new PerformanceCollectorModule();
    perfCollectorModule.Counters.Add(new PerformanceCounterCollectionRequest(
      @"\Sales(photo)\# Items Sold", "Photo sales"));
    perfCollectorModule.Initialize(TelemetryConfiguration.Active);

Leistungsindikatoren für Anwendungen, die in Azure Web Apps und Windows-Containern in Azure App Service ausgeführt werden

Sowohl ASP.NET als auch ASP.NET Core-Anwendungen, die in Azure Web Apps bereitgestellt werden, werden in einer speziellen Sandkastenumgebung ausgeführt. Anwendungen, die in Azure App Service bereitgestellt werden, können einen Windows-Container verwenden oder in einer Sandkastenumgebung gehostet werden. Wenn die Anwendung in einem Windows-Container bereitgestellt wird, sind alle Standardleistungsindikatoren im Containerimage verfügbar.

Die Sandkastenumgebung lässt keinen direkten Zugriff auf Systemleistungsindikatoren zu. Eine begrenzte Teilmenge von Leistungsindikatoren wird jedoch als Umgebungsvariablen verfügbar gemacht, wie in Perf-Leistungsindikatoren beschrieben, die als Umgebungsvariablen verfügbar gemacht werden. In dieser Umgebung ist nur eine Teilmenge von Leistungsindikatoren verfügbar. Die vollständige Liste finden Sie unter "Perf Counters", die als Umgebungsvariablen verfügbar gemacht werden.

Das Application Insights SDK für ASP.NET und ASP.NET Core erkennt, ob Code in einer Web-App oder einem Nicht-Windows-Container bereitgestellt wird. Die Erkennung bestimmt, ob leistungsindikatoren in einer Sandkastenumgebung erfasst oder der Standardsammlungsmechanismus verwendet wird, wenn sie auf einem Windows-Container oder virtuellen Computer gehostet wird.

Protokollanalyseabfragen für Leistungsindikatoren

Sie können Leistungsindikatorberichte in Log Analytics durchsuchen und anzeigen.

Das PerformanceCounters-Schema macht den Namen category und counter den instanceNamen der einzelnen Leistungsindikatoren verfügbar. In der Telemetrie für jede Anwendung werden nur die Leistungsindikatoren für diese Anwendung angezeigt. Um beispielsweise zu sehen, welche Leistungsindikatoren verfügbar sind:

performanceCounters | summarize count(), avg(value) by category, instance, counter

Instance Hier bezieht sich auf die Instanz des Leistungsindikators, nicht auf die Rolle oder die Servercomputerinstanz. Der Name der Instanz des Leistungsindikators segmentiert in der Regel Segmente, z. B. Prozessorzeit, anhand des Namens des Prozesses oder der Anwendung.

So rufen Sie ein Diagramm des verfügbaren Speichers über den letzten Zeitraum ab:

performanceCounters | where counter == "Available Bytes" | summarize avg(value), min(value) by bin(timestamp, 1h) | render timechart

Wie bei anderen Telemetriedaten verfügt performanceCounters auch über eine Spalte cloud_RoleInstance , die die Identität der Hostserverinstanz angibt, auf der Ihre App ausgeführt wird. Um beispielsweise die Leistung Ihrer App auf den verschiedenen Computern zu vergleichen:

performanceCounters | where counter == "% Processor Time" and instance == "SendMetrics" | summarize avg(value) by cloud_RoleInstance, bin(timestamp, 1d)

Häufig gestellte Fragen zu Leistungsindikatoren

Informationen zum Überprüfen häufig gestellter Fragen (FAQ) finden Sie unter Häufig gestellte Fragen zu Leistungsindikatoren.

Ereignisindikatoren

EventCounter ist .NET/.NET Core-Mechanismus zum Veröffentlichen und Nutzen von Leistungsindikatoren oder Statistiken. EventCounters werden auf allen Betriebssystemplattformen unterstützt – Windows, Linux und macOS. Es kann als plattformübergreifendes Äquivalent für performanceCounters betrachtet werden, das nur in Windows-Systemen unterstützt wird.

Während Benutzer alle benutzerdefinierten Ereigniszähler veröffentlichen können, um ihre Anforderungen zu erfüllen, veröffentlicht .NET standardmäßig eine Reihe dieser Leistungsindikatoren. In diesem Dokument werden die Schritte zum Sammeln und Anzeigen von Ereigniszählern (systemdefiniert oder benutzerdefiniert) in Azure Application Insights erläutert.

Verwenden von Application Insights zum Sammeln von EventCounters

Application Insights unterstützt das Sammeln EventCounters mit seinem EventCounterCollectionModulePaket , das Teil des neu veröffentlichten NuGet-Pakets "Microsoft.ApplicationInsights.EventCounterCollector" ist. EventCounterCollectionModule wird bei Verwendung von AspNetCore oder WorkerService automatisch aktiviert. EventCounterCollectionModule erfasst Indikatoren mit einer nicht konfigurierten Sammlungshäufigkeit von 60 Sekunden. Es sind keine speziellen Berechtigungen zum Sammeln von EventCounters erforderlich. Für ASP.NET Core-Anwendungen möchten Sie auch das Microsoft.ApplicationInsights.AspNetCore-Paket hinzufügen.

dotnet add package Microsoft.ApplicationInsights.EventCounterCollector
dotnet add package Microsoft.ApplicationInsights.AspNetCore

Gesammelte Standardindikatoren

Ab der Version 2.15.0 von AspNetCore SDK oder WorkerService SDK werden standardmäßig keine Indikatoren erfasst. Das Modul selbst ist aktiviert, sodass Benutzer die gewünschten Zähler hinzufügen können, um sie zu sammeln.

Eine Liste bekannter Leistungsindikatoren, die von .NET Runtime veröffentlicht werden, finden Sie im Dokument "Verfügbare Leistungsindikatoren ".

Anpassen der zu erfassenden Leistungsindikatoren

Das folgende Beispiel zeigt, wie Zähler hinzugefügt/entfernt werden. Diese Anpassung erfolgt im Rahmen der Anwendungsdienstkonfiguration, nachdem die Telemetriesammlung von Application Insights entweder AddApplicationInsightsTelemetry() oder AddApplicationInsightsWorkerService(). Nachfolgend sehen Sie einen Beispielcode aus einer ASP.NET Core-Anwendung. Weitere Arten von Anwendungen finden Sie in diesem Dokument.

using Microsoft.ApplicationInsights.Extensibility.EventCounterCollector;
using Microsoft.Extensions.DependencyInjection;

builder.Services.ConfigureTelemetryModule<EventCounterCollectionModule>(
        (module, o) =>
        {
            // Removes all default counters, if any.
            module.Counters.Clear();

            // Adds a user defined counter "MyCounter" from EventSource named "MyEventSource"
            module.Counters.Add(
                new EventCounterCollectionRequest("MyEventSource", "MyCounter"));

            // Adds the system counter "gen-0-size" from "System.Runtime"
            module.Counters.Add(
                new EventCounterCollectionRequest("System.Runtime", "gen-0-size"));
        }
    );

Deaktivieren des EventCounter-Auflistungsmoduls

EventCounterCollectionModule kann mithilfe von ApplicationInsightsServiceOptions.

Im folgenden Beispiel wird das ASP.NET Core SDK verwendet.

using Microsoft.ApplicationInsights.AspNetCore.Extensions;
using Microsoft.Extensions.DependencyInjection;

var applicationInsightsServiceOptions = new ApplicationInsightsServiceOptions();
applicationInsightsServiceOptions.EnableEventCounterCollectionModule = false;
builder.Services.AddApplicationInsightsTelemetry(applicationInsightsServiceOptions);

Ein ähnlicher Ansatz kann auch für das WorkerService SDK verwendet werden, aber der Namespace muss geändert werden, wie im folgenden Beispiel gezeigt.

using Microsoft.ApplicationInsights.AspNetCore.Extensions;
using Microsoft.Extensions.DependencyInjection;

var applicationInsightsServiceOptions = new ApplicationInsightsServiceOptions();
applicationInsightsServiceOptions.EnableEventCounterCollectionModule = false;
builder.Services.AddApplicationInsightsTelemetry(applicationInsightsServiceOptions);

Protokollanalyseabfragen für Ereignisindikatoren

Sie können Ereigniszählerberichte in Log Analytics in der customMetrics-Tabelle durchsuchen und anzeigen.

Führen Sie z. B. die folgende Abfrage aus, um zu sehen, welche Indikatoren gesammelt werden und für die Abfrage verfügbar sind:

customMetrics | summarize avg(value) by name

Führen Sie die folgende Abfrage aus, um ein Diagramm eines bestimmten Indikators (z. B.: ThreadPool Completed Work Item Count) über den letzten Zeitraum abzurufen.

customMetrics 
| where name contains "System.Runtime|ThreadPool Completed Work Item Count"
| where timestamp >= ago(1h)
| summarize avg(value) by cloud_RoleInstance, bin(timestamp, 1m)
| render timechart

Wie bei anderen Telemetriedaten verfügt customMetrics auch über eine Spalte cloud_RoleInstance , die die Identität der Hostserverinstanz angibt, auf der Ihre App ausgeführt wird. Die vorherige Abfrage zeigt den Leistungsindikatorwert pro Instanz an und kann verwendet werden, um die Leistung verschiedener Serverinstanzen zu vergleichen.

Häufig gestellte Fragen zu Ereignisindikatoren

Informationen zum Überprüfen häufig gestellter Fragen (FAQ) finden Sie unter Häufig gestellte Fragen zu Ereignisindikatoren.

Konfigurieren des Application Insights SDK

In diesem Abschnitt

• Telemetriekanäle
• Telemetriemodule
• Telemetrie deaktivieren
• Telemetrieinitialisierer
• Telemetrieprozessor
• ApplicationId-Anbieter
• Snapshot-Auflistung
• Probenahme
• Anreichern und Korrelieren über HTTP

Sie können das Application Insights SDK für ASP.NET und ASP.NET Core anpassen, um die Standardkonfiguration zu ändern.

Telemetriekanäle

Telemetriekanäle sind ein integraler Bestandteil der Application Insights SDKs. Sie verwalten Pufferung und Übertragung von Telemetrie an den Application Insights-Dienst. Die .NET- und .NET Core-Versionen der SDKs verfügen über zwei integrierte Telemetriekanäle: InMemoryChannel und ServerTelemetryChannel. In diesem Artikel werden die einzelnen Kanäle beschrieben und das Anpassen des Kanalverhaltens veranschaulicht.

Was sind Telemetriekanäle?

Telemetriekanäle sind für das Puffern von Telemetrieelementen und das Senden an den Application Insights-Dienst verantwortlich, in dem sie für Abfragen und Analysen gespeichert sind. Ein Telemetriekanal ist eine beliebige Klasse, die die Microsoft.ApplicationInsights.ITelemetryChannel Schnittstelle implementiert.

Die Send(ITelemetry item) Methode eines Telemetriekanals wird aufgerufen, nachdem alle Telemetrieinitialisierer und Telemetrieprozessoren aufgerufen wurden. Daher erreichen alle elemente, die von einem Telemetrieprozessor gelöscht wurden, nicht den Kanal. Die Send() Methode sendet die Elemente nicht sofort an das Back-End. In der Regel werden sie im Arbeitsspeicher gepuffert und in Batches zur effizienten Übertragung gesendet.

Vermeiden Sie anrufe Flush() , es sei denn, es ist wichtig, die gepufferte Telemetrie sofort zu senden. Verwenden Sie sie nur in Szenarien wie Herunterfahren der Anwendung, Ausnahmebehandlung oder bei Verwendung von kurzlebigen Prozessen wie Hintergrundaufträgen oder Befehlszeilentools. In Webanwendungen oder lang ausgeführten Diensten verarbeitet das SDK das sendende Telemetrie automatisch. Das Unnötige Aufrufen Flush() kann zu Leistungsproblemen führen.

Live Metrics Stream verfügt auch über einen benutzerdefinierten Kanal, der das Livestreaming der Telemetrie ermöglicht. Dieser Kanal ist unabhängig vom regulären Telemetriekanal, und dieses Dokument gilt nicht für diesen Kanal.

Integrierte Telemetriekanäle

Die Application Insights .NET- und .NET Core-SDKs werden mit zwei integrierten Kanälen ausgeliefert:

• InMemoryChannel: Ein einfacher Kanal, in dem Elemente im Arbeitsspeicher gepuffert werden, bis sie gesendet werden. Elemente werden im Arbeitsspeicher gepuffert und einmal alle 30 Sekunden geleert, oder wenn 500 Elemente gepuffert werden. Dieser Kanal bietet minimale Zuverlässigkeitsgarantien, da das Senden von Telemetrie nach einem Fehler nicht wiederholt wird. Dieser Kanal behält auch keine Elemente auf dem Datenträger bei. Daher gehen alle nicht gesendeten Elemente beim Herunterfahren der Anwendung dauerhaft verloren, unabhängig davon, ob sie ordnungsgemäß ist oder nicht. Dieser Kanal implementiert eine Flush() Methode, mit der alle im Arbeitsspeicher enthaltenen Telemetrieelemente synchron erzwungen werden können. Dieser Kanal eignet sich gut für Kurzlaufanwendungen, bei denen eine synchrone Spülung ideal ist.

  Dieser Kanal ist Teil des größeren Microsoft.ApplicationInsights NuGet-Pakets und ist der Standardkanal, den das SDK verwendet, wenn nichts anderes konfiguriert ist.

• ServerTelemetryChannel: Ein erweiterter Kanal mit Wiederholungsrichtlinien und der Funktion zum Speichern von Daten auf einem lokalen Datenträger. Dieser Kanal ruft das Senden von Telemetrie erneut auf, wenn vorübergehende Fehler auftreten. Dieser Kanal verwendet auch lokalen Datenträgerspeicher, um Elemente während Netzwerkausfällen oder hohen Telemetrievolumes auf dem Datenträger zu speichern. Aufgrund dieser Wiederholungsmechanismen und des lokalen Datenträgerspeichers gilt dieser Kanal als zuverlässiger. Es wird für alle Produktionsszenarien empfohlen. Dieser Kanal ist die Standardeinstellung für ASP.NET und ASP.NET Core-Anwendungen, die gemäß der offiziellen Dokumentation konfiguriert sind. Dieser Kanal ist für Serverszenarien mit langen Prozessen optimiert. Die Flush() von diesem Kanal implementierte Methode ist nicht synchron.

  Dieser Kanal wird als Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel NuGet-Paket ausgeliefert und automatisch abgerufen, wenn Sie entweder das Microsoft.ApplicationInsights.Web- oder Microsoft.ApplicationInsights.AspNetCore NuGet-Paket verwenden.

Konfigurieren eines Telemetriekanals

Sie konfigurieren einen Telemetriekanal, indem Sie ihn auf die aktive Telemetriekonfiguration festlegen. Bei ASP.NET Anwendungen muss die Konfiguration die Telemetriekanalinstanz auf TelemetryConfiguration.Active oder durch Ändern ApplicationInsights.configfestlegen. Für ASP.NET Core-Anwendungen umfasst die Konfiguration das Hinzufügen des Kanals zum Container zum Einfügen von Abhängigkeiten.

In den folgenden Abschnitten finden Sie Beispiele für die Konfiguration der StorageFolder Einstellung für den Kanal in verschiedenen Anwendungstypen. StorageFolder ist nur eine der konfigurierbaren Einstellungen. Die vollständige Liste der Konfigurationseinstellungen finden Sie im Abschnitt "Konfigurierbare Einstellungen in Kanälen " weiter unten in diesem Artikel.

using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
protected void Application_Start()
{
    var serverTelemetryChannel = new ServerTelemetryChannel();
serverTelemetryChannel.StorageFolder = @"d:\temp\applicationinsights";
    serverTelemetryChannel.Initialize(TelemetryConfiguration.Active);
    TelemetryConfiguration.Active.TelemetryChannel = serverTelemetryChannel;
}

    <TelemetrySinks>
        <Add Name="default">
            <TelemetryProcessors>
                <!-- Telemetry processors omitted for brevity -->
            </TelemetryProcessors>
            <TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel, Microsoft.AI.ServerTelemetryChannel">
                <StorageFolder>d:\temp\applicationinsights</StorageFolder>
            </TelemetryChannel>
        </Add>
    </TelemetrySinks>

using Microsoft.ApplicationInsights.Channel;
using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;

public void ConfigureServices(IServiceCollection services)
{
    // This sets up ServerTelemetryChannel with StorageFolder set to a custom ___location.
    services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel() {StorageFolder = @"d:\temp\applicationinsights" });

    services.AddApplicationInsightsTelemetry();
}

using Microsoft.ApplicationInsights.Channel;

var builder = WebApplication.CreateBuilder(args);

// Use the following to replace the default channel with InMemoryChannel.
// This can also be applied to ServerTelemetryChannel.
builder.Services.AddSingleton(typeof(ITelemetryChannel), new InMemoryChannel() {MaxTelemetryBufferCapacity = 19898 });

builder.Services.AddApplicationInsightsTelemetry();

var app = builder.Build();

Konfiguration im Code für Konsolenanwendungen

Bei Konsolen-Apps ist der Code für .NET und .NET Core identisch:

var serverTelemetryChannel = new ServerTelemetryChannel();
serverTelemetryChannel.StorageFolder = @"d:\temp\applicationinsights";
serverTelemetryChannel.Initialize(TelemetryConfiguration.Active);
TelemetryConfiguration.Active.TelemetryChannel = serverTelemetryChannel;

Betriebsdetails von ServerTelemetryChannel

ServerTelemetryChannel speichert eingehende Elemente in einem Speicherpuffer. Die Elemente werden einmal alle 30 Sekunden serialisiert, komprimiert und in einer Transmission Instanz gespeichert, oder wenn 500 Elemente gepuffert werden. Eine einzelne Transmission Instanz enthält bis zu 500 Elemente und stellt einen Batch von Telemetrie dar, der über einen einzelnen HTTPS-Aufruf an den Application Insights-Dienst gesendet wird.

Standardmäßig können maximal 10 Transmission Instanzen parallel gesendet werden. Wenn Telemetrie schneller eintrifft oder das Netzwerk oder das Application Insights-Back-End langsam ist, Transmission werden Instanzen im Arbeitsspeicher gespeichert. Die Standardkapazität dieses Speicherpuffers Transmission beträgt 5 MB. Wenn die In-Memory-Kapazität überschritten wird, Transmission werden Instanzen auf einem lokalen Datenträger bis zu einem Grenzwert von 50 MB gespeichert.

Transmission Instanzen werden auch auf dem lokalen Datenträger gespeichert, wenn Netzwerkprobleme auftreten. Nur die Elemente, die auf einem lokalen Datenträger gespeichert sind, überleben einen Anwendungsabsturz. Sie werden immer dann gesendet, wenn die Anwendung erneut gestartet wird. Wenn Netzwerkprobleme weiterhin bestehen, wird eine exponentielle Backofflogik verwendet, ServerTelemetryChannel die zwischen 10 Sekunden und 1 Stunde liegt, bevor Sie die Telemetrie erneut senden.

Konfigurierbare Einstellungen in Kanälen

Eine vollständige Liste der konfigurierbaren Einstellungen für jeden Kanal finden Sie unter:

• InMemoryChannel
• ServerTelemetryChannel

Hier sind die am häufigsten verwendeten Einstellungen für ServerTelemetryChannel:

• MaxTransmissionBufferCapacity: Die maximale Speichermenge in Bytes, die vom Kanal zum Puffern von Übertragungen im Arbeitsspeicher verwendet wird. Wenn diese Kapazität erreicht ist, werden neue Elemente direkt auf dem lokalen Datenträger gespeichert. Der Standardwert ist 5 MB. Das Festlegen eines höheren Werts führt zu einer geringeren Datenträgerauslastung, aber denken Sie daran, dass Elemente im Arbeitsspeicher verloren gehen, wenn die Anwendung abstürzt.

• MaxTransmissionSenderCapacity: Die maximale Anzahl von Transmission Instanzen, die gleichzeitig an Application Insights gesendet werden. Der Standardwert ist 10. Diese Einstellung kann auf eine höhere Zahl konfiguriert werden, die empfohlen wird, wenn ein großes Volumen an Telemetrie generiert wird. Ein hohes Volumen tritt in der Regel während der Auslastungstests oder beim Deaktivieren des Samplings auf.

• StorageFolder: Der Ordner, der vom Kanal zum Speichern von Elementen auf dem Datenträger nach Bedarf verwendet wird. In Windows wird entweder %LOCALAPPDATA% oder %TEMP% verwendet, wenn kein anderer Pfad explizit angegeben wird. In anderen Umgebungen als Windows müssen Sie einen gültigen Speicherort oder eine gültige Telemetrie angeben, die nicht auf einem lokalen Datenträger gespeichert ist.

Welchen Kanal sollte ich verwenden?

Wir empfehlen ServerTelemetryChannel für die meisten Produktionsszenarien, die lange ausgeführte Anwendungen umfassen. Weitere Informationen zum Leeren der Telemetrie finden Sie unter Verwendung.Flush()

Gründe für die Verwendung von Flush()

Die Flush() Methode sendet alle gepufferten Telemetrie sofort. Es sollte jedoch nur in bestimmten Szenarien verwendet werden.

Verwenden Sie Flush() folgendes:

• Die Anwendung wird heruntergefahren, und Sie möchten sicherstellen, dass Telemetrie vor dem Beenden gesendet wird.
• Sie befinden sich in einem Ausnahmehandler und müssen garantieren, dass Telemetrie übermittelt wird.
• Sie schreiben einen kurzlebigen Prozess wie einen Hintergrundauftrag oder ein CLI-Tool, das schnell beendet wird.

Vermeiden Sie die Verwendung Flush() in lang ausgeführten Anwendungen wie Webdiensten. Das SDK verwaltet die Pufferung und Übertragung automatisch. Das Unnötige Aufrufen Flush() kann zu Leistungsproblemen führen und garantiert nicht, dass alle Daten gesendet werden, insbesondere bei der Verwendung ServerTelemetryChannel, die nicht synchron geleert wird.

Telemetriemodule

Application Insights erfasst automatisch Telemetriedaten zu bestimmten Workloads, ohne dass eine manuelle Nachverfolgung durch den Benutzer erforderlich ist.

Die unten aufgeführten Module für die automatische Sammlung sind standardmäßig aktiviert. Sie können sie deaktivieren oder ihr Standardverhalten anpassen.

Konfigurieren von Telemetriemodulen

<ApplicationInsights>
  <TelemetryModules>

    <!-- Dependency tracking -->
    <Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule, Microsoft.AI.DependencyCollector">
      <!-- Match Core example: enable W3C header injection -->
      <EnableW3CHeadersInjection>true</EnableW3CHeadersInjection>
    </Add>

    <!-- EventCounterCollectionModule: add a single counter (if you use event counters) -->
    <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.EventCounterCollectionModule, Microsoft.AI.PerfCounterCollector">
      <Counters>
        <!-- Mirrors Core example: only collect 'gen-0-size' from System.Runtime -->
        <Add ProviderName="System.Runtime" CounterName="gen-0-size" />
      </Counters>
    </Add>

    <!-- PerformanceCollectorModule (classic Windows performance counters).
         To DISABLE perf-counter collection, do NOT include this module.
         If it already exists in your file, remove or comment it out.
         Example of the line you would remove:
    <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.PerformanceCollectorModule, Microsoft.AI.PerfCounterCollector" />
    -->

  </TelemetryModules>
</ApplicationInsights>

using Microsoft.ApplicationInsights.DependencyCollector;
using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddApplicationInsightsTelemetry();

// The following configures DependencyTrackingTelemetryModule.
// Similarly, any other default modules can be configured.
builder.Services.ConfigureTelemetryModule<DependencyTrackingTelemetryModule>((module, o) =>
        {
            module.EnableW3CHeadersInjection = true;
        });

// The following removes all default counters from EventCounterCollectionModule, and adds a single one.
builder.Services.ConfigureTelemetryModule<EventCounterCollectionModule>((module, o) =>
        {
            module.Counters.Add(new EventCounterCollectionRequest("System.Runtime", "gen-0-size"));
        });

// The following removes PerformanceCollectorModule to disable perf-counter collection.
// Similarly, any other default modules can be removed.
var performanceCounterService = builder.Services.FirstOrDefault<ServiceDescriptor>(t => t.ImplementationType == typeof(PerformanceCollectorModule));
if (performanceCounterService != null)
{
    builder.Services.Remove(performanceCounterService);
}

var app = builder.Build();

var builder = WebApplication.CreateBuilder(args);

var aiOptions = new Microsoft.ApplicationInsights.AspNetCore.Extensions.ApplicationInsightsServiceOptions();

// Disables adaptive sampling.
aiOptions.EnableAdaptiveSampling = false;

// Disables live metrics (also known as QuickPulse).
aiOptions.EnableQuickPulseMetricStream = false;

builder.Services.AddApplicationInsightsTelemetry(aiOptions);
var app = builder.Build();

{
    "ApplicationInsights": {
    "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000",
    "EnableAdaptiveSampling": false,
    "EnablePerformanceCounterCollectionModule": false
    }
}

Telemetrie deaktivieren

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddApplicationInsightsTelemetry();

// any custom configuration can be done here:
builder.Services.Configure<TelemetryConfiguration>(x => x.DisableTelemetry = true);

var app = builder.Build();

Telemetrieinitialisierer

Verwenden Sie Telemetrieinitialisierer, um Telemetrie mit zusätzlichen Informationen zu erweitern oder Telemetrieeigenschaften zu überschreiben, die von den Standard-Telemetriemodulen festgelegt wurden.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddSingleton<ITelemetryInitializer, MyCustomTelemetryInitializer>();

var app = builder.Build();

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddApplicationInsightsTelemetry();

// Remove a specific built-in telemetry initializer
var tiToRemove = builder.Services.FirstOrDefault<ServiceDescriptor>
                    (t => t.ImplementationType == typeof(AspNetCoreEnvironmentTelemetryInitializer));
if (tiToRemove != null)
{
    builder.Services.Remove(tiToRemove);
}

// Remove all initializers
// This requires importing namespace by using Microsoft.Extensions.DependencyInjection.Extensions;
builder.Services.RemoveAll(typeof(ITelemetryInitializer));

var app = builder.Build();

Telemetrieprozessoren

    <TelemetryProcessors>
      <Add Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.AdaptiveSamplingTelemetryProcessor, Microsoft.AI.ServerTelemetryChannel">
        <MaxTelemetryItemsPerSecond>5</MaxTelemetryItemsPerSecond>
      </Add>
    </TelemetryProcessors>

    <TelemetryProcessors>
     <Add Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.SamplingTelemetryProcessor, Microsoft.AI.ServerTelemetryChannel">

     <!-- Set a percentage close to 100/N where N is an integer. -->
     <!-- E.g. 50 (=100/2), 33.33 (=100/3), 25 (=100/4), 20, 1 (=100/100), 0.1 (=100/1000) -->
     <SamplingPercentage>10</SamplingPercentage>
     </Add>
   </TelemetryProcessors>

var builder = WebApplication.CreateBuilder(args);

// ...
builder.Services.AddApplicationInsightsTelemetry();
builder.Services.AddApplicationInsightsTelemetryProcessor<MyFirstCustomTelemetryProcessor>();

// If you have more processors:
builder.Services.AddApplicationInsightsTelemetryProcessor<MySecondCustomTelemetryProcessor>();

var app = builder.Build();

Verbindungszeichenfolge

Diese Einstellung bestimmt die Application Insights-Ressource, in der Ihre Daten angezeigt werden. In der Regel erstellen Sie eine separate Ressource mit einer separaten Verbindungszeichenfolge für jede Ihrer Anwendungen.

Siehe Verbindungszeichenfolgen in Application Insights für Codebeispiele .

Wenn Sie die Verbindungszeichenfolge dynamisch festlegen möchten, um z. B. Ergebnisse aus Ihrer Anwendung an unterschiedliche Ressourcen zu senden, können Sie die Verbindungszeichenfolge aus der Konfigurationsdatei weglassen und stattdessen im Code festlegen.

using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.ApplicationInsights;

    protected void Application_Start()
    {
        TelemetryConfiguration configuration = TelemetryConfiguration.CreateDefault();
        configuration.ConnectionString = "InstrumentationKey=00000000-0000-0000-0000-000000000000";
        var telemetryClient = new TelemetryClient(configuration);

    var tc = new TelemetryClient();
    tc.Context.ConnectionString = "InstrumentationKey=00000000-0000-0000-0000-000000000000";
    tc.TrackEvent("myEvent");
    // ...

using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.ApplicationInsights;

var builder = WebApplication.CreateBuilder(args);

// Add Application Insights
builder.Services.AddApplicationInsightsTelemetry();

var app = builder.Build();

// Resolve TelemetryConfiguration from DI and set the connection string
var config = app.Services.GetRequiredService<TelemetryConfiguration>();
config.ConnectionString = "InstrumentationKey=00000000-0000-0000-0000-000000000000";

app.Run();

using Microsoft.ApplicationInsights;

var tc = new TelemetryClient();
tc.Context.ConnectionString = "InstrumentationKey=00000000-0000-0000-0000-000000000000";
tc.TrackEvent("myEvent");
// ...

ApplicationId-Anbieter

Der Zweck dieses Anbieters besteht darin, eine Anwendungs-ID basierend auf einer Verbindungszeichenfolge nachzuschlagen. Die Anwendungs-ID ist enthalten RequestTelemetry und DependencyTelemetry wird verwendet, um die Korrelation im Portal zu ermitteln.

Diese Funktionalität ist durch Festlegen TelemetryConfiguration.ApplicationIdProviderverfügbar.

Schnittstelle: IApplicationIdProvider

public interface IApplicationIdProvider
{
    bool TryGetApplicationId(string instrumentationKey, out string applicationId);
}

Wir stellen zwei Implementierungen im Microsoft.ApplicationInsights SDK bereit: ApplicationInsightsApplicationIdProvider und DictionaryApplicationIdProvider.

ApplicationInsightsApplicationIdProvider

Dieser Wrapper ist für unsere Profil-API vorgesehen. Es drosselt Anforderungen und Cacheergebnisse. Dieser Anbieter wird automatisch eingeschlossen, wenn Sie entweder Microsoft.ApplicationInsights.DependencyCollector oder Microsoft.ApplicationInsights.Web installieren.

Die Klasse macht eine optionale Eigenschaft verfügbar, die aufgerufen wird ProfileQueryEndpoint. Standardmäßig ist sie auf https://dc.services.visualstudio.com/api/profiles/{0}/appId.

Wenn Sie einen Proxy konfigurieren müssen, empfehlen wir, die Basisadresse zu proxyen und sicherzustellen, dass der Pfad eingeschlossen ist /api/profiles/{0}/appId. Zur Laufzeit {0} wird der Instrumentierungsschlüssel für jede Anforderung durch den Instrumentierungsschlüssel ersetzt.

<ApplicationInsights>
    ...
    <ApplicationIdProvider Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.ApplicationInsightsApplicationIdProvider, Microsoft.ApplicationInsights">
        <ProfileQueryEndpoint>https://dc.services.visualstudio.com/api/profiles/{0}/appId</ProfileQueryEndpoint>
    </ApplicationIdProvider>
    ...
</ApplicationInsights>

TelemetryConfiguration.Active.ApplicationIdProvider = new ApplicationInsightsApplicationIdProvider();

using Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId;

var builder = WebApplication.CreateBuilder(args);

// Add Application Insights
builder.Services.AddApplicationInsightsTelemetry();

// Replace default provider with custom configuration
builder.Services.AddSingleton<IApplicationIdProvider>(sp =>
    new ApplicationInsightsApplicationIdProvider
    {
        ProfileQueryEndpoint = "https://custom-proxy/api/profiles/{0}/appId"
    });

var app = builder.Build();
app.Run();

DictionaryApplicationIdProvider

Dieser statische Anbieter basiert auf Ihren konfigurierten Instrumentierungsschlüssel-/Anwendungs-ID-Paaren.

Diese Klasse verfügt über die Defined Eigenschaft, bei der es sich um ein Dictionary<string,string> Instrumentierungsschlüssel-/Anwendungs-ID-Paar handelt.

Diese Klasse verfügt über die optionale Eigenschaft Next, die verwendet werden kann, um einen anderen Anbieter für die Verwendung zu konfigurieren, wenn eine Verbindungszeichenfolge angefordert wird, die in Ihrer Konfiguration nicht vorhanden ist.

<ApplicationInsights>
    ...
    <ApplicationIdProvider Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.DictionaryApplicationIdProvider, Microsoft.ApplicationInsights">
        <Defined>
            <Type key="InstrumentationKey_1" value="ApplicationId_1"/>
            <Type key="InstrumentationKey_2" value="ApplicationId_2"/>
        </Defined>
        <Next Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.ApplicationInsightsApplicationIdProvider, Microsoft.ApplicationInsights" />
    </ApplicationIdProvider>
    ...
</ApplicationInsights>

TelemetryConfiguration.Active.ApplicationIdProvider = new DictionaryApplicationIdProvider{
 Defined = new Dictionary<string, string>
    {
        {"InstrumentationKey_1", "ApplicationId_1"},
        {"InstrumentationKey_2", "ApplicationId_2"}
    }
};

using Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddApplicationInsightsTelemetry();

// Register DictionaryApplicationIdProvider
builder.Services.AddSingleton<IApplicationIdProvider>(sp =>
    new DictionaryApplicationIdProvider
    {
        Defined = new Dictionary<string, string>
        {
            { "InstrumentationKey_1", "ApplicationId_1" },
            { "InstrumentationKey_2", "ApplicationId_2" }
        },
        Next = new ApplicationInsightsApplicationIdProvider() // optional fallback
    });

var app = builder.Build();
app.Run();

Konfigurieren der Momentaufnahmesammlung

Informationen zum Konfigurieren der Snapshotsammlung für ASP.NET und ASP.NET Core-Anwendungen finden Sie unter "Aktivieren des Snapshotdebuggers für .NET-Apps in Azure Service Fabric,Cloud Services und virtuellen Computern".

Probenahme

Informationen zum Konfigurieren von Samplings für ASP.NET und ASP.NET Core-Anwendungen finden Sie unter Sampling in Application Insights.

Anreichern von Daten über HTTP

var requestTelemetry = HttpContext.Current?.Items["Microsoft.ApplicationInsights.RequestTelemetry"] as RequestTelemetry;

if (requestTelemetry != null)
{
    requestTelemetry.Properties["myProp"] = "someData";
}

HttpContext.Features.Get<RequestTelemetry>().Properties["myProp"] = someData

Hinzufügen der clientseitigen Überwachung

In den vorherigen Abschnitten haben Sie Anleitungen zu den Methoden erhalten, mit denen die serverseitige Überwachung automatisch und manuell konfiguriert werden kann. Wenn Sie die clientseitige Überwachung hinzufügen möchten, verwenden Sie das clientseitige JavaScript SDK. Sie können clientseitige Transaktionen einer beliebigen Webseite überwachen, indem Sie ein JavaScript (Web) SDK Loader-Skript vor dem schließenden </head>-Tag im HTML-Code der Seite hinzufügen.

Obwohl es möglich ist, das JavaScript (Web) SDK Loader-Skript manuell dem Header jeder HTML-Seite hinzuzufügen, sollten Sie das JavaScript (Web) SDK Loader-Skript stattdessen einer primären Seite hinzufügen. Diese Aktion schleust das JavaScript (Web) SDK Loader-Skript in alle Seiten einer Website ein.

<script> // apply custom changes to this script tag.
    @Html.Raw(JavaScriptSnippet.ScriptBody)
</script>

Problembehandlung

Informationen finden Sie in dem dedizierten Artikel zur Problembehandlung.

In Visual Studio 2019 gibt es ein bekanntes Problem: Das Speichern des Instrumentierungsschlüssels oder der Verbindungszeichenfolge in einem Benutzergeheimnis ist für .NET Framework-basierte Apps fehlerhaft. Der Schlüssel muss letztendlich in der Datei applicationinsights.config hartcodiert werden, um diesen Fehler zu umgehen. Dieser Artikel wurde so verfasst, dass dieses Problem komplett umgangen wird, indem keine Benutzergeheimnisse verwendet werden.

Testen der Konnektivität zwischen Ihrem Anwendungshost und dem Erfassungsdienst

Application Insights-SDKs und -Agents senden Telemetriedaten, die als REST-Aufrufe unserer Erfassungsendpunkte erfasst werden sollen. Sie können die Konnektivität Ihres Webservers oder Anwendungshostcomputers mit den Endpunkten des Erfassungsdiensts testen, indem Sie unformatierte REST-Clients über PowerShell- oder cURL-Befehle verwenden. Weitere Informationen finden Sie unter Problembehandlung bei fehlender Anwendungstelemetrie in Azure Monitor Application Insights.

Open-Source-SDK

Lesen und Hinzufügen von Code.

Informationen zu den neuesten Updates und Fehlerbehebungen finden Sie in den Versionshinweisen.

Versionshinweise

Versionen ab 2.12: .NET Software Development Kits (SDKs) einschließlich ASP.NET, ASP.NET Core und Protokollierungsadaptern

Unsere Dienstupdates fassen auch wichtige Application Insights-Verbesserungen zusammen.

Nächste Schritte

• Informationen zum Überprüfen häufig gestellter Fragen (FAQ) finden Sie unter Applications Insights for ASP.NET FAQ und Application Insights für ASP.NET Core FAQ.
• Überprüfen Sie, ob Sie eine unterstützte Version des Application Insights SDK ausführen.
• Siehe das Datenmodell für Application Insights-Typen und -Datenmodell.
• Fügen Sie synthetische Transaktionen hinzu, um zu testen, ob Ihre Website überall auf der Welt verfügbar ist. Informationen dazu finden Sie unter Verfügbarkeitsüberwachung.
• Lernen Sie die Grundlagen der Telemetriekorrelation in Application Insights kennen.
• Überprüfen Sie den Benutzerhandbuch "System.Diagnostics.Activity ", um zu sehen, wie telemetrie korreliert wird.
• Konfigurieren Sie eine Momentaufnahmensammlung, um den Status des Quellcodes und der Variablen zu dem Zeitpunkt anzuzeigen, an dem eine Ausnahme ausgelöst wurde.
• Verwenden Sie die API, um Ihre eigenen Ereignisse und Metriken für eine detaillierte Ansicht der Leistung und Nutzung Ihrer App zu senden.