Recommandations pour la conception et la création d’un système de surveillance

Article
11/15/2023

S’applique à cette recommandation de liste de contrôle d’excellence opérationnelle Azure Well-Architected Framework :

OE :07	Concevez et implémentez un système de surveillance pour valider les choix de conception et éclairer les décisions futures en matière de conception et d’entreprise. Ce système capture et expose les données de télémétrie opérationnelles, les métriques et les journaux qui émettent à partir de l’infrastructure et du code de la charge de travail.

Guide associé : Recommandations pour l’instrumentation d’une application

Ce guide décrit les recommandations relatives à la conception et à la création d’un système de surveillance. Pour surveiller efficacement la sécurité, les performances et la fiabilité de votre charge de travail, vous avez besoin d’un système complet avec sa propre pile qui fournit la base de toutes les fonctions de surveillance, de détection et d’alerte.

Définitions

Terme	Définition
Journaux d’activité	Événements système enregistrés. Les journaux peuvent contenir différents types de données dans un format de texte structuré ou de forme libre. Ils contiennent un horodatage.
Mesures	Valeurs numériques collectées à intervalles réguliers. Les métriques décrivent certains aspects d’un système à un moment donné.

Stratégies de conception

Pour implémenter une conception de système de supervision complète pour votre charge de travail, suivez les principes principaux suivants :

Chaque fois que cela est possible, tirez parti des outils de supervision fournis par la plateforme, qui nécessitent généralement très peu de configuration et peuvent fournir des informations approfondies sur votre charge de travail qui pourraient être difficiles à accomplir.
Collectez les journaux et les métriques de l’ensemble de la pile de charge de travail. Toutes les ressources d’infrastructure et les fonctions d’application doivent être configurées pour produire des données standardisées et significatives, et ces données doivent être collectées.
Stockez les données collectées dans une solution de stockage standardisée, fiable et sécurisée.
Traitez les données stockées afin qu’elles puissent être gérées par des solutions d’analyse et de visualisation.
Analysez les données traitées pour déterminer avec précision l’état de la charge de travail.
Visualisez l’état de la charge de travail dans des tableaux de bord ou des rapports significatifs pour les équipes de charge de travail et d’autres parties prenantes.
Configurez des alertes actionnables et d’autres réponses automatiques aux seuils définis de manière intelligente pour notifier les équipes de charge de travail en cas de problème.
Incluez des systèmes de supervision et d’alerte dans vos pratiques de test de charge de travail globales.
Assurez-vous que les systèmes de surveillance et d’alerte sont dans l’étendue de l’amélioration continue. Le comportement des applications et de l’infrastructure en production offre des opportunités d’apprentissage continu. Incorporez ces leçons dans les conceptions de surveillance et d’alerte.
Liez les données de surveillance que vous collectez et analysez à votre système et aux flux utilisateur pour mettre en corrélation l’intégrité des flux avec les données, en plus de l’intégrité globale de la charge de travail. L’analyse de ces données en termes de flux vous aidera à aligner votre stratégie d’observabilité sur votre modèle d’intégrité.

Vous devez automatiser toutes les fonctions du système de surveillance autant que possible, et elles doivent toutes s’exécuter en continu, toute la journée, tous les jours.

Ce pipeline de flux de travail illustre le système de surveillance :

Collection

Notes

Vous devez instrumenter votre application pour activer la journalisation. Pour plus d’informations, consultez le guide d’instrumentation.

Vous devez configurer tous les composants de charge de travail, qu’il s’agisse de ressources d’infrastructure ou de fonctions d’application, pour capturer les données de télémétrie et/ou les événements tels que les journaux et les métriques.

Les journaux sont principalement utiles pour la détection et l’examen des anomalies. En règle générale, les journaux sont produits par le composant de charge de travail, puis envoyés à la plateforme de supervision ou extraits par la plateforme de supervision via l’automatisation.

