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

Application Insights öffnen

Nachdem Ihr Workflow eine Ausführung abgeschlossen hat und ein paar Minuten vergangen sind, öffnen Sie Ihre Application Insights-Ressource.

1. Wählen Sie im Azure-Portal im Menü Ihrer Logik-App unter Einstellungen die Option Application Insights aus.

2. 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.

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:

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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. Um alle Trigger- und Aktionsereignisse anzuzeigen, muss die folgende Abfrage erstellt und ausgeführt werden:

   requests
   | sort by timestamp desc
   | take 10
   

   Das 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.

3. 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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. 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"
   

   

3. 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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. 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"
   

   

3. 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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. 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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. 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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. 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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. 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)
   

3. 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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. 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

   

3. 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:

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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. 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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. 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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. 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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. Um alle Ausnahmeereignisse anzuzeigen, erstellen und starten Sie die folgende Abfrage in Application Insights:

   exceptions
   | sort by timestamp desc
   

3. Um 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

4. 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.

1. Wählen Sie bei Bedarf den Zeitbereich aus, den Sie bewerten möchten. Dieser Wert ist standardmäßig die letzten 24 Stunden.

2. 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:

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.

Entfernen von Speicherabhängigkeitsfehlern

Zum Filtern von Speicherabhängigkeitsfehlern, z. B. der Fehler 404 Nicht gefunden und 412 Fehler bei Vorbedingung, legen Sie den Protokolliergrad Host.Workflow auf Keinen fest, z. B.:

{
   "logging": {
      "logLevel": {
         "Workflow.Host": "Warning",
         "Workflow.Jobs": "Warning",
         "Workflow.Runtime": "Warning",
         "Host.Workflow": "None"
      }
   }
}

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

1. Öffnen Sie die Application Insights-Ressource im Azure-Portal, wenn noch nicht geöffnet.

2. Wählen Sie im Ressourcenmenü „Application Insights“ unter Überwachung die Option Metriken aus.

3. Wählen Sie in der Bereichsliste Ihre Application Insights-Instanz aus.

4. Wählen Sie in der Liste Metrischer Namespace workflow.operations aus.

5. Wählen Sie in der Metrikliste eine Metrik aus, z. B. Ausführung abgeschlossen.

6. 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.

1. Aktivieren Sie in Ihrer Application Insights-Ressource multidimensionale Metriken.

2. Öffnen Sie in Application Insights das Metrik-Dashboard.

3. Wählen Sie auf der Diagrammsymbolleiste Filter hinzufügen aus.

4. Wählen Sie in der Liste Eigenschaften die Option Workflow aus.

5. Wählen Sie in der Operatorliste das Gleichheitszeichen (=).

6. 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.

1. Öffnen Sie die Application Insights-Ressource im Azure-Portal, wenn noch nicht geöffnet.

2. 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.

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.

1. Öffnen Sie im Azure-Portal Ihre Ressource vom Typ „Logic App (Standard)“.

2. 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:

   

Nächste Schritte

Aktivieren oder Öffnen von Application Insights