Häufig gestellte Fragen zu Application Insights – Häufig gestellte Fragen - Azure Monitor

Q: Kann ich Telemetriedaten an das Application Insights-Portal senden?

Wir empfehlen die Azure Monitor OpenTelemetry-Distro . Das Aufnahmeschema und das Endpunktprotokoll sind öffentlich verfügbar.

Offizielle Häufig gestellte Fragen zu Azure Monitor Application Insights. Hier finden Sie Antworten auf Fragen zur Verwendung von Application Insights mit Azure Monitor.

Überblick

Wie instrumentiere ich eine Anwendung?

Ausführliche Informationen zur Instrumentierung von Anwendungen zur Aktivierung von Application Insights finden Sie in den Grundlagen der Datensammlung.

Wie verwende ich Application Insights?

Nach dem Aktivieren von Application Insights durch das Instrumentieren einer Anwendung empfehlen wir zunächst das Überprüfen der Live-Metriken und der Anwendungskarte.

Welche Telemetriedaten erfasst Application Insights?

Von Server-Web-Apps:

HTTP-Anforderungen.
Abhängigkeiten. Aufrufe von SQL-Datenbanken, HTTP-Aufrufe externer Dienste, von Azure Cosmos DB, Azure Table Storage, Azure Blob Storage und Azure Queue Storage.
Ausnahmen und Stapelspuren.
Leistungsindikatoren: Leistungsindikatoren stehen bei Verwendung von Folgenden zur Verfügung:
Benutzerdefinierte Ereignisse und Metriken , die Sie codiert haben.
Ablaufverfolgungsprotokolle, wenn Sie den entsprechenden Sammler konfigurieren.

Von Kundenwebseiten:

Nicht abgefangene Ausnahmen in Ihrer App, einschließlich Informationen zu
- Stapelüberwachung
- Ausnahmedetails und Meldung, die den Fehler begleitet
- Zeilen- und Spaltennummer des Fehlers
- URL, bei der der Fehler ausgelöst wurde
- Anforderungen an die Netzwerkabhängigkeit, die von der XML HTTP-Anforderung (XHR) und Fetch Ihrer App ausgegeben werden (die Abrufsammlung ist standardmäßig deaktiviert), einschließlich Informationen zu:
  - URL der Abhängigkeitsquelle
  - Befehl und Methode, der bzw. die zum Anfordern der Abhängigkeit verwendet wird
  - Dauer der Anforderung
  - Ergebniscode und Erfolgsstatus der Anforderung
  - ID (sofern vorhanden) des Benutzers, der die Anforderung sendet
  - Korrelationskontext (falls vorhanden), in dem die Anforderung ausgegeben wird
Benutzerinformationen (z.B. Speicherort, Netzwerk, IP)
Geräteinformationen (z. B. Browser, Betriebssystem, Version, Sprache, Modell)
Sitzungsinformationen

Hinweis

Bei einigen Anwendungen, z. B. Einzelseitenanwendungen (SINGLE-Page Applications, SPAs), wird die Dauer nicht immer aufgezeichnet und in diesen Fällen standardmäßig auf 0 festgelegt.

Weitere Informationen finden Sie unter "Datenerfassung", "Aufbewahrung" und "Speicher" in Application Insights.

Aus anderen Quellen, sofern Sie sie konfigurieren:

Wie viele Application Insights-Ressourcen sollte ich bereitstellen?

Informationen zur Anzahl der Application Insights-Ressourcen, die erforderlich sind, um Ihre Anwendung oder Komponenten in allen Umgebungen abzudecken, finden Sie im Bereitstellungsplanungshandbuch für Application Insights.

Wie kann ich Application Insights-Ressourcen mithilfe von PowerShell verwalten?

Sie können PowerShell-Skripts mithilfe von Azure Resource Monitor schreiben in:

Erstellen und Aktualisieren von Application Insights-Ressourcen
Festlegen des Tarifs
Abrufen des Instrumentierungsschlüssels
Hinzufügen einer Metrikwarnung
Hinzufügen eines Verfügbarkeitstests

Sie können weder einen Metrik-Explorer-Bericht noch den fortlaufenden Export einrichten.

Wie kann ich Application Insights-Telemetriedaten abfragen?

Verwenden Sie die REST-API , um Log Analytics-Abfragen auszuführen.

Kann ich Telemetriedaten an das Application Insights-Portal senden?

Wir empfehlen die Azure Monitor OpenTelemetry-Distro.

Das Aufnahmeschema und das Endpunktprotokoll sind öffentlich verfügbar.

Wie lange dauert das Sammeln von Telemetriedaten?

Die meisten Application Insights-Daten weisen eine Wartezeit von weniger als 5 Minuten auf. Einige Daten können länger dauern, was für größere Protokolldateien typisch ist. Siehe das Service-Level-Agreement von Application Insights.

Wie handhabt Application Insights Datensammlung, -aufbewahrung, -speicherung und -schutz?

Sammlung

Application Insights sammelt Telemetrie zu Ihrer App, einschließlich Webserver-Telemetrie, Webseiten-Telemetrie und Leistungsindikatoren. Diese Daten können verwendet werden, um die Leistung, Integrität und Nutzung Ihrer App zu überwachen. Sie können den Speicherort auswählen, wenn Sie eine neue Application Insights-Ressource erstellen.

Aufbewahrung und Speicherung

Daten werden an einen Application Insights Log Analytics-Arbeitsbereich gesendet. Sie können den Aufbewahrungszeitraum für Rohdaten zwischen 30 und 730 Tagen auswählen. Aggregierte Daten werden 90 Tage lang aufbewahrt, und Debugmomentaufnahmen werden 15 Tage lang aufbewahrt.

Datenschutz

Application Insights verarbeitet standardmäßig keine vertraulichen Daten. Es wird empfohlen, vertrauliche Daten nicht als Nur-Text in URLs einzufügen und sicherzustellen, dass Ihr benutzerdefinierter Code keine personenbezogenen oder anderen vertraulichen Details sammelt. Überprüfen Sie während der Entwicklung und des Testens die gesendeten Daten in den Debugausgabefenstern Ihrer IDE und des Browsers.

Archivierte Informationen finden Sie unter "Datenerfassung", "Aufbewahrung" und "Speicher" in Application Insights.

Wie funktioniert das Preismodell von Application Insights?

Gebühren für Application Insights werden über den Log Analytics-Arbeitsbereich in Rechnung gestellt, in den die Protokolldaten aufgenommen wurden. Der standardmäßige, nutzungsbasierte Tarif für Log Analytics umfasst 5 GB pro Monat kostenloser Datenzuteilung pro Abrechnungskonto. Weitere Informationen finden Sie unter Preisoptionen für Azure Monitor-Protokolle.

Fallen Gebühren für die Datenübertragung zwischen einer Azure-Web-App und Application Insights an?

Wenn Ihre Azure-Web-App in einem Rechenzentrum gehostet wird, in dem ein Application Insights-Sammlungsendpunkt vorhanden ist, fallen keine Gebühren an.
Wenn in Ihrem Hostdatencenter kein Sammlungsendpunkt vorhanden ist, verursacht die Telemetrie Ihrer App ausgehende Azure-Gebühren.

Diese Antwort hängt von der Verteilung unserer Endpunkte ab, nicht davon, wo Ihre Application Insights-Ressource gehostet wird.

Fallen Netzwerkkosten an, wenn meine Application Insights-Ressource eine Azure-Ressource (d. h. Telemetrieproduzent) in einer anderen Region überwacht?

Ja, es können zusätzliche Netzwerkkosten anfallen, die je nach Region variieren, aus der die Telemetriedaten stammen und wohin sie gehen. Details finden Sie in den Azure-Bandbreitenpreisen .

Wenn unerwartete Gebühren oder hohe Kosten in Application Insights angezeigt werden, kann dieser Leitfaden hilfreich sein. Es deckt häufige Ursachen wie hohes Telemetrievolumen, Datenaufnahmespitzen und falsch konfiguriertes Sampling ab. Es ist besonders hilfreich, wenn Sie Probleme im Zusammenhang mit Kostenspitzen, Telemetrievolumen, nicht funktionierendem Sampling, Datenobergrenzen, hohem Dateninput oder unerwarteter Abrechnung beheben. Informationen zu den ersten Schritten finden Sie unter "Problembehandlung bei der Erfassung von hohen Daten in Application Insights".

Welche TLS-Versionen werden unterstützt?

Application Insights verwendet Transport Layer Security (TLS) 1.2 und 1.3.

Von Bedeutung

Am 1. März 2025 wird Azure ältere Versionen von TLS für alle Dienste nicht mehr unterstützen. Zu diesem Zeitpunkt unterstützt Application Insights tls 1.0, TLS 1.1 und die aufgeführten älteren TLS 1.2/1.3-Verschlüsselungssammlungen und elliptischen Kurven nicht mehr.

Allgemeine Fragen zum Legacy-TLS-Problem finden Sie unter Lösen von TLS-Problemen und Azure Resource Manager TLS-Support.

Wo erhalte ich weitere Informationen zu Application Insights?

Weitere Informationen finden Sie in der Einführung in Application Insights.

Application Insights-API für benutzerdefinierte Ereignisse und Metriken

Warum fehlen mir Telemetriedaten?

Beide TelemetryChannels verlieren gepufferte Telemetriedaten, wenn sie vor dem Herunterfahren einer Anwendung nicht geleert werden.

Um Datenverluste zu vermeiden, leeren Sie den TelemetryClient, wenn eine Anwendung heruntergefahren wird.

Weitere Informationen siehe Daten löschen.

Welche Ausnahmen können Track_()-Aufrufe auslösen?

Keiner. Sie müssen sie nicht mit try/catch-Klauseln umschließen. Sollte das SDK auf Probleme stoßen, werden Meldungen in der Debugkonsolenausgabe und (sofern die Meldungen ankommen) in der Diagnosesuche protokolliert.

Gibt es eine REST-API zum Abrufen von Daten aus dem Portal?

Ja, die Datenzugriffs-API. Weitere Möglichkeiten zum Extrahieren von Daten bietet Power BI in arbeitsbereichsbasierten Ressourcen.

Warum werden meine Aufrufe für benutzerdefinierte Ereignisse und Metrik-APIs ignoriert?

Das Application Insights SDK ist nicht mit der automatischen Instrumentierung kompatibel. Wenn die automatische Instrumentierung aktiviert ist, werden Aufrufe an Track() und andere benutzerdefinierte Ereignisse und Metrik-APIs ignoriert.

Deaktivieren Sie die automatische Instrumentierung im Azure-Portal auf der Registerkarte „Application Insights“ der App Service-Seite, oder legen Sie ApplicationInsightsAgent_EXTENSION_VERSION auf disabled fest.

Warum sind die Zahlen in den Diagrammen „Suchen“ und „Metriken“ unterschiedlich?

Durch Sampling wird die Anzahl der Telemetrieelemente (wie Anforderungen, benutzerdefinierte Ereignisse), die von der App an das Portal gesendet werden, verringert. In „Suchen“ sehen Sie die Anzahl der empfangenen Elemente. In Metrikdiagrammen, in denen die Anzahl der Ereignisse angezeigt wird, wird die Anzahl der ursprünglich eingetretenen Ereignisse angezeigt.

Jedes übertragene Element verfügt über eine itemCount-Eigenschaft, die angibt, wie viele ursprüngliche Ereignisse das Element darstellt. Sie können die folgende Abfrage in Log Analytics ausführen, um zu sehen, wie Sampling erfolgt:

requests | summarize original_events = sum(itemCount), transmitted_events = count()

Wie kann ich eine Warnung für ein Ereignis festlegen?

Azure-Warnungen gelten nur für Metriken. Erstellen Sie eine benutzerdefinierte Metrik, die immer einen Schwellenwert überschreitet, wenn das Ereignis eintritt. Legen Sie dann eine Warnung für die Metrik fest. Sie erhalten eine Benachrichtigung, wenn die Metrik den Schwellenwert in beide Richtungen überschreitet. Sie erhalten erst beim ersten Überschreiten eine Benachrichtigung, unabhängig davon, ob der Anfangswert hoch oder niedrig ist. Es gibt immer eine Wartezeit von einigen Minuten.

Wo erhalte ich weitere Informationen zur Application Insights-API für benutzerdefinierte Ereignisse und Metriken?

Weitere Informationen finden Sie unter Application Insights-API für benutzerdefinierte Ereignisse und Metriken.

Bereitstellen des Application Insights-Agents für lokale Server

Unterstützt der Application Insights-Agent Proxy-Installationen?

Ja. Es gibt mehrere Möglichkeiten, den Application Insights-Agent herunterzuladen:

Wenn Ihr Computer über einen Internetzugang verfügt, können Sie ein Onboarding des PowerShell-Katalogs mithilfe der -Proxy-Parameter durchführen.
Sie können dieses Modul auch manuell herunterladen und es auf Ihrem Computer installieren oder direkt verwenden.

Jede dieser Optionen wird in den ausführlichen Anweisungen beschrieben.

Werden ASP.NET Core-Anwendungen in Application Insights Agent unterstützt?

Ja. Ab Application Insights-Agent 2.0.0 werden in IIS gehostete ASP.NET Core-Anwendungen unterstützt.

Wie überprüfe ich, ob die Aktivierung erfolgreich war?

Sie können das Cmdlet Get-ApplicationInsightsMonitoringStatus verwenden, um zu überprüfen, ob die Aktivierung erfolgreich war.
Verwenden Sie Livemetriken, um schnell zu ermitteln, ob Ihre App Telemetriedaten sendet.
Sie können auch Log Analytics verwenden, um alle Cloudrollen aufzulisten, die derzeit Telemetriedaten senden.
```
union * | summarize count() by cloud_RoleName, cloud_RoleInstance
```

Erreichen von Proxy-Passthrough

Um Proxy-Passthrough zu erreichen, konfigurieren Sie einen Proxy auf Computerebene oder einen auf Anwendungsebene. Siehe DefaultProxy.

Beispieldatei „Web.config“:

<system.net>
    <defaultProxy>
    <proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
    </defaultProxy>
</system.net>

Wo erhalte ich weitere Informationen zum Bereitstellen des Application Insights-Agents für lokale Server?

Weitere Informationen finden Sie unter Deploy Application Insights Agent für lokale Server.

TLS-Unterstützung

Ermitteln, ob sich die TLS-Abschaltung auf Sie auswirkt

Application Insights und Azure Monitor steuern nicht die TLS-Version, die für HTTPS-Verbindungen verwendet wird. Die TLS-Version hängt vom Betriebssystem und der Laufzeitumgebung ab, in der Ihre Anwendung ausgeführt wird.

So bestätigen Sie die verwendete TLS-Version:

Lesen Sie die Dokumentation für Ihr Betriebssystem und Ihre Laufzeit oder Ihr Framework.
Wenden Sie sich an das entsprechende Supportteam, wenn Sie weitere Hilfe benötigen. Öffnen Sie keine Supportanfrage mit Application Insights.

Beispielsprache und Laufzeitunterstützung für TLS 1.2+

Die folgenden Versionen enthalten integrierte Unterstützung für TLS 1.2 oder höher:

.NET / .NET Core: .NET Framework 4.6.2 oder höher und alle Versionen von .NET Core
Java: Java 8 Update 161 (8u161) oder höher
Python: Python-Distributionen, die mit OpenSSL 1.0.1 oder höher erstellt wurden
Node.js: Node.js Version 10 oder höher

Beispiel für die Betriebssystemunterstützung für TLS 1.2+

Die folgenden Betriebssysteme enthalten integrierte Unterstützung für TLS 1.2 oder höher:

Windows: Windows 8, Windows Server 2012 und höher
Linux: Die meisten modernen Linux-Distributionen, die OpenSSL 1.0.1 oder höher verwenden

Wie kann ich sicherstellen, dass meine Ressourcen nicht betroffen sind?

Um Dienstunterbrechungen zu vermeiden, muss jeder Remote-Endpunkt (einschließlich abhängiger Anforderungen), mit dem Ihre Ressource interagiert, mindestens eine Kombination aus derselben Protokollversion, Cipher Suite und elliptische Kurve unterstützen, die zuvor erwähnt wurde. Wenn der Remoteendpunkt die erforderliche TLS-Konfiguration nicht unterstützt, muss er mit Unterstützung für eine Kombination der veralteten TLS-Konfiguration aktualisiert werden.

Nach dem 1. Mai 2025, was ist das Verhalten für betroffene Ressourcen?

Betroffene Application Insights-Ressourcen beenden das Aufnehmen von Daten und können nicht mehr auf erforderliche Anwendungskomponenten zugreifen. Daher funktionieren einige Features nicht mehr.

Welche Komponenten sind von der Veraltung betroffen?

Die in diesem Dokument beschriebene TLS-Veraltung (Transport Layer Security) sollte sich nur auf das Verhalten nach dem 1. Mai 2025 auswirken. Weitere Informationen zu CRUD-Vorgängen finden Sie unter Azure Resource Manager TLS Support. Diese Ressource enthält weitere Details zu TLS-Support und zu Abkündigungs-Zeitachsen.

Wo erhalte ich TLS-Unterstützung (Transport Layer Security)?

Allgemeine Fragen zum Legacy-TLS-Problem finden Sie unter Lösen von TLS-Problemen.

Wo erhalte ich weitere Informationen zur TLS-Unterstützung in Application Insights?

Weitere Informationen finden Sie unter TLS-Unterstützung.

ASP.NET

Wie kann ich das SDK deinstallieren?

Zum Entfernen von Application Insights müssen Sie die NuGet-Pakete und -Verweise aus der API in Ihrer Anwendung entfernen. Sie können NuGet-Pakete mithilfe des NuGet-Paket-Managers in Visual Studio deinstallieren.