Les métriques sont principalement utiles pour créer un modèle d’intégrité et identifier les tendances en matière de performances et de fiabilité des charges de travail. Les métriques sont également utiles pour identifier les tendances dans le comportement d’utilisation de vos clients. Ces tendances peuvent aider à guider les décisions relatives aux améliorations du point de vue du client. En règle générale, les métriques sont définies dans la plateforme de supervision, et la plateforme de supervision et d’autres outils interrogent la charge de travail pour capturer des métriques.

Données d'application

Pour les applications, le service de collecte peut être un outil de gestion des performances d’application (APM) qui peut s’exécuter de manière autonome à partir de l’application qui génère les données d’instrumentation. Une fois APM activé, vous disposez d’une visibilité claire sur les métriques importantes, en temps réel et historiquement. Utilisez un niveau de journalisation approprié. Une journalisation détaillée peut entraîner des coûts conséquents. Définissez les niveaux de journal en fonction de l’environnement. Les environnements inférieurs n’ont pas besoin du même niveau de détail que la production, par exemple.

Les journaux d’applications prennent en charge le cycle de vie des applications de bout en bout. La journalisation est essentielle pour comprendre le fonctionnement de l’application dans différents environnements, les événements qui se produisent et les conditions dans lesquelles ils se produisent.

Nous vous recommandons de collecter les journaux et les événements d’application dans tous les principaux environnements. Séparez les données entre les environnements autant que possible en utilisant des magasins de données différents pour chaque environnement, si cela est pratique. Utilisez des filtres pour vous assurer que les environnements non critiques ne compliquent pas l’interprétation des journaux de production. Enfin, les entrées de journal correspondantes dans l’application doivent capturer un ID de corrélation pour leurs transactions respectives.

Vous devez capturer les événements d’application dans des types de données structurés avec des points de données lisibles par machine plutôt que des types de chaîne non structurés. Un format structuré qui utilise un schéma connu peut faciliter l’analyse et l’analyse des journaux. Par ailleurs, vous pouvez facilement indexer des données structurées et y effectuer des recherches, et la génération de rapports est sensiblement simplifiée.

Les données doivent être dans un format indépendant de l’ordinateur, du système d’exploitation ou du protocole réseau. Par exemple, émettez des informations dans un format autodescripteur comme JSON, MessagePack ou Protobuf plutôt que DANS ETL/ETW. Un format standard permet au système de construire des pipelines de traitement. Les composants qui lisent, transforment et envoient des données au format standard peuvent être facilement intégrés.

Données d’infrastructure

Pour les ressources d’infrastructure dans votre charge de travail, veillez à collecter les journaux et les métriques. Pour les systèmes IaaS (Infrastructure as a Service), capturez le système d’exploitation, la couche application et les journaux de diagnostic en plus des métriques liées à l’intégrité de la charge de travail. Pour les ressources PaaS (Platform as a Service), vous pouvez être limité dans votre capacité à capturer des journaux liés à l’infrastructure sous-jacente, mais veillez à pouvoir capturer des journaux de diagnostic en plus des métriques liées à l’intégrité de la charge de travail.

Dans la mesure du possible, collectez les journaux à partir de votre plateforme cloud. Vous pourrez peut-être collecter des journaux d’activité pour votre abonnement et des journaux de diagnostic pour le plan de gestion.

Stratégies de collecte

Évitez de récupérer les données de télémétrie manuellement à partir de chaque composant. Déplacez les données vers un emplacement central et consolidez-les à cet emplacement. Pour une solution multirégion, nous vous recommandons de collecter, de consolider et de stocker des données région par région, puis d’agréger les données régionales dans un système central unique.

Compromis : N’oubliez pas que le fait d’avoir des magasins de données régionaux et centralisés a des répercussions sur les coûts.

Pour optimiser l’utilisation de la bande passante, hiérarchisez les données en fonction de leur importance. Vous pouvez transférer des données moins urgentes par lots. Toutefois, ces données ne doivent pas être retardées indéfiniment, en particulier si elles contiennent des informations qui respectent le temps.

Il existe deux modèles principaux que le service de collecte peut utiliser pour collecter des données d’instrumentation :

