Activer et afficher la télémétrie avancée dans Application Insights pour les workflows Standard dans Azure Logic Apps

Article
12/16/2024

S’applique à : Azure Logic Apps (Standard)

Dans Application Insights, vous pouvez activer la collecte améliorée de la télémétrie pour votre ressource d’application logique Standard, puis afficher les données collectées une fois que votre workflow a terminé une exécution. Cette fonctionnalité vous offre une expérience simplifiée pour trouver des informations sur vos flux de travail et avoir un meilleur contrôle sur le filtrage des événements à la source de données, ce qui vous permet de réduire les coûts de stockage. Ces améliorations se concentrent sur des mesures de performance en temps réel qui fournissent des informations sur l’intégrité et le comportement de votre système. Cela peut vous aider à détecter et résoudre les problèmes plus tôt de manière proactive.

Avec votre application logique connectée à Application Insights, vous pouvez afficher les données des journaux et d’autres indicateurs quasiment en temps réel via le portail Azure, à l’aide du Flux de métriques temps réel. Vous disposez également de visualisations pour vous aider à tracer les requêtes entrantes, les requêtes sortantes et l’intégrité globale, et pour accéder à une table des diagnostics de niveau de trace.

La liste suivante décrit quelques exemples d’améliorations de télémétrie :

Les événements liés aux déclencheurs et aux actions incluent désormais le type de déclencheur ou d’action et le nom de l’API, ce qui vous permet d’interroger une utilisation spécifique du connecteur.
Suivi plus facile des événements de nouvelle tentative.
Capture des exceptions pour les échecs de déclencheur et d’action.
Contrôle supplémentaire sur le filtrage des événements non liés au flux de travail.
Filtrage avancé qui vous permet de mieux contrôler la façon dont les événements sont émis, y compris les déclencheurs et les actions.

Ce guide montre comment activer la collecte améliorée de données de télémétrie dans Application Insights pour votre application logique standard.

Prérequis

Un compte et un abonnement Azure. Si vous n’avez pas encore d’abonnement, vous pouvez vous inscrire pour obtenir un compte Azure gratuitement.
Une instance Application Insights. Vous créez cette ressource à l’avance lorsque vous créez votre application logique Standard ou après le déploiement de l’application logique.
Une application logique et un workflow Standard, soit dans le portail Azure, soit dans Visual Studio Code.
- Votre ressource ou projet d’application logique doit utiliser le runtime Azure Functions v4, qui est activé par défaut.
- Votre application logique doit avoir Application Insights activé pour la journalisation et le suivi des diagnostics. Vous pouvez le faire lorsque vous créez votre application logique ou après le déploiement.

Activer la télémétrie avancée dans Application Insights

Portail
Visual Studio Code

Dans le portail Azure, ouvrez votre ressource d’application logique Standard.
Dans le menu de l’application logique, sous Outils de développement, sélectionnez Outils avancés. Dans la page Outils avancés, sélectionnez Accéder pour ouvrir les outils Kudu.
Dans la page Kudu, dans le menu Debug console, sélectionnez CMD. Dans le tableau des répertoires de dossiers, accédez au fichier suivant et sélectionnez Edit: site/wwwroot/host.json

Dans le fichier host.json, ajoutez le code JSON suivant :

{
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
      "version": "[1, 2.00]"
   },
   "extensions": {
      "workflow": {
         "Settings": {
            "Runtime.ApplicationInsightTelemetryVersion": "v2"
         }
      }
   }
}

Cette configuration permet d’avoir le niveau de verbosité par défaut. Pour d’autres options, consultez Appliquer le filtrage à la source.

Dans Visual Studio Code, ouvrez votre projet d’application logique et le fichier host.json du projet.

Dans le fichier host.json, ajoutez le code JSON suivant :

{
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
      "version": "[1, 2.00]"
   },
   "extensions": {
      "workflow": {
         "Settings": {
            "Runtime.ApplicationInsightTelemetryVersion": "v2"
         }
      }
   }
}

Cette configuration permet d’avoir le niveau de verbosité par défaut. Pour d’autres options, consultez Appliquer le filtrage à la source.

Ouvrir Application Insights

Une fois que votre workflow a terminé une exécution, et après quelques minutes, ouvrez votre ressource Application Insights.

Dans le portail Azure, dans le menu de votre application logique, sous Paramètres, sélectionnez Application Insights.
Dans le menu de ressources Application Insights, sous Surveillance, sélectionnez Journaux.