Wenn die Ablaufverfolgungssammlung aktiviert ist, deinstallieren Sie zuerst das Paket Microsoft.ApplicationInsights.TraceListener mithilfe des NuGet-Paket-Managers, entfernen jedoch keine Abhängigkeiten.
Deinstallieren Sie das Microsoft.ApplicationInsights.Web-Paket und entfernen Sie dessen Abhängigkeiten mithilfe des NuGet-Paket-Managers und den zugehörigen Deinstallationsoptionen im Steuerelement NuGet-Paket-Manager-Optionen.
Um Application Insights vollständig zu entfernen, müssen Sie den hinzugefügten Code bzw. die hinzugefügten Dateien sowie alle API-Aufrufe, die Sie in Ihrem Projekt hinzugefügt haben, überprüfen und manuell löschen. Weitere Informationen finden Sie unter Beim Hinzufügen von Application Insights SDK automatisch erstellte Elemente.

Beim Hinzufügen von Application Insights SDK automatisch erstellte Elemente

Wenn Sie Ihrem Projekt Application Insights hinzufügen, werden automatisch Dateien erstellt und einigen Dateien wird Code hinzugefügt. Durch alleiniges Deinstallieren der NuGet-Pakete werden die Dateien und der Code nicht immer gelöscht. Um Application Insights vollständig zu entfernen, sollten Sie den hinzugefügten Code bzw. die hinzugefügten Dateien sowie alle API-Aufrufe, die Sie in Ihrem Projekt hinzugefügt haben, überprüfen und manuell löschen.

Wenn Sie Application Insights-Telemetrie zu einem ASP.NET-Projekt in Visual Studio hinzufügen, werden folgende Dateien hinzugefügt:

ApplicationInsights.config
AiHandleErrorAttribute.cs

Die folgenden Codeelemente werden automatisch hinzugefügt:

[Name Ihres Projekts].csproj

  <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4</ApplicationInsightsResourceId>

Packages.config

<packages>
...

   <package id="Microsoft.ApplicationInsights" version="2.12.0" targetFramework="net472" />
   <package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net472" />
   <package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.12.0" targetFramework="net472" />
   <package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.12.0" targetFramework="net472" />
   <package id="Microsoft.ApplicationInsights.Web" version="2.12.0" targetFramework="net472" />
   <package id="Microsoft.ApplicationInsights.WindowsServer" version="2.12.0" targetFramework="net472" />
   <package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.12.0" targetFramework="net472" />

   <package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.7" targetFramework="net472" />

   <package id="System.Buffers" version="4.4.0" targetFramework="net472" />
   <package id="System.Diagnostics.DiagnosticSource" version="4.6.0" targetFramework="net472" />
   <package id="System.Memory" version="4.5.3" targetFramework="net472" />
   <package id="System.Numerics.Vectors" version="4.4.0" targetFramework="net472" />
   <package id="System.Runtime.CompilerServices.Unsafe" version="4.5.2" targetFramework="net472" />
...
</packages>

Layout.cshtml

Wenn Ihr Projekt über eine Datei vom Typ Layout.cshtml verfügt, wird der folgende Code hinzugefügt.

<head>
...
     <script type = 'text/javascript' >
         var appInsights=window.appInsights||function(config)
         {
             function r(config){ t[config] = function(){ var i = arguments; t.queue.push(function(){ t[config].apply(t, i)})} }
             var t = { config:config},u=document,e=window,o='script',s=u.createElement(o),i,f;for(s.src=config.url||'//az416426.vo.msecnd.net/scripts/a/ai.0.js',u.getElementsByTagName(o)[0].parentNode.appendChild(s),t.cookie=u.cookie,t.queue=[],i=['Event','Exception','Metric','PageView','Trace','Ajax'];i.length;)r('track'+i.pop());return r('setAuthenticatedUserContext'),r('clearAuthenticatedUserContext'),config.disableExceptionTracking||(i='onerror',r('_'+i),f=e[i],e[i]=function(config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t['_' + i](config, r, u, e, o),s}),t
         }({
             instrumentationKey:'00000000-0000-0000-0000-000000000000'
         });

         window.appInsights=appInsights;
         appInsights.trackPageView();
     </script>
...
</head>

ConnectedService.json

{
   "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
   "Version": "16.0.0.0",
   "GettingStartedDocument": {
     "Uri": "https://go.microsoft.com/fwlink/?LinkID=613413"
  }
}

FilterConfig.cs

         public static void RegisterGlobalFilters(GlobalFilterCollection filters)
         {
             filters.Add(new ErrorHandler.AiHandleErrorAttribute());// This line was added
         }

Wie kann ich die Telemetriekorrelation deaktivieren?

Weitere Informationen zum Deaktivieren der Telemetriekorrelation in der Konfiguration finden Sie unter <ExcludeComponentCorrelationHttpHeadersOnDomains> in Application Insights für Konsolenanwendungen.

Wo erhalte ich weitere Informationen zur Verwendung von Application Insights mit ASP.NET?

Weitere Informationen finden Sie unter Konfigurieren von Application Insights für Ihre ASP.NET Website.

ASP.NET Core-Anwendungen

Wird ASP.NET Core 3.1 in Application Insights unterstützt?

ASP.NET Core 3.1 wird von Microsoft nicht mehr unterstützt.

Application Insights SDK für ASP.NET Core-Version 2.8.0 und Visual Studio 2019 oder höher kann mit ASP.NET Core 3.1-Anwendungen verwendet werden.

Wie kann ich Telemetriedaten nachverfolgen, die nicht automatisch erfasst werden?

Rufen Sie eine Instanz von TelemetryClient ab. Verwenden Sie dazu die Konstruktorinjektion, und rufen Sie die erforderliche TrackXXX()-Methode auf. Es wird nicht empfohlen, neue TelemetryClient- oder TelemetryConfiguration-Instanzen in einer ASP.NET Core-Anwendung zu erstellen. Eine Singletoninstanz von TelemetryClient ist bereits im Container DependencyInjection registriert, der TelemetryConfiguration für alle sonstigen Telemetriedaten verwendet. Sie sollten nur dann eine neue TelemetryClient-Instanz erstellen, wenn für diese eine Konfiguration erforderlich ist, die sich von der für die sonstigen Telemetriedaten unterscheidet.

Im folgenden Beispiel wird veranschaulicht, wie Sie weitere Telemetriedaten über einen Controller nachverfolgen.

using Microsoft.ApplicationInsights;

public class HomeController : Controller
{
    private TelemetryClient telemetry;

    // Use constructor injection to get a TelemetryClient instance.
    public HomeController(TelemetryClient telemetry)
    {
       this.telemetry = telemetry;
    }

    public IActionResult Index()
    {
        // Call the required TrackXXX method.
        this.telemetry.TrackEvent("HomePageRequested");
        return View();
    }
}

Weitere Informationen zur benutzerdefinierten Datenberichterstattung in Application Insights finden Sie unter Application Insights benutzerdefinierte Metriken API-Referenz. Ein ähnlicher Ansatz kann verwendet werden, um mithilfe der GetMetric-API benutzerdefinierte Metriken an Application Insights zu senden.

Wie erfasse ich den Anforderungs- und Antworttext in meinen Telemetriedaten?

ASP.NET Core verfügt über integrierte Unterstützung zum Protokollieren von HTTP-Anforderungs-/Antwortinformationen (einschließlich Text) über ILogger. Es wird empfohlen, dies zu nutzen. Dadurch werden möglicherweise personenbezogene Informationen in den Telemetriedaten verfügbar gemacht, und die Kosten (Leistungskosten und Application Insights-Abrechnung) können erheblich steigen. Wägen Sie daher vor der Nutzung die Risiken sorgfältig ab.

Wie passe ich die Sammlung von ILogger-Protokollen an?

Die Standardeinstellung für Application Insights besteht darin, nur Warnung und schwerwiegendere Protokolle zu erfassen.

Erfassen Sie Informationen und weniger schwerwiegende Protokolle, indem Sie die Protokollierungskonfiguration für den Application Insights-Anbieter wie folgt ändern.

{
    "Logging": {
        "LogLevel": {
            "Default": "Information"
        },
        "ApplicationInsights": {
            "LogLevel": {
                "Default": "Information"
            }
        }
    },
    "ApplicationInsights": {
        "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
    }
}

Beachten Sie unbedingt, dass das folgende Beispiel nicht dazu führt, dass der Application Insights-Anbieter Information-Protokolle sammelt. Sie werden nicht gesammelt, da das SDK einen Standardprotokollierungsfilter hinzufügt, der ApplicationInsights anweist, nur Protokolle mit dem Schweregrad Warning und höher zu sammeln. Application Insights erfordert eine explizite Überschreibung.

{
    "Logging": {
       "LogLevel": {
           "Default": "Information"
       }
    }
}

Weitere Informationen finden Sie unter ILogger-Konfiguration.

Für einige Visual Studio-Vorlagen wurde die Erweiterungsmethode „UseApplicationInsights()“ in IWebHostBuilder verwendet, um Application Insights zu aktivieren. Ist diese Verwendung noch gültig?

Obwohl die Erweiterungsmethode UseApplicationInsights() weiterhin unterstützt wird, ist sie ab der Application Insights SDK-Version 2.8.0 als veraltet markiert. Sie wird in der nächsten Hauptversion des SDK entfernt. Verwenden Sie zum Aktivieren von Application Insights-Telemetriedaten AddApplicationInsightsTelemetry(), da es Überladungen zum Steuern einiger Konfigurationen bietet. In ASP.NET Core 3.X-Apps ist services.AddApplicationInsightsTelemetry() außerdem die einzige Möglichkeit zum Aktivieren von Application Insights.

Ich stelle meine ASP.NET Core-Anwendung in Web-Apps bereit. Sollte ich trotzdem die Application Insights-Erweiterung über Web-Apps aktivieren?

Wenn das SDK wie in diesem Artikel gezeigt zur Buildzeit installiert wird, ist es nicht erforderlich, die Application Insights-Erweiterung über das App Service-Portal zu aktivieren. Wenn die Erweiterung installiert ist, zieht sie sich zurück, wenn sie erkennt, dass das SDK bereits hinzugefügt wurde. Wenn Sie Application Insights über die Erweiterung aktivieren, müssen Sie das SDK nicht installieren und aktualisieren. Wenn Sie Application Insights jedoch mithilfe der Anweisungen in diesem Artikel aktivieren, sind Sie aus den folgenden Gründen flexibler:

Application Insights-Telemetrie funktioniert weiterhin in:
- auf allen Betriebssystemen einschließlich Windows, Linux und Mac.
- mit allen Veröffentlichungsmodi einschließlich dem eigenständigen oder frameworkabhängigen Modus.
- Alle Zielframeworks, einschließlich des vollständigen .NET Frameworks.
- Alle Hostingoptionen, einschließlich Web-Apps, VMs, Linux, Container, AKS und Nicht-Azure-Hosting.
- Alle .NET Core-Versionen, einschließlich Vorschauversionen.
Sie können Telemetriedaten lokal beim Debuggen in Visual Studio anzeigen.
Sie können mit der TrackXXX()-API weitere benutzerdefinierte Telemetriedaten nachverfolgen.
Die vollständige Steuerung der Konfiguration ist Ihnen überlassen.

Kann ich die Application Insights-Überwachung mithilfe von Tools wie Azure Monitor Application Insights-Agent (früher Statusmonitor v2) aktivieren?

Ja. Ab Application Insights-Agent 2.0.0-beta1 werden in IIS gehostete ASP.NET Core-Anwendungen unterstützt.

Werden alle Features unterstützt, wenn ich meine Anwendung unter Linux ausführe?

Ja. Die Featureunterstützung für das SDK ist auf allen Plattformen gleich. Es gelten lediglich die folgenden Ausnahmen:

Unter Linux sammelt das SDK EventCounters, da Leistungsindikatoren nur unter Windows unterstützt werden. Die meisten Metriken sind identisch.

Wird dieses SDK für Worker-Dienste unterstützt?

Nein. Verwenden Sie stattdessen Application Insights für Workerdienstanwendungen (Nicht-HTTP-Anwendungen) für Workerdienste.

Wie kann ich das SDK deinstallieren?

Hinweis

Diese Anweisungen gelten für die Deinstallation des ASP.NET Core SDK. Wenn Sie das ASP.NET SDK deinstallieren müssen, lesen Sie die Informationen unter Wie kann ich das ASP.NET SDK deinstallieren?.

Deinstallieren Sie das Paket „Microsoft.ApplicationInsights.AspNetCore“ mithilfe des NuGet-Paket-Managers.
Um Application Insights vollständig zu entfernen, müssen Sie den hinzugefügten Code bzw. die hinzugefügten Dateien sowie alle API-Aufrufe, die Sie in Ihrem Projekt hinzugefügt haben, überprüfen und manuell löschen. Weitere Informationen finden Sie unter Was wird erstellt, wenn Sie das Application Insights SDK hinzufügen?.

Was wird erstellt, wenn Sie das Application Insights SDK hinzufügen?

Wenn Sie Ihrem Projekt Application Insights hinzufügen, werden Dateien erstellt und einigen Dateien wird Code hinzugefügt. Durch alleiniges Deinstallieren der NuGet-Pakete werden die Dateien und der Code nicht immer gelöscht. Um Application Insights vollständig zu entfernen, sollten Sie den hinzugefügten Code bzw. die hinzugefügten Dateien sowie alle API-Aufrufe, die Sie in Ihrem Projekt hinzugefügt haben, überprüfen und manuell löschen.

Wenn Sie Application Insights-Telemetrie zu einem ASP.NET Core-Vorlagenprojekt in Visual Studio hinzufügen, wird folgender Code hinzugefügt:

[Name Ihres Projekts].csproj

<PropertyGroup>
     <TargetFramework>netcoreapp3.1</TargetFramework>
     <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4core</ApplicationInsightsResourceId>
</PropertyGroup>

<ItemGroup>
     <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.12.0" />
</ItemGroup>

<ItemGroup>
     <WCFMetadata Include="Connected Services" />
</ItemGroup>

Appsettings.json

"ApplicationInsights": {
     "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
}

ConnectedService.json

{    
     "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
     "Version": "16.0.0.0",
     "GettingStartedDocument": {
         "Uri": "https://go.microsoft.com/fwlink/?LinkID=798432"
     }
}

Startup.cs

public void ConfigureServices(IServiceCollection services)
     {
        services.AddRazorPages();
        services.AddApplicationInsightsTelemetry(); // This is added
     }

Wie kann ich die Telemetriekorrelation deaktivieren?

Weitere Informationen zum Deaktivieren der Telemetriekorrelation im Code finden Sie unter <ExcludeComponentCorrelationHttpHeadersOnDomains> in Application Insights für Konsolenanwendungen.

Wo erhalte ich weitere Informationen zur Verwendung von Application Insights für ASP.NET Core-Anwendungen?

Weitere Informationen finden Sie unter Application Insights für ASP.NET Core.

ASP.NET Leistungsindikatoren

Worin besteht der Unterschied zwischen der Ausnahmerate und der Ausnahmenmetrik?

Exception rate: Die Ausnahmerate ist ein Systemleistungsindikator. Die CLR zählt alle behandelten und nicht behandelten Ausnahmen, die ausgelöst werden, und dividiert das Ergebnis innerhalb eines Samplingintervalls durch die Länge dieses Intervalls. Das Application Insights SDK sammelt dieses Ergebnis und sendet es an das Portal.
Exceptions: Die Metrik „Ausnahmen“ zählt die TrackException-Meldungen, die das Portal innerhalb des Samplingintervalls des Diagramms empfangen hat. Sie enthält nur die behandelten Ausnahmen, bei denen Sie TrackException-Aufrufe in Ihren Code geschrieben haben. Sie enthält nicht alle nicht behandelten Ausnahmen.

Wo erhalte ich weitere Informationen zu ASP.NET Leistungsindikatoren?

Weitere Informationen finden Sie unter Leistungsindikatoren für .NET in Application Insights.

ASP.NET Ereignisindikatoren

Werden EventCounters in Livemetriken angezeigt?

Livemetriken zeigen „EventCounters“ nicht an. Verwenden Sie den Metrik-Explorer oder Analytics, um die Telemetrie anzuzeigen.

Warum sehe ich keine Ereigniszähler, nachdem ich Application Insights im Azure Web App-Portal aktiviert habe?

Die Application Insights-Erweiterung für ASP.NET Core unterstützt dieses Feature noch nicht.

Wo erhalte ich weitere Informationen zu ASP.NET Ereigniszählern?

Weitere Informationen finden Sie unter Leistungsindikatoren für .NET in Application Insights.

Skalierungsgruppen für Azure-VMs und virtuelle Computer

Wie kann ich die clientseitige Überwachung für ASP.NET Core-Apps deaktivieren?

Clientseitige Überwachung ist für ASP.NET Core-Apps standardmäßig aktiviert. Wenn Sie sie deaktivieren möchten, definieren Sie eine Umgebungsvariable auf dem Server mit den folgenden Informationen:

Name: APPINSIGHTS_JAVASCRIPT_ENABLED
Wert: false

Wo erhalte ich weitere Informationen zur Verwendung von Application Insights für Azure-VMs und VM-Skalierungsgruppen?

Weitere Informationen finden Sie unter Application Insights für Azure-VMs und VM-Skalierungsgruppen.

Abhängigkeitsüberwachung

Wie meldet der automatische Abhängigkeitskollektor fehlgeschlagene Aufrufe an Abhängigkeiten?

Bei fehlgeschlagenen Abhängigkeitsaufrufen wird das success-Feld auf False gesetzt. Das Modul DependencyTrackingTelemetryModule meldet ExceptionTelemetry nicht. Das vollständige Datenmodell für die Abhängigkeit wird unter Application Insights-Telemetriedatenmodell beschrieben.

Wie berechne ich die Erfassungslatenz für meine Abhängigkeitstelemetrie?

Verwenden Sie diesen Code:

dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp 
| extend TimeIngested = ingestion_time()

Wie ermittle ich die Uhrzeit, zu der der Abhängigkeitsaufruf initiiert wurde?

In der Log Analytics-Abfrageansicht stellt timestamp den Moment dar, in dem der TrackDependency()-Aufruf initiiert wurde, was unmittelbar nach dem Empfang der Antwort auf den Abhängigkeitsaufruf erfolgt. Um die Uhrzeit des Beginns des Abhängigkeitsaufrufs zu berechnen, subtrahieren Sie den aufgezeichneten timestamp-Wert des Abhängigkeitsaufrufs von duration.

Umfasst die Abhängigkeitsnachverfolgung in Application Insights Protokollierungsantworttexte?

Die Abhängigkeitsnachverfolgung in Application Insights umfasst keine Protokollierungsantworttexte, da sie für die meisten Anwendungen zu viele Telemetriedaten generieren würde.

Wo erhalte ich weitere Informationen zur Abhängigkeitsnachverfolgung in Application Insights?

Weitere Informationen finden Sie unter Abhängigkeitsnachverfolgung.

Verfügbarkeitstests

Kann ich Verfügbarkeitstests auf einem Intranetserver ausführen?

Verfügbarkeitstests werden auf Anwesenheitspunkten ausgeführt, die auf der ganzen Welt verteilt sind. Es gibt zwei Lösungen:

Tür in der Firewall: Lassen Sie Anfragen an Ihren Server von der umfangreichen und änderbaren Liste der Web-Test-Agenten zu.
Benutzerdefinierter Code: Schreiben Sie eigenen Code, um aus dem Intranet regelmäßig Anforderungen an den Server zu senden. Sie können zu diesem Zweck Visual Studio-Webtests ausführen. Der Tester kann die Ergebnisse mithilfe der TrackAvailability()-API an Application Insights senden.

Was ist die Benutzer-Agent-Zeichenfolge für Verfügbarkeitstests?

Die Zeichenfolge des Benutzer-Agenten lautet: Mozilla/5.0 (kompatibel; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights).

Wo erhalte ich weitere Informationen zu Application Insights-Verfügbarkeitstests?

Weitere Informationen finden Sie unter Verfügbarkeitstests.

TLS-Unterstützung für Verfügbarkeitstests

Wie wirkt sich die Veraltetkeit auf mein Webtestverhalten aus?

Verfügbarkeitstests dienen als verteilter Client an jedem der unterstützten Webteststandorte. Jedes Mal, wenn ein Webtest ausgeführt wird, versucht der Verfügbarkeitstestdienst, sich an den Remoteendpunkt zu wenden, der in der Webtestkonfiguration definiert ist. Es wird eine TLS-Client-Hello-Nachricht gesendet, die alle derzeit unterstützten TLS-Konfigurationen enthält. Wenn der Remoteendpunkt eine gemeinsame TLS-Konfiguration mit dem Verfügbarkeitstestclient gemeinsam verwendet, ist der TLS-Handshake erfolgreich. Andernfalls schlägt der Webtest mit einem TLS-Handshake-Fehler fehl.

Wie kann ich überprüfen, welche TLS-Konfiguration ein Remoteendpunkt unterstützt?

Es stehen mehrere Tools zur Verfügung, um zu testen, welche TLS-Konfiguration ein Endpunkt unterstützt. Eine Möglichkeit wäre, dem auf dieser Seite detaillierten Beispiel zu folgen. Wenn Ihr Remoteendpunkt nicht über das öffentliche Internet verfügbar ist, müssen Sie sicherstellen, dass Sie die TLS-Konfiguration validieren, die auf dem Remoteendpunkt unterstützt wird, von einem Computer aus, der Zugriff hat, um Ihren Endpunkt anzusprechen.

Hinweis

Für Schritte zum Aktivieren der erforderlichen TLS-Konfiguration auf Ihrem Webserver empfiehlt es sich, sich an das Team zu wenden, das die Hostplattform besitzt, auf der Ihr Webserver ausgeführt wird, wenn der Prozess nicht bekannt ist.

Was ist nach dem 1. Mai 2025 das Webtestverhalten für betroffene Tests?

Es gibt keinen Ausnahmetyp, bei dem sich alle von dieser Abkündigung betroffenen TLS-Handshakefehler selbst darstellen. Die häufigste Ausnahme, mit der Ihr Webtest fehlschlägt, wäre jedoch The request was aborted: Couldn't create SSL/TLS secure channel. Außerdem sollten Sie alle TLS-bezogenen Fehler im TLS-Transport-Problembehandlungsschritt für das Webtestergebnis sehen können, das potenziell beeinträchtigt wird.

Kann ich anzeigen, welche TLS-Konfiguration derzeit von meinem Webtest verwendet wird?

Die TLS-Konfiguration, die während einer Webtestausführung ausgehandelt wurde, kann nicht angezeigt werden. Solange der Remoteendpunkt übliche TLS-Konfigurationen mit Verfügbarkeitstests unterstützt, sollten nach der Stilllegung keine Auswirkungen erkennbar sein.

Welche Komponenten wirken sich auf die Abkündigung im Verfügbarkeitstestdienst aus?

Die in diesem Dokument beschriebene TLS-Abschaffung sollte sich nur auf das Ausführungsverhalten von Verfügbarkeitstests und Webtests nach dem 1. Mai 2025 auswirken. Weitere Informationen zur Interaktion mit dem Verfügbarkeitstestdienst für CRUD-Vorgänge finden Sie unter Azure Resource Manager TLS Support. Diese Ressource enthält weitere Details zu TLS-Support und zu Abkündigungs-Zeitachsen.

Wo erhalte ich TLS-Unterstützung?

Allgemeine Fragen zum Legacy-TLS-Problem finden Sie unter Lösen von TLS-Problemen.

Wo erhalte ich weitere Informationen zur TLS-Unterstützung für Verfügbarkeitstests?

Weitere Informationen finden Sie unter Unterstützte TLS-Konfigurationen.

Überwachung in Azure App Service für .NET, Node.js, Python und Java-Anwendungen

Welche Änderungen nimmt Application Insights in meinem Projekt vor?

Die Details hängen von der Art des Projekts ab. Die folgende Liste ist ein Beispiel für eine Webanwendung.

Fügt Ihrem Projekt Dateien hinzu:
- ApplicationInsights.config
- ai.js
Installiert NuGet-Pakete:
- Application Insights-API: Die Kern-API
- Application Insights-API für Webanwendungen: Zum Senden von Telemetriedaten vom Server
- Application Insights-API für JavaScript-Anwendungen: Zum Senden von Telemetriedaten vom Client
Enthält Assemblierungen in Paketen:
- Microsoft.ApplicationInsights
- Microsoft.ApplicationInsights.Platform
Fügt Elemente in:
- Web.config
- packages.config
Fügen Sie Codeausschnitte in den Client- und Servercode ein, um diese mit der Application Insights-Ressourcen-ID zu initialisieren. In einer MVC-App wird beispielsweise Code in die Hauptseite Views/Shared/_Layout.cshtml eingefügt. Nur für neue Projekte fügen Sie Application Insights einem vorhandenen Projekt manuell hinzu.

Was ist der Unterschied zwischen Standardmetriken von Application Insights und Azure App Service-Metriken?

Application Insights sammelt Telemetriedaten für die Anforderungen, die bis zur Anwendung gelangt sind. Wenn der Fehler in WebApps/WebServer auftritt und die Anforderung die Benutzeranwendung nicht erreicht hat, hat Application Insights keine Telemetriedaten dazu.

Die von Application Insights berechnete Dauer für serverresponsetime stimmt nicht unbedingt mit der von Web-Apps beobachteten Serverantwortzeit überein. Dies liegt daran, dass Application Insights nur die Dauer zählt, bis die Anforderung tatsächlich die Benutzeranwendung erreicht. Wenn die Anforderung in WebServer hängen bleibt oder in die Warteschlange gestellt wird, ist diese Wartezeit in den Web-App-Metriken enthalten, in den Application Insights-Metriken jedoch nicht.

Wo erhalte ich weitere Informationen zur Überwachung in Azure App Service für .NET, Node.js, Python und Java-Anwendungen?

Weitere Informationen finden Sie unter Aktivieren der Anwendungsüberwachung in Azure App Service.

Automatische Instrumentierung

Sollte der Begriff „Autoinstrumentation“ mit einem Bindestrich geschrieben werden?

Wir folgen dem Microsoft-Styleguide für Produktdokumentation, der auf der Microsoft Learn-Plattform veröffentlicht wurde.

In der Regel verwenden wir nach dem Präfix "auto" keinen Bindestrich.

Wo erhalte ich weitere Informationen zur automatischen Instrumentierung?

Weitere Informationen finden Sie unter Was ist die automatische Instrumentierung für Azure Monitor Application Insights?.

Automatische Instrumentierung für Azure Kubernetes Service

Unterstützt die automatische Instrumentierung von Azure Kubernetes Service (AKS) benutzerdefinierte Metriken?

Wenn Sie benutzerdefinierte Metriken in Node.jsmöchten, instrumentieren Sie Anwendungen manuell mit der Azure Monitor OpenTelemetry Distro.

Java ermöglicht benutzerdefinierte Metriken mit automatischer Instrumentierung. Sie können benutzerdefinierte Metriken sammeln , indem Sie Ihren Code aktualisieren und dieses Feature aktivieren. Wenn Ihr Code bereits benutzerdefinierte Metriken enthält, fließen sie durch, wenn die automatische Instrumentierung aktiviert ist.

Funktioniert AKS autoinstrumentation mit Anwendungen, die mit einem Open Source Software (OSS) OpenTelemetry SDK instrumentiert sind?

Die AKS-Autoinstrumentierung kann die von einem OSS OpenTelemetry SDK an Dritte gesendete Telemetrie beeinträchtigen.

Kann AKS autoinstrumentation mit manueller Instrumentierung koexistieren?

AKS autoinstrumentation ist so konzipiert, dass sie mit beiden manuellen Instrumentierungsoptionen koexistieren kann: dem klassischen Application Insights API SDK und openTelemetry Distro.

Es verhindert immer doppelte Daten und stellt sicher, dass benutzerdefinierte Metriken funktionieren.

In diesem Diagramm können Sie ermitteln, wann die automatische Instrumentierung oder manuelle Instrumentierung Vorrang hat.

Sprache	Vorrang
Node.js	Manuelle Instrumentierung
Java	Automatische Instrumentierung

Wie kann ich sicherstellen, dass ich die neuesten und sichersten Versionen von Azure Monitor OpenTelemetry Distro verwende?

Sicherheitsrisiken, die in der Azure Monitor OpenTelemetry Distro erkannt wurden, werden priorisiert, behoben und in der nächsten Version veröffentlicht.

Die automatische AKS-Instrumentierung fügt die aktuelle Version der OpenTelemetry-Distribution für Azure Monitor jedes Mal in Ihre Anwendungspods ein, wenn Ihre Bereitstellung geändert oder neu gestartet wird.

Die OpenTelemetry-Distro kann anfällig für Bereitstellungen werden, die nicht für längere Zeiträume geändert oder neu gestartet werden. Aus diesem Grund empfehlen wir, Bereitstellungen wöchentlich zu aktualisieren oder neu zu starten, um sicherzustellen, dass eine aktuelle Version der Distro verwendet wird.

Wie lerne ich mehr über die Azure Monitor OpenTelemetry Distro?

Diese Funktion erreicht die automatische Instrumentierung durch Injektion der Azure Monitor OpenTelemetry-Distribution in Anwendungs-Pods.

Für Java integriert dieses Feature die eigenständige Azure Monitor OpenTelemetry Distribution für Java. Weitere Informationen zur Binärdatei der Java-Instrumentierung finden Sie in unserer Java-Distro-Dokumentation .

Für Node.js fügen wir eine Binärdatei für die automatische Instrumentierung hinzu, die auf unserer OpenTelemetry-Distribution für Azure Monitor für Node.js basiert. Weitere Informationen finden Sie in der Dokumentation zurNode.js-Distribution. Denken Sie daran, dass wir keine eigenständige Autoinstrumentation für Node.js haben, sodass unsere Distro-Dokumentation auf manuelle Instrumentierung ausgerichtet ist. Sie können codebasierte Konfigurationsschritte im Zusammenhang mit der manuellen Instrumentierung ignorieren. Alles andere gilt jedoch in unserer Distro-Dokumentation wie Standardeinstellungen, Umgebungsvariablenkonfigurationen usw. für dieses Feature.

Wo erhalte ich weitere Informationen zur Autoinstrumentation für AKS?

Weitere Informationen finden Sie unter Autoinstrumentation für AKS.

Verbindungszeichenfolgen

Erfordern neue Azure-Regionen die Verwendung von Verbindungszeichenfolgen?

Neue Azure-Regionen erfordern die Verwendung von Verbindungszeichenfolgen anstelle von Instrumentierungsschlüsseln. Eine Verbindungszeichenfolge identifiziert die Ressource, die Sie Ihren Telemetriedaten zuordnen möchten. Hier können Sie die Endpunkte ändern, die Ihre Ressource als Ziel für die Telemetrie verwendet. Kopieren Sie die Verbindungszeichenfolge, und fügen Sie sie dem Code Ihrer Anwendung oder einer Umgebungsvariable hinzu.

Sollte ich Verbindungszeichenfolgen oder Instrumentierungsschlüssel verwenden?

Es wird empfohlen, Verbindungszeichenfolgen anstelle von Instrumentierungsschlüsseln zu verwenden.

Wann muss ich die Umgebungsvariable festlegen?

Stellen Sie das APPLICATIONINSIGHTS_CONNECTION_STRING manuell in allen Szenarien ein, in denen das System es nicht automatisch bereitstellt. Diese Szenarien umfassen, sind jedoch nicht beschränkt auf: lokale Entwicklung und .NET Isolierte Funktionen mit ASP.NET Core-Integration. In diesen Fällen stellt die Umgebungsvariable sicher, dass die OpenTelemetry-Pipeline Telemetrie an Application Insights senden kann. Weitere Informationen zum Konfigurieren von Verbindungszeichenfolgen mit einer Umgebungsvariablen finden Sie unter Konfigurieren von OpenTelemetry in Application Insights.

Wie kann ich eine globale Webanwendung instrumentieren, um regionale Datencompliance-Anforderungen zu erfüllen?

Verwenden Sie regionale Application Insights-Endpunkte anstelle des globalen Endpunkts, um regionale Datencomplianceanforderungen zu erfüllen. Der globale Endpunkt garantiert nicht, dass Daten innerhalb einer bestimmten Region verbleiben. Regionale Endpunkte sorgen dafür, dass Telemetrie von Benutzern in regulierten Bereichen nur an Rechenzentren in diesen Regionen gesendet wird.

So konfigurieren Sie Ihre globale Webanwendung für regionale Compliance:

Erstellen Sie eine Application Insights-Ressource pro Region mit strengen Complianceanforderungen, z. B. der Europäischen Union oder den VEREINIGTEN Staaten.
Erstellen Sie eine weitere Application Insights-Ressource für Benutzer in allen anderen Regionen.
Konfigurieren Sie Ihre Anwendung so, dass telemetrie an die entsprechende Application Insights-Ressource basierend auf der Region der einzelnen Benutzer gesendet wird. Bestimmen Sie die Region mithilfe von Signalen wie IP-Adresse, Kontometadaten oder Standorteinstellungen.
Verbinden Sie alle Application Insights-Ressourcen mit einem Log Analytics-Arbeitsbereich, wenn Sie eine einheitliche Abfrageerfahrung in allen Regionen benötigen.

Beispiel:

Senden von Daten aus Region A-Benutzern an die Ressource „Region A Application Insights“ mithilfe der Verbindungszeichenfolge „Region A“.
Senden von Daten von Region B-Benutzern an die Region B Application Insights-Ressource mithilfe der Region B-Verbindungszeichenfolge.
Senden Sie alle anderen Benutzerdaten mithilfe einer anderen Verbindungszeichenfolge an eine allgemeine Application Insights-Ressource.

Von Bedeutung

Die Verwendung des globalen Endpunkts stellt keine regionale Compliance sicher. Verwenden Sie für die Erfüllung der Anforderungen an die Datenhaltung immer regionsspezifische Endpunkte, und leiten Sie Telemetrie basierend auf der Region des Benutzers weiter.

Das folgende Diagramm zeigt ein Beispielsetup für eine globale Webanwendung:

Wo erhalte ich weitere Informationen zu Verbindungszeichenfolgen in Application Insights?

Weitere Informationen finden Sie unter Verbindungszeichenfolgen.

Erstellen und Konfigurieren von Application Insights-Ressourcen

Wie kann ich eine Application Insights-Ressource in eine neue Region verschieben?

Das Übertragen vorhandener Application Insights-Ressourcen zwischen Regionen wird nicht unterstützt, und Sie können historische Daten nicht zu einer neuen Region migrieren. Die Problemumgehung umfasst Folgendes:

Erstellen einer neuen Application Insights-Ressource in der gewünschten Region.
Neuerstellen aller eindeutigen Anpassungen der ursprünglichen Ressource in der neuen Ressource
Aktualisieren Ihrer Anwendung mit der Verbindungszeichenfolge der Ressource in der neuen Region
Testen mit der neuen Application Insights-Ressource, um die erwartungsgemäße Funktionsweise sicherzustellen
Festlegen, ob die ursprüngliche Application Insights-Ressource beibehalten oder gelöscht werden soll. Beim Löschen einer klassischen Ressource gehen alle historischen Daten verloren. Wenn die Ressource arbeitsbereichsbasiert ist, verbleiben die Daten in Log Analytics, sodass der Zugriff auf historische Daten bis zum Ablauf des Aufbewahrungszeitraums möglich ist.

Eindeutige Anpassungen, die für die Ressource in der neuen Region normalerweise manuell neu erstellt oder aktualisiert werden müssen, umfassen beispielsweise Folgendes:

Neuerstellen von benutzerdefinierten Dashboards und Arbeitsmappen.
Neuerstellen oder Aktualisieren des Umfangs von benutzerdefinierten Protokoll-/Metrikwarnungen.
Neuerstellen von Verfügbarkeitswarnungen.
Neuerstellen aller benutzerdefinierten Einstellungen für die rollenbasierte Zugriffssteuerung in Azure, die Ihre Benutzer für den Zugriff auf die neue Ressource benötigen.
Einstellungen für Stichprobenentnahme von Daten, Datenaufbewahrung, tägliche Obergrenze und Aktivierung benutzerdefinierter Metriken replizieren. Diese Einstellungen werden über den Bereich Nutzungs- und geschätzte Kosten gesteuert.
Jede Integration, die auf API-Schlüsseln basiert, wie z. B. Versionsanmerkungen und einem sicheren Steuerungskanal für Livemetriken. Sie müssen neue API-Schlüssel generieren und die zugeordnete Integration aktualisieren.
Der fortlaufende Export in klassische Ressourcen muss erneut konfiguriert werden.
Diagnoseeinstellungen in arbeitsbereichsbasierten Ressourcen müssen erneut konfiguriert werden.