Modèle d’extraction : récupère activement les données des différents journaux et d’autres sources pour chaque instance de l’application.
Modèle Push : attend passivement que les données soient envoyées à partir des composants qui constituent chaque instance de l’application.

Agents de surveillance

Vous pouvez utiliser des agents de surveillance dans le modèle d’extraction. Les agents s’exécutent localement dans un processus distinct avec chaque instance de l’application, extrayant régulièrement les données et écrivant les informations directement dans le stockage commun partagé par toutes les instances de l’application.

Notes

L’utilisation d’un agent de surveillance convient idéalement à la capture des données d’instrumentation qui sont naturellement extraites d’une source de données. Il convient à une application à petite échelle qui s’exécute sur un nombre limité de nœuds dans un emplacement unique. Il s’agit par exemple d’informations provenant de SQL Server vues de gestion dynamique ou de la longueur d’une file d’attente Azure Service Bus.

Considérations relatives aux performances

Une application complexe et hautement évolutive peut générer d’énormes volumes de données. La quantité de données peut facilement surcharger la bande passante d’E/S disponible pour un emplacement central unique. La solution de télémétrie ne doit pas agir comme un goulot d’étranglement et doit adapter son échelle à mesure que le système se développe. Dans l’idéal, la solution doit incorporer un degré de redondance pour réduire les risques de perte d’informations de supervision importantes (telles que des données d’audit ou de facturation) en cas de défaillance d’une partie du système.

Une façon de mettre en mémoire tampon les données d’instrumentation consiste à utiliser la mise en file d’attente :

Dans cette architecture, le service de collecte de données met des données dans une file d’attente. Une file d’attente de messages convient, car elle fournit une sémantique « au moins une fois » qui permet de garantir que les données mises en file d’attente ne seront pas perdues après leur publication. Vous pouvez implémenter le service d’écriture de stockage à l’aide d’un rôle de travail distinct. Vous pouvez utiliser le modèle de file d’attente prioritaire pour implémenter cette architecture.

Pour la scalabilité, vous pouvez exécuter plusieurs instances du service d’écriture de stockage. Si un volume élevé d’événements ou un nombre élevé de points de données sont surveillés, vous pouvez utiliser Azure Event Hubs pour distribuer les données à un autre instance de calcul à des fins de traitement et de stockage.

Stratégies de consolidation

Les données collectées à partir d’un seul instance d’une application fournissent une vue localisée de l’intégrité et des performances de cette instance. Pour évaluer l’intégrité globale du système, vous devez consolider certains aspects des données à partir des vues locales. Vous pouvez le faire une fois les données stockées, mais, dans certains cas, vous pouvez le faire au fur et à mesure que les données sont collectées.

Les données d’instrumentation peuvent passer par un service de consolidation de données distinct qui combine les données et agit comme un processus de filtrage et de nettoyage. Par exemple, vous pouvez fusionner des données d’instrumentation qui incluent les mêmes informations de corrélation, comme un ID d’activité. (Un utilisateur peut démarrer une opération métier sur un nœud, puis être transféré vers un autre nœud si le premier nœud échoue ou en raison de la façon dont l’équilibrage de charge est configuré.) Ce processus peut également détecter et supprimer toutes les données dupliquées. (Une duplication peut se produire si le service de télémétrie utilise des files d’attente de messages pour envoyer les données d’instrumentation au stockage.)

Stockage

Lorsque vous choisissez une solution de stockage, tenez compte du type de données, de la façon dont elle est utilisée et de l’urgence requise.

Notes

Utilisez des solutions de stockage distinctes pour les environnements hors production et de production afin de vous assurer que les données de chaque environnement sont faciles à identifier et à gérer.

Technologies de stockage

Envisagez une approche de persistance polyglotte, où différents types d’informations sont stockés dans des technologies qui conviennent le mieux à la façon dont chaque type est susceptible d’être utilisé.

