Die automatische Instrumentierung ermöglicht die Erfassung von Telemetriedaten über die Konfiguration, ohne dass der Code der Anwendung bearbeitet werden muss. Obwohl es bequemer ist, ist es weniger konfigurierbar. Es ist auch nicht in allen Sprachen verfügbar. Weitere Informationen finden Sie unter Unterstützte Umgebungen und Sprachen für die automatische Instrumentierung. Wenn die automatische Instrumentierung verfügbar ist, stellt sie die einfachste Möglichkeit dar, Azure Monitor Application Insights zu aktivieren.
Tipp
Derzeit ist die Microsoft Entra-Authentifizierung nicht mit automatischer Instrumentierung verfügbar. Wenn Sie die Microsoft Entra-Authentifizierung benötigen, müssen Sie die manuelle Instrumentierung verwenden.
Die manuelle Instrumentierung ist die Codierung gegen die Application Insights- oder OpenTelemetry-API. Im Kontext eines Benutzers bezieht sich dies typischerweise auf die Installation eines sprachspezifischen SDKs in einer Anwendung. Dies bedeutet, dass Sie die Updates für die neueste Paketversion selbst verwalten müssen. Sie können diese Option verwenden, wenn Sie benutzerdefinierte Abhängigkeitsaufrufe oder API-Aufrufe vornehmen müssen, die nicht standardmäßig mit automatischer Instrumentierung erfasst werden. Es gibt zwei Optionen für die manuelle Instrumentierung:
Obwohl wir OpenTelemetry als unsere zukünftige Richtung betrachten, haben wir keine Pläne, die Sammlung von Daten aus älteren SDKs zu beenden. Wir haben noch viel Weg vor uns, bevor unsere Azure OpenTelemetry-Distros Featureparität mit unseren Application Insights-SDKs erreichen. In vielen Fällen bleiben Kunden noch eine ganze Zeit lang bei der Verwendung von Application Insights-SDKs.
Wichtig
„Manuell“ bedeutet nicht, dass Sie komplexen Code schreiben müssen, um Spans für verteilte Ablaufverfolgung zu definieren, obwohl dies eine Option bleibt. Mit den in unsere Distributionen gepackten Instrumentierungsbibliotheken können sie Telemetriesignale mühelos über gängige Frameworks und Bibliotheken hinweg erfassen. Wir arbeiten aktiv daran, die beliebtesten Azure-Dienst-SDKs mithilfe von OpenTelemetry zu instrumentieren, damit diese Signale für Kunden verfügbar werden, die die OpenTelemetry-Distro von Azure Monitor verwenden.
Telemetriearten
Die Telemetrie, d. h. die zur Beobachtung Ihrer Anwendung gesammelten Daten, kann in drei Arten oder "Säulen" unterteilt werden:
Verteilte Ablaufverfolgung
Metriken
Protokolle
Eine vollständige Beobachtungsgeschichte umfasst alle drei Säulen, und Application Insights unterteilt diese Säulen weiter in Tabellen, die auf unserem Datenmodell basieren. Unsere Application Insights-SDKs oder Azure Monitor OpenTelemetry-Distros enthalten alles, was Sie für die Überwachung der Leistung von Anwendungen auf Azure benötigen. Die Installation der Distribution selbst ist kostenlos, Sie zahlen nur für die Daten, die Sie in Azure Monitor erfassen.
Es gibt zwei Möglichkeiten, Ihre Daten an Azure Monitor (oder einen anderen Anbieter) zu senden:
Über einen direkten Exporter
Über einen Agent
Ein direkter Exporter sendet Telemetriedaten prozessintern (aus dem Code der Anwendung) direkt an den Erfassungsendpunkt von Azure Monitor. Der Hauptvorteil dieser Methode liegt in der Einfachheit des Onboardings.
Die derzeit verfügbaren Application Insights-SDKs und Azure Monitor OpenTelemetry-Distros beruhen auf einem direkten Exporter.
Falls Sie planen, OpenTelemetry-Collector für Stichprobenentnahmen oder zusätzliche Datenverarbeitung zu verwenden, können Sie diese Funktionen möglicherweise in Azure Monitor integriert erhalten. Kundschaft, die zu arbeitsbereichsbasiertem Application Insights migriert ist, können von Transformationen zur Erfassungszeit profitieren. Befolgen Sie zum Aktivieren die Details im Tutorial und überspringen Sie dabei den Schritt, der zeigt, wie Sie eine Diagnoseeinstellung einrichten, da diese bei arbeitsbereichsorientiertem Application Insights bereits konfiguriert ist. Wenn Sie weniger als 50 % des Gesamtvolumens filtern, fallen keine zusätzlichen Kosten an. Ab 50 % fallen Kosten an, aber viel weniger als die Standardgebühr pro GB.
OpenTelemetry
Microsoft freut sich darauf, OpenTelemetry als die Zukunft der Telemetrie-Instrumentierung zu begrüßen. Sie, unsere Kunden, haben nach einer herstellerneutralen Instrumentierung gefragt, und wir freuen uns, mit der OpenTelemetry-Community zusammenzuarbeiten, um konsistente APIs und SDKs für verschiedene Sprachen zu erstellen.
Microsoft hat mit Projektbeteiligten von zwei zuvor beliebten Open-Source-Telemetrieprojekten, OpenCensus und OpenTracing, zusammengearbeitet. Gemeinsam haben wir dazu beigetragen, ein einzelnes Projekt zu erstellen: OpenTelemetry. OpenTelemetry umfasst Beiträge von allen wichtigen Cloud- und APM-Anbietern (Application Performance Management) und gehört zur Cloud Native Computing Foundation (CNCF). Microsoft ist Platinmitglied von CNCF.
Informationen zur Terminologie finden Sie im Glossar in den OpenTelemetry-Spezifikationen.
Einige ältere Begriffe in Application Insights sind aufgrund der Konvergenz der Branche zu OpenTelemetry verwirrend. In der folgenden Tabelle sind diese Unterschiede hervorgehoben. OpenTelemetry-Begriffe ersetzen Application Insights-Begriffe.
Azure Monitor Exporter verwendet EventSource für die interne Protokollierung. Die Exporterprotokolle sind für alle EventListener verfügbar, indem Sie sich für die Quelle anmelden, die OpenTelemetry-AzureMonitor-Exporter genannt wird. Schritte zur Problembehandlung finden Sie unter OpenTelemetry Troubleshooting auf GitHub.
Schritt 2: Testen der Konnektivität zwischen Ihrem Anwendungshost und dem Erfassungsdienst
Application Insights SDKs und -Agents senden Telemetriedaten, die als REST-Aufrufe unserer Erfassungsendpunkte erfasst werden sollen. Verwenden Sie cURL-Befehle oder unformatierte REST-Anforderungen von PowerShell, um die Konnektivität von Ihrem Webserver- oder Anwendungshostcomputer mit den Endpunkten des Aufnahmediensts zu testen. Ausführliche Informationen finden Sie unter Problembehandlung bei fehlender Anwendungstelemetrie in Azure Monitor Application Insights.
Bekannte Probleme
Die folgenden Elemente sind bekannte Probleme für die OpenTelemetry-Exporter von Azure Monitor:
Der Vorgangsname fehlt in der Abhängigkeitstelemetrie. Der fehlende Name des Vorgangs verursacht Fehler und wirkt sich negativ auf die Leistung der Registerkartenerfahrung aus.
Das Gerätemodell fehlt bei der Anforderungs- und Abhängigkeitstelemetrie. Das fehlende Gerätemodell wirkt sich negativ auf die Analyse der Gerätekohorten aus.
Schritt 1: Aktivieren der Diagnoseprotokollierung
Azure Monitor Exporter verwendet EventSource für die interne Protokollierung. Die Exporterprotokolle sind für alle EventListener verfügbar, indem Sie sich für die Quelle anmelden, die OpenTelemetry-AzureMonitor-Exporter genannt wird. Schritte zur Problembehandlung finden Sie unter OpenTelemetry Troubleshooting auf GitHub.
Schritt 2: Testen der Konnektivität zwischen Ihrem Anwendungshost und dem Erfassungsdienst
Application Insights SDKs und -Agents senden Telemetriedaten, die als REST-Aufrufe unserer Erfassungsendpunkte erfasst werden sollen. Verwenden Sie cURL-Befehle oder unformatierte REST-Anforderungen von PowerShell, um die Konnektivität von Ihrem Webserver- oder Anwendungshostcomputer mit den Endpunkten des Aufnahmediensts zu testen. Ausführliche Informationen finden Sie unter Problembehandlung bei fehlender Anwendungstelemetrie in Azure Monitor Application Insights.
Bekannte Probleme
Die folgenden Elemente sind bekannte Probleme für die OpenTelemetry-Exporter von Azure Monitor:
Der Vorgangsname fehlt in der Abhängigkeitstelemetrie. Der fehlende Name des Vorgangs verursacht Fehler und wirkt sich negativ auf die Leistung der Registerkartenerfahrung aus.
Das Gerätemodell fehlt bei der Anforderungs- und Abhängigkeitstelemetrie. Das fehlende Gerätemodell wirkt sich negativ auf die Analyse der Gerätekohorten aus.
Schritt 2: Testen der Konnektivität zwischen Ihrem Anwendungshost und dem Erfassungsdienst
Application Insights SDKs und -Agents senden Telemetriedaten, die als REST-Aufrufe unserer Erfassungsendpunkte erfasst werden sollen. Verwenden Sie cURL-Befehle oder unformatierte REST-Anforderungen von PowerShell, um die Konnektivität von Ihrem Webserver- oder Anwendungshostcomputer mit den Endpunkten des Aufnahmediensts zu testen. Ausführliche Informationen finden Sie unter Problembehandlung bei fehlender Anwendungstelemetrie in Azure Monitor Application Insights.
Bekannte Probleme
Wenn Sie die Application Insights-Clientbibliothek für die Installation aus einem Browser herunterladen, ist manchmal die heruntergeladene JAR-Datei beschädigt und ist etwa die Hälfte der Größe der Quelldatei. Wenn dieses Problem auftritt, laden Sie die JAR-Datei herunter, indem Sie den Befehl curl oder wget ausführen, wie in den folgenden Beispielbefehlsaufrufen gezeigt:
Der Beispielbefehl gilt für Application Insights für Java, Version 3.4.11. Informationen zur Versionsnummer und URL-Adresse der aktuellen Version von Application Insights für Java finden Sie unter https://github.com/microsoft/ApplicationInsights-Java/releases.
Die folgenden Schritte gelten für systemeigene Spring Boot-Anwendungen.
Schritt 1: Überprüfen der OpenTelemetry-Version
Möglicherweise erscheint beim Starten der Anwendung die folgende Meldung:
WARN c.a.m.a.s.OpenTelemetryVersionCheckRunner - The OpenTelemetry version is not compatible with the spring-cloud-azure-starter-monitor dependency.
The OpenTelemetry version should be <version>
In diesem Fall müssen Sie die OpenTelemetry Bills of Materials importieren, indem Sie die OpenTelemetry-Dokumentation im Spring Boot Starter befolgen.
Schritt 2: Aktivieren der Selbstdiagnose
Wenn etwas nicht wie erwartet funktioniert, können Sie die Selbstdiagnose auf Ebene DEBUG aktivieren, um einige Erkenntnisse zu erhalten. Legen Sie dazu mithilfe der Umgebungsvariablen APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL die Selbstdiagnosestufe auf ERROR, WARN, INFO, DEBUG oder TRACE fest.
Führen Sie den folgenden Befehl aus, um die Selbstdiagnose auf Ebene DEBUG beim Ausführen eines Docker-Containers zu aktivieren:
docker run -e APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL=DEBUG <image-name>
Hinweis
Ersetzen Sie <image-name> entsprechend durch den Namen des Docker-Image.
Informationen zum Haftungsausschluss von Drittanbietern
Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.
Schritt 1: Aktivieren der Diagnoseprotokollierung
Azure Monitor Exporter verwendet die OpenTelemetry-API-Protokollierung für interne Protokolle. Führen Sie zum Aktivieren des Loggers den folgenden Codeausschnitt aus:
Schritt 2: Testen der Konnektivität zwischen Ihrem Anwendungshost und dem Erfassungsdienst
Application Insights SDKs und -Agents senden Telemetriedaten, die als REST-Aufrufe unserer Erfassungsendpunkte erfasst werden sollen. Verwenden Sie cURL-Befehle oder unformatierte REST-Anforderungen von PowerShell, um die Konnektivität von Ihrem Webserver- oder Anwendungshostcomputer mit den Endpunkten des Aufnahmediensts zu testen. Ausführliche Informationen finden Sie unter Problembehandlung bei fehlender Anwendungstelemetrie in Azure Monitor Application Insights.
Bekannte Probleme
Die folgenden Elemente sind bekannte Probleme für die OpenTelemetry-Exporter von Azure Monitor:
Der Vorgangsname fehlt in der Abhängigkeitstelemetrie. Der fehlende Name des Vorgangs verursacht Fehler und wirkt sich negativ auf die Leistung der Registerkartenerfahrung aus.
Das Gerätemodell fehlt bei der Anforderungs- und Abhängigkeitstelemetrie. Das fehlende Gerätemodell wirkt sich negativ auf die Analyse der Gerätekohorten aus.
Der Datenbankservername fehlt im Abhängigkeitsnamen. Da der Datenbankservername nicht enthalten ist, aggregieren OpenTelemetry Exporters fälschlicherweise Tabellen mit demselben Namen auf verschiedenen Servern.
Schritt 1: Aktivieren der Diagnoseprotokollierung
Microsoft Azure Monitor Exporter verwendet die Python-Standardprotokollierungsbibliothek für die interne Protokollierung. OpenTelemetry-API und Azure Monitor Exporter-Protokolle werden einem Schweregrad von WARNING oder ERROR für unregelmäßige Aktivitäten zugewiesen. Der Schweregrad INFO wird für reguläre oder erfolgreiche Aktivitäten verwendet.
Standardmäßig legt die Python-Protokollierungsbibliothek den Schweregrad auf WARNING fest. Daher müssen Sie den Schweregrad ändern, um Protokolle unter diesem Schweregrad anzuzeigen. Der folgende Beispielcode zeigt, wie Protokolle aller Schweregradstufen in die Konsole und eine Datei ausgegeben werden:
Schritt 2: Testen der Konnektivität zwischen Ihrem Anwendungshost und dem Erfassungsdienst
Application Insights SDKs und -Agents senden Telemetriedaten, die als REST-Aufrufe unserer Erfassungsendpunkte erfasst werden sollen. Verwenden Sie cURL-Befehle oder unformatierte REST-Anforderungen von PowerShell, um die Konnektivität von Ihrem Webserver- oder Anwendungshostcomputer mit den Endpunkten des Aufnahmediensts zu testen. Ausführliche Informationen finden Sie unter Problembehandlung bei fehlender Anwendungstelemetrie in Azure Monitor Application Insights.
Schritt 3: Vermeiden doppelter Telemetrie
Doppelte Telemetrie wird häufig verursacht, wenn Sie mehrere Instanzen von Prozessoren oder Exportern erstellen. Stellen Sie sicher, dass Sie jeweils nur einen Exporteur und Prozessor für jede Telemetriesäule ausführen (Protokolle, Metriken und verteilte Ablaufverfolgung).
In den folgenden Abschnitten werden Szenarien beschrieben, die doppelte Telemetrie verursachen können.
Doppelte Ablaufverfolgungsprotokolle in Azure Functions
Wenn für jedes Ablaufverfolgungsprotokoll in Application Insights ein Paar Einträge angezeigt wird, haben Sie wahrscheinlich die folgenden Arten der Protokollierungsinstrumentation aktiviert:
Die systemeigene Protokollierungsinstrumentation in Azure Functions
Die azure-monitor-opentelemetry-Protokollierungsinstrumentation innerhalb der Verteilung
Um Duplizierungen zu verhindern, können Sie die Protokollierung der Verteilung deaktivieren, aber die systemeigene Protokollierungsinstrumentation in Azure Functions aktiviert lassen. Legen Sie dazu die Umgebungsvariable OTEL_LOGS_EXPORTER auf None fest.
Doppelte Telemetrie in Azure Functions „Always On“
Wenn die Einstellung Always On in Azure Functions auf On festgelegt ist, werden einige Prozesse nach Abschluss jeder Ausführung im Hintergrund ausgeführt. Angenommen, Sie verfügen über eine fünfminütige Timerfunktion, die jedes Mal configure_azure_monitor aufruft. Nach 20 Minuten verfügen Sie möglicherweise über vier Metrikexporteure, die gleichzeitig ausgeführt werden. Diese Situation kann die Quelle Ihrer doppelten Metrik-Telemetrie sein.
Legen Sie in diesem Fall entweder die Einstellung Always On auf Off fest, oder versuchen Sie, die Anbieter zwischen jedem configure_azure_monitor-Aufruf manuell zu beenden. Um jeden Anbieter herunterzufahren, führen Sie Herunterfahren-Aufrufe für jeden aktuellen Meter-, Tracer- und Logger-Anbieter aus, wie im folgenden Code gezeigt:
Azure-Arbeitsmappen und Jupyter-Notebooks können Exporterprozesse im Hintergrund beibehalten. Um doppelte Telemetrie zu verhindern, löschen Sie den Cache, bevor Sie weitere Aufrufe an configure_azure_monitor tätigen.
Schritt 4: Sicherstellen, dass Flask-Anforderungsdaten gesammelt werden
Wenn Sie eine Flask-Anwendung implementieren, stellen Sie möglicherweise fest, dass Sie keine Anforderungstabellendaten aus Application Insights sammeln können, während Sie die Azure Monitor OpenTelemetry Distro-Clientbibliothek für Python verwenden. Dieses Problem kann auftreten, wenn Sie ihre import-Deklarationen nicht ordnungsgemäß strukturieren. Möglicherweise importieren Sie das flask.Flask Webanwendungsframework, bevor Sie die configure_azure_monitor-Funktion aufrufen, um die Flask-Bibliothek zu instrumentieren. Der folgende Code instrumentiert die Flask-App z. B. nicht erfolgreich:
from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask
configure_azure_monitor()
app = Flask(__name__)
Stattdessen wird empfohlen, das flask-Modul als Ganzes zu importieren und dann configure_azure_monitor aufzurufen, um OpenTelemetry so zu konfigurieren, dass Azure Monitor verwendet wird, bevor Sie auf flask.Flask zugreifen:
from azure.monitor.opentelemetry import configure_azure_monitor
import flask
configure_azure_monitor()
app = flask.Flask(__name__)
Alternativ können Sie vor dem Import von flask.Flaskconfigure_azure_monitor aufrufen:
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
from flask import Flask
app = Flask(__name__)
Unterstützung
Wählen Sie eine Registerkarte für die Sprache Ihrer Wahl aus, um Supportoptionen zu ermitteln.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.