Kann ich „providers('Microsoft.Insights', 'components').apiVersions[0]“ in meinen Azure Resource Manager-Bereitstellungen verwenden?

Es wird davon abgeraten, diese Methode zum Auffüllen der API-Version zu verwenden. Die neueste Version kann Vorschaureleases darstellen, die Breaking Changes enthalten können. Auch bei neueren Nichtvorschauversionen sind die API-Versionen nicht immer abwärtskompatibel mit vorhandenen Vorlagen. In einigen Fällen ist die API-Version möglicherweise nicht für alle Abonnements verfügbar.

Wo erhalte ich weitere Informationen zum Erstellen und Konfigurieren von Application Insights-Ressourcen?

Weitere Informationen finden Sie unter Erstellen und Konfigurieren von Application Insights-Ressourcen.

Telemetriedatenmodell

Wie kann ich Datenmodell- oder Schemaprobleme und Vorschläge melden?

Falls Sie Probleme mit dem Datenmodell oder Schema melden möchten oder Anregungen haben, verwenden Sie das GitHub-Repository.

Wie kann ich die Auswirkungen einer Überwachungskampagne messen?

Die PageView-Telemetrie enthält eine URL, und Sie können den UTM-Parameter mithilfe einer RegEx-Funktion in Kusto analysieren.

Es kann gelegentlich vorkommen, dass diese Daten fehlen oder ungenau sind, wenn der Benutzer oder das Unternehmen das Senden des Benutzer-Agents in den Browsereinstellungen deaktiviert. Die regulären Ausdrücke (regex) des Benutzer-Agent-Parsers enthalten möglicherweise nicht alle Geräteinformationen. Oder Application Insights hat möglicherweise nicht die neuesten Updates übernommen.

Warum wäre eine benutzerdefinierte Messung ohne Fehler erfolgreich, aber das Protokoll wird nicht angezeigt?

Dies kann auftreten, wenn Sie Zeichenfolgenwerte verwenden. Nur numerische Werte funktionieren mit benutzerdefinierten Messungen.

Wo erhalte ich weitere Informationen zum Telemetriedatenmodell?

Weitere Informationen finden Sie unter Application Insights-Telemetriedatenmodell.

Protokollierung mit .NET

Welcher Typ von Application Insights-Telemetriedaten wird anhand von ILogger-Protokollen erstellt? Wo kann ich ILogger-Protokolle in Application Insights einsehen?

ApplicationInsightsLoggerProvider erfasst ILogger-Protokolle und erstellt TraceTelemetry daraus. Wenn ein Exception-Objekt an die Log-Methode in ILogger übergeben wird, wird anstelle von ExceptionTelemetryTraceTelemetry erstellt.

Anzeigen der ILogger-Telemetrie

Im Azure-Portal:

Wechseln Sie zum Azure-Portal, und greifen Sie auf Ihre Application Insights-Ressource zu.
Wählen Sie in Application Insights den Abschnitt Protokolle aus.
Verwenden Sie Kusto Query Language (KQL), um ILogger-Nachrichten abzufragen, die in der Tabelle traces gespeichert sind. Beispielabfrage: traces | where message contains "YourSearchTerm".
Verfeinern Sie Ihre Abfragen, um ILogger-Daten nach Schweregrad, Zeitbereich oder bestimmten Nachrichteninhalten zu filtern.

Gehen Sie in Visual Studio (lokaler Debugger) folgendermaßen vor:

Starten Sie Ihre Anwendung in Visual Studio im Debugmodus.
Öffnen Sie das Fenster Diagnosetools, während die Anwendung ausgeführt wird.
Auf der Registerkarte Ereignisse werden ILogger-Protokolle und andere Telemetriedaten angezeigt.
Verwenden Sie die Such- und Filterfeatures im Fenster Diagnosetools, um bestimmte ILogger-Nachrichten zu suchen.

Wenn Sie immer TraceTelemetry senden möchten, verwenden Sie diesen Codeausschnitt:

builder.AddApplicationInsights(
    options => options.TrackExceptionsAsExceptionTelemetry = false);

Warum weisen einige ILogger-Protokolle nicht dieselben Eigenschaften wie andere auf?

Application Insights erfasst und sendet ILogger-Protokolle mithilfe derselben TelemetryConfiguration-Informationen, die auch für andere Telemetriedaten verwendet werden. Es gibt jedoch eine Ausnahme. Standardmäßig ist die TelemetryConfiguration nicht vollständig eingerichtet, wenn Sie aus Program.cs oder Startup.cs protokollieren. Protokolle aus diesen Quellen weisen nicht die Standardkonfiguration auf, daher führen sie nicht alle TelemetryInitializer- und TelemetryProcessor-Instanzen aus.

Ich verwende das eigenständige Paket „Microsoft.Extensions.Logging.ApplicationInsights“ und möchte weitere benutzerdefinierte Telemetriedaten manuell protokollieren. Wie sollte ich dazu vorgehen?

Wenn Sie das eigenständige Paket verwenden, wird TelemetryClient nicht in den Abhängigkeitseinschleusungscontainer (Dependency Injection, DI) eingeschleust. Sie müssen eine neue Instanz von TelemetryClient erstellen und dieselbe Konfiguration verwenden, die der Protokollierungsanbieter verwendet, wie im folgenden Code gezeigt. Durch diese Anforderung wird sichergestellt, dass dieselbe Konfiguration für alle benutzerdefinierten Telemetriedaten sowie für die Telemetriedaten von ILogger verwendet wird.

public class MyController : ApiController
{
   // This TelemetryClient instance can be used to track additional telemetry through the TrackXXX() API.
   private readonly TelemetryClient _telemetryClient;
   private readonly ILogger _logger;

   public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)
   {
        _telemetryClient = new TelemetryClient(options.Value);
        _logger = logger;
   }  
}

Hinweis

Wenn Sie Application Insights mit dem Paket Microsoft.ApplicationInsights.AspNetCore aktivieren, ändern Sie diesen Code, um TelemetryClient direkt in den Konstruktor abzurufen.

Ich habe das SDK nicht installiert und verwende die Azure-Web-Apps-Erweiterung, um Application Insights für meine ASP.NET Core-Anwendungen zu aktivieren. Wie verwende ich den neuen Anbieter?

Die Application Insights-Erweiterung in Azure-Web-Apps verwendet den neuen Anbieter. Sie können die Filterregeln in der Datei appsettings.json für die Anwendung ändern.

Wo erhalte ich weitere Informationen zur Protokollierung mit .NET?

Weitere Informationen finden Sie unter Application Insights-Protokollierung mit .NET.

Java Profiler

Was ist die Azure Monitor Application Insights-Java-Profilerstellung?

Der Java-Profiler verwendet Java Flight Recorder (JFR), um ein Profil Ihrer Anwendung mithilfe einer benutzerdefinierten Konfiguration zu erstellen.

Was ist Java Flight Recorder?

Java Flight Recorder (JFR) ist ein Tool zum Sammeln von Profilerstellungsdaten einer ausgeführten Java-Anwendung. JFR ist in der Java Virtual Machine (JVM) integriert und wird zum Beheben von Leistungsproblemen verwendet. Erfahren Sie mehr über die Java SE JFR Runtime.

Wie hoch sind die Kosten und/oder Lizenzgebühren für die Aktivierung von App Insights-Java-Profilerstellung?

Die Java-Profilerstellung ist ein kostenloses Feature von Application Insights. Die Preise für Azure Monitor Application Insights basieren auf den Erfassungskosten.

Welche Java-Profilerstellungsinformationen werden erfasst?

Zu den vom JFR gesammelten Profilerstellungsdaten gehören: Methoden- und Ausführungsprofilerstellungsdaten, Garbage Collection-Daten und Sperrprofile.

Wie kann ich die App Insights-Java-Profilerstellung verwenden und die Daten visualisieren?

JFR-Aufzeichnungen können mit Ihrem bevorzugten Tool angezeigt und analysiert werden, z. B. Java Mission Control (JMC).

Werden mit der App Insights-Java-Profilerstellung Leistungsdiagnosen und Empfehlungen zur Behebung von Problemen bereitgestellt?

„Leistungsdiagnose und Empfehlungen“ ist ein neues Feature, das in Kürze als Application Insights-Java-Diagnose verfügbar sein wird. Sie können sich für eine Vorschau dieses Features registrieren. Die JFR-Aufzeichnung kann mit Java Mission Control (JMC) angezeigt werden.

Was ist der Unterschied zwischen der bedarfsgesteuerten und der automatischen Java-Profilerstellung in App Insights?

Die bedarfsgesteuerte Profilerstellung erfolgt durch den Benutzer in Echtzeit, während die automatische Profilerstellung mit vorkonfigurierten Triggern erfolgt.

Verwenden Sie Jetzt Profil erstellen für die Option zur bedarfsgesteuerten Profilerstellung. Jetzt Profil erstellen erstellt sofort ein Profil aller Agents, die mit der Application Insights-Instanz verbunden sind.

Die automatisierte Profilerstellung wird durch das Erreichen eines Ressourcenschwellenwerts ausgelöst.

Welche Trigger für die Java-Profilerstellung kann ich konfigurieren?

Der Application Insights-Java-Agent unterstützt derzeit die Überwachung von CPU- und Arbeitsspeicherverbrauch. Der CPU-Schwellenwert wird als Prozentsatz aller verfügbaren Kerne auf dem Computer konfiguriert. Der Arbeitsspeicher ist die aktuelle Belegung der Tenured-Speicherregion (OldGen) im Verhältnis zur maximal möglichen Größe der Region.

Welche Voraussetzungen müssen erfüllt sein, um die Java-Profilerstellung zu aktivieren?

Überprüfen Sie die Voraussetzungen.

Kann ich Java Profiling für eine Microservices-Anwendung verwenden?

Ja, Sie können für eine JVM, die Microservices mithilfe von JFR ausführt, ein Profil erstellen.

Wo erhalte ich weitere Informationen zu Java Profiler?

Weitere Informationen finden Sie unter Azure Monitor Application Insights Profiler für Java.

Sampling-Außerkraftsetzungen – Application Insights für Java

Muss ich manuelle Instrumentierung verwenden, um Sampling-Außerkraftsetzungen zu aktivieren?

Nein, Sampling-Außerkraftsetzungen sind jetzt allgemein verfügbar (GA) und können sowohl mit automatischer Instrumentierung als auch mit manueller Instrumentierung verwendet werden.

Wie kann ich Sampling-Außerkraftsetzungen konfigurieren, wenn ich Azure App Service mit automatischer Instrumentierung verwende?

Wenn Sie autoinstrumentation verwenden, aktualisieren Sie die applicationinsights.json Datei im Azure-Portal.

Ist es erforderlich, die Application Insights-Agent-Datei manuell zum Sampling von Außerkraftsetzungen hochzuladen?

Für die automatische Instrumentierung ist kein manueller Agentupload erforderlich. Bei manueller Instrumentierung müssen Sie jedoch weiterhin die Application Insights-Agent-JAR-Datei und Konfigurationsdateien in Ihr Bereitstellungspaket einschließen.

Was ist der Unterschied zwischen "lokaler Entwicklung" und "Anwendungsserver" im Kontext der manuellen Instrumentierung?

Die lokale Entwicklung bezieht sich auf die Umgebung, in der die App erstellt oder getestet wird, z. B. den Computer eines Entwicklers oder eine Azure Cloud Shell-Instanz. Anwendungsserver bezieht sich auf den Webserver, auf dem die Anwendung ausgeführt wird, z. B. Tomcat 11 in einer Azure App Service-Umgebung. Bei Verwendung manueller Instrumentierung müssen Sie sicherstellen, dass die Agent-JAR-Datei auf dem Anwendungsserver korrekt platziert ist.

Wenn ich einen Azure App Service mit einer Java-Runtime (z. B. Tomcat 11) verwende, wie kann ich Sampling-Außerkraftsetzungen konfigurieren?

Für die automatische Instrumentierung können Sie Samplingüberschreibungen über das Azure-Portal konfigurieren. Wenn Sie die manuelle Instrumentierung verwenden, sollten Sie den Application Insights-Agent JAR in das entsprechende Verzeichnis einfügen und die applicationinsights.json Datei mit den gewünschten Samplingeinstellungen einschließen.

Wo erhalte ich weitere Informationen zu Samplingüberschreibungen?

Weitere Informationen finden Sie unter Sampling-Außerkraftsetzungen – Azure Monitor Application Insights for Java.

Telemetrieprozessoren

Warum verarbeitet der Protokollprozessor Protokolle nicht mithilfe von „TelemetryClient.trackTrace()“?

TelemetryClient.trackTrace() ist Teil der Application Insights Classic SDK-Brücke, und die Protokollprozessoren funktionieren nur mit der neuen OpenTelemetry-basierten Instrumentierung.

Wo erhalte ich weitere Informationen zu Telemetrieprozessoren?

Weitere Informationen finden Sie unter Telemetrieprozessoren (Vorschau) – Azure Monitor Application Insights für Java.

JavaScript SDK

Was sind Benutzer- und Sitzungszähler?

Das JavaScript-SDK legt im Webclient ein Benutzercookie zum Identifizieren wiederkehrender Benutzer und ein Sitzungscookie zum Gruppieren von Aktivitäten fest.
Wenn kein clientseitiges Skript vorhanden ist, können Sie Cookies auf dem Server festlegen.
Wenn ein realer Benutzer Ihre Website in verschiedenen Browsern, beim InPrivate- oder Inkognito-Browsing oder auf unterschiedlichen Computern verwendet, wird er mehrmals gezählt.
Um einen angemeldeten Benutzer auf verschiedenen Computern und in verschiedenen Browsern zu identifizieren, fügen Sie einen Aufruf von setAuthenticatedUserContext() hinzu.

Wo liegt die JavaScript SDK-Leistung/der Mehraufwand?

Das Application Insights JavaScript SDK hat einen minimalen Mehraufwand für Ihre Website. Mit einer Größe von nur 36 KB (gzip) und einer Initialisierungszeit von nur etwa 15 ms fügt das SDK Ihrer Website nur eine vernachlässigbare Menge an Ladezeit hinzu. Die minimalen Komponenten der Bibliothek werden schnell geladen, wenn Sie das SDK verwenden, und das vollständige Skript wird im Hintergrund heruntergeladen.

Darüber hinaus wird während des Herunterladens des Skripts aus dem CDN die gesamte Nachverfolgung Ihrer Seite in die Warteschlange gestellt, sodass Sie während des gesamten Lebenszyklus Ihrer Seite keine Telemetriedaten verlieren. Dieser Setupvorgang stellt für Ihre Seite ein nahtloses Analysesystem bereit, das für Ihre Benutzer unsichtbar ist.

Welche Browser werden vom JavaScript SDK unterstützt?


Chrome (neueste Version) ✔	Firefox (neueste Version) ✔	v3.x: IE 9 und höher sowie Microsoft Edge ✔ v2.x: Kompatibel mit IE 8+ & Microsoft Edge ✔	Opera (neueste Version) ✔	Safari (neueste Version) ✔

Wo finde ich Codebeispiele für das JavaScript SDK?

Ausführbare Beispiele finden Sie in den Beispielen für das Application Insights JavaScript SDK.

Wie ist die ES3-/Internet-Explorer 8-Kompatibilität mit dem JavaScript SDK?

Wir müssen sicherstellen, dass dieses SDK weiterhin funktioniert und nicht die Ausführung von JavaScript unterbricht, wenn es von einem älteren Browser geladen wird. Es wäre zwar optimal, ältere Browser nicht zu unterstützen, aber zahlreiche Großkunden können nicht steuern, welchen Browser ihre Benutzer verwenden.

Diese Aussage bedeutet nicht, dass wir nur den kleinsten gemeinsamen Leistungsumfang unterstützen werden. Wir müssen ES3-Codekompatibilität aufrechterhalten. Neue Funktionen müssen so hinzugefügt werden, dass die Analyse von ES3-JavaScript nicht unterbrochen wird und dass sie als optionale Funktion hinzugefügt werden.

Weitere Informationen zur Unterstützung von Internet Explorer 8 finden Sie auf GitHub.

Ist das JavaScript SDK Open Source?

Ja, das Application Insights JavaScript SDK ist Open Source. Wenn Sie den Quellcode anzeigen oder zum Projekt beitragen möchten, besuchen Sie das offizielle GitHub-Repository.

Wo erhalte ich weitere Informationen zum JavaScript SDK?

Weitere Informationen finden Sie unter Enable Azure Monitor Application Insights Real User Monitoring.

JavaScript SDK-Konfiguration

Wie kann ich die Serverkonfiguration eines Drittanbieters für das JavaScript SDK aktualisieren?

Auf Serverseite müssen Verbindungen mit diesen Headern akzeptiert werden können. Je nach serverseitiger Konfiguration von Access-Control-Allow-Headers ist es häufig erforderlich, die serverseitige Liste zu erweitern, indem Request-Id, Request-Context und traceparent (verteilter W3C-Header) manuell hinzugefügt werden.

Access-Control-Allow-Headers: Request-Id, traceparent, Request-Context, <your header>.

Wie kann ich die verteilte Ablaufverfolgung für das JavaScript SDK deaktivieren?

In der Konfiguration kann das verteilte Tracing deaktiviert werden.

Werden HTTP 502- und 503-Antworten immer von Application Insights erfasst?

Nein. Die Fehler „502 Ungültiges Gateway“ und „503 Dienst nicht verfügbar“ werden nicht immer von Application Insights erfasst. Wenn nur clientseitiges JavaScript für die Überwachung verwendet wird, ist dieses Verhalten zu erwarten, da die Fehlerantwort vor der Seite zurückgegeben wird, die den HTML-Header mit dem gerenderten JavaScript-Codeausschnitt für die Überwachung enthält.