Par exemple, Stockage Blob Azure et stockage Table Azure sont accessibles de manière similaire. Mais les opérations que vous pouvez effectuer sur ces derniers diffèrent, tout comme la granularité des données qu’ils contiennent. Si vous devez effectuer plusieurs opérations analytiques ou si vous avez besoin de fonctionnalités de recherche en texte intégral sur les données, il peut être plus pertinent d’utiliser le stockage de données qui fournit des fonctionnalités optimisées pour des types spécifiques de requêtes et d’accès aux données. Par exemple :

Les données des compteurs de performances peuvent être stockées dans une base de données SQL pour activer l’analyse ad hoc.
Il peut être préférable de stocker les journaux de trace dans les journaux Azure Monitor ou azure Data Explorer.
Vous pouvez stocker des informations de sécurité dans une solution HDFS.

Les mêmes données d’instrumentation peuvent servir à plus d’une fin. Par exemple, vous pouvez utiliser des compteurs de performances pour fournir une vue historique des performances du système au fil du temps. Ces informations peuvent être combinées avec d’autres données d’utilisation pour générer les informations de facturation client. Dans ces situations, les mêmes données peuvent être envoyées à plusieurs destinations, comme à une base de données de documents qui peut être un magasin à long terme pour stocker des informations de facturation, et à un magasin multidimensionnel pour gérer des analyses de performances complexes.

Veillez à activer les fonctionnalités pour protéger les données contre toute suppression accidentelle, comme les verrous de ressources et la suppression réversible.

Veillez également à sécuriser l’accès au stockage en utilisant le contrôle d’accès en fonction du rôle pour vous assurer que seules les personnes qui ont besoin d’accéder aux données peuvent le faire.

Service de consolidation

Vous pouvez implémenter un autre service qui récupère régulièrement les données à partir du stockage partagé, les partitionne et les filtre en fonction de son objectif, puis les écrit dans un ensemble approprié de magasins de données.

Une autre approche consiste à inclure cette fonctionnalité dans le processus de consolidation et de nettoyage, et à écrire les données directement dans ces magasins à mesure qu’elles sont récupérées plutôt que de les enregistrer dans une zone de stockage partagée intermédiaire.

Chaque approche a des avantages et des inconvénients. L’implémentation d’un service de partitionnement distinct réduit la charge sur le service de consolidation et de nettoyage, et permet de régénérer au moins une partie des données partitionnée si nécessaire (en fonction de la quantité de données conservées dans le stockage partagé). Toutefois, cette approche consomme des ressources supplémentaires. En outre, il peut y avoir un délai entre la réception des données d’instrumentation à partir de chaque instance d’application et la conversion de ces données en informations utilisables.

Considérations relatives à l’interrogation

Réfléchissez à l’urgence de disposer des données. Les données qui génèrent des alertes doivent être accessibles rapidement. Elles doivent donc être conservées dans le stockage de données rapide, et indexées ou structurées pour optimiser les requêtes exécutées par le système d’alerte. Dans certains cas, il peut être nécessaire que le service de collecte formate et enregistre les données localement afin qu’une instance locale du système d’alerte puisse envoyer des notifications rapidement. Les mêmes données peuvent être transmises au service d’écriture dans le stockage indiqué dans les diagrammes précédents, et stockées de façon centralisée si elles doivent également servir à d’autres fins.

Considérations relatives à la conservation des données

Dans certains cas, une fois les données traitées et transférées, vous pouvez supprimer les données sources brutes d’origine stockées localement. Dans d’autres cas, il peut être nécessaire ou utile d’enregistrer les informations brutes. Par exemple, vous pouvez conserver les données générées pour le débogage disponibles dans leur forme brute, puis les ignorer rapidement une fois les bogues résolus.

Les données de performances ont souvent une durée de vie plus longue, ce qui vous permet de les utiliser pour repérer les tendances de performances et pour la planification de la capacité. La vue consolidée de ces données est en général conservée en ligne pour une période limitée afin de permettre un accès rapide. Après quoi, elle peut être archivée ou ignorée.

Il est souvent utile de stocker les données historiques afin de pouvoir identifier les tendances à long terme. Au lieu d’enregistrer les anciennes données dans leur intégralité, vous pourriez être en mesure de réduire l’échantillon des données pour réduire leur résolution et réduire les coûts de stockage. Par exemple, au lieu d’enregistrer les indicateurs de performance minute par minute, vous pouvez consolider les données datant de plus d’un mois pour former une vue heure par heure.

