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

S’applique à cette recommandation de liste de contrôle Azure Well-Architected Framework Operational Excellence :

Guide connexe : 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 votre charge de travail pour la sécurité, les performances et la fiabilité, 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

Stratégies de conception

Pour implémenter une conception complète du système de supervision pour votre charge de travail, suivez ces principes fondamentaux :

• Chaque fois qu’il est pratique, tirez parti des outils de surveillance fournis par la plateforme, qui nécessitent généralement très peu de configuration et peuvent fournir des insights approfondis sur votre charge de travail qui pourraient autrement être difficiles à accomplir.

• Collectez les journaux et les métriques à partir de l’ensemble de la pile de charge de travail. Toutes les ressources d’infrastructure et toutes les fonctions d’application doivent être configurées pour produire des données standardisées, significatives et que 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 intelligemment pour notifier les équipes de charge de travail lorsque des problèmes se produisent.

• Incluez la surveillance et les systèmes d’alerte dans vos pratiques globales de test de charge de travail.

• Assurez-vous que les systèmes de surveillance et d’alerte sont dans le cadre de l’amélioration continue. Le comportement de l’application et de l’infrastructure en production offre des opportunités d’apprentissage continue. Intégrez ces leçons aux conceptions de surveillance et d’alerte.

• Associez les données de surveillance que vous collectez et analysez à vos flux système et 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 permet d’aligner votre stratégie d’observabilité avec 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, tous les jours, tous les jours.

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

Collecter des données d’instrumentation

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

Les journaux sont principalement utiles pour détecter et examiner les anomalies. En règle générale, les journaux sont générés par le composant de charge de travail, puis envoyés à la plateforme de surveillance 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 sur les améliorations du point de vue du client. En règle générale, les métriques sont définies dans la plateforme de surveillance, et la plateforme de surveillance et d’autres outils interrogent la charge de travail pour capturer les métriques.

Données d'application

Pour les applications, le service de collecte peut être un outil de gestion des performances des applications (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 L’APM activé, vous disposez d’une visibilité claire sur les métriques importantes, en temps réel et historiquement. Utilisez un niveau approprié de journalisation. 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’application prennent en charge le cycle de vie des applications de bout en bout. La journalisation est essentielle pour comprendre comment l’application fonctionne dans différents environnements, quels événements se produisent et les conditions dans lesquelles elles se produisent.

Nous vous recommandons de collecter les journaux d’activité 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 c’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.

Il est préférable de capturer les événements d'application dans des types de données structurés avec des points de données lisibles par une machine plutôt que dans des types de chaînes non structurés. Un format structuré qui utilise un schéma connu peut faciliter 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 auto-décrivant tel que JSON, MessagePack ou Protobuf plutôt que 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 assurez-vous que vous pouvez capturer les journaux de diagnostic en plus des métriques liées à l’intégrité de la charge de travail.

Autant que possible, collectez les journaux à partir de votre plateforme cloud. Vous pouvez peut-être collecter les journaux d’activité de 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 des données vers un emplacement central et regroupez-les là. Pour une solution multirégion, nous vous recommandons de commencer par collecter, consolider et stocker des données sur une base régionale par région, puis d’agréger les données régionales dans un système central unique.

Compromis : Sachez qu’il y a des implications sur les coûts liés à l’existence de magasins de données régionaux et centralisés.

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 sensibles dans 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 des données et écrivant les informations directement dans un stockage commun partagé par toutes les instances de l’application.

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 submerger 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 surveillance importantes (comme l’audit ou les données de facturation) si une partie du système échoue.

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 s’assurer que les données mises en file d’attente ne seront pas perdues après sa 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 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 grand nombre de points de données est surveillé, vous pouvez utiliser Azure Event Hubs pour distribuer les données à une autre instance de calcul pour le traitement et le stockage.

Stratégies de consolidation

Les données collectées à partir d’une seule 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 des vues locales. Vous pouvez le faire une fois les données stockées, mais, dans certains cas, vous pouvez le faire à 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 les 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 en cas d’échec du premier nœud ou en raison de la configuration de l’équilibrage de charge.) Ce processus peut également détecter et supprimer toutes les données dupliquées. (La duplication peut se produire si le service de télémétrie utilise des files d’attente de messages pour envoyer des données d’instrumentation vers le stockage.)

Stocker des données pour la requête et l’analyse

Lorsque vous choisissez une solution de stockage, tenez compte du type de données, de son utilisation et de son besoin urgent.

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 à chaque type est susceptible d’être utilisé.

Par exemple, Stockage Blob Azure et Stockage Table Azure sont accessibles de manière similaire. Toutefois, les opérations que vous pouvez effectuer sur elles diffèrent, comme la granularité des données qu’elles 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 d’activité 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 contenir des informations de facturation et à un magasin multidimensionnel pour gérer des analyses de performances complexes.

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