Wenn die 502- oder 503-Antwort von einem Server mit aktivierter serverseitiger Überwachung gesendet wird, werden die Fehler vom Application Insights SDK erfasst.

Selbst bei aktivierter serverseitiger Überwachung auf dem Webserver einer Anwendung wird manchmal ein 502- oder 503-Fehler nicht von Application Insights erfasst. Viele moderne Webserver ermöglichen Clients keine direkte Kommunikation. Stattdessen wenden sie Lösungen wie Reverseproxys an, um Informationen zwischen dem Client und den Front-End-Webservern zu übergeben.

In diesem Szenario kann eine 502- oder 503-Antwort aufgrund eines Problems auf Reverseproxyebene an einen Client zurückgegeben werden, weshalb sie nicht in der Standardkonfiguration von Application Insights erfasst wird. Um Probleme auf dieser Ebene zu erkennen, müssen Sie möglicherweise Protokolle vom Reverseproxy an Log Analytics weiterleiten und eine benutzerdefinierte Regel erstellen, um nach 502- oder 503-Antworten zu suchen. Weitere Informationen zu häufigen Ursachen von 502- und 503-Fehlern finden Sie unter Problembehandlung von HTTP-Fehlern „502 Ungültiges Gateway“ und „503 Dienst nicht verfügbar“ in Azure App Service.

Wo erhalte ich weitere Informationen zur JavaScript SDK-Konfiguration?

Weitere Informationen finden Sie unter Application Insights JavaScript SDK-Konfiguration.

JavaScript-Frameworkerweiterungen

Wie werden von Application Insights Geräteinformationen wie Browser, Betriebssystem, Sprache und Modell generiert?

Der Browser übergibt die Benutzer-Agent-Zeichenfolge im HTTP-Header der Anforderung. Der Application Insights-Erfassungsdienst verwendet den UA Parser, um die Felder zu generieren, die in den Datentabellen und Erlebnissen angezeigt werden. Dies hat zur Folge, dass diese Felder von Application Insights-Benutzern nicht geändert werden können.

Wo erhalte ich weitere Informationen zu JavaScript-Frameworkerweiterungen?

Weitere Informationen finden Sie unter Enable a framework extension for Application Insights JavaScript SDK.

Verwaltete Arbeitsbereiche

Muss ich Skripts oder Automatisierung aktualisieren, die auf klassische Ressourcen verweisen?

Nein. Vorhandene ARM-Vorlagen und API-Aufrufe funktionieren weiterhin. Wenn Sie versuchen, eine klassische Ressource zu erstellen, wird stattdessen eine arbeitsbereichbasierte Ressource mit einem verwalteten Arbeitsbereich erstellt.

Bin ich benachrichtigt, bevor meine Ressource migriert wird?

Nein. Die Benachrichtigung für einzelne Ressourcenmigrationen ist nicht verfügbar. Um zu steuern, wann und wie Ihre Ressourcen migriert werden, verwenden Sie die manuelle Migration.

Wie lange dauert der Migrationsprozess?

Einzelne Migrationen werden in der Regel in weniger als zwei Minuten abgeschlossen. Der vollständige Rollout findet über mehrere Wochen in allen Regionen statt.

Wie kann ich feststellen, ob eine Ressource migriert wird?

Nach der Migration wird die Ressource mit einem Log Analytics-Arbeitsbereich auf der Seite "Übersicht" verknüpft. Der klassische Ruhestandshinweis wird entfernt, und die Ruhestandsarbeitsmappe listet die Ressource nicht mehr auf.

Ändert sich meine Abrechnung nach der Migration?

Die Kosten bleiben in der Regel ähnlich. Arbeitsbereichsbasierte Application Insights ermöglicht kostensparende Features und wir empfehlen, Preispläne zu überprüfen.

Wenn Sie ein älteres Abrechnungsmodell verwenden, lesen Sie die Preisdokumentation für Details.

Verliere ich Warnungen oder Verfügbarkeitstests während der Migration?

Nein. Alle Warnungen, Dashboards und Verfügbarkeitstests bleiben erhalten und funktionieren nach der Migration weiterhin.

Wo erhalte ich weitere Informationen zu verwalteten Arbeitsbereichen?

Weitere Informationen finden Sie unter Verwaltete Arbeitsbereiche in Application Insights.

Node.js

Wie kann ich die Telemetriekorrelation deaktivieren?

Verwenden Sie die correlationHeaderExcludedDomains-Eigenschaft in der Konfiguration, um die Telemetriekorrelation zu deaktivieren. Weitere Informationen finden Sie unter ApplicationInsights-node.js.

Wie kann ich die gewünschte Protokollebene konfigurieren?

Um die gewünschte Protokollebene zu konfigurieren, die von APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL Application Insights verwendet wird, verwenden Sie die Umgebungsvariable. Die unterstützten Werte sind NONE, ERROR, WARN, INFO, DEBUG, VERBOSE und ALL. Weitere Informationen finden Sie unter ApplicationInsights-node.js.

Wo erhalte ich weitere Informationen zur Überwachung von Node.js Diensten und Apps mit Application Insights?

Weitere Informationen finden Sie unter Überwachen Ihrer Node.js Dienste und Apps mit Application Insights.

Azure Monitor OpenTelemetry

Wo finde ich eine Liste mit den Application Insights SDK-Versionen und ihren Namen?

Eine Liste mit SDK-Versionen und -Namen wird auf GitHub gehostet. Weitere Informationen finden Sie unter SDK-Version.

Wo erhalte ich weitere Informationen zu OpenTelemetry?

Weitere Informationen finden Sie unter Sammeln von Telemetrie mit OpenTelemetry in Application Insights.

Migrieren von .NET Application Insights SDKs zu Azure Monitor OpenTelemetry

Wie ordnen die SDK-APIs openTelemetry-Konzepte zu?

OpenTelemetry ist ein anbieterneutrales Framework für Observierbarkeit. Das OpenTelemetry SDK und die Bibliotheken enthalten keine Application Insights-APIs. Vor der Migration ist es wichtig, sich mit einigen der Konzepte von OpenTelemetry vertraut zu machen.

In Application Insights wurden sämtliche Telemetriedaten über einen einzelnen Telemetrieclient (TelemetryClient) und über eine einzelne Telemetriekonfiguration (TelemetryConfiguration) verwaltet. In OpenTelemetry hat jedes der drei Telemetriesignale (Traces, Metriken und Logs) seine eigene Konfiguration. Sie können Telemetriedaten manuell und ohne externe Bibliotheken über die .NET-Runtime erstellen. Weitere Informationen finden Sie in den .NET-Leitfäden zu verteilter Ablaufverfolgung, Metriken und Protokollierung.
Von Application Insights wurde TelemetryModules verwendet, um automatisch Telemetriedaten für Ihre Anwendung zu sammeln. OpenTelemetry verwendet stattdessen Instrumentierungsbibliotheken, um Telemetriedaten von bestimmten Komponenten zu sammeln (z. B. AspNetCore für Anforderungen und HttpClient für Abhängigkeiten).
Von Application Insights wurde TelemetryInitializers verwendet, um Telemetriedaten mit zusätzlichen Informationen anzureichern oder Eigenschaften außer Kraft zu setzen. Bei OpenTelemetry können Sie einen Prozessor schreiben, um ein bestimmtes Signal anzupassen. Darüber hinaus bieten viele OpenTelemetry-Instrumentierungsbibliotheken eine Enrich-Methode zum Anpassen der Telemetriedaten, die von dieser spezifischen Komponente generiert werden.
Von Application Insights wurde TelemetryProcessors verwendet, um Telemetriedaten zu filtern. Mit einem Prozessor von OpenTelemetry können auch Filterregeln auf ein bestimmtes Signal angewendet werden.

Wie sieht die Zuordnung zwischen Application Insights-Telemetrietypen und OpenTelemetry aus?

Diese Tabelle zeigt die Zuordnung zwischen Application Insights-Datentypen und OpenTelemetry-Konzepten sowie deren .NET-Implementierungen.

Azure Monitor-Tabelle	Application Insights-Datentyp	OpenTelemetry-Datentyp	.NET-Implementierung
customEvents	Ereignis-Telemetrie (EventTelemetry)	Nicht verfügbar	Nicht verfügbar
customMetrics	MetricTelemetry	Metriken	System.Diagnostics.Metrics.Meter
Abhängigkeiten	DependencyTelemetry	Spans (Client, intern, Consumer)	System.Diagnostics.Activity
Ausnahmen	ExceptionTelemetry	Ausnahmen	System.Exception
Aufforderungen	RequestTelemetry	Spans (Server, Produzent)	System.Diagnostics.Activity
Spuren	Trace-Telemetrie	Logdateien	Microsoft.Extensions.Logging.ILogger
Spuren	Trace-Telemetrie	Span-Ereignisse	System.Diagnostics.ActivityEvent

Weitere Informationen finden Sie in folgenden Dokumenten:

Wie sieht die Zuordnung zwischen Application Insights-Konzepten für die Stichprobenentnahme und OpenTelemetry aus?

In Application Insights standen mehrere Optionen zum Konfigurieren der Stichprobenentnahme zur Verfügung. Der Azure Monitor-Exporter und die Azure Monitor-Distribution bieten dagegen nur eine Stichprobenentnahme mit festem Prozentsatz. Stichproben können nur für Anforderungen und Abhängigkeiten (OpenTelemetry-Ablaufverfolgungen) entnommen werden.

Codebeispiele zur Konfiguration der Stichprobenentnahme finden Sie in unserem Leitfaden zum Aktivieren der Stichprobenentnahme.

Wie sieht die Zuordnung zwischen Telemetrieprozessoren bzw. -initialisierern und OpenTelemetry aus?

Verwenden Sie im Application Insights .NET SDK Telemetrieprozessoren, um Telemetriedaten zu filtern und zu ändern oder zu verwerfen. Verwenden Sie Telemetrieinitialisierer, um benutzerdefinierte Eigenschaften hinzuzufügen oder zu ändern. Weitere Informationen finden Sie in der Dokumentation zu Azure Monitor. OpenTelemetry ersetzt diese Konzepte durch Aktivitäts- oder Protokollprozessoren, die Telemetriedaten anreichern und filtern.

Filtern von Ablaufverfolgungen

Wenn Sie Telemetriedaten in OpenTelemetry filtern möchten, können Sie einen Aktivitätsprozessor implementieren. Dieses Beispiel entspricht dem Application Insights-Beispiel zum Filtern von Telemetriedaten aus der Dokumentation zu Azure Monitor. Das Beispiel zeigt, wo nicht erfolgreiche Abhängigkeitsaufrufe gefiltert werden.

using System.Diagnostics;
using OpenTelemetry;

internal sealed class SuccessfulDependencyFilterProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (!OKtoSend(activity))
        {
            activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
        }
    }

    private bool OKtoSend(Activity activity)
    {
       return activity.Kind == ActivityKind.Client && activity.Status == ActivityStatusCode.Ok;
    }
}

Um diesen Prozessor zu verwenden, müssen Sie ein TracerProvider-Element erstellen und den Prozessor vor AddAzureMonitorTraceExporter hinzufügen.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddProcessor(new SuccessfulDependencyFilterProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Filtern von Protokollen

ILogger-Implementierungen verfügen über einen integrierten Mechanismus zum Anwenden der Protokollfilterung. Mit dieser Filterung können Sie die Protokolle steuern, die an die einzelnen registrierten Anbieter gesendet werden (einschließlich OpenTelemetryLoggerProvider). „OpenTelemetry“ ist der Alias für OpenTelemetryLoggerProvider, der beim Konfigurieren von Filterregeln verwendet wird.

Im folgenden Beispiel wird „Error“ als standardmäßiger Protokolliergrad (LogLevel) und „Warning“ als minimaler Protokolliergrad (LogLevel) für eine benutzerdefinierte Kategorie definiert. Diese Regeln gelten wie definiert nur für OpenTelemetryLoggerProvider.

builder.AddFilter<OpenTelemetryLoggerProvider>("*", LogLevel.Error);
builder.AddFilter<OpenTelemetryLoggerProvider>("MyProduct.MyLibrary.MyClass", LogLevel.Warning);

Weitere Informationen finden Sie in der OpenTelemetry .NET-Dokumentation zu Protokollen.

Hinzufügen benutzerdefinierter Eigenschaften zu Ablaufverfolgungen

In OpenTelemetry können Sie Aktivitätsprozessoren verwenden, um Telemetriedaten mit weiteren Eigenschaften anzureichern. Dies funktioniert ähnlich wie die Verwendung von Telemetrieinitialisierern in Application Insights zum Ändern von Telemetrieeigenschaften.

Standardmäßig kennzeichnet der Azure Monitor-Exporter jede HTTP-Anforderung mit einem Antwortcode ab 400 als nicht erfolgreich. Wenn Sie 400 jedoch als Erfolg behandeln möchten, können Sie einen anreichernden Aktivitätsprozessor hinzufügen, der den Erfolg für die Aktivität festlegt und ein Tag hinzufügt, um weitere Telemetrieeigenschaften einzuschließen. Dies ist vergleichbar mit dem Hinzufügen oder Ändern von Eigenschaften mithilfe eines Initialisierers in Application Insights, wie in der Dokumentation zu Azure Monitor beschrieben.

Hier ist ein Beispiel für das Hinzufügen von benutzerdefinierten Eigenschaften und die Außerkraftsetzung des Standardverhaltens für bestimmte Antwortcodes:

using System.Diagnostics;
using OpenTelemetry;

/// <summary>
/// Custom Processor that overrides the default behavior of treating response codes >= 400 as failed requests.
/// </summary>
internal class MyEnrichingProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (activity.Kind == ActivityKind.Server)
        {
            int responseCode = GetResponseCode(activity);

            if (responseCode >= 400 && responseCode < 500)
            {
               // If we set the Success property, the SDK won't change it
               activity.SetStatus(ActivityStatusCode.Ok);

               // Allow to filter these requests in the portal
              activity.SetTag("Overridden400s", "true");
            }

            // else leave the SDK to set the Success property
        }
    }

    private int GetResponseCode(Activity activity)
    {
       foreach (ref readonly var tag in activity.EnumerateTagObjects())
       {    
          if (tag.Key == "http.response.status_code" && tag.Value is int value)
          {
           return value;
          }
       }

       return 0;
    }
}

Um diesen Prozessor zu verwenden, müssen Sie ein TracerProvider-Element erstellen und den Prozessor vor AddAzureMonitorTraceExporter hinzufügen.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddSource("Company.Product.Name")
       .AddProcessor(new MyEnrichingProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Wie kann ich Telemetriedaten mit OpenTelemetry manuell nachverfolgen?

Senden von Ablaufverfolgungen: Manuell

Ablaufverfolgungen in Application Insights werden als RequestTelemetry und DependencyTelemetry gespeichert. In OpenTelemetry werden Ablaufverfolgungen mithilfe der Span-Klasse als Activity modelliert.

OpenTelemetry .NET verwendet die Klassen ActivitySource und Activity für die Ablaufverfolgung. Diese sind Teil der .NET-Runtime. Dieser Ansatz ist unterscheidend, da die .NET-Implementierung die Ablaufverfolgungs-API direkt in die Runtime selbst integriert. Mit dem Paket System.Diagnostics.DiagnosticSource können Entwickler ActivitySource verwenden, um Activity-Instanzen zu erstellen und zu verwalten. Mithilfe dieser Methode können Sie .NET-Anwendungen nahtlos Ablaufverfolgung hinzufügen, ohne sich auf externe Bibliotheken zu verlassen, und dabei die integrierten Funktionen des .NET-Ökosystems nutzen. Ausführlichere Informationen finden Sie in den exemplarischen Vorgehensweisen zur verteilten Ablaufverfolgungsinstrumentierung.

So migrieren Sie die manuelle Nachverfolgung:

Hinweis

In Application Insights können der Rollenname und die Rolleninstanz auf Telemetrieebene festgelegt werden. Mit dem Azure Monitor-Exporter ist jedoch keine Anpassung auf Telemetrieebene möglich. Der Rollenname und die Rolleninstanz werden aus der OpenTelemetry-Ressource extrahiert und auf alle Telemetriedaten angewendet. Weitere Informationen zum Festlegen des Cloudrollennamens und der Cloudrolleninstanz finden Sie hier.

DependencyTelemetry

Application Insights DependencyTelemetry wird verwendet, um ausgehende Anforderungen zu modellieren. So konvertieren Sie sie in OpenTelemetry:

Application Insights-Beispiel:

DependencyTelemetry dep = new DependencyTelemetry
{
   Name = "DependencyName",
   Data = "https://www.example.com/",
   Type = "Http",
   Target = "www.example.com",
   Duration = TimeSpan.FromSeconds(10),
   ResultCode = "500",
   Success = false
};

dep.Context.Cloud.RoleName = "MyRole";
dep.Context.Cloud.RoleInstance = "MyRoleInstance";
dep.Properties["customprop1"] = "custom value1";
client.TrackDependency(dep);

OpenTelemetry-Beispiel:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("DependencyName", ActivityKind.Client))
{
  activity?.SetTag("url.full", "https://www.example.com/");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("http.request.method", "GET");
  activity?.SetTag("http.response.status_code", "500");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Error);
  activity?.SetEndTime(activity.StartTimeUtc.AddSeconds(10));
}

RequestTelemetry

RequestTelemetry von Application Insights modelliert eingehende Anforderungen. So migrieren Sie sie zu OpenTelemetry:

Application Insights-Beispiel:

RequestTelemetry req = new RequestTelemetry
{
   Name = "RequestName",
   Url = new Uri("http://example.com"),
   Duration = TimeSpan.FromSeconds(10),
   ResponseCode = "200",
   Success = true,
   Properties = { ["customprop1"] = "custom value1" }
};

req.Context.Cloud.RoleName = "MyRole";
req.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackRequest(req);

