Partager via


Éléments à prendre en compte sur la gestion des opérations pour l’accélérateur de zone d’atterrissage Services d’intégration Azure

Cet article fournit des éléments à prendre en compte et des recommandations sur la gestion et la surveillance des opérations lors de l’utilisation des offres Services d’intégration Azure.

La plupart des recommandations de cette section s’appliquent à la version Standard (à tenant unique) de Logic Apps, qui elle-même fait partie de l’offre Azure App Service et partage en grande partie les mêmes fonctionnalités de gestion.

De nombreuses ressources qui composent la catégorie Services d’intégration Azure peuvent être configurées pour stocker des données de journal, de télémétrie et de métrique dans Log Analytics/Application Insights, ou dans des emplacements de stockage personnalisés (ces ressources incluent les comptes de stockage, Event Hubs, et bien plus encore).

Nous pouvons utiliser ces informations pour visualiser l’intégrité globale de nos ressources, puis prendre les mesures de gestion appropriées.

Définitions

  • Les journaux Azure Monitor collectent, puis organisent les données de performances et de journal issues de ressources surveillées. Des outils tels que Log Analytics peuvent alors interroger ou visualiser ces informations de journal, ou vous permettent d’émettre une alerte si certaines conditions sont remplies.

  • Les journaux de métriques Azure collectent des données numériques depuis des ressources supervisées dans une base de données de séries chronologiques. Des outils tels qu’Application Insights peuvent ensuite visualiser ces données, puis vous aider à identifier les problèmes de performances et de runtime.

  • Log Analytics est une offre Azure Monitor, qui fournit un emplacement de stockage des données de journal et de performances, fournit un mécanisme et un langage pour interroger ces journaux (Kusto) ; et permet de créer des alertes et des tableaux de bord en fonction de ces journaux (entre autres fonctionnalités).

  • Application Insights est une offre Azure Monitoring, qui permet de visualiser les données de performances émises par les ressources surveillées, puis d’émettre des alertes au sujet de ces données.

  • Le Langage de requête Kusto (KQL) est un langage de requête puissant optimisé pour l’interrogation et la mise en forme des données. Par exemple, c’est le langage de requête principal de Log Analytics.

Remarques sur la conception

  • Considérez votre solution de supervision dans son ensemble :

    • Quelles ressources devez-vous surveiller ?

    • Comment suivrez-vous les messages qui circulent entre les ressources ?

    • À quels systèmes externes vous connecterez-vous ?

    • De quels types d’alertes aurez-vous besoin ?

  • Pensez aux requêtes que vous devez exécuter. Par exemple, devrez-vous savoir si une requête donnée prend plus de temps que prévu ? Ou si vous obtenez une seule erreur par opposition à un cluster d’erreurs ?

  • De quel niveau de suivi aurez-vous besoin ? Par exemple, si un message arrive d’un tiers, devez-vous suivre ce message via toutes les ressources associées ?

  • Quelles tâches de gestion devrez-vous effectuer ? Devrez-vous soumettre de nouveau des messages ou des fichiers ?

  • L’historique des exécutions de l’application logique est stocké dans le service Stockage Azure par défaut, mais vous pouvez également choisir d’exporter des métriques et des fichiers journaux vers d’autres sources (par exemple, Log Analytics ou un compte de stockage externe). Prenez en compte votre mode d’utilisation de vos informations de journalisation et l’utilisation ou non d’un magasin de journaux centralisé.

  • Application Insights permet de fournir une surveillance des performances des applications. Pour ce faire, cette fonctionnalité collecte des métriques des ressources qui composent votre solution.

  • Log Analytics sert à interroger les journaux et à configurer des alertes, ce qui vous permet de connaître l’intégrité de vos ressources et de comprendre les problèmes qui peuvent se produire. Les données de journal peuvent inclure des propriétés personnalisées (veuillez consulter la rubrique Propriétés suivies ci-dessous).

  • Veuillez consulter l’article sur la gestion de l’accélérateur de zone d’atterrissage App Service si vous souhaitez en savoir plus et obtenir des recommandations sur App Services.

Recommandations relatives à la conception

  • Configurez Application Insights pour qu’il utilise un espace de travail Log Analytics comme source de données (appelée ressource basée sur un espace de travail). Cela permet de conserver les données de journalisation et de performances dans un emplacement consolidé.

  • Configurez des alertes sur toutes les ressources pour informer les équipes concernées des événements liés à des ressources prises séparément ou à la charge de travail.

  • Liez les ressources de votre solution à Application Insights, si ce système est pris en charge. Par exemple, vous pouvez lier une application logique à Application Insights pour pouvoir interroger les données et les métriques d’exécution. Veuillez cliquer ici pour obtenir un exemple.

  • Utilisez la fonctionnalité clientTrackingId de Logic Apps pour fournir un ID de suivi personnalisé, ce qui vous permet de mettre en corrélation les événements d’une exécution d’application logique à une autre. Vous pouvez utiliser l’en-tête x-ms-client-tracking-id pour obtenir ce résultat avec les déclencheurs Request (requête), HTTP ou HTTP+WebHook.

  • Utilisez la fonctionnalité Propriétés suivies de Logic Apps pour consigner d’autres données (entrée ou sortie) d’une action dans les fichiers journaux. Ces propriétés sont ensuite disponibles pour l’interrogation des journaux à l’aide du langage KQL avec Log Analytics ou une autre solution.

  • Pensez à utiliser des étiquettes de ressources. Les étiquettes de ressources peuvent vous aider à gérer et à organiser les ressources sur Azure. Vous pouvez les utiliser pour attribuer des métadonnées à des ressources. Vous pouvez utiliser ces métadonnées à différentes fins, telles que la catégorisation des ressources par application ou unité commerciale, le suivi du coût des ressources et l’identification des ressources pour la conformité.

Exemples de requêtes Kusto

Les requêtes ci-dessous montrent comment interroger les trois tables principales utilisées pour les données de journal AIS. Chacune de ces tables est accessible depuis l’option Journaux de la section Surveillance de votre application logique.

Les tables de requête principales sont les suivantes :

  • exceptions
    Cette table contient toutes les exceptions enregistrées par votre ressource, comme des exceptions levées par le runtime d’application logique. Vous pouvez l’utiliser pour rechercher la cause sous-jacente des problèmes constatés, soit dans le portail, soit pendant l’exécution de votre code.

  • requests
    Cette table journalise toutes les requêtes effectuées par le runtime d’application logique vers une autre ressource OU pour des actions spécifiques dans votre flux de travail.

  • traces
    Cette table contient l’essentiel des journaux d’exécution Logic Apps, des détails de journalisation sur l’exécution des déclencheurs, le démarrage et l’arrêt des flux de travail et l’exécution des actions. Si vous avez enregistré des propriétés suivies depuis vos actions, vous trouverez ces données dans la section customDimensions. Vous pouvez alors utiliser la clause d’extension d’une requête pour ajouter les données sous forme de colonnes dans la réponse de votre requête.

Flux de travail avec des erreurs :

> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions.LogLevel == "Error"

Nombre d’exécutions de flux de travail au cours des 24 dernières heures sur tous les flux de travail :

> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions\["EventName"\] == "WorkflowActionStart"
>
> \| where timestamp \> ago(1d)
>
> \| count

Taux de réussite du déclencheur, graphique au fil du temps

> traces  
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"  
> \| where customDimensions\["EventName"\] == "WorkflowTriggerEnd"  
> \|summarize
>
> success = countif(customDimensions\["prop\_\_status"\] ==
> "Succeeded"),
>
> failures = countif(customDimensions\["prop\_\_status"\] == "Failed")
>
> by bin(timestamp, 1m)  
> \| render timechart

Étape suivante

Passez en revue les zones de conception critiques pour prendre en compte l’ensemble des considérations et recommandations relatives à votre architecture.