Veillez également à sécuriser l’accès au stockage à l’aide du contrôle d’accès en fonction du rôle pour vous assurer que seules les personnes qui doivent 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é, des partitions 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 au moins une partie des données partitionnés d’être régénérées 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 souhaiterez peut-être conserver les données générées pour le débogage disponibles sous sa 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 afin que vous puissiez l’utiliser pour repérer les tendances des 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 d’anciennes données dans son intégralité, vous pourrez peut-être réduire l’échantillon des données afin de réduire sa résolution et de réduire les coûts de stockage. Par exemple, au lieu d’économiser des indicateurs de performances minute par minute, vous pouvez consolider les données de plus d’un mois pour former une vue horaire 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 dicter que les informations collectées pour l’audit et la 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 valider la fraude d’identité. Vous devez nettoyer ces détails des données avant leur stockage.

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

Analyser les données pour comprendre l’intégrité d’une charge de travail

Une fois que vous avez 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 les points suivants :

• Comment structurer les 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 aux 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 s’étendre sur 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 les journaux 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 récepteur de données unique ou tirer parti des méthodes qui interrogent les événements des deux niveaux. Nous vous recommandons une solution unifiée, comme Azure Log Analytics, pour agréger et interroger les journaux au niveau de l’application et des ressources.

• Définissez des temps de rétention clairs sur le stockage pour l’analyse à froid. Nous recommandons cette pratique d’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 des données de stockage et d’agrégation moins coûteuses 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 approchent de la cible maximale.

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

Visualiser les rapports d’intégrité de la charge de travail

Tableaux de bord

La façon la plus courante de visualiser les 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 dans un autre formulaire visuel. 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étériorés ou défectueux.

Pour qu’un système de tableau de bord fonctionne efficacement, il doit être significatif pour l’équipe de charge de travail. Visualisez les informations relatives à l’intégrité de la charge de travail et qui sont également exploitables. Lorsque la charge de travail ou un composant est détérioré ou défectueux, les membres de l’équipe de charge de travail doivent être en mesure d’identifier facilement où dans la charge de travail le problème provient et de commencer leurs actions correctives ou enquêtes. À l’inverse, y compris les informations qui ne sont pas exploitables ou qui ne sont pas liées à l’intégrité de la charge de travail peuvent rendre le tableau de bord inutilement complexe et frustrant pour les membres de l’équipe qui tentent de discerner le bruit d’arrière-plan des données actionnables.

Vous pouvez avoir des tableaux de bord pour les parties prenantes ou les développeurs personnalisés pour afficher uniquement les données relatives à 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 que d’autres équipes souhaitent voir et prévisualiser les tableaux de bord avant de les partager pour vérifier la clarté. Fournir des tableaux de bord sur votre charge de travail pour les parties prenantes est un bon moyen de les garder informés de l’intégrité de la charge de travail, mais présente un risque d’être contre-productif si les parties prenantes ne comprennent pas clairement les données qu’ils 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, selon le référentiel 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.

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 leurs 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 client du système. 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 termine, 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 effectuées par un utilisateur 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 tel que SQL Server Reporting Services pour extraire et mettre en forme des données et les présenter sous la forme d’un ensemble de rapports.

Définir des alertes pour les événements clés

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 de réparation automatique. Les alertes peuvent également permettre la prise en charge des coûts en fournissant 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 personnes recherchent activement des problèmes.

• Utilisez des alertes pour opérationnaliser 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

Les alertes sont générées lorsque des seuils sont franchis, comme détectés 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 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 dépassé au point d’une expérience utilisateur détériorée. Basez les valeurs de seuil que vous affectez à votre expérience passée dans la gestion de l’infrastructure et validez-les par le biais des tests que vous effectuez dans le cadre de vos pratiques de test.

Pour obtenir des instructions détaillées 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 permettant de collecter, d’analyser et de répondre aux données de surveillance à 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 d’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’analyse avancés pour des technologies Azure spécifiques (telles que des machines virtuelles, des services d’application et des conteneurs). Ces outils font partie d’Azure Monitor et de Log Analytics.

• Les solutions Azure Monitor pour SAP sont 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 connexes

• Guide d’instrumentation
• Recommandations pour la conception d’une stratégie de surveillance et d’alerte fiable
• Recommandations pour la surveillance et la détection des menaces
• Recommandations pour la collecte des données de performances

Liens de la communauté

• Les alertes de référence Azure Monitor (AMBA) sont 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 d’excellence opérationnelle

Reportez-vous à l’ensemble complet de recommandations.