OpenTelemetry-Beispiel:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("RequestName", ActivityKind.Server))
{
  activity?.SetTag("url.scheme", "https");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("url.path", "/");
  activity?.SetTag("http.response.status_code", "200");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Ok);
}

Nachverfolgung benutzerdefinierter Vorgänge

In Application Insights können benutzerdefinierte Vorgänge mithilfe von StartOperation- und StopOperation-Methoden nachverfolgt werden. Verwenden Sie dazu ActivitySource und Activity in OpenTelemetry .NET. Für Vorgänge mit ActivityKind.Server und ActivityKind.Consumer generiert der Azure Monitor-Exporter RequestTelemetry. Für ActivityKind.Client, ActivityKind.Producer und ActivityKind.Internal wird DependencyTelemetry generiert. Weitere Informationen zur Nachverfolgung benutzerdefinierter Vorgänge finden Sie in der Dokumentation zu Azure Monitor. Weitere Informationen zur Verwendung von ActivitySource und Activity in .NET finden Sie in den exemplarischen Vorgehensweisen zur verteilten Ablaufverfolgungsinstrumentierung von .NET.

Hier ist ein Beispiel für das Starten und Beenden einer Aktivität für benutzerdefinierte Vorgänge:

using System.Diagnostics;
using OpenTelemetry;

var activitySource = new ActivitySource("Company.Product.Name");

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddSource(activitySource.Name)
    .AddAzureMonitorTraceExporter()
    .Build();

// Start a new activity
using (var activity = activitySource.StartActivity("CustomOperation", ActivityKind.Server))
{
    activity?.SetTag("customTag", "customValue");

    // Perform your custom operation logic here

    // No need to explicitly call Activity.Stop() because the using block automatically disposes the Activity object, which stops it.
}

Senden von Protokollen

Protokolle in Application Insights werden als TraceTelemetry und ExceptionTelemetry gespeichert.

Trace-Telemetrie

In OpenTelemetry ist die Protokollierung über die ILogger-Schnittstelle integriert. So funktioniert die Migration von TraceTelemetry:

Application Insights-Beispiel:

TraceTelemetry traceTelemetry = new TraceTelemetry 
{
   Message = "hello from tomato 2.99",
   SeverityLevel = SeverityLevel.Warning,
};

traceTelemetry.Context.Cloud.RoleName = "MyRole";
traceTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackTrace(traceTelemetry);

OpenTelemetry-Beispiel:

var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory
var logger = loggerFactory.CreateLogger<Program>();

// Emit log: This uses the logger instance to write a new log
logger.FoodPrice("tomato", 2.99);

internal static partial class LoggerExtensions
{
   [LoggerMessage(LogLevel.Warning, "Hello from `{name}` `{price}`.")]
   public static partial void FoodPrice(this ILogger logger, string name, double price);
}

ExceptionTelemetry

Application Insights verwendet ExceptionTelemetry, um Ausnahmen zu protokollieren. So führen Sie die Migration zu OpenTelemetry durch:

Application Insights-Beispiel:

ExceptionTelemetry exceptionTelemetry = new ExceptionTelemetry(new Exception("Test exception"))
{
    SeverityLevel = SeverityLevel.Error
};

exceptionTelemetry.Context.Cloud.RoleName = "MyRole";
exceptionTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
exceptionTelemetry.Properties["customprop1"] = "custom value1";
client.TrackException(exceptionTelemetry);

OpenTelemetry-Beispiel:

var resourceAttributes = new Dictionary<string, object> 
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory.
var logger = loggerFactory.CreateLogger<Program>();

try
{
    // Simulate exception
    throw new Exception("Test exception");
}
catch (Exception ex)
{
   // Emit exception: This uses the logger instance to write a new exception
   logger?.LogError(ex, "An error occurred");
}

Senden von Metriken

Metriken in Application Insights werden als MetricTelemetry gespeichert. In OpenTelemetry werden Metriken als Meter aus dem Paket System.Diagnostics.DiagnosticSource modelliert.

Application Insights verfügt sowohl über Metrik-APIs ohne Vorabaggregation (TrackMetric()) als auch über Metrik-APIs mit Vorabaggregation (GetMetric().TrackValue()). Im Gegensatz zu OpenTelemetry gibt es in Application Insights kein Konzept für Instrumente. Application Insights verwendet die gleiche API für alle Metrikszenarien.

Bei OpenTelemetry müssen Benutzer dagegen zuerst das richtige Metrikinstrument auswählen (basierend auf der tatsächlichen Semantik der Metrik). Wenn beispielsweise etwas gezählt werden soll (z. B. die Anzahl empfangener Serveranforderungen oder Ähnliches), muss der OpenTelemetry-Zähler verwendet werden. Wenn verschiedene Perzentile berechnet werden sollen (z. B. der P99-Wert der Serverlatenz), sollte das Instrument OpenTelemetry-Histogramm verwendet werden. Aufgrund dieses grundlegenden Unterschieds zwischen Application Insights und OpenTelemetry gibt es keinen direkten Vergleich zwischen ihnen.

Im Gegensatz zu Application Insights bietet OpenTelemetry keine integrierten Mechanismen zum Anreichern oder Filtern von Metriken. In Application Insights können Telemetrieprozessoren und -initialisierer verwendet werden, um Metriken zu ändern oder zu verwerfen. Diese Funktion ist in OpenTelemetry jedoch nicht verfügbar.

Darüber hinaus unterstützt OpenTelemetry das direkte Senden von Rohmetriken nicht, da es dort keine Entsprechung für die in Application Insights enthaltene TrackMetric()-Funktion gibt.

Im Zuge der Migration von Application Insights zu OpenTelemetry müssen alle Verwendungen der Metrik-APIs von Application Insights durch die OpenTelemetry-API ersetzt werden. Dies erfordert Vertrautheit mit den verschiedenen OpenTelemetry-Instrumenten und deren Semantik.

Tipp

Das Histogramm ist am vielseitigsten und entspricht am ehesten der GetMetric().TrackValue()-API von Application Insights. Sie können Metrik-APIs von Application Insights durch das Histogramm ersetzen, um das gleiche Ergebnis zu erzielen.

Weitere Telemetrietypen

Benutzerdefinierte Ereignisse

Wird in OpenTelemetry nicht unterstützt.

Application Insights-Beispiel:

TelemetryClient.TrackEvent()

Verfügbarkeitstelemetrie

Wird in OpenTelemetry nicht unterstützt.

Application Insights-Beispiel:

TelemetryClient.TrackAvailability()

PageViewTelemetry

Wird in OpenTelemetry nicht unterstützt.

Application Insights-Beispiel:

TelemetryClient.TrackPageView()

Kann ich Live-Metriken für Konsolen- und Workerdienstanwendungen abrufen?

Wir empfehlen den Azure Monitor OpenTelemetry Exporter für Konsolen- und Workerdienstanwendungen, die keine Livemetriken enthalten.

Wo erhalte ich weitere Informationen zum Migrieren von .NET Application Insights-SDKs zu OpenTelemetry?

Weitere Informationen finden Sie unter Migrieren von .NET Application Insights SDKs zu Azure Monitor OpenTelemetry.

OpenTelemetry-Stichprobenentnahme

Ist das benutzerdefinierte Stichprobenentnahmemodul von Application Insights tailbasiert?

Das benutzerdefinierte Stichprobenentnahmemodul von Application Insights trifft Entscheidungen zur Stichprobenentnahme nach der Erstellung des Bereichs, nicht vorher. Es folgt daher nicht dem herkömmlichen headbasierten Ansatz. Stattdessen werden Entscheidungen zur Stichprobenentnahme am Ende der Bereichserstellung angewendet – nach Abschluss des Bereichs, aber vor dem Export.

Obwohl dieses Verhalten in gewisser Weise einer tailbasierten Stichprobenentnahme ähnelt, wartet das Stichprobenentnahmemodul nicht darauf, mehrere Bereiche aus derselben Ablaufverfolgung zu sammeln, bevor eine Entscheidung getroffen wird. Stattdessen wird ein Hash der Nachverfolgungs-ID verwendet, um die Vollständigkeit der Nachverfolgung sicherzustellen.

Dieser Ansatz gleicht die Vollständigkeit der Ablaufverfolgung und die Effizienz ab und vermeidet die höheren Kosten, die mit der vollständigen Abtastung verbunden sind.

Um Entscheidungen über die Probenentnahme basierend auf dem Ergebnis einer vollständigen Ablaufverfolgung zu treffen (z. B. um festzustellen, ob ein Bereich innerhalb der Ablaufverfolgung fehlgeschlagen ist), ist eine vollständige tailbasierte Stichprobenentnahme in einem nachgelagerten Agent oder Collector erforderlich. Diese Funktion wird derzeit nicht unterstützt, Sie können sie aber über den Feedback-Hub als neue Funktion anfordern.

Wie verhält sich das benutzerdefinierte Stichprobenentnahmemodul von Application Insights im Vergleich mit der head- oder tailbasierten Stichprobenentnahme von OpenTelemetry?

Stichprobenverfahren	Entscheidungspunkt	Stärken	Schwächen
Headbasiert	Vor Beginn eines Bereichs	Geringe Latenz, minimaler Aufwand	Beispiel für gewünschte Ablaufverfolgungen, einschließlich Fehlern
Tailbasiert	Nach dem Puffern von Bereichen basierend auf Zeit- oder Volumenschwellenwerten	Ermöglicht hoch selektive Kriterien für die Stichprobenentnahme für Ablaufverfolgungen	Höhere Kosten und zusätzliche Verarbeitungsverzögerung
Benutzerdefinierter Sampler für App Insights	Ende der Bereichserstellung	Abgleich der Ablaufverfolgungsvollständigkeit mit Effizienz	Erforderlich für Livemetriken und klassische API-Kompatibilität

Kann ich Abhängigkeiten, Anforderungen oder andere Telemetrietypen mit unterschiedlichen Raten erfassen?