Afficher les journaux avancés dans Application Insights

Les sections suivantes décrivent les tableaux d’Application Insights dans lesquels vous pouvez rechercher et afficher la télémétrie avancée générée par l’exécution de votre workflow.

Nom de table	Description
Demandes	Détails sur les événements suivants dans les exécutions de workflow : - Événements de déclencheur et d’action - Nouvelles tentatives - Utilisation de connecteur
Traces	Détails sur les événements suivants dans les exécutions de workflow : - Événements de début et de fin de workflow - Événements d’envoi et de réception par lots
Exceptions	Détails sur les événements d’exception dans les exécutions de workflow
Dépendances	Détails sur les événements de dépendance dans les exécutions de workflow

Table de requêtes

Le tableau Requêtes contient des champs qui suivent les données sur les événements suivants dans les exécutions de workflow Standard :

Événements de déclencheur et d’action
Nouvelles tentatives
Utilisation de connecteur

Pour montrer comment les données sont introduites dans ces champs, supposons que vous avez l’exemple de workflow Standard suivant qui commence par le déclencheur Request suivi de l’action Compose et de l’action Response.

Capture d’écran montrant le portail Azure et le concepteur de flux de travail Standard avec déclencheur et actions.

La configuration du déclencheur inclut un paramètre appelé ID de suivi personnalisé. La valeur du paramètre est définie sur une expression qui extrait la valeur de propriété orderId du corps d’un message entrant :

Capture d’écran montrant le portail Azure, le flux de travail Standard, le déclencheur de requête sélectionné, l’onglet Paramètres et l’ID de suivi personnalisé.

Ensuite, les paramètres de l’action Compose du workflow ont une propriété suivie qui a été ajoutée et qui s’appelle solutionName. La valeur de propriété est définie avec le nom de la ressource d’application logique.

Capture d’écran montrant le portail Azure, le flux de travail Standard, l’action Composer sélectionnée, l’onglet Paramètres et la propriété suivie.

L’action Compose est suivie d’une action Response qui retourne une réponse à l’appelant.

La liste suivante contient des exemples de requêtes que vous pouvez créer et exécuter dans le tableau Requêtes :

Tâche	Étapes
Afficher tous les événements de déclencheur et d’action	Requête pour tous les événements de déclencheur et d’action
Afficher uniquement les événements de déclencheur ou les événements d’action	Requête pour les événements de déclencheur ou d’action uniquement
Afficher les événements de déclencheur ou d’action avec un type d’opération spécifique	Requête pour les événements de déclencheur ou d’action par type d’opération
Afficher les événements de déclencheur et d’action avec un ID d’exécution de workflow spécifique	Requête pour les événements de déclencheur et d’action par ID d’exécution de workflow
Afficher les événements de déclencheur et d’action avec un ID de suivi client spécifique	Requête pour les événements de déclencheur et d’action par ID de suivi client
Afficher les événements de déclencheur et d’action avec un nom de solution spécifique	Requête pour les événements de déclencheur et d’action par nom de solution
Afficher les événements de déclencheur et d’action avec les nouvelles tentatives	Requête pour les événements de déclencheur et d’action pour les nouvelles tentatives
Afficher les événements de déclencheur et d’action avec l’utilisation de connecteur	Requête pour les événements de déclencheur et d’action pour l’utilisation de connecteur

Requête pour tous les événements de déclencheur et d’action

Une fois que le workflow est exécuté, et après quelques minutes, vous pouvez créer une requête dans le tableau Requêtes pour afficher tous les événements d’opération.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.

Pour afficher tous les événements de déclencheur et d’action, créez et exécutez la requête suivante :

requests
| sort by timestamp desc
| take 10

L’exemple suivant montre l’onglet Résultats avec les colonnes et données notées dans chaque ligne :

Colonne	Description	Exemple
name	Nom des opérations de workflow	Pour cet exemple, les lignes affichent manual (déclencheur de requête), Compose et Response.
success	État d’exécution des opérations	Pour cet exemple, toutes les lignes affichent True pour une exécution réussie. Si une erreur s’est produite, la valeur est False.
resultCode	Code d’état d’exécution des opérations	Pour cet exemple, toutes les lignes affichent Succeeded (200).
duration	Durée d’exécution des opérations	Varie pour chaque opération.

Pour afficher les détails d’une opération spécifique, développez la ligne du déclencheur ou de l’action :

L’exemple suivant montre les détails développés pour le déclencheur Request :

Propriété	Description	Exemple
Catégorie	Catégorie d’opération, qui est toujours Workflow.Operations.Triggers ou Workflow.Operations.Actions, en fonction de l’opération	Workflow.Operations.Triggers.
clientTrackingId	ID de suivi personnalisé, s’il est spécifié	123456
runId	ID de l’instance d’exécution du workflow	08585358375819913417237801890CU00
triggerName	Nom du déclencheur	manual
workflowId	ID du workflow qui a exécuté le déclencheur	c7711d107e6647179c2e15fe2c2720ce
workflowName	Nom du workflow qui a exécuté le déclencheur	Request-Response-Workflow
operation_Name	Nom de l’opération qui a exécuté le déclencheur. Dans ce cas, ce nom est identique au nom du workflow.	Request-Response-Workflow
operation_Id	ID du composant ou du workflow qui vient d’être exécuté. Cet ID est identique à la valeur runId de l’instance d’exécution du workflow. Si des exceptions ou des dépendances existent, cette valeur transcende les tables afin de vous permettre de lier cet enregistrement de déclencheur à ces exceptions ou dépendances.	08585358375819913417237801890CU00
operation_ParentId	ID pouvant être lié pour le workflow qui a appelé le déclencheur	f95138daff8ab129

L’exemple suivant montre les détails développés pour l’action Compose :

Propriété	Description	Exemple
Catégorie	Catégorie d’opération, qui est toujours Workflow.Operations.Triggers ou Workflow.Operations.Actions, en fonction de l’opération	Workflow.Operations.Actions
clientTrackingId	ID de suivi personnalisé, s’il est spécifié	123456
actionName	Nom de l’action	Composer.
runId	ID de l’instance d’exécution du workflow	08585358375819913417237801890CU00
workflowId	ID du workflow qui a exécuté l’action	c7711d107e6647179c2e15fe2c2720ce
workflowName	Nom du workflow qui a exécuté l’action	Request-Response-Workflow
solutionName	Nom de la propriété suivie, s’il est spécifié	LA-AppInsights
operation_Name	Nom de l’opération qui a exécuté l’action. Dans ce cas, ce nom est identique au nom du workflow.	Request-Response-Workflow
operation_Id	ID du composant ou du workflow qui vient d’être exécuté. Cet ID est identique à la valeur runId de l’instance d’exécution du workflow. Si des exceptions ou des dépendances existent, cette valeur transcende les tables afin de vous permettre de lier cet enregistrement d’action à ces exceptions ou dépendances.	08585358375819913417237801890CU00
operation_ParentId	ID pouvant être lié pour le workflow qui a appelé l’action	f95138daff8ab129

Requête pour les événements de déclencheur ou d’action uniquement

Vous pouvez créer une requête dans la table Requêtes pour afficher un sous-ensemble d’événements d’opération, en fonction de la catégorie d’opération et du nom du workflow.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.
Pour afficher tous les événements de déclencheur dans un workflow spécifique, créez et exécutez une requête avec la valeur de propriété customDimensions.Category définie sur Workflow.Operations.Triggers et operation_Name défini sur le nom du workflow, par exemple :
```
requests
| where customDimensions.Category == "Workflow.Operations.Triggers" and operation_Name == "Request-Response-Workflow"
```
Pour afficher tous les événements d’action dans un workflow spécifique, créez une requête avec la valeur de propriété customDimensions.Category définie sur Workflow.Operations.Actions et operation_Name défini sur le nom du workflow, par exemple :
```
requests
| where customDimensions.Category == "Workflow.Operations.Actions" and operation_Name == "Request-Response-Workflow"
```

Requête pour les événements de déclencheur ou d’action par type d’opération

Vous pouvez créer une requête dans la table Requêtes pour afficher les événements d’un déclencheur ou d’un type d’action spécifique.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.
Pour afficher tous les événements d’opération avec un type de déclencheur spécifique, créez et exécutez une requête avec la valeur customDimensions.triggerType définie sur le type de déclencheur de votre choix, par exemple :
```
requests
| where customDimensions.triggerType == "Request"
```
Pour afficher tous les événements d’opération avec un type d’action spécifique, créez et exécutez une requête avec la valeur customDimensions.actionType définie sur le type d’action de votre choix, par exemple :
```
requests
| where customDimensions.actionType == "Compose"
```

Requête pour les événements de déclencheur et d’action par ID d’exécution de workflow

Vous pouvez créer une requête dans la table Requêtes pour afficher un sous-ensemble d’événements d’opération, en fonction de l’ID d’exécution de workflow. Cet ID d’exécution de workflow est le même ID que celui que vous trouverez dans l’historique des exécutions du workflow.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.
Pour afficher tous les événements d’opération avec un ID d’exécution de workflow spécifique, créez et exécutez une requête avec la valeur operation_Id définie sur l’ID d’exécution de workflow, par exemple :
```
requests
| where operation_Id == "08585287554177334956853859655CU00"
```

Requête pour les événements de déclencheur et d’action par ID de suivi client

Vous pouvez créer une requête dans la table Requêtes pour afficher un sous-ensemble d’événements d’opération, en fonction du nom du workflow et de l’ID de suivi client.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.
Pour afficher tous les événements d’opération avec un ID de suivi client spécifique dans un workflow spécifique, créez et exécutez une requête avec la valeur operation_Name définie sur le nom du workflow et la valeur de propriété clientTrackingId définie sur la valeur de votre choix, par exemple :
```
requests
| where operation_Name == "Request-Response-Workflow"
| extend correlation = todynamic(tostring(customDimensions.correlation))
| where correlation.clientTrackingId == "123456"
```

Requête pour les événements de déclencheur et d’action par nom de solution

Vous pouvez créer une requête dans la table Requêtes pour afficher un sous-ensemble d’événements d’opération, en fonction du nom du workflow et du nom de la solution.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.
Pour afficher tous les événements d’opération avec un ID de suivi client spécifique dans un workflow spécifique, créez et exécutez une requête avec la valeur operation_Name définie sur le nom du workflow et la valeur de propriété solutionName définie sur la valeur de votre choix, par exemple :
```
requests
| where operation_Name == "Request-Response-Workflow" and customDimensions has "trackedProperties"
| extend trackedProperties = todynamic(tostring(customDimensions.trackedProperties))
| where trackedProperties.solutionName == "LA-AppInsights"
```

Nouvelles tentatives

Pour montrer comment ces données sont introduites dans la table Requêtes, l’exemple de workflow Standard suivant utilise une action HTTP qui appelle une URL, qui n’effectue pas de résolution. Le workflow a également une stratégie de nouvelle tentative définie sur un intervalle fixe qui retente trois fois, une fois toutes les 60 secondes.

Capture d’écran montrant le portail Azure, le flux de travail Standard, l’action HTTP sélectionnée, l’onglet Paramètres et la stratégie de nouvelle tentative.

Requête pour les événements de déclencheur et d’action pour les nouvelles tentatives

Vous pouvez créer une requête dans la table Requêtes pour afficher un sous-ensemble d’événements d’opération avec les nouvelles tentatives.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.
Pour afficher uniquement les événements de déclencheur et d’action avec l’historique des nouvelles tentatives, créez et exécutez la requête suivante dans Application Insights :
```
requests
| extend retryHistory = tostring(tostring(customDimensions.retryHistory))
| where isnotempty(retryHistory)
```

Pour afficher les nouvelles tentatives d’une opération spécifique avec une stratégie de nouvelle tentative, développez la ligne de cette opération.

L’exemple suivant montre les détails développés pour l’action HTTP :

Les valeurs de propriété success et resultCode indiquent que l’action HTTP a échoué. En plus des propriétés décrites dans Interroger la table Requêtes pour tous les événements de déclencheur et d’action, l’enregistrement contient les informations suivantes, qui incluent trois nouvelles tentatives :

Propriété	Description	Exemple
retryHistory	Détails de l’historique pour une ou plusieurs nouvelles tentatives
code	Type d’erreur pour une nouvelle tentative spécifique
error	Détails sur l’erreur spécifique qui s’est produite

Requête pour les événements de déclencheur et d’action pour l’utilisation de connecteur

Vous pouvez créer une requête dans la table Requêtes pour afficher un sous-ensemble d’événements d’opération, en fonction d’une utilisation de connecteur spécifique.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.

Pour afficher tous les événements de déclencheur à l’aide d’un type de connecteur spécifique, créez et exécutez une requête avec les propriétés et valeurs suivantes :

requests
| where customDimensions.Category == "Workflow.Operations.Triggers" and customDimensions.triggerType =="ApiConnectionWebhook" and customDimensions.apiName =="commondataservice"

Propriété	Valeur d'exemple
customDimensions.Category	Workflow.Operations.Triggers
customDimensions.triggerType	Type d’opération, par exemple, ApiConnectionWebhook
customDimensions.apiName	Le nom de l’API du connecteur au format JSON, par exemple commondataservice, pour le connecteur Microsoft Dataverse

Capture d’écran montrant Application Insights, l’onglet Résultats pour les événements de déclencheur Microsoft Dataverse avec connexion ApiConnectionWebhook.

Pour afficher tous les événements d’action avec une utilisation de connecteur spécifique, créez et exécutez une requête avec la valeur customDimensions.Category définie sur Workflow.Operations.Actions, la valeur customDimensions.triggerType définie sur le type d’opération et la valeur customDimensions.apiName définie sur le nom de l’API du connecteur au format JSON, par exemple :

Propriété	Valeur d'exemple
customDimensions.Category	Workflow.Operations.Actions
customDimensions.triggerType	Type d’opération, par exemple, ApiConnection
customDimensions.apiName	Le nom de l’API du connecteur au format JSON, par exemple office365, pour le connecteur Microsoft Office 365 Outlook

requests
| where customDimensions.Category == "Workflow.Operations.Actions" and customDimensions.actionType == "ApiConnection" and customDimensions.apiName == "office365"

Capture d’écran montrant Application Insights, l’onglet Résultats pour les événements d’action Microsoft Office 365 Outlook avec connexion ApiConnection.

Pour les déclencheurs et les actions, Application Insights différencie les types de connexions qui existent. Vous risquez de voir différentes valeurs dans les champs actionType et triggerType selon si la connexion a ApiConnection, ApiConnectionWebhook, le type de base intégré tel que Request ou le type intégré ServiceProvider basé sur un fournisseur de services.

Table des traces

Le tableau Traces contient des champs qui suivent les données sur les événements suivants dans les exécutions de workflow Standard :

Événements de début et de fin de workflow

Ces informations sont représentées sous la forme de deux événements distincts en raison du risque d’exécutions de workflow de longue durée.
Événements d’envoi et de réception par lots

Pour plus d’informations, consultez Utilisation d’opérations par lots intégrées dans Azure Logic Apps (Standard)

La liste suivante contient des exemples de requêtes que vous pouvez créer et exécuter dans la table Traces :

Tâche	Étapes
Afficher les événements de début et de fin dans toutes les exécutions de workflow	Requête pour les événements de début et de fin dans toutes les exécutions de workflow
Afficher les événements de début et de fin dans une exécution de workflow spécifique	Requête pour les événements de début et de fin dans une exécution de workflow
Afficher les événements d’envoi et de réception par lots dans toutes les exécutions de workflow	Requête pour les événements d’envoi et de réception par lots dans toutes les exécutions de workflow

Requête pour les événements de début et de fin dans toutes les exécutions de workflow

Vous pouvez créer une requête dans la table Traces pour afficher tous les événements de début et de fin pour toutes les exécutions de workflow.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.
Créez et exécutez une requête avec la valeur customDimensions.Category définie sur Workflow.Operations.Runs, par exemple :
```
traces
| where customDimensions.Category == "Workflow.Operations.Runs"
```

Requête pour les événements de début et de fin dans une exécution de workflow spécifique

Vous pouvez créer une requête dans la table Traces pour afficher les événements de début et de fin d’une exécution de workflow spécifique.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.
Créez et exécutez une requête avec la valeur customDimensions.Category définie sur Workflow.Operations.Runs et la valeur operation_Id définie sur l’ID d’exécution de workflow, par exemple :
```
traces
| where customDimensions.Category == "Workflow.Operations.Runs"
| and operation_Id == "08585287571846573488078100997CU00"
```

Requête pour les événements d’envoi et de réception par lots dans toutes les exécutions de workflow

Vous pouvez créer une requête dans la table Traces pour afficher les événements d’envoi et de réception par lot dans toutes les exécutions de workflow.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.
Créez et exécutez une requête avec la valeur customDimensions.Category définie sur Workflow.Operations.Runs et la valeur operation_Id définie sur l’ID d’exécution de workflow, par exemple :
```
traces
| where customDimensions.Category == "Workflow.Operations.Batch"
```

Table des exceptions

La table Exceptions contient des champs qui suivent les données sur les événements d’exception dans les exécutions de workflow Standard. Pour montrer comment les données sont introduites dans ces champs, supposons que vous avez l’exemple de workflow Standard suivant qui commence par le déclencheur Request suivi de l’action Compose et de l’action Response. L’action Compose utilise une expression qui divise une valeur par zéro, ce qui génère une exception :

Capture d’écran du portail Azure, le concepteur de workflows Standard, le déclencheur de requête, l’action Composer avec une expression générant une exception, et l'action Réponse.

Requête pour les événements d’exception dans toutes les exécutions de workflow

Vous pouvez créer une requête dans la table Exceptions pour afficher les événements d’exception dans toutes les exécutions de workflow.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.
Pour afficher tous les événements d’exception, créez et exécutez la requête suivante dans Application Insights :
```
exceptions
| sort by timestamp desc
```

Pour afficher les détails d’une exception spécifique, développez la ligne de l’exception :

L’exemple suivant montre l’exception développée pour l’action Compose et des détails sur l’exception :

Propriété	Description
problemId	Type d’exception ou courte description de l’exception qui s’est produite
outerMessage	Description plus détaillée de l’exception
details	Informations détaillées les plus complètes sur l’exception
clientTrackingId	ID de suivi client, s’il est spécifié
workflowId	ID du workflow qui a rencontré l’exception
workflowName	Nom du workflow qui a rencontré l’exception
runId	ID de l’instance d’exécution du workflow
actionName	Nom de l’action ayant échoué avec l’exception
operation_Name	Nom du workflow qui a rencontré l’exception
operation_Id	ID du composant ou du workflow qui vient d’être exécuté. Cet ID est identique à la valeur runId de l’instance d’exécution du workflow. Cette valeur transcende les tables, ce qui vous permet de lier cet enregistrement d’exception à l’instance d’exécution de workflow.
operation_ParentId	ID du workflow qui a appelé l’action, que vous pouvez lier à l’ID de l’action dans la table Requêtes

Pour afficher les exceptions d’un workflow spécifique, créez et exécutez la requête suivante :
```
exceptions
| where operation_Name contains "Request-Response-Workflow-Exception"
```

Table des dépendances

Le tableau Dépendances contient des champs qui suivent les données sur les événements de dépendance dans les exécutions de workflow Standard. Ces événements sont émis lorsqu’une ressource appelle une autre ressource et quand les deux ressources utilisent Application Insights. Un service appelant un autre service via HTTP, une base de données ou un système de fichiers sont autant d’exemples Azure Logic Apps. Application Insights mesure la durée des appels de dépendances et indiquent si ces appels réussissent ou échouent, avec des informations comme le nom des dépendances. Vous pouvez examiner des appels de dépendances spécifiques et les mettre en corrélation avec les requêtes et les exceptions.

Pour montrer comment les données sont introduites dans ces champs, supposons que vous avez l’exemple de workflow parent Standard suivant qui appelle un workflow enfant via HTTP à l’aide de l’action HTTP :

Capture d’écran montrant le portail Azure, le concepteur de flux de travail Standard avec flux de travail parent à l’aide de l’action HTTP pour appeler un flux de travail enfant.

Requête pour les événements de dépendance dans un workflow spécifique

Vous pouvez créer une requête dans la table Dépendances pour afficher les événements de dépendance dans une exécution de workflow spécifique.

Si nécessaire, sélectionnez l’intervalle de temps que vous souhaitez regarder. Par défaut, cette valeur correspond aux dernières 24 heures.

Pour afficher les événements de dépendance entre le workflow parent et le workflow enfant, créez et exécutez la requête suivante :

union requests, dependencies
| where operation_Id contains "<runId>"

Cette requête utilise l’opérateur union pour retourner des enregistrements de la table Requêtes et de la table Dépendances. La requête utilise également la valeur de propriété operation_Id pour fournir le lien entre les enregistrements en spécifiant la valeur runId de workflow de votre choix, par exemple :

union requests, dependencies
| where operation_Id contains "08585355753671110236506928546CU00"

L’exemple suivant montre un événement de dépendance pour le workflow spécifié, notamment les enregistrements des événements d’opération dans le workflow parent de la table Requêtes, puis un enregistrement de dépendance de la table Dépendances :

Pour les enregistrements d’événements d’opération, la colonne itemType affiche leurs types d’enregistrements en tant que requête. Pour l’enregistrement de dépendance, la colonne itemType indique le type d’enregistrement en tant que dépendance.

Propriété	Description
runId	ID de l’instance d’exécution du workflow
actionName	Nom de l’action où l’événement de dépendance se produit
operation_Id	ID du workflow spécifié. Cet ID est identique à la valeur runId de l’instance d’exécution du workflow. Cette valeur transcende les tables afin de vous permettre de lier cet enregistrement de dépendance à l’instance d’exécution de workflow.
operation_ParentId	ID de l’action où se produit l’événement de dépendance, qui lie également l’enregistrement d’événement d’opération et l’enregistrement d’événement de dépendance ensemble

Avec votre requête, vous pouvez également visualiser l’appel de dépendance entre un workflow parent et un workflow enfant lorsque vous utilisez la cartographie d’application dans Application Insights. La valeur operation_Id dans votre requête fournit le lien qui rend cette visualisation possible.

Pour ouvrir la cartographie d’application, dans le menu de ressources Application Insights, sous Investiguer, sélectionnez Cartographie d’application.

Capture d’écran montrant Application Insights et la mise en correspondance d'applications avec une dépendance entre le flux de travail parent et le flux de travail enfant.

Filtrer les événements

Dans Application Insights, vous pouvez filtrer des événements des manières suivantes :

Créer et exécuter des requêtes comme décrit dans les sections précédentes.
Filtrer à la source en spécifiant des critères à évaluer avant d’émettre des événements.

En appliquant des filtres à la source, vous pouvez réduire la quantité de stockage nécessaire et, par conséquent, les coûts d’exploitation.

Appliquer le filtrage à la source

Dans la table Requêtes ou Traces, un enregistrement a un nœud appelé customDimensions, qui contient une propriété Category. Par exemple, dans la table Requêtes, l’enregistrement de requête d’un événement de déclencheur par lots ressemble à l’exemple suivant :

Capture d’écran montrant Application Insights avec la table Requêtes et l’enregistrement d’un événement de déclencheur de messages Batch.

Dans la table Requêtes, les valeurs de propriété Category suivantes peuvent vous aider à différencier et à associer différents niveaux de verbosité :

Valeur de catégorie	Description
Workflow.Operations.Triggers	Identifie un enregistrement de requête pour un événement de déclencheur
Workflow.Operations.Actions	Identifie un enregistrement de requête pour un événement d’action

Pour chaque valeur Category, vous pouvez définir indépendamment le niveau de verbosité dans le fichier host.json pour votre ressource ou projet d’application logique. Par exemple, pour retourner uniquement les enregistrements des événements de déclencheur ou d’action qui ont des erreurs, dans le fichier host.json, vous pouvez ajouter l’objet JSON logging suivant, qui contient un objet JSON logLevel avec les niveaux de verbosité souhaités :

{
   "logging": {
      "logLevel": {
         "Workflow.Operations.Actions": "Error",
         "Workflow.Operations.Triggers": "Error"
      }
   }
}

Pour les enregistrements de la table Traces, les exemples suivants montrent comment changer le niveau de verbosité des événements :

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

L’exemple suivant définit le niveau de verbosité par défaut du journal sur Warning, mais conserve le niveau de verbosité sur Information pour les événements de déclencheur, d’action et d’exécution de workflow :

{
   "logging": {
      "logLevel": {
         "default": "Warning",
         "Workflow.Operations.Actions": "Information",
         "Workflow.Operations.Runs": "Information",
         "Workflow.Operations.Triggers": "Information"
      }
   }
}

Si vous ne spécifiez aucune valeur logLevel, le niveau de verbosité par défaut est Information. Pour plus d’informations, consultez Configurer les niveaux de journalisation.

Supprimer des erreurs de dépendance de stockage

Pour filtrer des erreurs de dépendance de stockage, comme les erreurs 404 Introuvable et les erreurs 412 Échec de la précondition, définissez le niveau de journal Host.Workflow sur Aucun, par exemple :

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

Portail
Visual Studio Code

Dans le portail Azure, ouvrez votre ressource d’application logique Standard.
Dans le menu de l’application logique, sous Outils de développement, sélectionnez Outils avancés. Dans la page Outils avancés, sélectionnez Accéder pour ouvrir les outils Kudu.
Dans la page Kudu, dans le menu Debug console, sélectionnez CMD. Dans le tableau des répertoires de dossiers, accédez au fichier suivant et sélectionnez Edit: site/wwwroot/host.json

