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)
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
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.
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.
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 :
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 :
| 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 10L’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.
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 
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 :
| 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 :
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 descPour 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 :
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.
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é :
| 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.
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>" } } }
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 :