Nein, das Stichprobenentnahmemodul wendet eine feste Rate für alle Telemetrietypen in einer Ablaufverfolgung an. Anforderungen, Abhängigkeiten und andere Spannweiten folgen dem gleichen Sampling-Prozentsatz. Um unterschiedliche Raten pro Telemetrietyp anzuwenden, sollten Sie die Verwendung von OpenTelemetry-Bereichsprozessoren oder (Transformationen zur Erfassungszeit) [opentelemetry-overview.md#telemetry-routing] in Betracht ziehen.

Wie gibt der benutzerdefinierte Sampler von Application Insights Samplingentscheidungen weiter?

Der benutzerdefinierte Sampler "Application Insights" verteilt Samplingentscheidungen standardmäßig mithilfe des W3C Trace Context-Standards. Mit diesem Standard können Samplingentscheidungen zwischen Diensten fließen. Doch da das Stichprobenentnahmemodul Entscheidungen zur Stichprobenentnahme am Ende der Bereichserstellung trifft (nach dem Aufruf der nachgelagerten Dienste), sind die Stichprobeninformationen in der Verteilung unvollständig. Diese Einschränkung entspricht der W3C-Ablaufverfolgungskontextspezifikation, aber nachgeschaltete Dienste können diese verteilte Samplingentscheidung nicht zuverlässig verwenden.

Berücksichtigt der benutzerdefinierte Sampler von Application Insights die Samplingentscheidungen von vorgelagerten Diensten?

Nein, der benutzerdefinierte Sampler application Insights trifft immer eine unabhängige Samplingentscheidung, auch wenn der upstream-Dienst denselben Samplingalgorithmus verwendet. Samplingentscheidungen von Upstream-Diensten, einschließlich derjenigen, die W3C Trace Context Headers verwenden, beeinflussen die Entscheidung des nachgeschalteten Diensts nicht. Die Stichprobenentnahme basiert jedoch auf einem Hash der Ablaufverfolgungs-ID, um die Vollständigkeit der Ablaufverfolgung sicherzustellen. Um die Konsistenz zu verbessern und die Wahrscheinlichkeit fehlerhafter Ablaufverfolgungen zu verringern, konfigurieren Sie alle Komponenten im System so, dass sie dasselbe Stichprobenentnahmemodul und dieselbe Rate für die Stichprobenentnahme verwenden.

Warum werden einige Ablaufverfolgungen auch bei Verwendung des benutzerdefinierten Application Insights-Samplers unvollständig angezeigt?

Es gibt mehrere Gründe, warum Spuren unvollständig sein können:

Verschiedene Knoten in einem verteilten System verwenden unterschiedliche Samplingansätze, die keine Entscheidungen koordinieren. Beispielsweise wendet ein Knoten headbasierte openTelemetry-Stichprobenentnahme an, und ein anderer Knoten wendet Stichprobenentnahme über den benutzerdefinierten Azure Monitor Sampler an.
Verschiedene Knoten werden auf unterschiedliche Samplingraten festgelegt, auch wenn beide denselben Sampling-Ansatz verwenden.
Sie legen Filterung, Stichprobenentnahme oder Ratenobergrenzen in der dienstseitigen Pipeline fest. Diese Konfiguration gibt zufällig Stichproben für Bereiche aus, ohne die Vollständigkeit der Ablaufverfolgung zu berücksichtigen.

Wenn eine Komponente eine headbasierte Stichprobenentnahme anwendet, ohne die Entscheidung zur Stichprobenentnahme (über W3C-Header für den Ablaufverfolgungskontext) zu verteilen, erstellen nachgelagerte Dienste unabhängig Stichproben zur Ablaufverfolgung, was zu verworfenen Bereichen führen kann. Daher sind einige Teile der Ablaufverfolgung nicht immer verfügbar, wenn sie in Application Insights angezeigt werden.

Wo erhalte ich weitere Informationen zum OpenTelemetry Sampling?

Weitere Informationen finden Sie unter Sampling in Azure Monitor Application Insights mit OpenTelemetry.

OpenTelemetry-Unterstützung und Feedback

Was ist OpenTelemetry?

Es ist ein Open-Source-Standard für die Observability. Weitere Informationen finden Sie unter OpenTelemetry.

Warum investiert Microsoft Azure Monitor in OpenTelemetry?

Microsoft investiert aus folgenden Gründen in OpenTelemetry:

Es ist anbieterneutral und bietet konsistente APIs und SDKs für alle Sprachen.
Wir glauben, dass OpenTelemetry im Laufe der Zeit Azure Monitor-Kunden ermöglichen wird, auch Anwendungen zu überwachen, die in anderen als den von uns unterstützten Sprachen geschrieben wurden.
Es erweitert die Datentypen, die Sie über eine Vielzahl von Instrumentierungsbibliotheken erfassen können.
OpenTelemetry-SDKs sind tendenziell bei hoher Skalierung leistungsstärker als ihre Vorgänger, die Application Insights-SDKs.
OpenTelemetry entspricht der Microsoft-Strategie zur Förderung von Open Source.

Wie ist der Status von OpenTelemetry?

Siehe OpenTelemetry Status.

Was ist die OpenTelemetry-Distribution von Azure Monitor?

Sie können sie sich als einfachen Wrapper vorstellen, der alle OpenTelemetry-Komponenten für eine erstklassige Erfahrung in Azure bündelt. Dieser Wrapper wird auch als Distribution in OpenTelemetry bezeichnet.

Warum sollte ich die OpenTelemetry-Distribution von Azure Monitor verwenden?

Die Verwendung der OpenTelemetry-Distribution von Azure Monitor hat gegenüber der nativen OpenTelemetry aus der Community mehrere Vorteile:

Reduziert den Aktivierungsaufwand
Unterstützt von Microsoft
Bietet Azure-spezifische Features, z. B.:
- Sampling kompatibel mit klassischen Application Insights SDKs
- Microsoft Entra-Authentifizierung
- Offlinespeicher und automatische Wiederholungsversuche
- Statsbeat
- Application Insights-Standardmetriken
- Erkennung von Ressourcenmetadaten zur automatischen Ausfüllung von Cloud-Rollennamen und Cloud-Rolleninstanzen in verschiedenen Azure-Umgebungen
- Livemetriken

Im Sinne von OpenTelemetry haben wir die Distribution so konzipiert, dass sie offen und erweiterbar ist. Zum Beispiel können Sie Folgendes hinzufügen:

Ein OpenTelemetry Protocol (OTLP)-Exporter und gleichzeitiges Senden an ein zweites Ziel
Andere Instrumentierungsbibliotheken, die nicht in der Distribution enthalten sind

Da die Distro eine OpenTelemetry-Verteilung bereitstellt, unterstützt die Distro alles, was von OpenTelemetry unterstützt wird. Sie können beispielsweise weitere Telemetrieprozessoren, Exporteure oder Instrumentierungsbibliotheken hinzufügen, wenn OpenTelemetry sie unterstützt.

Hinweis

Die Distro legt den Sampler auf einen benutzerdefinierten Sampler mit fester Rate für Application Insights fest. Sie können dies auf einen anderen Sampler umstellen, allerdings könnten dadurch einige der in der Distribution enthaltenen Funktionen deaktiviert werden. Weitere Informationen zum unterstützten Sampler finden Sie im Abschnitt Aktivieren des Samplings von Konfigurieren von Azure Monitor OpenTelemetry.

Für Sprachen ohne einen unterstützten eigenständigen OpenTelemetry-Exporter ist der Azure Monitor OpenTelemetry Distro die einzige derzeit unterstützte Methode zur Verwendung von OpenTelemetry mit Azure Monitor. Für Sprachen mit einem unterstützten eigenständigen OpenTelemetry-Exporter haben Sie je nach Telemetrieszenario die Möglichkeit, entweder den Azure Monitor OpenTelemetry Distro oder den entsprechenden eigenständigen OpenTelemetry-Exporter zu verwenden. Weitere Informationen finden Sie unter Wann sollte ich den OpenTelemetry-Exporter von Azure Monitor verwenden?.

Wie kann ich die OpenTelemetry-Distribution von Azure Monitor testen?

Sehen Sie sich unsere Aktivierungsdokumentation für .NET, Java, JavaScript (Node.js) und Python an.

Sollte ich OpenTelemetry oder das Application Insights-SDK verwenden?

Wir empfehlen die Verwendung der Azure Monitor OpenTelemetry Distro für neue Projekte, wenn ihre Funktionen ihren Überwachungsanforderungen entsprechen. OpenTelemetry ist ein Branchenstandardframework, das die plattformübergreifende Observability verbessert und einen standardisierten Ansatz für die Telemetriesammlung bietet.

Die Application Insights-SDKs bieten jedoch weiterhin bestimmte Funktionen, die in OpenTelemetry noch nicht vollständig automatisiert sind, einschließlich:

Automatische Abhängigkeitsnachverfolgung – OpenTelemetry unterstützt die Abhängigkeitsnachverfolgung, aber einige Abhängigkeiten erfordern eine zusätzliche Konfiguration im Vergleich zur automatischen Nachverfolgung, die in Application Insights-SDKs verfügbar ist.
Benutzerdefinierte Telemetrietypen, wie z. B. AvailabilityTelemetry und PageViewTelemetry – OpenTelemetry verfügt nicht über direkte Entsprechungen. Ähnliche Funktionen können über manuelle Instrumentierung implementiert werden.
Telemetrieprozessoren und Initialisierer – OpenTelemetry verfügt über Prozessoren und Span-Prozessoren, aber sie ersetzen Application Insights Telemetrieprozessoren und Initialisierer nicht vollständig in allen Szenarien.
Erweiterte Metriksammlung – Während OpenTelemetry über ein starkes Metriksystem verfügt, erfordern einige integrierte Metriken aus Application Insights-SDKs manuelle Einrichtung in OpenTelemetry.

OpenTelemetry bietet auch Vorteile gegenüber den Application Insights SDKs, darunter:

Bessere Standardisierung über Plattformen hinweg
Ein breiteres Ökosystem von Instrumentierungsbibliotheken
Mehr Flexibilität bei der Datenerfassung und -verarbeitung
Verbesserte Anbieterneutralität, obwohl Azure Monitor OpenTelemetry Distro weiterhin für Azure optimiert ist.

Die OpenTelemetry-Integration von Azure Monitor entwickelt sich kontinuierlich weiter, und Microsoft verbessert weiterhin seine Funktionen. Wenn Sie einen Übergang in Betracht ziehen, bewerten Sie sorgfältig, ob OpenTelemetry derzeit Ihre Observability-Anforderungen erfüllt oder ob das Application Insights SDK für Ihre Anforderungen besser geeignet ist.

Wann sollte ich den OpenTelemetry-Exporter von Azure Monitor verwenden?

Für ASP.NET Core, Java, Node.js und Python empfehlen wir die Verwendung der Azure Monitor OpenTelemetry Distro. Mit nur einer einzigen Codezeile können Sie loslegen.

Für alle anderen .NET-Szenarien, einschließlich klassischem ASP.NET, Konsolenanwendungen, Windows Forms (WinForms) usw., empfehlen wir die Verwendung des .NET Azure Monitor OpenTelemetry-Exporters: Azure.Monitor.OpenTelemetry.Exporter.

Für komplexere Python-Telemetrieszenarien, die eine erweiterte Konfiguration erfordern, empfehlen wir die Verwendung des Python Azure Monitor OpenTelemetry-Exporters.

Wie lautet der aktuelle Releasestatus der Features in der OpenTelemetry-Distribution von Azure Monitor?

Im folgenden Diagramm ist die Unterstützung der OpenTelemetry-Funktion für jede Sprache aufgeschlüsselt.

Merkmal	.NETTO	Node.js	Python	Java
Verteilte Ablaufverfolgung	✅	✅	✅	✅
Benutzerdefinierte Metriken	✅	✅	✅	✅
Standardmetriken	✅	✅	✅	✅
Stichprobenerstellung mit festem Prozentsatz	✅	✅	✅	✅
Offlinespeicherung und automatische Wiederholungen	✅	✅	✅	✅
Ausnahmeberichterstattung	✅	✅	✅	✅
Protokollerfassung	✅	⚠️	✅	✅
Benutzerdefinierte Ereignisse	⚠️	⚠️	⚠️	✅
Microsoft Entra-Authentifizierung	✅	✅	✅	✅
Livemetriken	✅	✅	✅	✅
Filtern von Livemetriken	✅	❌	❌	❌
Erkennen des Ressourcenkontexts für VM/VMSS und App Service	✅	❌	✅	✅
Erkennen des Ressourcenkontexts für Azure Kubernetes Service (AKS) und Funktionen	❌	❌	❌	✅
Verfügbarkeitstestereignisse, die mit der API zum Nachverfolgen der Verfügbarkeit (Track Availability-API) generiert werden	❌	❌	❌	✅
Filtern von Anforderungen, Abhängigkeiten, Protokollen und Ausnahmen nach anonymer Benutzer-ID und synthetischer Quelle	❌	❌	❌	✅
Filtern von Abhängigkeiten, Protokollen und Ausnahmen nach Vorgangsname	❌	❌	❌	✅
Adaptive Stichprobenerstellung	❌	❌	❌	✅
.NET-Profiler	⚠️	❌	❌	⚠️
Momentaufnahmedebugger	❌	❌	❌	❌

Schlüssel

✅: Dieses Feature steht allen Kunden mit formellem Support zur Verfügung.
⚠: Dieses Feature ist als Public Preview (öffentliche Vorschau) verfügbar. Siehe Ergänzende Nutzungsbedingungen für Microsoft Azure-Vorschauversionen.
❌ Dieses Feature ist nicht verfügbar oder nicht anwendbar.

Kann OpenTelemetry für Webbrowser verwendet werden?

Ja, aber wir empfehlen es nicht, und Azure unterstützt es nicht. OpenTelemetry JavaScript ist in hohem Maße für Node.js optimiert. Stattdessen wird empfohlen, das Application Insights JavaScript SDK zu verwenden.

Wann können wir damit rechnen, dass das OpenTelemetry SDK für die Verwendung in Webbrowsern verfügbar sein wird?

Für das OpenTelemetry-Web-SDK gibt es keine festgelegte Verfügbarkeitszeitachse. Wir sind wahrscheinlich noch einige Jahre von einem Browser-SDK entfernt, das eine brauchbare Alternative zum Application Insights JavaScript-SDK wäre.

Kann ich OpenTelemetry heute in einem Webbrowser testen?

Die OpenTelemetry Web Sandbox ist ein Fork, mit dem OpenTelemetry in einem Browser funktioniert. Es ist aber noch nicht möglich, Telemetriedaten an Application Insights zu senden. Das SDK definiert keine allgemeinen Clientereignisse.

Wird die Ausführung von Application Insights zusammen mit Agents von Mitbewerbern wie AppDynamics, DataDog und NewRelic unterstützt?

Wir haben nicht vor, diese Praxis zu testen oder zu unterstützen, obwohl unsere Distributionen es Ihnen ermöglichen, gleichzeitig neben Azure Monitor einen OTLP-Endpunkt zu exportieren.

Kann ich in Produktionsumgebungen die Previewfunktionen verwenden?

Wir raten davon ab. Siehe Ergänzende Nutzungsbedingungen für Microsoft Azure-Vorschauversionen.

Was ist der Unterschied zwischen manueller und automatischer Instrumentierung?

Weitere Informationen finden Sie in der OpenTelemetry-Übersicht.

Kann ich den OpenTelemetry-Collector verwenden?

Einige Kunden verwenden den OpenTelemetry-Collector als Agent-Alternative, obwohl Microsoft einen Agent-basierenden Ansatz für die Anwendungsüberwachung noch nicht offiziell unterstützt. In der Zwischenzeit wurde von der Open-Source-Community ein Azure Monitor-Exporter für den OpenTelemetry-Collector bereitgestellt, der von einigen Kunden zum Senden von Daten an Azure Monitor Application Insights verwendet wird. Dies wird von Microsoft nicht unterstützt.

Worin besteht der Unterschied zwischen OpenCensus und OpenTelemetry?

OpenCensus ist der Vorgänger von OpenTelemetry. Mit Hilfe von Microsoft wurden OpenTracing und OpenCensus zusammengeführt, um OpenTelemetry als einen einzigen Observabilitätsstandard für die Welt zu schaffen. Das aktuelle für die Produktion empfohlene Python SDK für Azure Monitor basiert auf OpenCensus. Microsoft hat sich verpflichtet, Azure Monitor auf der Grundlage von OpenTelemetry zu entwickeln.

Warum sehe ich in Grafana "Status 500. Können Ablaufverfolgungsereignisse nicht mithilfe der Ablaufverfolgungsschnellansicht visualisiert werden"?

Sie könnten versuchen, unformatierte Textprotokolle anstelle von OpenTelemetry-Ablaufverfolgungen zu visualisieren.

In Application Insights speichert die Tabelle „Traces“ Rohtextprotokolle zu Diagnosezwecken. Sie helfen bei der Identifizierung und Korrelation von Traces im Zusammenhang mit Benutzeranforderungen, anderen Ereignissen und Ausnahmeberichten. Die Tabelle „Traces“ trägt jedoch nicht direkt zur End-to-End-Transaktionsansicht (Wasserfalldiagramm) in Visualisierungstools wie Grafana bei.

Mit der zunehmenden Einführung von Cloud-nativen Verfahren entwickelt sich auch die Telemetrieerfassung und -terminologie weiter. OpenTelemetry wurde zu einem Standard für die Erfassung und Instrumentierung von Telemetriedaten. In diesem Zusammenhang bekam der Begriff „Traces“ eine neue Bedeutung. Anstelle von Rohdaten beziehen sich „Traces“ in OpenTelemetry auf eine umfassendere, strukturierte Form der Telemetrie, die sogenannte Spans umfasst, welche einzelne Arbeitseinheiten darstellen. Diese Spans sind entscheidend für die Erstellung von detaillierten Transaktionsansichten, die eine bessere Überwachung und Diagnose von Cloud-nativen Anwendungen ermöglichen.

Wie soll ich Blazor Apps instrumentieren?

Um eine Blazor-App zu instrumentieren, identifizieren Sie zuerst das Hostingmodell. Blazor Server unterstützt vollständige OpenTelemetry-basierte Instrumentierung. Blazor WebAssembly wird im Browser ausgeführt und unterstützt eingeschränkte Instrumentierung über JavaScript.

Wo erhalte ich weitere Informationen zum OpenTelemetry-Support und Feedback?

Weitere Informationen finden Sie unter OpenTelemetry Support und Feedback für Application Insights.

Übersichtsdashboard

Kann ich mehr als 30 Tage an Daten anzeigen?

Derzeit gibt es ein Limit von 30 Tagen, in denen Daten in einem Dashboard angezeigt werden.

Im Dashboard wird ein Fehler "Ressource nicht gefunden" angezeigt.

Wenn Sie Ihre Application Insights-Instanz verschieben oder umbenennen, kann ein „Ressource nicht gefunden“-Fehler auftreten.

Um dieses Verhalten zu umgehen, löschen Sie das Standarddashboard, und wählen Sie das Anwendungsdashboard erneut aus, um ein neues zu erstellen.

Wo erhalte ich weitere Informationen zum Übersichtsdashboard?

Weitere Informationen finden Sie unter Application Insights-Übersichtsdashboard.

Telemetriekanäle

Garantiert der Application Insights-Kanal die Übermittlung von Telemetriedaten? Wenn nicht, in welchen Szenarien können Telemetriedaten verloren gehen?

Die kurze Antwort ist, dass keiner der integrierten Kanäle als Transaktionstyp die Übermittlung von Telemetriedaten an das Back-End garantiert. ServerTelemetryChannel bietet im Vergleich zu InMemoryChannel eine zuverlässigere Übermittlung, führt aber auch nur den bestmöglichen Versuch durch, Telemetriedaten zu senden. Telemetriedaten können in verschiedenen Situationen verloren gehen. Dazu gehören diese häufigen Szenarien:

Elemente im Arbeitsspeicher gehen verloren, wenn die Anwendung abstürzt.
Telemetriedaten gehen bei länger andauernden Netzwerkproblemen verloren. Telemetriedaten werden bei Netzwerkausfällen oder bei Auftreten Problemen mit dem Application Insights-Back-End auf dem lokalen Datenträger gespeichert. Allerdings werden Elemente verworfen, die älter als 48 Stunden sind.
Die Standardspeicherorte auf dem Datenträger zum Speichern von Telemetriedaten unter Windows sind %LOCALAPPDATA% oder %TEMP%. Diese Speicherorte befinden sich normalerweise lokal auf dem Computer. Wenn die Anwendung physisch von einem Speicherort an einen anderen migriert, gehen alle Telemetriedaten verloren, die am ursprünglichen Speicherort gespeichert sind.
In Azure-Web-Apps unter Windows ist der Standardspeicherort auf dem Datenträger „D:\local\LocalAppData“. Dieser Speicherort ist nicht permanent. Bei App-Neustarts, Skalierungen und ähnlichen Vorgängen werden die dort gespeicherten Telemetriedaten gelöscht, was zu einem Verlust dieser Daten führt. Sie können die Standardeinstellung überschreiben und eine Speicherung an einem permanenten Speicherort wie „D:\home“ angeben. Solche permanenten Speicherorte basieren jedoch auf Remotespeicher und können daher langsam sein.

Es ist zwar weniger wahrscheinlich, aber dennoch möglich, dass der Kanal doppelte Telemetrieelemente verursacht. Dieses Verhalten tritt dann auf, wenn ServerTelemetryChannel aufgrund eines Netzwerkfehlers/-timeouts einen erneuten Versuch unternimmt, obwohl die Telemetriedaten an das Back-End übermittelt wurden, die Antwort aber aufgrund von Netzwerkproblemen verloren ging oder ein Timeout auftrat.

Kann ServerTelemetryChannel auf anderen Systemen als Windows verwendet werden?

Obwohl der Name des Pakets und des Namespace „WindowsServer“ beinhaltet, wird dieser Kanal auf anderen Systemen als Windows mit folgender Ausnahme unterstützt. Auf anderen Systemen als Windows erstellt der Kanal standardmäßig keinen lokalen Speicherordner. Sie müssen einen lokalen Speicherordner erstellen und den Kanal für die Verwendung dieses Ordners konfigurieren. Nachdem die lokale Speicherung konfiguriert wurde, funktioniert der Kanal auf allen Systemen gleich.

Hinweis

Ab Version 2.15.0-beta3 wird nun automatisch lokaler Speicher für Linux, Mac und Windows erstellt. Für Nicht-Windows-Systeme erstellt das SDK automatisch einen lokalen Speicherordner auf Grundlage der folgenden Logik:

${TMPDIR}: Wenn die Umgebungsvariable ${TMPDIR} festgelegt ist, wird dieser Speicherort verwendet.
/var/tmp: Wenn der vorherige Speicherort nicht vorhanden ist, versuchen wir /var/tmp.
/tmp: Wenn beide vorherige Speicherorte nicht vorhanden sind, versuchen wir tmp.
Wenn keiner dieser Speicherorte vorhanden ist, wird kein lokaler Speicher erstellt, wodurch eine manuelle Konfiguration weiterhin erforderlich ist. Vollständige Implementierungsdetails finden Sie in diesem GitHub-Repository.

Erstellt das SDK einen temporären lokalen Speicher? Werden die Daten beim Speichern verschlüsselt?

Das SDK speichert Telemetrieelemente bei Netzwerkproblemen oder Drosselung im lokalen Speicher. Diese Daten werden nicht lokal verschlüsselt.

Bei Windows-Systemen erstellt das SDK automatisch einen temporären lokalen Ordner im Verzeichnis %TEMP% oder %LOCALAPPDATA% und schränkt den Zugriff auf Administratoren und den aktuellen Benutzer ein.

Bei anderen Systemen als Windows wird vom SDK kein lokaler Speicher automatisch erstellt, sodass standardmäßig keine Daten lokal gespeichert werden.

Hinweis

Ab Version 2.15.0-beta3 wird nun automatisch lokaler Speicher für Linux, Mac und Windows erstellt.

Sie können selbst ein Speicherverzeichnis erstellen und den Kanal für dessen Verwendung konfigurieren. In diesem Fall müssen Sie sicherstellen, dass das Verzeichnis gesichert ist. Lesen Sie weitere Informationen zum Datenschutz.

Wo erhalte ich weitere Informationen zu Telemetriekanälen?

Weitere Informationen finden Sie unter Telemetriekanäle in Application Insights.

Transaktionssuche

Wie viele Daten werden beibehalten?

Entsprechende Informationen finden Sie unter Zusammenfassung der Grenzwerte.

Wie kann ich die POST-Daten in meinen Serveranforderungen anzeigen?

POST-Daten werden nicht automatisch protokolliert. Sie können jedoch TrackTrace oder Protokollaufrufe verwenden. Fügen Sie die POST-Daten in den "message"-Parameter ein. Sie können nicht nach der Nachricht wie nach Eigenschaften filtern, aber die Größenbeschränkung ist höher.

Warum gibt meine Azure Functions-Suche keine Ergebnisse zurück?

Azure Functions protokolliert keine URL-Abfragezeichenfolgen.

Wo erhalte ich weitere Informationen zur Transaktionssuche?

Weitere Informationen finden Sie unter Transaktionssuche und -diagnose.

Transaktionsdiagnose

Warum wird eine einzelne Komponente im Diagramm angezeigt, und die anderen Komponenten werden nur als externe Abhängigkeiten ohne Details angezeigt?

Mögliche Ursachen:

Sind die anderen Komponenten mit Application Insights instrumentiert?
Verwenden sie das neueste stabile Application Insights-SDK?
Wenn es sich bei diesen Komponenten um separate Application Insights-Ressourcen handelt, prüfen Sie, ob Sie den erforderlichen Zugriff haben. Wenn Sie Zugriff haben und die Komponenten mit den neuesten Application Insights-SDKs instrumentiert sind, informieren Sie uns über den Feedbackkanal in der oberen rechten Ecke.

Ich sehe doppelte Zeilen für die Abhängigkeiten. Ist dieses Verhalten zu erwarten?

Zurzeit zeigen wir den ausgehenden Abhängigkeitsaufruf separat von der eingehenden Anforderung an. Normalerweise sehen die beiden Aufrufe identisch aus, lediglich der Wert für die Dauer unterscheidet sich aufgrund des Netzwerk-Roundtrips. Das führende Symbol und die unterschiedliche Gestaltung der Balken für die Dauer erleichtern die Unterscheidung zwischen ihnen. Finden Sie diese Darstellung der Daten verwirrend? Senden Sie uns Ihr Feedback!

Treten Uhrabweichungen über verschiedene Komponenteninstanzen hinweg auf?

Die Zeitachsen im Transaktionsdiagramm gleichen Uhrabweichungen aus. Sie können die genauen Zeitstempel im Detailbereich oder mithilfe von Log Analytics anzeigen.

Warum fehlen auf der neuen Benutzeroberfläche die meisten der zugehörigen Elementabfragen?

Dieses Verhalten ist beabsichtigt. Alle verwandten Elemente sind komponentenübergreifend bereits auf der linken Seite im oberen und unteren Abschnitt verfügbar. Die neue Benutzeroberfläche weist zwei zugehörige Elemente auf, die von der linken Seite nicht abgedeckt werden: die gesamte Telemetrie fünf Minuten vor und nach dem Ereignis und die Benutzerzeitachse.

Gibt es eine Möglichkeit, weniger Ereignisse pro Transaktion anzuzeigen, wenn ich das Application Insights JavaScript SDK verwende?

In der Transaktionsdiagnoseerfahrung werden alle Telemetriedaten in einem einzelnen Vorgang angezeigt, der eine Vorgangs-ID freigibt. Standardmäßig erstellt das Application Insights SDK für JavaScript einen neuen Vorgang für jede eindeutige Seitenansicht. In einer Single-Page-Anwendung (SPA) wird nur ein Seitenansichtsereignis generiert, eine einzelne Vorgangs-ID wird für alle generierten Telemetriedaten verwendet. Dies kann dazu führen, dass viele Ereignisse mit demselben Vorgang korreliert werden.

In diesen Szenarien können Sie die automatische Routenverfolgung verwenden, um automatisch neue Vorgänge für die Navigation in Ihrer SPA (Single-Page-App) zu erstellen. Sie müssen enableAutoRouteTracking aktivieren, damit bei jeder Aktualisierung der URL-Route (logische Seitenansicht) eine Seitenansicht generiert wird. Wenn Sie die Vorgangs-ID manuell aktualisieren möchten, rufen Sie appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId() auf. Das manuelle Auslösen eines PageView-Ereignisses setzt ebenfalls die Vorgangs-ID zurück.

Warum ergibt die Addition der Transaktionsdetaildauern nicht die Dauer der Top-Anforderung?

Zeiten, die nicht im Gantt-Diagramm erläutert werden, sind Zeiten, die nicht durch eine nachverfolgte Abhängigkeit abgedeckt sind. Dieses Problem kann auftreten, weil externe Anrufe weder automatisch noch manuell instrumentiert wurden. Es kann auch auftreten, weil die benötigte Zeit nicht aufgrund eines externen Aufrufs, sondern während der Verarbeitung aufgebracht wurde.

Wenn alle Aufrufe instrumentiert wurden, ist „in Bearbeitung“ die wahrscheinliche Grundursache für die aufgewendete Zeit. Ein nützliches Tool für die Diagnose des Prozesses ist der .NET-Profiler.

Was geschieht, wenn beim Navigieren in Application Insights im Azure-Portal die Meldung "Fehler beim Abrufen von Daten" angezeigt wird?

Dieser Fehler zeigt an, dass der Browser eine erforderliche API nicht aufrufen konnte, oder dass die API eine Fehlerantwort zurückgegeben hat. Um das Verhalten zu behandeln, öffnen Sie ein InPrivate-Fenster im Browser, und deaktivieren Sie alle Browsererweiterungen, die ausgeführt werden. Identifizieren Sie dann, ob Sie das Portalverhalten immer noch reproduzieren können. Wenn der Portalfehler weiterhin auftritt, versuchen Sie, dies mit anderen Browsern oder anderen Computern zu testen, untersuchen Sie DNS- oder andere netzwerkbezogene Probleme des Clientcomputers, auf dem die API-Aufrufe fehlschlagen. Wenn der Portalfehler weiterhin auftritt und eine weitere Untersuchung erforderlich ist, erfassen Sie eine Browsernetzwerkverfolgung, während Sie das unerwartete Portalverhalten reproduzieren, und öffnen Sie einen Supportfall über das Azure-Portal.

Wo erhalte ich weitere Informationen zur Transaktionsdiagnose?

Weitere Informationen finden Sie unter Transaktionssuche und -diagnose.

Nutzungsanalyse

Stellt das anfängliche Ereignis das erste Auftreten des Ereignisses in einer Sitzung dar, oder jedes Mal, wenn es in einer Sitzung vorkommt?

Das Ausgangsereignis in der Visualisierung stellt nur die erste Instanz eines Seitenaufrufs oder benutzerdefinierten Ereignisses dar, den bzw. das ein Benutzer während einer Sitzung gesendet hat. Wenn Benutzer das Ausgangsereignis mehrmals in einer Sitzung senden können, zeigt die Spalte Step 1 (Schritt 1) nur das Verhalten von Benutzern nach der ersten Instanz eines Ausgangsereignisses (nicht alle Instanzen).

Einige Knoten in meiner Visualisierung sind zu allgemein gehalten. Wie erhalte ich ausführlichere Knoten?

Verwenden Sie im Menü Bearbeiten die Optionen unter Teilen nach:

Wählen Sie das Ereignis, das Sie unterteilen möchten, im Menü Ereignis aus.
Wählen Sie im Menü Dimension eine Dimension aus. Wenn Sie beispielsweise über ein Ereignis Button Clicked (Auf Schaltfläche geklickt) verfügen, können Sie es mit der benutzerdefinierten Eigenschaft Button Name (Schaltflächenname) versuchen.

Ich habe eine Kohorte von Benutzern aus einem bestimmten Land/einer bestimmten Region definiert. Wenn ich diese Kohorte im Tool „Benutzer“ mit dem Ergebnis durch Festlegen eines Filters für dieses Land/diese Region vergleiche, warum sehe ich unterschiedliche Ergebnisse?

Kohorten und Filter unterscheiden sich. Angenommen, Sie haben eine Kohorte von Benutzern aus Großbritannien (definiert wie im vorherigen Beispiel), und Sie vergleichen deren Ergebnisse mit dem Festlegen des Filters auf Country or region = United Kingdom:

Für die Kohortenversion werden alle Ereignisse von Benutzern angezeigt, die im aktuellen Zeitbereich mindestens ein Ereignis aus Großbritannien gesendet haben. Wenn Sie nach Land oder Region aufteilen, werden wahrscheinlich viele Länder und Regionen angezeigt.
Für die Filterversion werden nur Ereignisse aus Großbritannien angezeigt. Wenn Sie nach Land oder Region aufteilen, sehen Sie nur Großbritannien.

Wie kann ich die Daten in unterschiedlichen Auflösungen anzeigen (täglich, monatlich oder wöchentlich)?

Sie können den Filter Date Grain (Datumsauflösung) auswählen, um die Auflösung zu ändern. Der Filter ist auf allen Dimensionsregisterkarten verfügbar.

Wie greife ich auf Erkenntnisse über meine Anwendung zu, die nicht in den HEART-Arbeitsmappen verfügbar sind?

Sie können die Daten, die als Quelle der HEART-Arbeitsmappe dienen, tiefer analysieren, wenn die visuellen Elemente nicht alle Ihre Fragen beantworten. Um diese Aufgabe durchzuführen, wählen Sie im Abschnitt Überwachung in Application Insights Protokolle aus und führen Sie eine Abfrage der customEvents-Tabelle durch. Einige der Klickanalyse-Attribute sind im customDimensions-Feld enthalten.

Hier sehen Sie eine Beispielabfrage:

customEvents
| where isnotnull(customDimensions.actionType)
| extend parentid=tostring(customDimensions.parenId),
pagename=tostring(customDimensions.pageName),
actiontype=tostring(customDimensions.actionType)
| project actiontype,parentid,pagename,
user_AuthenticatedId,user_Id,session_Id,itemType,timestamp

Weitere Informationen zu Protokollen in Azure Monitor finden Sie unter Übersicht über Azure Monitor-Protokolle.

Kann ich visuelle Elemente in der Arbeitsmappe bearbeiten?

Ja. Informationen zum Bearbeiten von Arbeitsmappenvorlagen finden Sie unter Azure Workbooks-Vorlagen.

Wo erhalte ich weitere Informationen zur Nutzungsanalyse?

Weitere Informationen finden Sie unter Verwendungsanalyse mit Application Insights.

Worker Service-Anwendungen

Welches Paket sollte ich verwenden?

Szenario für .NET Core-Apps	Paket
Ohne HostedServices	WorkerService
Mit HostedServices	AspNetCore (nicht WorkerService)
Mit HostedServices, nur Überwachung von HostedServices	WorkerService (seltenes Szenario)

Kann in HostedServices in einer .NET Core-App mit dem AspNetCore-Paket TelemetryClient eingeschleust werden?

Ja, die Konfiguration wird für den Rest der Webanwendung freigegeben.

Wie kann ich Telemetriedaten nachverfolgen, die nicht automatisch erfasst werden?

Rufen Sie eine Instanz von TelemetryClient ab. Verwenden Sie dazu die Konstruktorinjektion, und rufen Sie die erforderliche TrackXXX()-Methode auf. Es wird nicht empfohlen, neue TelemetryClient-Instanzen zu erstellen. Eine Singletoninstanz von TelemetryClient ist bereits im Container DependencyInjection registriert, der TelemetryConfiguration für alle sonstigen Telemetriedaten verwendet. Sie sollten nur dann eine neue TelemetryClient-Instanz erstellen, wenn für diese eine Konfiguration erforderlich ist, die sich von der für die sonstigen Telemetriedaten unterscheidet.

Kann ich die Visual Studio-IDE für das Onboarding von Application Insights in ein Workerdienstprojekt verwenden?

Das Onboarding mit der Visual Studio-IDE wird derzeit nur für ASP.NET-/ASP.NET Core-Anwendungen unterstützt. Dieses Dokument wird aktualisiert, wenn Visual Studio das Onboarding von Workerdienstanwendungen unterstützt.

Kann ich die Application Insights-Überwachung mithilfe von Tools wie Azure Monitor Application Insights-Agent (früher Statusmonitor v2) aktivieren?

Nein. Der Azure Monitor Application Insights-Agent unterstützt derzeit nur .NET.

Werden alle Features unterstützt, wenn ich meine Anwendung unter Linux ausführe?

Ja. Die Featureunterstützung für dieses SDK ist auf allen Plattformen gleich. Es gelten jedoch die folgenden Ausnahmen:

Leistungsindikatoren werden nur unter Windows unterstützt, mit Ausnahme der Anzeige von Prozess-CPU/Arbeitsspeicher in Livemetriken.

Auch wenn ServerTelemetryChannel standardmäßig aktiviert ist, wird über den Kanal bei der Anwendungsausführung unter Linux oder macOS nicht automatisch ein lokaler Speicherordner erstellt, um die Telemetriedaten bei Netzwerkproblemen vorübergehend zu speichern. Aufgrund dieser Einschränkung gehen Telemetriedaten verloren, wenn vorübergehende Netzwerk- oder Serverprobleme auftreten. Sie können das Problem umgehen, indem Sie einen lokalen Ordner für den Kanal konfigurieren:

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

     public void ConfigureServices(IServiceCollection services)
     {
         // The following will configure the channel to use the given folder to temporarily
         // store telemetry items during network or Application Insights server issues.
         // User should ensure that the given folder already exists
         // and that the application has read/write permissions.
         services.AddSingleton(typeof(ITelemetryChannel),
                                 new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
         services.AddApplicationInsightsTelemetryWorkerService();
     }

Wo erhalte ich weitere Informationen zu Worker Service-Anwendungen?

Weitere Informationen finden Sie unter Application Insights for Worker Service-Anwendungen (nicht HTTP-Anwendungen).

Teilen über

Häufig gestellte Fragen zu Application Insights – Häufig gestellte Fragen

Überblick

Wie instrumentiere ich eine Anwendung?

Wie verwende ich Application Insights?

Welche Telemetriedaten erfasst Application Insights?

Wie viele Application Insights-Ressourcen sollte ich bereitstellen?

Wie kann ich Application Insights-Ressourcen mithilfe von PowerShell verwalten?

Wie kann ich Application Insights-Telemetriedaten abfragen?

Kann ich Telemetriedaten an das Application Insights-Portal senden?

Wie lange dauert das Sammeln von Telemetriedaten?

Wie handhabt Application Insights Datensammlung, -aufbewahrung, -speicherung und -schutz?

Sammlung

Aufbewahrung und Speicherung

Datenschutz

Wie funktioniert das Preismodell von Application Insights?

Fallen Gebühren für die Datenübertragung zwischen einer Azure-Web-App und Application Insights an?

Fallen Netzwerkkosten an, wenn meine Application Insights-Ressource eine Azure-Ressource (d. h. Telemetrieproduzent) in einer anderen Region überwacht?

Welche TLS-Versionen werden unterstützt?

Wo erhalte ich weitere Informationen zu Application Insights?

Application Insights-API für benutzerdefinierte Ereignisse und Metriken

Warum fehlen mir Telemetriedaten?

Welche Ausnahmen können Track_()-Aufrufe auslösen?

Gibt es eine REST-API zum Abrufen von Daten aus dem Portal?

Warum werden meine Aufrufe für benutzerdefinierte Ereignisse und Metrik-APIs ignoriert?

Warum sind die Zahlen in den Diagrammen „Suchen“ und „Metriken“ unterschiedlich?

Wie kann ich eine Warnung für ein Ereignis festlegen?

Wo erhalte ich weitere Informationen zur Application Insights-API für benutzerdefinierte Ereignisse und Metriken?

Bereitstellen des Application Insights-Agents für lokale Server

Unterstützt der Application Insights-Agent Proxy-Installationen?

Werden ASP.NET Core-Anwendungen in Application Insights Agent unterstützt?

Wie überprüfe ich, ob die Aktivierung erfolgreich war?

Erreichen von Proxy-Passthrough

Wo erhalte ich weitere Informationen zum Bereitstellen des Application Insights-Agents für lokale Server?

TLS-Unterstützung

Ermitteln, ob sich die TLS-Abschaltung auf Sie auswirkt

Wie kann ich sicherstellen, dass meine Ressourcen nicht betroffen sind?

Nach dem 1. Mai 2025, was ist das Verhalten für betroffene Ressourcen?

Welche Komponenten sind von der Veraltung betroffen?

Wo erhalte ich TLS-Unterstützung (Transport Layer Security)?

Wo erhalte ich weitere Informationen zur TLS-Unterstützung in Application Insights?

ASP.NET

Wie kann ich das SDK deinstallieren?

Beim Hinzufügen von Application Insights SDK automatisch erstellte Elemente

Wie kann ich die Telemetriekorrelation deaktivieren?

Wo erhalte ich weitere Informationen zur Verwendung von Application Insights mit ASP.NET?

ASP.NET Core-Anwendungen

Wird ASP.NET Core 3.1 in Application Insights unterstützt?

Wie kann ich Telemetriedaten nachverfolgen, die nicht automatisch erfasst werden?

Wie erfasse ich den Anforderungs- und Antworttext in meinen Telemetriedaten?

Wie passe ich die Sammlung von ILogger-Protokollen an?

Für einige Visual Studio-Vorlagen wurde die Erweiterungsmethode „UseApplicationInsights()“ in IWebHostBuilder verwendet, um Application Insights zu aktivieren. Ist diese Verwendung noch gültig?

Ich stelle meine ASP.NET Core-Anwendung in Web-Apps bereit. Sollte ich trotzdem die Application Insights-Erweiterung über Web-Apps aktivieren?

Kann ich die Application Insights-Überwachung mithilfe von Tools wie Azure Monitor Application Insights-Agent (früher Statusmonitor v2) aktivieren?

Werden alle Features unterstützt, wenn ich meine Anwendung unter Linux ausführe?

Wird dieses SDK für Worker-Dienste unterstützt?

Wie kann ich das SDK deinstallieren?

Was wird erstellt, wenn Sie das Application Insights SDK hinzufügen?

Wie kann ich die Telemetriekorrelation deaktivieren?

Wo erhalte ich weitere Informationen zur Verwendung von Application Insights für ASP.NET Core-Anwendungen?

ASP.NET Leistungsindikatoren

Worin besteht der Unterschied zwischen der Ausnahmerate und der Ausnahmenmetrik?

Wo erhalte ich weitere Informationen zu ASP.NET Leistungsindikatoren?

ASP.NET Ereignisindikatoren

Werden EventCounters in Livemetriken angezeigt?

Warum sehe ich keine Ereigniszähler, nachdem ich Application Insights im Azure Web App-Portal aktiviert habe?

Wo erhalte ich weitere Informationen zu ASP.NET Ereigniszählern?

Skalierungsgruppen für Azure-VMs und virtuelle Computer

Wie kann ich die clientseitige Überwachung für ASP.NET Core-Apps deaktivieren?

Wo erhalte ich weitere Informationen zur Verwendung von Application Insights für Azure-VMs und VM-Skalierungsgruppen?

Abhängigkeitsüberwachung

Wie meldet der automatische Abhängigkeitskollektor fehlgeschlagene Aufrufe an Abhängigkeiten?

Wie berechne ich die Erfassungslatenz für meine Abhängigkeitstelemetrie?

Wie ermittle ich die Uhrzeit, zu der der Abhängigkeitsaufruf initiiert wurde?

Umfasst die Abhängigkeitsnachverfolgung in Application Insights Protokollierungsantworttexte?

Wo erhalte ich weitere Informationen zur Abhängigkeitsnachverfolgung in Application Insights?

Verfügbarkeitstests

Kann ich Verfügbarkeitstests auf einem Intranetserver ausführen?

Was ist die Benutzer-Agent-Zeichenfolge für Verfügbarkeitstests?

Wo erhalte ich weitere Informationen zu Application Insights-Verfügbarkeitstests?