Les données collectées pour le contrôle et la facturation des clients peuvent devoir être enregistrées indéfiniment. En outre, les exigences réglementaires peuvent imposer que les informations collectées à des fins d’audit et de sécurité doivent être archivées et enregistrées. Ces données sont également sensibles et peuvent devoir être chiffrées ou protégées d’une quelconque façon pour empêcher toute falsification. Vous ne devez jamais enregistrer les mots de passe utilisateur ou d’autres informations susceptibles d’être utilisées pour commettre une fraude d’identité. Vous devez nettoyer ces détails des données avant qu’elles ne soient stockées.

Pour vous assurer que vous respectez les lois et les réglementations, réduisez le stockage de toutes les informations identifiables. Si vous avez besoin de stocker des informations d’identification, veillez, lors de la conception de votre solution, à prendre en compte les exigences qui permettent aux individus de demander la suppression de leurs informations.

Analyse

Après avoir collecté des données à partir de différentes sources de données, analysez-les pour évaluer le bien-être global du système. Pour cette analyse, comprenez clairement :

Comment structurer des données en fonction des indicateurs de performance clés et des métriques de performances que vous avez définies.
Comment mettre en corrélation les données capturées dans des fichiers de métriques et fichiers journaux. Cette corrélation est importante lorsque vous effectuez le suivi d’une séquence d’événements et peut vous aider à diagnostiquer les problèmes.

Dans la plupart des cas, les données de chaque composant de l’architecture sont capturées localement, puis combinées avec précision avec les données générées par d’autres composants.

Par exemple, une application à trois niveaux peut avoir :

Niveau de présentation qui permet à un utilisateur de se connecter à un site web.
Niveau intermédiaire qui héberge un ensemble de microservices qui traite la logique métier.
Niveau de base de données qui stocke les données associées à l’opération.

Les données d’utilisation d’une seule opération métier peuvent couvrir les trois niveaux. Ces informations doivent être corrélées pour fournir une vue d’ensemble de l’utilisation des ressources et du traitement pour l’opération. La corrélation peut impliquer le prétraitement et le filtrage des données au niveau base de données. Sur le niveau intermédiaire, l’agrégation et la mise en forme sont des tâches courantes.

Recommandations

Mettre en corrélation les journaux au niveau de l’application et au niveau des ressources. Évaluez les données aux deux niveaux pour optimiser la détection des problèmes et la résolution de ces problèmes. Vous pouvez agréger les données dans un seul récepteur de données ou tirer parti des méthodes qui interrogent les événements sur les deux niveaux. Nous recommandons une solution unifiée, comme Azure Log Analytics, pour agréger et interroger les journaux au niveau de l’application et au niveau des ressources.
Définissez des durées de rétention claires sur le stockage pour l’analyse à froid. Nous recommandons cette pratique pour activer l’analyse historique sur une période spécifique. Il peut également vous aider à contrôler les coûts de stockage. Implémentez des processus qui garantissent que les données sont archivées dans un stockage moins coûteux et agrègent les données pour l’analyse des tendances à long terme.
Analysez les tendances à long terme pour prédire les problèmes opérationnels. Évaluez les données à long terme pour former des stratégies opérationnelles et prédire les problèmes opérationnels susceptibles de se produire et quand. Par exemple, vous pouvez noter que les temps de réponse moyens augmentent lentement au fil du temps et s’approchent de la cible maximale.

Pour obtenir des conseils détaillés sur ces recommandations, consultez Analyser les données de supervision pour les applications cloud.

Visualisation

Tableaux de bord

La façon la plus courante de visualiser des données consiste à utiliser des tableaux de bord qui peuvent afficher des informations sous la forme d’une série de graphiques ou de graphiques, ou sous une autre forme visuelle. Ces éléments peuvent être paramétrés et un analyste peut sélectionner les paramètres importants, comme la période, pour toute situation spécifique.

Alignez vos tableaux de bord avec votre modèle d’intégrité afin qu’ils indiquent quand la charge de travail ou les composants de la charge de travail sont sains, dégradés ou non sains.

Pour qu’un système de tableau de bord fonctionne efficacement, il doit avoir un sens pour l’équipe de charge de travail. Visualisez les informations relatives à l’intégrité de la charge de travail et qui peuvent également être actionnables. Lorsque la charge de travail ou un composant est dégradé ou défectueux, les membres de l’équipe de charge de travail doivent être en mesure d’identifier facilement l’origine du problème dans la charge de travail et de commencer leurs actions correctives ou enquêtes. À l’inverse, l’inclusion d’informations qui ne sont pas exploitables ou qui ne sont pas liées à l’intégrité de la charge de travail peut rendre le tableau de bord inutilement complexe et frustrant pour les membres de l’équipe qui tentent de discerner le bruit de fond des données exploitables.

Vous pouvez avoir des tableaux de bord pour les parties prenantes ou les développeurs qui sont personnalisés pour afficher uniquement les données sur la charge de travail qu’ils trouvent pertinentes. Assurez-vous que l’équipe de charge de travail comprend les types de points de données qui intéressent les autres équipes et affiche un aperçu des tableaux de bord avant de les partager pour case activée par souci de clarté. La fourniture de tableaux de bord sur votre charge de travail aux parties prenantes est un bon moyen de les tenir informées de l’intégrité de la charge de travail, mais comporte un risque d’être contre-productif si les parties prenantes ne comprennent pas clairement les données qu’elles voient.

Un bon tableau de bord n’affiche pas seulement des informations. Il permet également à un analyste de poser des questions improvisées sur ces informations. Certains systèmes fournissent des outils de gestion qu’un opérateur peut utiliser pour effectuer ces tâches et explorer les données sous-jacentes. Au lieu de cela, en fonction du dépôt utilisé pour contenir les informations, il peut être possible d’interroger les données directement ou de les importer dans des outils comme Excel pour une analyse et des rapports supplémentaires.

Notes

Limitez l’accès au tableau de bord au personnel autorisé. Les informations sur les tableaux de bord peuvent être commercialement sensibles. Vous devez également protéger les données sous-jacentes pour empêcher les utilisateurs de les modifier.

Signalement

Le reporting permet de générer une vue d’ensemble du système. Il peut incorporer des données historiques et des informations actuelles. Les exigences des rapports se répartissent en deux grandes catégories : rapports opérationnels et rapports de sécurité.

Les rapports opérationnels incluent généralement les éléments suivants :

Agrégation des statistiques qui vous permettent de comprendre l’utilisation des ressources du système global ou des sous-systèmes spécifiés pendant un laps de temps spécifié.
Identification des tendances de l’utilisation des ressources pour le système global ou des sous-systèmes spécifiés pendant une période spécifiée.
Monitoring des exceptions qui se sont produites dans le système ou dans des sous-systèmes spécifiés pendant une période spécifiée.
Déterminer l’efficacité de l’application pour les ressources déployées et comprendre si le volume de ressources et les coûts associés peuvent être réduits sans affecter inutilement les performances.

Les rapports de sécurité effectuent le suivi de l’utilisation du système par les clients. Il peut inclure les éléments suivants :

Audit des opérations de l’utilisateur. Cette tâche nécessite l’enregistrement des demandes individuelles que chaque utilisateur effectue, ainsi que des dates et des heures. Les données doivent être structurées pour permettre à un administrateur de reconstruire rapidement la séquence d’opérations qu’un utilisateur effectue pendant une période spécifiée.
Suivi de l’utilisation des ressources par l’utilisateur. Cette tâche nécessite d’enregistrer la façon dont chaque requête d’un utilisateur accède aux différentes ressources qui composent le système, et pendant combien de temps. Un administrateur peut utiliser ces données pour générer un rapport d’utilisation, par utilisateur, pendant une période spécifiée, éventuellement pour la facturation.

Dans de nombreux cas, les traitements par lots peuvent générer des rapports en fonction d’une planification définie. La latence n’est normalement pas un problème. Vous devez également disposer de processus par lots qui peuvent générer des rapports spontanément, selon les besoins. Par exemple, si vous stockez des données dans une base de données relationnelle comme Azure SQL Database, vous pouvez utiliser un outil comme SQL Server Reporting Services pour extraire et mettre en forme des données et les présenter sous forme d’ensemble de rapports.

Alertes

Pour vous assurer que le système reste sain, réactif et sécurisé, définissez des alertes afin que les opérateurs puissent y répondre en temps opportun. Une alerte peut contenir suffisamment d’informations contextuelles pour les aider à démarrer rapidement sur les activités de diagnostic. Les alertes peuvent être utilisées pour appeler des fonctions de correction telles que la mise à l’échelle automatique ou d’autres mécanismes d’autoréparation. Les alertes peuvent également permettre la prise de conscience des coûts en offrant une visibilité sur les budgets et les limites.

Recommandations

Définissez un processus de réponse aux alertes qui identifie les propriétaires responsables et les actions.
Configurez des alertes pour une étendue bien définie (types de ressources et groupes de ressources) et ajustez la verbosité afin de réduire le bruit.
Utilisez une solution d’alerte automatisée, comme Splunk ou Azure Monitor, au lieu d’exiger que les utilisateurs recherchent activement les problèmes.
Utilisez des alertes pour rendre opérationnels les processus de correction. Par exemple, créez automatiquement des tickets pour suivre les problèmes et les solutions.
Suivez l’intégrité de vos services de plateforme cloud dans les régions, la communication sur les pannes, les activités de maintenance planifiées et d’autres avis d’intégrité.

Seuils

Des alertes sont générées lorsque des seuils sont dépassés, comme détecté par votre système de surveillance. Assurez-vous que les seuils que vous définissez vous donnent généralement suffisamment de temps pour implémenter les modifications nécessaires à votre charge de travail afin d’éviter les dégradations ou les pannes. Par exemple, définissez votre seuil de mise à l’échelle automatique pour lancer la mise à l’échelle avant que l’un des systèmes en cours d’exécution ne soit submergé au point d’une expérience utilisateur dégradée. Basez les valeurs de seuil que vous affectez à votre expérience passée dans la gestion de l’infrastructure et validez-les via les tests que vous effectuez dans le cadre de vos pratiques de test.

Pour obtenir des conseils détaillés sur les cas d’usage d’alerte et d’autres considérations, consultez Conception d’une stratégie de surveillance et d’alerte fiable.

Facilitation Azure

Azure Monitor est une solution de supervision complète pour la collecte, l’analyse et la réponse aux données de supervision à partir de vos environnements cloud et locaux.
Log Analytics est un outil de l’Portail Azure que vous pouvez utiliser pour modifier et exécuter des requêtes de journal sur des données dans l’espace de travail Log Analytics.

Si vous utilisez plusieurs espaces de travail, consultez le guide de l’architecture de l’espace de travail Log Analytics pour connaître les meilleures pratiques.
Application Insights est une extension d’Azure Monitor. Il fournit des fonctionnalités APM.
Azure Monitor Insights est des outils d’analytique avancés pour des technologies Azure spécifiques (telles que les machines virtuelles, les services d’application et les conteneurs). Ces outils font partie d’Azure Monitor et de Log Analytics.
Azure Monitor pour les solutions SAP est un outil de supervision Azure pour les paysages SAP qui s’exécutent sur Azure.
Azure Policy peut vous aider à appliquer des normes organisationnelles et à évaluer la conformité à grande échelle.

Liens de la communauté

Azure Monitor Baseline Alerts (AMBA) est un référentiel central de définitions d’alerte que les clients et les partenaires peuvent utiliser pour améliorer leur expérience d’observabilité grâce à l’adoption d’Azure Monitor.

Liste de contrôle de l’excellence opérationnelle

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de l’excellence opérationnelle

Recommandations pour la conception et la création d’un système de surveillance