Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel erfahren Sie, wie Sie Ihre Funktions-App so konfigurieren, dass Protokoll- und Ablaufverfolgungsdaten in einem OpenTelemetry-Format exportiert werden. Azure Functions generiert Telemetriedaten zu Ihren Funktionsausführungen sowohl aus dem Hostprozess der Funktionen als auch aus dem sprachspezifischen Arbeitsprozess, in dem Ihr Funktionscode ausgeführt wird. Standardmäßig werden diese Telemetriedaten mithilfe des Application Insights SDK an Application Insights gesendet. Sie können diese Daten jedoch mithilfe der OpenTelemetry-Semantik exportieren. Sie können zwar weiterhin ein OpenTelemetry-Format verwenden, um Ihre Daten an Application Insights zu senden, aber Sie können jetzt auch dieselben Daten in einen anderen mit OpenTelemetry kompatiblen Endpunkt exportieren.
Sie können diese Vorteile erhalten, indem Sie OpenTelemetry in Ihrer Funktions-App aktivieren:
- Korreliert Daten über Ablaufverfolgungen und Protokolle hinweg, die sowohl auf dem Host als auch im Anwendungscode generiert werden.
- Ermöglicht eine konsistente, standardsbasierte Generierung von exportierbaren Telemetriedaten.
- Integriert sich in andere Anbieter, die mit OpenTelemetry kompatible Daten nutzen können.
Beachten Sie bei der Verwendung dieses Artikels die folgenden Überlegungen:
Probieren Sie das Lernprogramm OpenTelemetry aus, das Ihnen bei den ersten Schritten mit OpenTelemetry und Azure Functions helfen soll. In diesem Artikel wird die Azure Developer CLI (
azd) verwendet, um eine Funktions-App zu erstellen und bereitzustellen, die die OpenTelemetry-Integration für verteiltes Tracing verwendet.Da sich dieser Artikel auf ihre Entwicklungssprache bezieht, denken Sie daran, am Anfang des Artikels die richtige Sprache auszuwählen.
- OpenTelemetry wird derzeit für C#-In-Process-Apps nicht unterstützt.
- OpenTelemetry ist auf Funktions-App-Ebene aktiviert, sowohl in der Hostkonfiguration (
host.json) als auch im Codeprojekt. Funktionen bieten auch eine clientoptimierte Oberfläche zum Exportieren von OpenTelemetry-Daten aus Ihrem Funktionscode, der in einem sprachspezifischen Arbeitsprozess ausgeführt wird.
Aktivieren von OpenTelemetry im Functions-Host
Wenn Sie die OpenTelemetry-Ausgabe in der Datei der Funktions-App host.json aktivieren, exportiert Ihr Host die OpenTelemetry-Ausgabe unabhängig vom von Ihrer App verwendeten Sprachstapel.
Um die OpenTelemetry-Ausgabe vom Funktionshost zu aktivieren, aktualisieren Sie die host.json Datei in Ihrem Codeprojekt, um der Stammauflistung ein "telemetryMode": "OpenTelemetry"-Element hinzuzufügen. Wenn OpenTelemetry aktiviert ist, sieht ihre host.json Datei möglicherweise wie folgt aus:
{
"version": "2.0",
"telemetryMode": "OpenTelemetry",
...
}
Konfigurieren von Anwendungseinstellungen
Wenn Sie OpenTelemetry in der host.json Datei aktivieren, bestimmen die Umgebungsvariablen der App die Endpunkte zum Senden von Daten, basierend auf denen openTelemetry-unterstützte Anwendungseinstellungen verfügbar sind.
Erstellen Sie bestimmte Anwendungseinstellungen in Ihrer Funktions-App basierend auf dem OpenTelemetry-Ausgabeziel. Wenn Sie Verbindungseinstellungen für Application Insights und einen OTLP-Exporter (OpenTelemetry-Protokoll) bereitstellen, werden OpenTelemetry-Daten an beide Endpunkte gesendet.
APPLICATIONINSIGHTS_CONNECTION_STRING: die Verbindungszeichenfolge für einen Application Insights-Arbeitsbereich. Wenn diese Einstellung vorhanden ist, werden OpenTelemetry-Daten an diesen Arbeitsbereich gesendet. Verwenden Sie dieselbe Einstellung, um eine Verbindung mit Application Insights herzustellen, ohne Dass OpenTelemetry aktiviert ist. Wenn Ihre App noch nicht über diese Einstellung verfügt, müssen Sie möglicherweise die Application Insights-Integration aktivieren.
JAVA_APPLICATIONINSIGHTS_ENABLE_TELEMETRY: Auf true festgelegt, damit der Funktionshost dem Java-Arbeiterprozess erlaubt, OpenTelemetry-Protokolle direkt zu streamen, wodurch doppelte Einträge der Hostebene verhindert werden.
PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY: Auf true festgelegt, sodass der Funktionshost dem Python Arbeitsprozess das direkte Streamen von OpenTelemetry-Protokollen ermöglicht, wodurch doppelte Einträge auf Hostebene verhindert werden.
Aktivieren von OpenTelemetry in Ihrer App
Nachdem Sie den Funktionenhost für die Verwendung von OpenTelemetry konfiguriert haben, aktualisieren Sie den Anwendungscode so, dass OpenTelemetry-Daten ausgegeben werden. Wenn Sie OpenTelemetry sowohl im Host als auch im Anwendungscode aktivieren, erhalten Sie eine bessere Korrelation zwischen Ablaufverfolgungen und Protokollen, die der Funktionenhostprozess und der Spracharbeitsprozess ausgeben.
Wie Sie Ihre Anwendung zur Verwendung von OpenTelemetry instrumentieren, hängt von Ihrem Ziel-OpenTelemetry-Endpunkt ab:
Beispiele in diesem Artikel gehen davon aus, dass Ihre App IHostApplicationBuilder verwendet, das in Version 2.x und höher in Microsoft.Azure verfügbar ist. Functions.Worker. Weitere Informationen finden Sie unter Version 2.x im C#-Handbuch für isolierte Arbeitsmodelle.
Führen Sie die folgenden Befehle aus, um die erforderlichen Assemblys in Ihrer App zu installieren:
Hinweis
Ab Version 3.0 nutzt das
Microsoft.ApplicationInsights.WorkerService-Paket Azure Monitor Exporter. Sie können dieses Paket verwenden, um das vorhandene Anwendungseinblick-Konfigurationsverhalten bei der internen Verwendung der Azure Monitor-Pipeline zu verwalten, einschließlich des OpenTelemetry-Exporters. Sie können dasMicrosoft.ApplicationInsights.WorkerService-Paket (v3.0 oder höher) anstelle desAzure.Monitor.OpenTelemetry.Exporter-Pakets verwenden, das im folgenden Beispiel gezeigt wird.dotnet add package Microsoft.Azure.Functions.Worker.OpenTelemetry dotnet add package OpenTelemetry.Extensions.Hosting dotnet add package Azure.Monitor.OpenTelemetry.ExporterFügen Sie in Ihrer Program.cs-Projektdatei diese
using-Anweisung hinzu:using Azure.Monitor.OpenTelemetry.Exporter;Konfigurieren Sie OpenTelemetry, je nachdem, ob Ihr Projektstart
IHostBuilderoderIHostApplicationBuilderverwendet. Letzteres wurde in v2.x der .NET Erweiterung des isolierten Arbeitsmodells eingeführt.Fügen Sie in program.cs diese Codezeile nach
ConfigureFunctionsWebApplicationhinzu:builder.Services.AddOpenTelemetry() .UseFunctionsWorkerDefaults() .UseAzureMonitorExporter();Sie können beide OpenTelemetry-Endpunkte aus derselben App exportieren.
Fügen Sie Ihrer App die erforderlichen Bibliotheken hinzu. Die Art und Weise, wie Sie Bibliotheken hinzufügen, hängt davon ab, ob Sie Maven oder Kotlin verwenden und ob Sie auch Daten an Application Insights senden möchten.
<dependency> <groupId>com.microsoft.azure.functions</groupId> <artifactId>azure-functions-java-opentelemetry</artifactId> <version>1.0.0</version> </dependency> <dependency> <groupId>com.azure</groupId> <artifactId>azure-monitor-opentelemetry-autoconfigure</artifactId> <version>1.2.0</version> </dependency>(Optional) Fügen Sie diesen Code hinzu, um benutzerdefinierte Bereiche zu erstellen:
import com.microsoft.azure.functions.opentelemetry.FunctionsOpenTelemetry; import io.opentelemetry.api.trace.Span; import io.opentelemetry.api.trace.SpanKind; import io.opentelemetry.context.Scope; Span span = FunctionsOpenTelemetry.startSpan( "com.contoso.PaymentFunction", // tracer name "validateCharge", // span name null, // parent = current context SpanKind.INTERNAL); try (Scope ignored = span.makeCurrent()) { // business logic here } finally { span.end(); }
Installieren Sie diese npm-Pakete in Ihrem Projekt:
npm install @opentelemetry/api npm install @opentelemetry/auto-instrumentations-node npm install @azure/monitor-opentelemetry-exporter npm install @azure/functions-opentelemetry-instrumentation
Erstellen Sie eine Codedatei in Ihrem Projekt, kopieren Sie den folgenden Code, fügen Sie ihn in diese neue Datei ein, und speichern Sie die Datei unter
src/index.js:const { AzureFunctionsInstrumentation } = require('@azure/functions-opentelemetry-instrumentation'); const { AzureMonitorLogExporter, AzureMonitorTraceExporter } = require('@azure/monitor-opentelemetry-exporter'); const { getNodeAutoInstrumentations, getResourceDetectors } = require('@opentelemetry/auto-instrumentations-node'); const { registerInstrumentations } = require('@opentelemetry/instrumentation'); const { detectResourcesSync } = require('@opentelemetry/resources'); const { LoggerProvider, SimpleLogRecordProcessor } = require('@opentelemetry/sdk-logs'); const { NodeTracerProvider, SimpleSpanProcessor } = require('@opentelemetry/sdk-trace-node'); const resource = detectResourcesSync({ detectors: getResourceDetectors() }); const tracerProvider = new NodeTracerProvider({ resource }); tracerProvider.addSpanProcessor(new SimpleSpanProcessor(new AzureMonitorTraceExporter())); tracerProvider.register(); const loggerProvider = new LoggerProvider({ resource }); loggerProvider.addLogRecordProcessor(new SimpleLogRecordProcessor(new AzureMonitorLogExporter())); registerInstrumentations({ tracerProvider, loggerProvider, instrumentations: [getNodeAutoInstrumentations(), new AzureFunctionsInstrumentation()], });Aktualisieren Sie das
mainFeld in Ihrer package.json-Datei, um die neuesrc/index.jsDatei einzuschließen. Beispiel:"main": "src/{index.js,functions/*.js}"
Erstellen Sie eine Codedatei in Ihrem Projekt, kopieren Sie den folgenden Code, fügen Sie ihn in diese neue Datei ein, und speichern Sie die Datei unter
src/index.ts:import { AzureFunctionsInstrumentation } from '@azure/functions-opentelemetry-instrumentation'; import { AzureMonitorLogExporter, AzureMonitorTraceExporter } from '@azure/monitor-opentelemetry-exporter'; import { getNodeAutoInstrumentations, getResourceDetectors } from '@opentelemetry/auto-instrumentations-node'; import { registerInstrumentations } from '@opentelemetry/instrumentation'; import { detectResourcesSync } from '@opentelemetry/resources'; import { LoggerProvider, SimpleLogRecordProcessor } from '@opentelemetry/sdk-logs'; import { NodeTracerProvider, SimpleSpanProcessor } from '@opentelemetry/sdk-trace-node'; const resource = detectResourcesSync({ detectors: getResourceDetectors() }); const tracerProvider = new NodeTracerProvider({ resource }); tracerProvider.addSpanProcessor(new SimpleSpanProcessor(new AzureMonitorTraceExporter())); tracerProvider.register(); const loggerProvider = new LoggerProvider({ resource }); loggerProvider.addLogRecordProcessor(new SimpleLogRecordProcessor(new AzureMonitorLogExporter())); registerInstrumentations({ tracerProvider, loggerProvider, instrumentations: [getNodeAutoInstrumentations(), new AzureFunctionsInstrumentation()], });Aktualisieren Sie das Feld
mainin Ihrer package.json-Datei, um die Ausgabe dieser neuensrc/index.ts-Datei einzuschließen, die wie folgt aussehen kann:"main": "dist/src/{index.js,functions/*.js}"
Wichtig
Die OpenTelemetry-Ausgabe für Application Insights vom Sprachworker wird für PowerShell-Apps derzeit nicht unterstützt. Sie sollten vielleicht stattdessen einen OTLP-Exporter-Endpunkt verwenden. Wenn Sie Ihren Host für die OpenTelemetry-Ausgabe in Application Insights konfigurieren, werden die vom PowerShell-Arbeitsprozess generierten Protokolle weiterhin weitergeleitet, die verteilte Ablaufverfolgung wird derzeit jedoch nicht unterstützt.
Diese Anweisungen gelten nur für einen OTLP-Exporter:
Fügen Sie eine Anwendungseinstellung mit dem Namen
OTEL_FUNCTIONS_WORKER_ENABLEDmit einem Wert vonTruehinzu.Erstellen Sie einen App-Ebene
ModulesOrdner im Stammverzeichnis Ihrer App, und führen Sie den folgenden Befehl aus:Save-Module -Name AzureFunctions.PowerShell.OpenTelemetry.SDKMit diesem Befehl wird das erforderliche
AzureFunctions.PowerShell.OpenTelemetry.SDKModul direkt in Ihrer App installiert. Sie können die Dateirequirements.psd1nicht verwenden, um diese Abhängigkeit automatisch zu installieren, da verwaltete Abhängigkeiten derzeit in der Vorschau des Flex-Verbrauchsplans nicht unterstützt werden.Fügen Sie diesen Code zur Datei „profile.ps1“ hinzu:
Import-Module AzureFunctions.PowerShell.OpenTelemetry.SDK -Force -ErrorAction Stop Initialize-FunctionsOpenTelemetry
Stellen Sie sicher, dass sich diese Bibliotheken in Ihrer
requirements.txt-Datei befinden, ganz gleich, ob Sie die Kommentare aufheben oder sich selbst hinzufügen:azure-monitor-opentelemetryFügen Sie diesen Code zu Ihrer
function_app.pyHaupteinstiegspunktdatei hinzu:Wenn Sie ihrer Anwendungseinstellungen bereits
PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY=truehinzugefügt haben, können Sie diesen Schritt überspringen. Um die Application Insights-Auflistung ohne automatische Instrumentierung manuell zu aktivieren, fügen Sie Ihrer App diesen Code hinzu:from azure.monitor.opentelemetry import configure_azure_monitor configure_azure_monitor()Lesen Sie die Dokumentation zu Azure Monitor Distro-Nutzung, um sich über Optionen zur weiteren Konfiguration des SDK zu informieren.
Überlegungen zu OpenTelemetry
Wenn Sie Ihre Daten mithilfe von OpenTelemetry exportieren, sollten Sie diese Überlegungen berücksichtigen.
Das Azure-Portal unterstützt
Recent function invocationNachverfolgungen nur, wenn die Telemetrie an Azure Monitor gesendet wird.Wenn Sie den Host für die Verwendung von OpenTelemetry konfigurieren, unterstützt das Azure-Portal das Protokollstreaming nicht.
Wenn Sie
telemetryModeaufOpenTelemetrysetzen, gilt die Konfiguration im Abschnittlogging.applicationInsightsder host.json nicht.
Benutzerdefinierte Spans enthalten automatisch alle Ressourcenattribute und verwenden die in Ihrer App konfigurierten Exporter.
Wenn Ihre App außerhalb Azure ausgeführt wird, einschließlich während der lokalen Entwicklung, legt der Ressourcendetektor standardmäßig das Attribut
service.nameaufjava-function-appfest.Verwenden Sie diese Java Virtual Machine (JVM)-Flags, um Telemetrie zu unterdrücken, wenn sie während Unit-Tests lokal ausgeführt werden.
-Dotel.traces.exporter=none-Dotel.metrics.exporter=none-Dotel.logs.exporter=none
- Sie müssen Middleware nicht manuell registrieren; der Java Worker erkennt
OpenTelemetryInvocationMiddlewareautomatisch.
Ressourcendetektoren und semantische Konventionen
In Azure Functions beschreiben Ressourcenattribute den Funktions-App-Prozess und seine Umgebung. Span-Attribute beschreiben einen einzelnen Aufruf.
Standardverhalten (keine Aktion erforderlich)
In Azure Functions in App Service füllen Ressourcendetektoren in der Regel allgemeine Attribute automatisch auf, darunter:
-
service.name(Standardmäßig wird der App-Name der Funktion verwendet) - Azure Cloudattribute wie
cloud.provider,cloud.regionundcloud.resource_id
In den meisten Fällen reichen diese Standardwerte für die richtige Anwendungszuordnungsgruppierung und Azure Kontext aus.
Wann der service.name (Cloudrollenname) überschrieben werden sollte
Überschreiben Sie nur, wenn Sie einen anderen, stabilen Knotennamen in Application Insights (Application Map-Gruppierung) benötigen, um beispielsweise die Benennung über Slots oder Umgebungen hinweg zu normalisieren.
Setzen Sie OTEL_SERVICE_NAME fest, um den erkannten Wert außer Kraft zu setzen.
export OTEL_SERVICE_NAME="my-function-app"
Aufrufspannattribute (in der Regel automatisch)
Sie müssen diese nicht manuell festlegen, es sei denn, Sie erstellen eine benutzerdefinierte Aufrufspanne.
-
faas.name(Funktionsname) -
faas.trigger(z. B.http,servicebus,eventhubs) -
faas.execution(Aufruf-/Ausführungs-ID)
Wichtig
Funktions-Apps können mehrere Funktionen in einem Prozess hosten. Platzieren Sie keine funktionsspezifischen Werte für die Ressource. Legen Sie die Identität pro Aufruf auf Spannen fest.
Hinweis
Wenn sie lokal (Funktionen Core Tools) oder in containerisierten/selbst gehosteten Umgebungen ausgeführt werden, in denen Azure Metadaten nicht verfügbar sind, kann service.name standardmäßig einen generischen Wert aufweisen. Legen Sie OTEL_SERVICE_NAME lokal fest, um sie mit der Produktionsbenennung abzugleichen.
Problembehandlung
Wenn Sie Ihre Daten mithilfe von OpenTelemetry exportieren, sollten Sie diese häufig auftretenden Probleme und Lösungen berücksichtigen.
Protokollfilterung
Um die Protokollfilterung in Ihrer Funktions-App ordnungsgemäß zu konfigurieren, müssen Sie den Unterschied zwischen dem Hostprozess und dem Arbeitsprozess verstehen.
Der Host-Prozess ist die Azure Functions-Runtime, die Trigger, Skalierung und Telemetrie auf Systemebene verwaltet, wie z.B. Initialisierungsprotokolle, Anforderungsprotokolle und Laufzeitzustandsinformationen.
Der Arbeitsprozess ist sprachspezifisch, führt Ihren Funktionscode aus und erzeugt Anwendungsprotokolle und Telemetrie unabhängig voneinander.
Wichtig
Filter, die in host.json definiert sind, gelten nur für Log-Dateien, die vom Hostprozess generiert werden. Sie müssen sprachspezifische OpenTelemetry-Einstellungen verwenden, um Protokolle aus dem Arbeitsprozess zu filtern.
Beispiel: Filtern von Hostprotokollen für alle Anbieter in host.json
Verwenden Sie diesen Ansatz, um eine globale Protokollebene für alle vom Host verwalteten Anbieter festzulegen:
{
"version": "2.0",
"telemetryMode": "OpenTelemetry",
"logging": {
"logLevel": {
"default": "Warning"
}
}
}
Beispiel: Filterprotokolle nur für den OpenTelemetry-Loggeranbieter
Verwenden Sie diesen Ansatz, um nur auf den OpenTelemetry-Loggeranbieter zu abzielen, während andere Anbieter (z. B. Konsolen- oder Dateiprotokollierung) nicht betroffen sind:
{
"version": "2.0",
"telemetryMode": "OpenTelemetry",
"logging": {
"OpenTelemetry": {
"logLevel": {
"default": "Warning"
}
}
}
}
Konsolenprotokollierung
Der Funktionshost erfasst automatisch alles, was in Stdout oder Stderr geschrieben wurde, und leitet es an die Telemetriepipeline weiter. Wenn Sie auch einen ConsoleExporter verwenden oder direkt in die Konsole in Ihrem Code schreiben, können doppelte Protokolle in Ihren Telemetriedaten auftreten.
Hinweis
Fügen Sie „ConsoleExporter“ nicht hinzu, oder schreiben in die Konsole im Produktionscode, um doppelte Telemetrie zu vermeiden.
Microsoft Entra Authentifizierung
Wenn Sie Microsoft Entra Authentifizierung mit OpenTelemetry verwenden, müssen Sie die Authentifizierung sowohl für den Hostprozess als auch für den Arbeitsprozess separat konfigurieren.
Informationen zum Konfigurieren der Authentifizierung für den Hostprozess finden Sie unter Require Microsoft Entra authentication.
Informationen zum Konfigurieren der Authentifizierung für den Arbeitsprozess finden Sie unter Enable Microsoft Entra authentication.
Unterstützung von Ressourcenattributen
Die Unterstützung von Ressourcenattributen in Azure Monitor befindet sich derzeit in der Vorschauversion. Um dieses Feature zu aktivieren, legen Sie die OTEL_DOTNET_AZURE_MONITOR_ENABLE_RESOURCE_METRICS Umgebungsvariable auf true. Diese Einstellung nimmt Ressourcenattribute in die benutzerdefinierte Metriktabelle ein.
Telemetrie für doppelte Anfragen
Der Hostprozess sendet automatisch die Anfrage-Telemetrie. Wenn der Arbeitsprozess auch mit Anforderungsverfolgungsbibliotheken (z. B. AspNetCoreInstrumentation in .NET) instrumentiert wird, wird dieselbe Anforderung zweimal gemeldet.
Hinweis
Da die Azure Monitor Distro in der Regel AspNetCoreInstrumentation in .NET und ähnliche Instrumentierung in anderen Sprachen enthält, vermeiden Sie die Verwendung der Azure Monitor Distro im Arbeitsprozess, um doppelte Telemetrie zu verhindern.
Nicht enthaltene Protokollierungsbereiche
Standardmäßig enthält der Arbeitsprozess keine Geltungsbereiche in seinen Protokollen. Um Scopes zu aktivieren, müssen Sie diese Einstellung explizit im Worker konfigurieren. Das folgende Beispiel zeigt, wie Bereiche in .NET Isoliert aktiviert werden:
builder.Logging.AddOpenTelemetry(b => b.IncludeScopes = true);
Fehlende Anforderungstelemetrie
Trigger wie HTTP, Service Bus und Event Hubs hängen von der Kontextverteilung für die verteilte Ablaufverfolgung ab. Bei einem übergeordneten Sampling als Standardverhalten wird die Telemetrieanforderung nicht generiert, wenn die eingehende Anforderung oder Nachricht nicht abgetastet wird.
Doppelte Operations-ID
In Azure Functions stammt die OperationId, die zum Korrelieren von Telemetrie verwendet wird, direkt aus dem Wert traceparent in der eingehenden Anforderung oder Nachricht. Wenn mehrere Aufrufe denselben traceparent Wert wiederverwenden, erhalten sie alle denselben OperationId.
Konfigurieren von OpenTelemetry mit Umgebungsvariablen
Sie können das OpenTelemetry-Verhalten mithilfe der Standardumgebungsvariablen konfigurieren. Diese Variablen bieten eine konsistente Möglichkeit zum Steuern des Verhaltens in verschiedenen Sprachen und Laufzeiten. Sie können Samplingstrategien, Exportereinstellungen und Ressourcenattribute anpassen. Weitere Informationen zu unterstützten Umgebungsvariablen finden Sie in der OpenTelemetry-Dokumentation.
Verwenden Sie Diagnosetools, um Probleme bei der Überwachung zu beheben
Azure Functions Diagnostics im Azure Portal ist eine nützliche Ressource zum Erkennen und Diagnostizieren potenzieller überwachungsbezogener Probleme.
So greifen Sie auf die Diagnose in Ihrer App zu:
Wechseln Sie im Azure-Portal zu Ihrer Funktions-App-Ressource.
Wählen Sie im linken Bereich Probleme diagnostizieren und beheben aus, und suchen Sie nach dem Workflow In der Funktions-App fehlt Telemetrie von Application Insights oder OpenTelemetry.
Wählen Sie diesen Workflow aus, wählen Sie Ihre Aufnahmemethode und dann "Weiter" aus.
Überprüfen Sie die Richtlinien und Empfehlungen, die von der Problembehandlung bereitgestellt werden.
Nächste Schritte
Weitere Informationen zu OpenTelemetry und der Überwachung von Azure Functions: