Hilfe, Support und Feedback zu OpenTelemetry

Artikel
10/14/2024

Dieser Artikel enthält Hilfe-, Support- und Feedbackoptionen für OpenTelemetry in Azure Monitor Application Insights für .NET-, Java-, Node.js- und Python-Apps.

Häufig gestellte Fragen
Schritte zur Problembehandlung
Support anfordern
Feedback geben

Häufig gestellte Fragen

Was ist OpenTelemetry?

Es handelt sich um einen neuen Open-Source-Standard für Einblicke. 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 im großen Stil 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 Verteilung 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 Wiederholungen
- Statsbeat
- Application Insights-Standardmetriken
- Erkennen von Ressourcenmetadaten zum automatischen Auffüllen von Cloudrollennamen und Cloudrolleninstanzen in verschiedenen Azure-Umgebungen
- Livemetriken

Im Sinne von OpenTelemetry haben wir die Distribution so konzipiert, dass sie offen und erweiterbar ist. Sie können beispielsweise Folgendes tun:

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 in einen anderen Sampler ändern, dies kann jedoch einige der enthaltenen Funktionen von Distro deaktivieren. 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 OpenTelemetry-Distribution, es sei denn, Sie benötigen ein Feature, das nur mit formaler Unterstützung im Application Insights-SDK verfügbar ist.

Wenn OpenTelemetry jetzt eingeführt wird, wird verhindert, dass zu einem späteren Zeitpunkt migriert werden muss.

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. Es ist nur eine Codezeile, um loszulegen.

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.

Funktion	.NET	Node.js	Python	Java
Verteilte Ablaufverfolgung	✅	✅	✅	✅
Benutzerdefinierte Metriken	✅	✅	✅	✅
Standardmetriken	✅	✅	✅	✅
Stichprobenerstellung mit festem Prozentsatz	✅	✅	✅	✅
Offlinespeicher und automatische Wiederholungsversuche	✅	✅	✅	✅
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 der Hilfe von Microsoft entstand OpenTelemetry aus einer Zusammenführung von OpenTracing und OpenCensus als einzelner Einblickstandard für die ganze Welt. 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. Can't visualize trace events using the trace visualizer`?

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 Rohprotokollen beziehen sich „Traces“ in OpenTelemetry auf eine reichhaltigere, strukturierte Form der Telemetrie, die Spans enthält, die 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.

Problembehandlung

Schritt 1: Aktivieren der Diagnoseprotokollierung

Azure Monitor Exporter verwendet EventSource für die interne Protokollierung. Die Exporterprotokolle sind für alle EventListener über die Quelle OpenTelemetry-AzureMonitor-Exporter verfügbar. 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 (Software Development Kits) 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

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

Die Diagnoseprotokollierung ist standardmäßig in Azure Monitor Application Insights aktiviert. Weitere Informationen finden Sie im Handbuch zur Problembehandlung: Azure Monitor Application Insights for Java.

Schritt 2: Testen der Konnektivität zwischen Ihrem Anwendungshost und dem Erfassungsdienst

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:
```
curl --location --output applicationinsights-agent-3.6.2.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download//applicationinsights-agent-3.6.2.jar
```
```
wget --output-document=applicationinsights-agent-3.6.2.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download//applicationinsights-agent-3.6.2.jar
```
Hinweis

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

Microsoft übernimmt keine Garantie, weder ausdrücklich noch konkludent, für die Leistung oder Zuverlässigkeit dieser Produkte von unabhängigen Drittanbietern.

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:

const { diag, DiagConsoleLogger, DiagLogLevel } = require("@opentelemetry/api");
const { NodeTracerProvider } = require("@opentelemetry/sdk-trace-node");

const provider = new NodeTracerProvider();
diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.ALL);
provider.register();

Schritt 2: Testen der Konnektivität zwischen Ihrem Anwendungshost und dem Erfassungsdienst

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.

Diagnoseprotokollierung aktivieren

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:

...
import logging

logging.basicConfig(format = "%(asctime)s:%(levelname)s:%(message)s", level = logging.DEBUG)

logger = logging.getLogger(__name__)
file = logging.FileHandler("example.log")
stream = logging.StreamHandler()
logger.addHandler(file)
logger.addHandler(stream)
...

Testen der Konnektivität zwischen Ihrem Anwendungshost und dem Erfassungsdienst

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. Um dieses Ziel zu erreichen, legen Sie die OTEL_LOGS_EXPORTER-Umgebungsvariable 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:

get_meter_provider().shutdown()
get_tracer_provider().shutdown()
get_logger_provider().shutdown()

Azure-Arbeitsmappen und Jupyter-Notebooks

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.

Fehlende Telemetrieanforderungen von FastAPI- oder Flask-Apps

Wenn Tabellendaten von Anforderungen fehlen, aber keine anderen Kategorien, ist es wahrscheinlich, dass Ihr HTTP-Framework nicht instrumentiert wird. Dies kann in FastAPI- und Flask-Apps mit der Clientbibliothek der Azure Monitor OpenTelemetry-Distribution für Python auftreten, wenn Sie Ihre import-Deklarationen nicht richtig strukturieren. Möglicherweise importieren Sie fastapi.FastAPI bzw. flask.Flask, bevor Sie die configure_azure_monitor-Funktion aufrufen, um die FastAPI- und Flask-Bibliotheken zu instrumentieren. Der folgende Code instrumentiert beispielsweise die FastAPI- und Flask-Apps nicht erfolgreich:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor
from fastapi import FastAPI

configure_azure_monitor()

app = FastAPI()

# Flask

from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask

configure_azure_monitor()

app = Flask(__name__)

Stattdessen wird empfohlen, das Modul fastapi bzw. flask im Ganzen zu importieren und dann configure_azure_monitor aufzurufen, um OpenTelemetry für die Verwendung von Azure Monitor zu konfigurieren, bevor Sie auf fastapi.FastAPI oder flask.Flask zugreifen:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor
import fastapi

configure_azure_monitor()

app = fastapi.FastAPI(__name__)

# Flask

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 fastapi.FastAPI oder flask.Flask configure_azure_monitor aufrufen:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor

configure_azure_monitor()

from fastapi import FastAPI

app = FastAPI(__name__)

# Flask

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.

Bei Azure-Supportproblemen öffnen Sie ein Azure-Supportticket.
Wenden Sie sich bei OpenTelemetry-Problemen direkt an die OpenTelemetry .NET-Community.
Eine Liste der offenen Probleme im Zusammenhang mit Azure Monitor Exporter finden Sie auf der Issues-Seite auf GitHub.

OpenTelemetry-Feedback

So können Sie Feedback geben

Füllen Sie die Kundenfeedbackumfrage der OpenTelemetry-Community aus.
Erzählen Sie Microsoft von sich, indem Sie der OpenTelemetry Early Adopter-Community beitreten.
Interagieren Sie mit anderen Azure Monitor-Benutzern in der Technischen Community von Microsoft.
Featureanfragen können Sie im Azure-Feedbackforum stellen.

Freigeben über

Hilfe, Support und Feedback zu OpenTelemetry

Häufig gestellte Fragen

Was ist OpenTelemetry?

Warum investiert Microsoft Azure Monitor in OpenTelemetry?

Wie ist der Status von OpenTelemetry?

Was ist die OpenTelemetry-Distribution von Azure Monitor?

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

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

Sollte ich OpenTelemetry oder das Application Insights-SDK verwenden?

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

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

Kann OpenTelemetry für Webbrowser verwendet werden?

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

Kann ich OpenTelemetry heute in einem Webbrowser testen?

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

Kann ich in Produktionsumgebungen die Previewfunktionen verwenden?

Was ist der Unterschied zwischen manueller und automatischer Instrumentierung?

Kann ich den OpenTelemetry-Collector verwenden?

Worin besteht der Unterschied zwischen OpenCensus und OpenTelemetry?

Warum sehe ich in Grafana Status: 500. Can't visualize trace events using the trace visualizer?

Problembehandlung

Schritt 1: Aktivieren der Diagnoseprotokollierung

Schritt 2: Testen der Konnektivität zwischen Ihrem Anwendungshost und dem Erfassungsdienst

Bekannte Probleme

Unterstützung

OpenTelemetry-Feedback

Feedback

Zusätzliche Ressourcen

Warum sehe ich in Grafana `Status: 500. Can't visualize trace events using the trace visualizer`?