Aktivieren und Anzeigen erweiterter Telemetrie in Application Insights für Standardworkflows in Azure Logic Apps
Gilt für: Azure Logic Apps (Standard)
In Application Insights können Sie die erweiterte Telemetriesammlung für Ihre Standardlogik-App-Ressource aktivieren und dann die gesammelten Daten anzeigen, nachdem der Workflow eine Ausführung abgeschlossen hat. Diese Funktion bietet Ihnen eine vereinfachte Erfahrung, um Erkenntnisse über Ihre Workflows zu gewinnen und mehr Kontrolle über Filterereignisse an der Datenquelle zu erhalten, wodurch Sie die Speicherkosten reduzieren können. Diese Verbesserungen konzentrieren sich auf Echtzeit-Leistungsmetriken, die Einblicke in die Integrität und das Verhalten Ihres Systems bieten. Auf diese Weise können Sie Probleme proaktiv früher erkennen und beheben.
Mit Ihrer Logik-App, die mit Application Insights verbunden ist, können Sie über das Azure-Portal mithilfe von Live Metrics Stream Protokolldaten und andere Metriken nahezu in Echtzeit anzeigen. Außerdem verfügen Sie über Visualisierungen, mit denen Sie eingehende Anforderungen, ausgehende Anforderungen, die allgemeine Integrität und den Zugriff auf eine Tabelle mit Diagnosen auf Ablaufverfolgungsebene darstellen können.
In der folgenden Liste werden einige Beispiel für Telemetrieverbesserungen beschrieben:
- Trigger- und Aktionsereignisse umfassen jetzt den Trigger- oder Aktionstyp und den API-Namen, mit dem Sie die Verwendung bestimmter Connector abfragen können.
- Erleichtern Sie das Nachverfolgen von Wiederholungsereignissen.
- Erfassen Sie Ausnahmen für Trigger- und Aktionsfehler.
- Mehr Kontrolle über das Filtern von Ereignissen, die sich nicht auf Workflows beziehen.
- Erweiterte Filterung, mit der Sie mehr Kontrolle darüber erhalten, wie Ereignisse ausgegeben werden, einschließlich Trigger und Aktionen.
In diesem Handbuch wird gezeigt, wie Sie die erweiterte Telemetriesammlung in Application Insights für Ihre Standardlogik-App aktivieren.
Voraussetzungen
Ein Azure-Konto und ein Azure-Abonnement. Falls Sie kein Abonnement besitzen, können Sie sich für ein kostenloses Azure-Konto registrieren.
Eine Application Insights-Instanz. Sie erstellen diese Ressource im Voraus, wenn Sie Ihre Standardlogik-App erstellen, oder nach der Bereitstellung von Logik-Apps.
Eine Standardlogik-App und ein Workflow, entweder im Azure-Portal oder in Visual Studio Code.
Ihre Logik-App-Ressource oder Ihr Projekt muss die Azure Functions v4-Laufzeit verwenden, die standardmäßig aktiviert ist.
Ihre Logik-App muss Application Insights für die Diagnoseprotokollierung und Ablaufverfolgung aktiviert haben. Dies ist entweder beim Erstellen der Logik-App oder nach der Bereitstellung möglich.
Aktivieren der erweiterten Telemetrie in Application Insights
Öffnen Sie im Azure-Portal Ihre Ressource vom Typ „Logic App (Standard)“.
Wählen Sie im Menü Ihrer Logik-App unter Entwicklungstools die Option Erweiterte Tools aus. Wählen Sie auf der Seite Erweiterte Tools die Option Goaus, wodurch die Kudu-Tools geöffnet werden.
Wählen Sie auf der Seite Kudu im Menü der Debugging-Konsole CMD. Navigieren Sie in der Ordnerverzeichnistabelle zur folgenden Datei, und wählen Sie Bearbeiten aus: site/wwwroot/host.json
Fügen Sie in der Datei host.json den folgenden JSON-Code hinzu:
{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "version": "[1, 2.00]" }, "extensions": { "workflow": { "Settings": { "Runtime.ApplicationInsightTelemetryVersion": "v2" } } } }Diese Konfiguration aktiviert die Standardebene der Ausführlichkeit. Weitere Optionen finden Sie unter Filterung an der Quelle anwenden.
Application Insights öffnen
Nachdem Ihr Workflow eine Ausführung abgeschlossen hat und ein paar Minuten vergangen sind, öffnen Sie Ihre Application Insights-Ressource.
Wählen Sie im Azure-Portal im Menü Ihrer Logik-App unter Einstellungen die Option Application Insights aus.
Wählen Sie im Ressourcenmenü von Application Insights unter Überwachung die Option Protokolle aus.
Anzeigen erweiterter Protokolle in Application Insights
In den folgenden Abschnitten werden die Tabellen in Application Insights beschrieben, in denen Sie die erweiterte Telemetrie finden und anzeigen können, die aus ihrer Workflowausführung generiert wurde.
| Tabellenname | Beschreibung |
|---|---|
| Anforderungen | Details zu den folgenden Ereignissen in Workflowausführungen: - Auslöse- und Aktionsereignisse - Wiederholungsversuche – Connectornutzung |
| Traces | Details zu den folgenden Ereignissen in Workflowausführungen: – Start- und Endereignisse des Workflows – Batch-Sende- und Batch-Empfangsereignisse |
| Ausnahmen | Details zu Ausnahmeereignissen in Workflowausführungen |
| Abhängigkeiten | Details zu Abhängigkeitsereignissen in Workflowausführungen |
Tabelle „Anforderungen“
Die Tabelle „Anforderungen“ enthält Felder, die Daten zu den folgenden Ereignissen im Standardworkflow verfolgen:
- Auslöse- und Aktionsereignisse
- Wiederholungsversuche
- Connectorverwendung
Um zu zeigen, wie Daten in diese Felder gelangen, nehmen Sie an, sie haben den folgenden Standardworkflow, der mit dem Anforderungstrigger beginnt, gefolgt von der Aktion zum Verfassen und der Antwortaktion.
Die Einstellungen des Triggers verfügen über einen Parameter mit dem Namen Custom Tracking ID (Benutzerdefinierte Nachverfolgungs-ID). Der Parameterwert wird auf einen Ausdruck festgelegt, der den OrderId-Eigenschaftswert aus dem Textkörper einer eingehenden Nachricht abruft:
Als Nächstes weisen die Aktionseinstellungen Verfassen des Workflows eine hinzugefügte nachverfolgte Eigenschaft namens solutionNamezu. Der Eigenschaftswert wird auf den Namen der Logik-App-Ressource festgelegt.
Auf die Verfassen-Aktion folgt eine Antwort-Aktion, die eine Antwort an die aufrufende Funktion zurückgibt.
Die folgende Liste enthält Beispielabfragen, die Sie für die Tabelle „Anforderungen“ erstellen und ausführen können:
| Task | Schritte |
|---|---|
| Alle Trigger- und Aktionsereignisse anzeigen | Abfrage für alle Trigger- und Aktionsereignisse |
| Nur Triggerereignisse oder Aktionsereignisse anzeigen | Abfrage nur für Trigger- oder Aktionsereignisse |
| Anzeigen von Trigger- oder Aktionsereignissen mit einem bestimmten Vorgangstyp | Abfrage von Trigger- oder Aktionsereignissen nach Vorgangstyp |
| Anzeigen von Trigger- und Aktionsereignissen mit einer bestimmten Workflowausführungs-ID | Abfrage von Trigger- und Aktionsereignissen nach Workflowausführungs-ID |
| Anzeigen von Trigger- und Aktionsereignissen mit einer bestimmten Clientnachverfolgungs-ID | Abfrage von Trigger- und Aktionsereignissen nach Clientnachverfolgungs-ID |
| Anzeigen von Trigger- und Aktionsereignissen mit einem bestimmten Lösungsnamen | Abfrage von Trigger- und Aktionsereignissen nach Lösungsname |
| Anzeigen von Trigger- und Aktionsereignissen mit Wiederholungsversuchen | Abfrage von Trigger- und Aktionsereignissen für Wiederholungsversuche |
| Anzeigen von Trigger- und Aktionsereignissen mit Connectorverwendung | Abfrage nach Trigger- und Aktionsereignissen für die Connectorverwendung |
Abfrage für alle Trigger- und Aktionsereignisse
Nachdem der Workflow ausgeführt wurde und einige Minuten vergangen sind, können Sie eine Abfrage für die Tabelle „Anforderungen“ erstellen, um alle Vorgangsereignisse anzuzeigen.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Um alle Trigger- und Aktionsereignisse anzuzeigen, muss die folgende Abfrage erstellt und ausgeführt werden:
requests | sort by timestamp desc | take 10Das folgende Beispiel zeigt die Registerkarte Ergebnisse mit den angegebenen Spalten und Daten in jeder Zeile:
Spalte Beschreibung Beispiel name Name von Workflowvorgängen In diesem Beispiel zeigen die Zeilen manuell (Anforderungstrigger), Verfassenund Antwort an. Erfolg Status der Vorgangsausführung In diesem Beispiel zeigen alle Zeilen Wahr für eine erfolgreiche Ausführung an. Wenn ein Fehler aufgetreten ist, lautet der Wert Falsch. resultCode Statuscode der Vorgangsausführung In diesem Beispiel zeigen alle Zeilen Erfolgreich (200) an. duration Ausführungsdauer des Vorgangs Variiert für jeden Vorgang. Um die Details für einen bestimmten Vorgang anzuzeigen, erweitern Sie die Zeile für den Trigger oder die Aktion:
Das folgende Beispiel zeigt die aufgeklappten Details für den Anforderungstrigger :
Eigenschaft BESCHREIBUNG Beispiel Kategorie Vorgangskategorie, die basierend auf dem Vorgang immer Workflow.Operations.Triggers oder Workflow.Operations.Actions ist Workflow.Operations.Triggers. clientTrackingId Benutzerdefinierte Nachverfolgungs-ID, falls angegeben 123456 runId ID für die Workflowausführungsinstanz 08585358375819913417237801890CU00 triggerName Triggername manuell workflowId ID für den Workflow, der den Trigger ausgeführt hat c7711d107e6647179c2e15fe2c2720ce workflowName Name für den Workflow, der den Trigger ausgeführt hat Request-Response-Workflow operation_Name Name für den Vorgang, der den Trigger ausgeführt hat. In diesem Fall entspricht dieser Name dem Workflownamen. Request-Response-Workflow operation_Id ID für die Komponente oder den Workflow, die gerade ausgeführt wurde. Diese ID ist identisch mit dem RunId-Wert für die Workflowausführungsinstanz. Wenn Ausnahmen oder Abhängigkeiten vorhanden sind, überschreitet dieser Wert die Tabellen, sodass Sie diesen Triggerdatensatz mit den Ausnahmen oder Abhängigkeiten verknüpfen können. 08585358375819913417237801890CU00 operation_ParentId Verbindungsfähige ID für den Workflow, der den Trigger aufgerufen hat f95138daff8ab129 Das folgende Beispiel zeigt die aufgeklappten Details für die Verfassen-Aktion :
Eigenschaft BESCHREIBUNG Beispiel Kategorie Vorgangskategorie, die basierend auf dem Vorgang immer Workflow.Operations.Triggers oder Workflow.Operations.Actions ist Workflow.Operations.Actions clientTrackingId Benutzerdefinierte Nachverfolgungs-ID, falls angegeben 123456 actionName Aktionsname Compose runId ID für die Workflowausführungsinstanz 08585358375819913417237801890CU00 workflowId ID für den Workflow, der die Aktion ausgeführt hat c7711d107e6647179c2e15fe2c2720ce workflowName Name für den Workflow, der die Aktion ausgeführt hat Request-Response-Workflow solutionName Name der nachverfolgten Eigenschaft, sofern angegeben LA-AppInsights operation_Name Name für den Vorgang, der die Aktion ausgeführt hat. In diesem Fall entspricht dieser Name dem Workflownamen. Request-Response-Workflow operation_Id ID für die Komponente oder den Workflow, die gerade ausgeführt wurde. Diese ID ist identisch mit dem RunId-Wert für die Workflowausführungsinstanz. Wenn Ausnahmen oder Abhängigkeiten vorhanden sind, überschreitet dieser Wert die Tabellen, sodass Sie diesen Aktionsdatensatz mit den Ausnahmen oder Abhängigkeiten verknüpfen können. 08585358375819913417237801890CU00 operation_ParentId Verbindungsfähige ID für den Workflow, der die Aktion aufgerufen hat f95138daff8ab129
Abfrage nur für Trigger- oder Aktionsereignisse
Sie können eine Abfrage für die Tabelle „Anforderungen“ erstellen, um eine Teilmenge von Vorgangsereignissen basierend auf der Vorgangskategorie und dem Workflownamen anzuzeigen.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Um alle Triggerereignisse in einem bestimmten Workflow anzuzeigen, erstellen und führen Sie eine Abfrage aus, wobei der Eigenschaftswert der customDimensions.Category auf Workflow.Operations.Triggers festgelegt ist, und operation_Name auf den Workflownamen, z. B.:
requests | where customDimensions.Category == "Workflow.Operations.Triggers" and operation_Name == "Request-Response-Workflow"
Um alle Aktionsereignisse in einem bestimmten Workflow anzuzeigen, erstellen Sie eine Abfrage aus, wobei der Eigenschaftswert der customDimensions.Category auf Workflow.Operations.Aktionen festgelegt ist, und operation_Name auf den Workflownamen, z. B.:
requests | where customDimensions.Category == "Workflow.Operations.Actions" and operation_Name == "Request-Response-Workflow"
Abfragetrigger oder Aktionsereignisse nach Vorgangstyp
Sie können eine Abfrage für die Tabelle „Anforderungen“ erstellen, um Ereignisse für einen bestimmten Trigger oder Aktionstyp anzuzeigen.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Um alle Vorgangsereignisse mit einem bestimmten Triggertyp anzuzeigen, erstellen und starten Sie eine Abfrage mit dem WertcustomDimensions.triggerType, der auf den gewünschten Triggertyp festgelegt ist, z. B.:
requests | where customDimensions.triggerType == "Request"
Zum Anzeigen aller Vorgangsereignisse mit einem bestimmten Aktionstyp erstellen und starten Sie eine Abfrage mit dem Wert customDimensions.actionType, der auf den gewünschten Aktionstyp festgelegt ist, z. B.:
requests | where customDimensions.actionType == "Compose"
Abfragetrigger- und Aktionsereignisse nach Workflowausführungs-ID
Sie können eine Abfrage für die Tabelle „Anforderungen“ erstellen, um eine Teilmenge von Vorgangsereignissen basierend auf der Workflowausführungs-ID anzuzeigen. Diese Workflowausführungs-ID ist die gleiche ID, die Sie im Ausführungsverlauf des Workflows finden können.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Zum Anzeigen aller Vorgangsereignisse mit einer bestimmten Workflowausführungs-ID erstellen und starten Sie eine Abfrage mit dem Wert operation_Id, der auf die Workflowausführungs-ID festgelegt ist, z. B.:
requests | where operation_Id == "08585287554177334956853859655CU00"
Abfragetrigger- und Aktionsereignisse nach Clientnachverfolgungs-ID
Sie können eine Abfrage für die Tabelle „Anforderungen“ erstellen, um eine Teilmenge von Vorgangsereignissen basierend auf dem Workflownamen und der Clientnachverfolgungs-ID anzuzeigen.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Um alle Vorgangsereignisse mit einer bestimmten Clientnachverfolgungs-ID in einem bestimmten Workflow anzuzeigen, erstellen und starten Sie eine Abfrage, wobei der Wert operation_Name auf den Workflownamen festgelegt ist und der Eigenschaftswert clientTrackingId auf den gewünschten Wert, z. B.:
requests | where operation_Name == "Request-Response-Workflow" | extend correlation = todynamic(tostring(customDimensions.correlation)) | where correlation.clientTrackingId == "123456"
Abfragetrigger und Aktionsereignisse nach Lösungsname
Sie können eine Abfrage für die Tabelle „Anforderungen“ erstellen, um eine Teilmenge von Vorgangsereignissen basierend auf dem Workflownamen und dem Lösungsnamen anzuzeigen.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Um alle Vorgangsereignisse mit einer bestimmten Clientnachverfolgungs-ID in einem bestimmten Workflow anzuzeigen, erstellen und starten Sie eine Abfrage, wobei der Wert operation_Name auf den Workflownamen festgelegt ist und der Eigenschaftswert solutionName auf den gewünschten Wert, z. B.:
requests | where operation_Name == "Request-Response-Workflow" and customDimensions has "trackedProperties" | extend trackedProperties = todynamic(tostring(customDimensions.trackedProperties)) | where trackedProperties.solutionName == "LA-AppInsights"
Wiederholungsversuche
Um zu zeigen, wie diese Daten in die Tabelle „Anforderungen“ gelangen, verwendet der folgende Standardworkflow eine HTTP-Aktion, die eine URL aufruft, die nicht aufgelöst wird. Der Workflow verfügt auch über eine Wiederholungsrichtlinie, die auf ein festes Intervall festgelegt ist, das dreimal wiederholt wird, einmal alle 60 Sekunden.
Abfragetrigger- und Aktionsereignisse für Wiederholungsversuche
Sie können eine Abfrage für die Tabelle „Anforderungen“ erstellen, um eine Teilmenge von Vorgangsereignissen mit Wiederholungsversuchen anzuzeigen.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Wenn Sie nur Trigger- und Aktionsereignisse mit Wiederholungsverlauf anzeigen möchten, erstellen Sie die folgende Abfrage in Application Insights, und führen Sie sie aus:
requests | extend retryHistory = tostring(tostring(customDimensions.retryHistory)) | where isnotempty(retryHistory)Um die Wiederholungsversuche für einen bestimmten Vorgang mit einer Wiederholungsrichtlinie anzuzeigen, erweitern Sie die Zeile für diesen Vorgang.
Das folgende Beispiel zeigt die aufgeklappten Details für die HTTP-Aktion :
Die Erfolgs- und Ergebniscode-Eigenschaftswerte deuten darauf hin, dass die HTTP-Aktion fehlgeschlagen ist. Zusammen mit den Eigenschaften, die in der Abfrage der Tabelle „Anforderungen“ für alle Trigger- und Aktionsereignisse beschrieben sind, enthält der Datensatz die folgenden Informationen, die drei Wiederholungsversuche umfassen:
Eigenschaft BESCHREIBUNG Beispiel retryHistory Verlaufsdetails für mindestens einen Wiederholungsversuch code Fehlertyp für einen bestimmten Wiederholungsversuch error Details zu dem spezifischen Fehler, der aufgetreten ist
Abfragetrigger- und Aktionsereignisse für die Connectorverwendung
Sie können eine Abfrage für die Tabelle „Anforderungen“ erstellen, um eine Teilmenge von Vorgangsereignissen basierend auf der spezifischen Connectorverwendung anzuzeigen.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Um alle Triggerereignisse mit einem bestimmten Connectortyp anzuzeigen, erstellen und starten Sie eine Abfrage mit den folgenden Eigenschaften und Werten:
requests | where customDimensions.Category == "Workflow.Operations.Triggers" and customDimensions.triggerType =="ApiConnectionWebhook" and customDimensions.apiName =="commondataservice"Eigenschaft Beispielwert customDimensions.Category Workflow.Operations.Triggers customDimensions.triggerType Der Vorgangstyp, z.B. ApiConnectionWebhook customDimensions.apiName Der API-Name des Connectors im JSON-Format, z. B. commondataservice für den Microsoft Dataverse-Connector 
Um alle Aktionsereignisse mit einer bestimmten Connectorverwendung anzuzeigen, erstellen und starten Sie eine Abfrage, wobei der Wert customDimensions.Category auf Workflow.Operations.Actions festgelegt ist, der Wert customDimensions.triggerType auf den Vorgangstyp, und der customDimensions.apiName auf den API-Namen des Connectors im JSON-Format, z. B.:
Eigenschaft Beispielwert customDimensions.Category Workflow.Operations.Actions customDimensions.triggerType Der Vorgangstyp, z. B. ApiConnection customDimensions.apiName Der API-Name des Connectors im JSON-Format, z. B.Office365 für den Microsoft Office 365 Outlook-Connector requests | where customDimensions.Category == "Workflow.Operations.Actions" and customDimensions.actionType == "ApiConnection" and customDimensions.apiName == "office365"
Für Trigger und Aktionen unterscheidet Application Insights zwischen den Typen von Verbindungen, die vorhanden sind. Möglicherweise werden unterschiedliche Werte in den Feldern actionType und triggerType angezeigt, je nachdem, ob die Verbindung über ApiConnection, ApiConnectionWebhook, den integrierten Basistyp wie Request oder den integrierten Anbietertyp ServiceProvider verfügt.
Tabelle „Ablaufverfolgungen“
Die Tabelle „Ablaufverfolgungen“ enthält Felder, die Daten zu den folgenden Ereignissen im Standardworkflow nachverfolgen:
Start- und Endereignisse des Workflows
Diese Informationen werden aufgrund des Potenzials für lange Workflowausführungen als zwei unterschiedliche Ereignisse dargestellt.
Senden und Empfangen von Ereignissen
Weitere Informationen finden Sie unter Verwenden integrierter Batchvorgänge in Azure Logic Apps (Standard)
Die folgende Liste enthält Beispielabfragen, die Sie für die Tabelle „Ablaufverfolgungen“ erstellen und ausführen können:
| Task | Schritte |
|---|---|
| Anzeigen von Start- und Endereignissen in allen Workflowausführungen | Abfrage für Start- und Endereignisse in allen Workflowausführungen |
| Anzeigen von Start- und Endereignissen in einer bestimmten Workflowausführung | Abfragen von Start- und Endereignissen in einem Workflowlauf |
| Anzeigen von Batch-Sende- und Empfangsereignissen in allen Workflowausführungen | Abfrage für Batch-Sende- und Batch-Empfangen-Ereignisse in allen Workflowausführungen |
Abfrage für Start- und Endereignisse in allen Workflowausführungen
Sie können eine Abfrage für die Tabelle „Ablaufverfolgungen“ erstellen, um alle Start- und Endereignisse für alle Workflowausführungen anzuzeigen.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Erstellen und Ausführen einer Abfrage mit dem Wert customDimensions.Category, der auf Workflow.Operations.Runsfestgelegt ist, z. B.:
traces | where customDimensions.Category == "Workflow.Operations.Runs"
Abfragen von Start- und Endereignissen in einer bestimmten Workflowausführung
Sie können eine Abfrage für die Tabelle „Ablaufverfolgungen“ erstellen, um die Start- und Endereignisse für eine bestimmte Workflowausführung anzuzeigen.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Erstellen und Ausführen einer Abfrage mit dem WertcustomDimensions.Category auf Workflow.Operations.Runs und dem Wert operation_Id auf die Workflowausführungs-ID festgelegt, z. B.:
traces | where customDimensions.Category == "Workflow.Operations.Runs" | and operation_Id == "08585287571846573488078100997CU00"
Abfrage für Batch-Sende- und Batch-Empfangen-Ereignisse in allen Workflowausführungen
Sie können eine Abfrage für die Tabelle „Ablaufverfolgungen“ erstellen, um die Ereignisse zum Senden und Empfangen des Batchs in allen Workflowausführungen anzuzeigen.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Erstellen und Ausführen einer Abfrage mit dem WertcustomDimensions.Category auf Workflow.Operations.Runs und dem Wert operation_Id auf die Workflowausführungs-ID festgelegt, z. B.:
traces | where customDimensions.Category == "Workflow.Operations.Batch"
Tabelle „Ausnahmen“
Die Tabelle „Ausnahmen“ enthält Felder, die Daten zu Ausnahmeereignissen in Standardworkflowausführungen nachverfolgen. Um zu zeigen, wie Daten in diese Felder gelangen, nehmen Sie an, sie haben den folgenden Standardworkflow, der mit dem Anforderungstrigger beginnt, gefolgt von der Aktion zum Verfassen und der Antwortaktion. Die Verfassen-Aktion verwendet einen Ausdruck, der einen Wert durch Null dividiert, wodurch eine Ausnahme generiert wird:
Abfragen von Ausnahmeereignissen in allen Workflowausführungen
Sie können eine Abfrage für die Ausnahmentabelle erstellen, um die Ausnahmeereignisse in allen Workflowausführungen anzuzeigen.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Um alle Ausnahmeereignisse anzuzeigen, erstellen und starten Sie die folgende Abfrage in Application Insights:
exceptions | sort by timestamp descUm die Details für eine bestimmte Ausnahme anzuzeigen, erweitern Sie die Zeile für diese Ausnahme:
Das folgende Beispiel zeigt die erweiterte Ausnahme für die Verfassen-Aktion und Details zur Ausnahme:
Eigenschaft Beschreibung problemId Ausnahmetyp oder eine kurze Beschreibung zu der Ausnahme, die aufgetreten ist outerMessage Ausführlichere Beschreibung zur Ausnahme details Ausführliche und vollständigste Informationen zur Ausnahme clientTrackingId Clientnachverfolgungs-ID, falls angegeben workflowId ID für den Workflow, für den die Ausnahme aufgetreten ist workflowName Name für den Workflow, für den die Ausnahme aufgetreten ist runId ID für die Workflowausführungsinstanz actionName Name für die Aktion, die mit der Ausnahme fehlgeschlagen ist operation_Name Name für den Workflow, für den die Ausnahme aufgetreten ist operation_Id ID für die Komponente oder den Workflow, die gerade ausgeführt wurde. Diese ID ist identisch mit dem RunId-Wert für die Workflowausführungsinstanz. Dieser Wert überschreitet Tabellen, sodass Sie diesen Ausnahmedatensatz mit der Workflowausführungsinstanz verknüpfen können. operation_ParentId ID für den Workflow, der die Aktion aufgerufen hat, die Sie mit der ID der Aktion in der Tabelle „Anforderungen“ verknüpfen können Um die Ausnahmen für einen bestimmten Workflow anzuzeigen, erstellen und starten Sie die folgende Abfrage:
exceptions | where operation_Name contains "Request-Response-Workflow-Exception"
Tabelle „Abhängigkeiten“
Die Tabelle „Abhängigkeiten“ enthält Felder, die Daten zu Abhängigkeitsereignissen in Standardworkflowausführungen nachverfolgen. Diese Ereignisse werden ausgegeben, wenn eine Ressource eine andere Ressource aufruft und beide Ressourcen Application Insights verwenden. Beispiele für Azure Logic Apps sind ein Dienst, der einen anderen Dienst über HTTP, eine Datenbank oder ein Dateisystem aufruft. Application Insights misst die Dauer von Abhängigkeitsaufrufen und ob diese Aufrufe erfolgreich sind oder fehlschlagen, zusammen mit Informationen wie dem Abhängigkeitsnamen. Sie können bestimmte Abhängigkeitsaufrufe untersuchen und sie mit Anforderungen und Ausnahmen korrelieren.
Um zu zeigen, wie Daten in diese Felder gelangen, nehmen Sie an, dass Sie über den folgenden Standard-übergeordneten Workflow verfügen, der einen untergeordneten Workflow über HTTP mithilfe der HTTP-Aktion aufruft:
Abfragen von Abhängigkeitsereignissen in einem bestimmten Workflow
Sie können eine Abfrage für die Tabelle „Abhängigkeiten“ erstellen, um die Abhängigkeitsereignisse in einer bestimmten Workflowausführung anzuzeigen.
Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.
Um Abhängigkeitsereignisse zwischen dem übergeordneten und dem untergeordneten Workflow anzuzeigen, erstellen und starten Sie die folgende Abfrage:
union requests, dependencies | where operation_Id contains "<runId>"Diese Abfrage verwendet den Union-Operator, um Datensätze aus der Tabelle „Anforderungen“ und „Abhängigkeiten“ zurückzugeben. Die Abfrage verwendet auch den Eigenschaftswert operation_Id, um die Verknüpfung zwischen Datensätzen bereitzustellen, indem der gewünschte Wert für den Workflow runId-Wert angeben wird, z. B.:
union requests, dependencies | where operation_Id contains "08585355753671110236506928546CU00"Das folgende Beispiel zeigt ein Abhängigkeitsereignis für den angegebenen Workflow, einschließlich Datensätze für die Vorgangsereignisse im übergeordneten Workflow aus der Tabelle „Anforderungen“ und dann einen Abhängigkeitsdatensatz aus der Tabelle „Abhängigkeiten“:
Für die Vorgangsereignisdatensätze zeigt die Spalte ItemType deren Datensatztypen als Anforderung an. Für den Abhängigkeitsdatensatz gibt die Spalte ItemType den Datensatztyp als Abhängigkeit an.
Eigenschaft Beschreibung runId ID für die Workflowausführungsinstanz actionName Name für die Aktion, in der das Abhängigkeitsereignis auftritt operation_Id ID für den angegebenen Workflow. Diese ID ist identisch mit dem RunId-Wert für die Workflowausführungsinstanz. Dieser Wert überschreitet Tabellen, sodass Sie diesen Abhängigkeitsdatensatz mit der Workflowausführungsinstanz verknüpfen können. operation_ParentId ID für die Aktion, in der das Abhängigkeitsereignis auftritt, das auch den Ereignisdatensatz des Vorgangs und den Abhängigkeitsereignisdatensatz miteinander verknüpft
Mit Ihrer Abfrage können Sie auch den Abhängigkeitsaufruf von einem übergeordneten Workflow zu einem untergeordneten Workflow visualisieren, wenn Sie die Anwendungszuordnung in Application Insights verwenden. Der Wert operation_Id in Ihrer Abfrage stellt den Link bereit, der diese Visualisierung ermöglicht.
Um die Anwendungszuordnung zu öffnen, wählen Sie im Ressourcenmenü „Application Insights“ unter Untersuchen die Option Anwendungszuordnung aus.
Filtern von Ereignissen
In Application Insights können Sie Ereignisse auf folgende Weise filtern:
Erstellen und Ausführen von Abfragen, wie in früheren Abschnitten beschrieben.
Filtern Sie an der Quelle, indem Sie Kriterien angeben, die vor dem Ausgeben von Ereignissen ausgewertet werden sollen.
Durch das Anwenden von Filtern an der Quelle können Sie den erforderlichen Speicher und dadurch die Betriebskosten reduzieren.
Anwenden der Filterung an der Quelle
In der Tabelle „Anforderungen“ oder „Ablaufverfolgungen“ weist ein Datensatz einen Knoten mit dem Namen customDimensionsauf, der eine Eigenschaft Kategorie enthält. In der Tabelle „Anforderungen“ sieht der Anforderungsdatensatz für ein Batchtriggerereignis z. B. ähnlich wie im folgenden Beispiel aus:
In der Tabelle „Anforderungen“ können die folgenden EigenschaftswerteKategorie Ihnen dabei helfen, unterschiedliche Ausführlichkeitsebenen zu unterscheiden und zuzuordnen:
| Kategoriewert | Beschreibung |
|---|---|
| Workflow.Operations.Triggers | Identifiziert einen Anforderungsdatensatz für ein Triggerereignis |
| Workflow.Operations.Actions | Identifiziert einen Anforderungsdatensatz für ein Aktionsereignis |
Für jeden Wert Kategorie können Sie die Ausführlichkeitsebene in der Host.json-Datei für Ihre Logik-App-Ressource oder Ihr Projekt unabhängig festlegen. Um beispielsweise nur die Datensätze für Trigger- oder Aktionsereignisse mit Fehlern zurückzugeben, können Sie in der Datei host.json das folgende JSON-Protokollierungsobjekt hinzufügen, das ein logLevel-JSON-Objekt mit den gewünschten Ausführlichkeitsebenen enthält:
{
"logging": {
"logLevel": {
"Workflow.Operations.Actions": "Error",
"Workflow.Operations.Triggers": "Error"
}
}
}
In den folgenden Beispielen für Ablaufverfolgungstabellendatensätze wird gezeigt, wie Sie die Ausführlichkeitsstufe für Ereignisse ändern können:
{
"logging": {
"logLevel": {
"Workflow.Host": "Warning",
"Workflow.Jobs": "Warning",
"Workflow.Runtime": "Warning"
}
}
}
Im folgenden Beispiel wird die standardmäßige Ausführlichkeitsstufe des Protokolls auf Warnung festgelegt, die Ausführlichkeitsstufe wird jedoch bei Information für Trigger-, Aktions- und Workflowausführungsereignisse beibehalten:
{
"logging": {
"logLevel": {
"default": "Warning",
"Workflow.Operations.Actions": "Information",
"Workflow.Operations.Runs": "Information",
"Workflow.Operations.Triggers": "Information"
}
}
}
Wenn Sie keine LogLevel-Werte angeben, ist die standardmäßige Ausführlichkeitsstufe Information. Weitere Informationen finden Sie unter Konfigurieren von Protokollierungsgraden.
Öffnen Sie im Azure-Portal Ihre Ressource vom Typ „Logic App (Standard)“.
Wählen Sie im Menü Ihrer Logik-App unter Entwicklungstools die Option Erweiterte Tools aus. Wählen Sie auf der Seite Erweiterte Tools die Option Goaus, wodurch die Kudu-Tools geöffnet werden.
Wählen Sie auf der Seite Kudu im Menü der Debugging-Konsole CMD. Navigieren Sie in der Ordnerverzeichnistabelle zur folgenden Datei, und wählen Sie Bearbeiten aus: site/wwwroot/host.json
Fügen Sie in der Datei host.json das JSON-Objekt Protokollierung hinzu, wobei die Werte logLevel auf die gewünschten Ausführlichkeitsebenen festgelegt sind:
{ "logging": { "logLevel": { "Workflow.Operations.Actions": "<verbosity-level>", "Workflow.Operations.Triggers": "<verbosity-level>" } } }
Anzeigen von Workflowmetriken in Application Insights
Mit den Telemetrieverbesserungen in Application Insights erhalten Sie auch Workfloweinblicke im Metrik-Dashboard.
Öffnen sie das Metrik-Dashboard, und richten Sie grundlegende Filter ein
Öffnen Sie die Application Insights-Ressource im Azure-Portal, wenn noch nicht geöffnet.
Wählen Sie im Ressourcenmenü „Application Insights“ unter Überwachung die Option Metriken aus.
Wählen Sie in der Bereichsliste Ihre Application Insights-Instanz aus.
Wählen Sie in der Liste Metrischer Namespace workflow.operations aus.
Wählen Sie in der Metrikliste eine Metrik aus, z. B. Ausführung abgeschlossen.
Wählen Sie in der Aggregationsliste einen Typ aus, z. B. Anzahl oder Mittelwert.
Wenn Sie fertig sind, zeigt das Metrik-Dashboard ein Diagramm mit den fertigen Workflowausführungen an.
Filtern basierend auf einem bestimmten Workflow
Wenn Sie multidimensionale Metriken im Metrik-Dashboard aktivieren, können Sie auf eine Teilmenge der gesamten in Application Insights erfassten Ereignisse abzielen und Ereignisse basierend auf einem bestimmten Workflow filtern.
Aktivieren Sie in Ihrer Application Insights-Ressource multidimensionale Metriken.
Öffnen Sie in Application Insights das Metrik-Dashboard.
Wählen Sie auf der Diagrammsymbolleiste Filter hinzufügen aus.
Wählen Sie in der Liste Eigenschaften die Option Workflow aus.
Wählen Sie in der Operatorliste das Gleichheitszeichen (=).
Wählen Sie in der Werte-Liste die gewünschten Workflows aus.
Anzeigen von „Live“-Protokolldaten und Metriken
Mit aktivierter erweiterter Telemetrie von Application Insights können Sie nahezu Echtzeitprotokolldaten und andere Metriken aus Ihrer Application Insights-Instanz im Azure-Portal anzeigen. Mit dieser Visualisierung können Sie eingehende Anforderungen, ausgehende Anforderungen und allgemeine Integrität darstellen. Außerdem erhalten Sie eine Tabelle für die Diagnose auf Ablaufverfolgungsebene.
Öffnen Sie die Application Insights-Ressource im Azure-Portal, wenn noch nicht geöffnet.
Wählen Sie im Ressourcenmenü „Application Insights“ unter Untersuchen die Option Live-Metriken aus.
Auf der Seite Live-Metriken werden die Protokolldaten und andere Metriken angezeigt, z. B.:
Weitere Informationen finden Sie unter Livemetriken: Überwachen und Diagnostizieren einer Latenz von 1 Sekunde.
Hinweis
Da standardmäßige Logik-App-Workflows auf Azure Functions basieren, unterstützt Live-Metriken diese Logik-App-Workflows.
Streamen und Anzeigen der Debugausgabe aus Anwendungsprotokolldateien
Mit aktivierter erweiterter Telemetrie von Application Insights können Sie ausführliche Debuginformationen im Azure-Portal für die Protokolldateien Ihrer Anwendung streamen. Diese Informationen entsprechen der Ausgabe, die aus dem Debuggen Ihres Workflows in Ihrer lokalen Visual Studio Code-Umgebung generiert wurde.
Öffnen Sie im Azure-Portal Ihre Ressource vom Typ „Logic App (Standard)“.
Wählen Sie im Ressourcenmenü der Logik-App unter Überwachung die Option Protokolldatenstrom " aus.
Die Protokolldatenstromseite stellt eine Verbindung mit Ihrer Application Insights-Instanz her und zeigt die Debugausgabe an. Die folgende Ausgabe enthält beispielsweise Anforderungs- und Antwortaufrufe:
