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

S’applique à : Azure Logic Apps (Standard)

Ce guide pratique montre comment activer la collecte de la télémétrie avancée dans Application Insights pour votre ressource d’application logique Standard, puis comment afficher les données collectées une fois que votre workflow a terminé une exécution.

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

Ouvrir Application Insights

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

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

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

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.

Les paramètres du déclencheur ont 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 :

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.

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 :

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.

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

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

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

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

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

   

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

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

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

   

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

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

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

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

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

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

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

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.

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

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

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

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

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

   

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

   

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 :

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.

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

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

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

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

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

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

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.

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

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

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

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

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.

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

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

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 :

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

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.

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

1. Dans le portail Azure, ouvrez votre ressource Application Insights si ce n’est pas déjà fait.

2. Dans le menu de votre ressource Application Insights, sous Surveillance, sélectionnez Métriques.

3. Dans la liste Étendue, sélectionnez votre instance Application Insights.

4. Dans la liste Espace de noms de métrique, sélectionnez workflow.operations.

5. Dans la liste Métrique, sélectionnez une métrique, par exemple Exécutions effectuées.

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

1. Sur votre ressource Application Insights, activez les métriques multidimensionnelles.

2. Dans Application Insights, ouvrez le tableau de bord Métriques.

3. Dans la barre d’outils de graphique, sélectionnez Ajouter un filtre.

4. Dans la liste Propriété, sélectionnez Workflow.

5. Dans la liste Opérateur, sélectionnez le signe égal (=).

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

1. Dans le portail Azure, ouvrez votre ressource Application Insights si ce n’est pas déjà fait.

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

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.

1. Dans le portail Azure, ouvrez votre ressource d’application logique Standard.

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