Dans le fichier host.json, ajoutez l’objet JSON logging avec les valeurs logLevel définies sur les niveaux de verbosité souhaités :

{
   "logging": {
      "logLevel": {
         "Workflow.Operations.Actions": "<verbosity-level>",
         "Workflow.Operations.Triggers": "<verbosity-level>"
      }
   }
}

Dans Visual Studio Code, ouvrez votre projet d’application logique et le fichier host.json du projet.

Dans le fichier host.json, ajoutez l’objet JSON logging avec les valeurs logLevel définies sur les niveaux de verbosité souhaités :

{
   "logging": {
      "logLevel": {
         "Workflow.Operations.Actions": "<verbosity-level>",
         "Workflow.Operations.Triggers": "<verbosity-level>"
      }
   }
}

Afficher les métriques de workflow dans Application Insights

Avec la télémétrie avancée dans Application Insights, vous bénéficiez également d’insights de workflow dans le tableau de bord Métriques.

Ouvrir le tableau de bord Métriques et configurer les filtres de base

Dans le portail Azure, ouvrez votre ressource Application Insights si ce n’est pas déjà fait.
Dans le menu de votre ressource Application Insights, sous Surveillance, sélectionnez Métriques.
Dans la liste Étendue, sélectionnez votre instance Application Insights.
Dans la liste Espace de noms de métrique, sélectionnez workflow.operations.
Dans la liste Métrique, sélectionnez une métrique, par exemple Exécutions effectuées.
Dans la liste Agrégation, sélectionnez un type, par exemple Nombre ou Moy.

Lorsque vous avez fini, le tableau de bord Métriques montre un graphique avec vos exécutions de workflow terminées.

Filtrer sur un workflow spécifique

Lorsque vous activez des métriques multidimensionnelles dans le tableau de bord Métriques, vous pouvez cibler une partie de tous les événements capturés dans Application Insights et filtrer les événements sur un workflow spécifique.

Sur votre ressource Application Insights, activez les métriques multidimensionnelles.
Dans Application Insights, ouvrez le tableau de bord Métriques.
Dans la barre d’outils de graphique, sélectionnez Ajouter un filtre.
Dans la liste Propriété, sélectionnez Workflow.
Dans la liste Opérateur, sélectionnez le signe égal (=).
Dans la liste Valeurs, sélectionnez les workflows que vous voulez.

Afficher les données de journal et autres métriques « en direct »

Une fois la télémétrie avancée d’Application Insights activée, vous pouvez afficher les données de journal et autres métriques en quasi-temps réel à partir de votre instance Application Insights dans le portail Azure. Vous pouvez utiliser cette visualisation pour tracer les requêtes entrantes, les requêtes sortantes et l’intégrité globale. Vous bénéficiez également d’une table pour les diagnostics au niveau de la trace.

Dans le portail Azure, ouvrez votre ressource Application Insights si ce n’est pas déjà fait.
Dans le menu de votre ressource Application Insights, sous Investiguer, sélectionnez Métriques en direct.

La page Métriques en direct affiche les données de journal et d’autres métriques, par exemple :

Pour plus d’informations, consultez Métriques en direct : superviser et diagnostiquer avec une latence de 1 seconde.

Remarque

Dans la mesure où les workflows d’application logique Standard sont basés sur Azure Functions, la fonctionnalité Métriques en direct prend en charge ces workflows d’application logique.

Diffuser et afficher la sortie du débogage à partir des fichiers journaux d’application

Une fois la télémétrie avancée d’Application Insights activée, vous pouvez diffuser des informations de débogage détaillées dans le portail Azure pour les fichiers journaux de votre application. Ces informations sont équivalentes à la sortie générée à partir du débogage de votre workflow dans votre environnement Visual Studio Code local.

Dans le portail Azure, ouvrez votre ressource d’application logique Standard.
Dans le menu de votre ressource d’application logique, sous Surveillance, sélectionnez Flux de journaux.

La page Flux de journaux se connecte à votre instance Application Insights et affiche la sortie de débogage. Par exemple, la sortie suivante inclut les appels de requête et de réponse entre autres informations :

Étapes suivantes

Activer ou ouvrir Application Insights

Partager via