Partager via

Superviser Azure Service Fabric

  • Article

Cet article aborde les points suivants :

  • Types de données de monitoring que vous pouvez collecter pour ce service.
  • Comment analyser ces données.

Remarque

Si vous connaissez déjà ce service et/ou Azure Monitor et que vous voulez simplement savoir comment analyser les données de monitoring, consultez la section Analyser vers la fin de cet article.

Quand vous avez des applications critiques et des processus métier qui s’appuient sur des ressources Azure, vous devez monitorer votre système et obtenir des alertes. Le service Azure Monitor collecte et agrège les métriques et les journaux de chaque composant de votre système. Azure Monitor vous fournit une vue de la disponibilité, des performances et de la résilience, et vous avertit des problèmes. Vous pouvez utiliser le portail Azure, PowerShell, Azure CLI, l’API REST ou des bibliothèques de client pour configurer et visualiser les données de monitoring.

Supervision d’Azure Service Fabric

Azure Service Fabric comporte les couches suivantes que vous pouvez superviser :

  • Surveillance des applications : les applications qui s’exécutent sur les nœuds. Vous pouvez superviser des applications avec une clé Application Insights ou un Kit de développement logiciel (SDK), EventStore ou la journalisation ASP.NET Core.
  • Surveillance (du cluster) de la plateforme : Indicateurs de performance, journaux et événements clients pour les nœuds de plateforme ou de cluster, y compris les métriques de conteneur. Les métriques et les journaux sont différents pour les nœuds Linux ou Windows.
  • Surveillance de (la performance de) l’infrastructure: compteurs d’intégrité des services et de performance pour le service et infrastructure.

Vous pouvez superviser la façon dont vos applications sont utilisées, les actions effectuées par la plateforme Service Fabric, votre utilisation des ressources avec des compteurs de performances et l’intégrité globale de votre cluster. Les journaux Azure Monitor et Application Insights offrent une intégration intégrée à Service Fabric.

Service Fabric Explorer

Service Fabric Explorer, une application de bureau pour Windows, macOS et Linux, est un outil open source permettant d’inspecter et de gérer des clusters Azure Service Fabric. Pour activer l’automatisation, toutes les actions effectuées via le Service Fabric Explorer le sont également par l’intermédiaire de PowerShell ou d’une API REST.

Monitoring des applications

Le monitoring des applications permet de suivre l’utilisation des fonctionnalités et des composants de votre application. L’objectif est d’intercepter les problèmes qui impactent les utilisateurs. La responsabilité de la supervision des applications revient aux utilisateurs qui développent une application et ses services dans la mesure où il est unique à la logique métier de l’application. Le monitoring des applications peut être utile dans les scénarios suivants :

  • Quel est le trafic que rencontre mon application ? - Devez-vous mettre à l’échelle vos services pour répondre aux demandes des utilisateurs ou traiter un goulot d’étranglement potentiel dans votre application ?
  • Mes appels de service à service sont-ils fructueux et suivis ?
  • Quelles actions sont prises par les utilisateurs de mon application ? - La collecte de données de télémétrie peut guider le développement de nouvelles fonctionnalités et améliorer les diagnostics des erreurs d’application
  • Mon application lève-t-elle des exceptions non gérées ?
  • Que se passe-t-il dans les services qui s’exécutent au sein de mes conteneurs ?

L’avantage de la supervision des applications est que les développeurs peuvent utiliser les outils et le framework qu’ils souhaitent dans la mesure où il réside dans le contexte de votre application. Vous pouvez en apprendre plus sur la solution Azure pour la supervision des applications avec Azure Monitor – Application Insights dans Analyse d’événements avec Application Insights.

Nous disposons également d’un tutoriel qui explique comment configurer ceci pour les applications .NET. Ce tutoriel aborde la façon d’installer les outils appropriés, un exemple pour écrire des données de télémétrie personnalisées dans votre application, et l’affichage des données de télémétrie et de diagnostic de l’application dans le portail Azure.

Journalisation des applications

L’instrumentation de votre code est un moyen d’obtenir des informations sur vos utilisateurs, mais également la seule façon de savoir si quelque chose est incorrect dans votre application et de diagnostiquer ce qui doit être corrigé. Bien qu’il soit techniquement possible de connecter un débogueur à un service de production, cette pratique n’est pas courante. Par conséquent, il est important de disposer de données d’instrumentation détaillées.

Certains produits instrumentent automatiquement votre code. Ces solutions peuvent s’avérer efficaces, mais une instrumentation manuelle doit presque toujours être spécifique à votre logique métier. Au final, vous devez disposer d’assez d’informations pour déboguer l’application de manière approfondie. Les applications Service Fabric peuvent être instrumentées avec n’importe quel framework de journalisation. Cette section décrit quelques approches différentes d’instrumentation de votre code et explique quand privilégier telle ou telle approche.

  • Kit de développement logiciel (SDK) Application Insights : Application Insights bénéficie d’une intégration riche prête à l’emploi avec Service Fabric. Les utilisateurs peuvent ajouter les packages NuGet AI Service Fabric et ainsi recevoir des données et journaux d’activité créés et collectés tel qu’affichés dans le Portail Azure. En outre, ils sont invités à ajouter leurs propres données de télémétrie pour diagnostiquer et déboguer leurs applications, mais aussi pour effectuer le suivi des services et parties de leur application les plus utilisés. Dans le SDK, la classe TelemetryClient offre de nombreuses façons d’effectuer le suivi des données de télémétrie dans vos applications. Pour plus d’informations, consultez Analyse et visualisation des événements avec Application Insights.

    Consultez un exemple dans notre didacticiel montrant comment utiliser et ajouter Application Insights à votre application pour surveiller et diagnostiquer une application .NET.

  • EventSource : Lorsque vous créez une solution Service Fabric à partir d’un modèle dans Visual Studio, une classe dérivée d’EventSource (ServiceEventSource ou ActorEventSource) est générée. Un modèle dans lequel vous pouvez ajouter des événements pour votre application ou votre service est créé. Le nom de la classe dérivée EventSourcedoit être unique et créé à partir de la chaîne de modèle par défaut MyCompany-<solution>-<project>. Un même nom attribué à plusieurs définitions EventSource peut causer des problèmes lors de l’exécution. Chaque événement défini doit avoir un identificateur unique. Si l’identificateur n’est pas unique, l’exécution échoue. Certaines organisations préaffectent des valeurs aux identificateurs afin d’éviter les conflits entre les équipes de développement. Pour plus d’informations, consultez le blog de Vance ou la documentation MSDN.

  • Journalisation ASP.NET Core : Il est important de planifier avec soin la manière dont vous allez instrumenter votre code. Avec le plan d’instrumentation adéquat, vous pouvez éviter de déstabiliser votre base de code et d’avoir alors à réinstrumenter le code. Afin de réduire les risques, vous pouvez choisir une bibliothèque d’instrumentation telle que Microsoft.Extensions.Logging, qui fait partie de Microsoft ASP.NET Core. ASP.NET Core présente une interface ILogger que vous pouvez utiliser avec le fournisseur de votre choix, tout en limitant les répercussions sur le code existant. Vous pouvez utiliser le code dans ASP.NET Core sur Windows et Linux, ainsi que dans la version complète de .NET Framework. Par conséquent, votre code d’instrumentation est normalisé.

Pour obtenir des exemples d’utilisation de ces suggestions, consultez Ajouter une connexion à votre application Service Fabric.

Surveillance (du cluster) de la plateforme

Un utilisateur contrôle les données de télémétrie qui proviennent de l’application dans la mesure où un utilisateur écrit le code lui-même, mais qu’en est-il du diagnostic provenant de la plateforme Service Fabric ? L’un des objectifs de Service Fabric est d’assurer le bon fonctionnement des applications même en cas de défaillances matérielles. Cet objectif repose sur la capacité des services système de la plateforme à détecter les problèmes d’infrastructure et à basculer rapidement les charges de travail sur d’autres nœuds du cluster. Mais dans ce cas précis, que se passe-t-il si les services système subissent eux aussi des problèmes ? Que se passe-t-il si, durant une tentative de déploiement ou de déplacement d’une charge de travail, les règles de placement des services sont enfreintes ? Service Fabric fournit des diagnostics pour cela et pour vous garantir d’être informé de l’activité en cours dans votre cluster. Voici quelques exemples de scénarios pour la surveillance du cluster :

Pour plus d’informations sur la surveillance de la plateforme (du cluster) de la plateforme, consultez Surveillance du cluster.

Événements de Service Fabric

Service Fabric fournit un ensemble complet d’événements de diagnostic prêts à l’emploi, auxquels vous pouvez accéder via EventStore ou le canal d’événement opérationnel exposé par la plateforme. Ces événements Service Fabric illustrent les actions effectuées par la plateforme sur différentes entités telles que les nœuds, les applications, les services et les partitions. Les mêmes événements sont disponibles sur les clusters Windows et Linux.

  • Canaux d’événements Service Fabric : Sur Windows, les événements Service Fabric sont disponibles à partir d’un seul fournisseur de suivi d’événements pour Windows (ETW) avec un ensemble de logLevelKeywordFilters pertinents permettant de choisir entre le canal opérationnel et le canal de données de messagerie. Il s’agit de la façon dont nous séparons les événements Service Fabric sortants à filtrer selon les besoins. Sur Linux, les événements Service Fabric transitent par LTTng et sont placés dans une table de stockage où ils peuvent être filtrés selon les besoins. Ces canaux contiennent des événements organisés et structurés que vous pouvez utiliser pour mieux comprendre l’état de votre cluster. Les diagnostics sont activés par défaut au moment de la création du cluster. Vous disposez ainsi d’une table Stockage Azure où sont envoyés les événements de ces canaux que vous pourrez interroger ultérieurement.

  • EventStore est une fonctionnalité qui montre les événements de plateforme Service Fabric dans Service Fabric Explorer et par programme via l’API REST de la bibliothèque de client Service Fabric. Vous pouvez obtenir une vue de capture de ce qui se passe dans votre cluster pour chaque nœud, service, application et requête en fonction de l’heure de l’événement. Les API EventStore sont réservées aux clusters Windows s’exécutant sur Azure. Sur les ordinateurs Windows, ces événements sont enregistrés dans le journal des événements afin de pouvoir voir les événements Service Fabric dans l’observateur d’événements.

Capture d'écran représentant l'onglet ÉVÉNEMENTS du volet Nœuds et affichant plusieurs événements, dont un événement NodeDown.

Les diagnostics fournis sont sous la forme d’un ensemble complet d’événements prêts à l’emploi. Ces événements Service Fabric illustrent les actions effectuées par la plateforme sur différentes entités telles que les nœuds, les applications, les services, les partitions, etc. Dans le dernier scénario ci-dessus, si un nœud venait à tomber en panne, la plateforme émettrait un événement NodeDown et vous pourriez être informé immédiatement par votre outil de supervision préféré. D’autres exemples courants incluent ApplicationUpgradeRollbackStarted ou PartitionReconfigured lors d’un basculement. Les mêmes événements sont disponibles sur les clusters Windows et Linux.

Les événements sont envoyés par le biais des canaux standard sur Windows et Linux, et peuvent être lus par n’importe quel outil de supervision qui les prend en charge. La solution Azure Monitor correspond aux journaux Azure Monitor. Renseignez-vous sur notre intégration des journaux Azure Monitor, qui comporte un tableau de bord opérationnel personnalisé pour votre cluster et quelques exemples de requêtes permettant de créer des alertes. D’autres concepts de supervision de cluster sont disponibles dans Événement au niveau de la plateforme et génération de journal.

Surveillance de l’intégrité

La plateforme Service Fabric inclut un modèle d’intégrité qui fournit des rapports d’intégrité extensibles sur l’état des entités dans un cluster. Chaque nœud, application, service, partition, réplica ou instance a un état d’intégrité qui est mis à jour en permanence. L’état d’intégrité peut avoir la valeur « OK », « Avertissement » ou « Erreur ». Considérez les événements Service Fabric comme des verbes appliqués par le cluster aux diverses entités et l’intégrité comme un adjectif pour chaque entité. Chaque fois que l’intégrité d’une entité particulière change, un événement est également émis. De cette façon, vous pouvez définir des requêtes et des alertes pour les événements d’intégrité dans votre outil de supervision préféré, tout comme pour n’importe quel autre événement.

De plus, nous laissons même les utilisateurs remplacer l’intégrité des entités. Si votre application est en cours de mise à niveau et que des tests de validation se soldent par un échec, vous pouvez vous adresser à la cellule Intégrité de Service Fabric à l’aide de l’API Intégrité pour indiquer que votre application n’est plus saine, et Service Fabric restaurera automatiquement la mise à niveau ! Pour plus d’informations sur le modèle d’intégrité, consultez Présentation du contrôle d’intégrité de Service Fabric.

Capture d’écran du tableau de bord d’intégrité SFX.

Agents de surveillance

En général, un agent de surveillance est un service distinct capable de surveiller l’intégrité et la charge des services, d’effectuer des tests ping sur les points de terminaison et de créer des rapports à partir des événements non sains du cluster. Cela vous permet de détecter plus facilement les erreurs que vous n’auriez pas pu détecter en vous basant uniquement sur les performances d’un seul service. Les agents de surveillance constituent également un bon emplacement pour héberger du code qui exécute des actions correctives sans intervention de l’utilisateur (par exemple, le nettoyage de fichiers journaux dans le stockage à intervalles réguliers). Si vous souhaitez un service de surveillance SF open source entièrement implémenté qui comprend un modèle d’extensibilité de surveillance facile à utiliser et qui s’exécute dans les clusters Windows et Linux, consultez le projet FabricObserver. FabricObserver est un logiciel prêt pour la production. Nous vous encourageons à déployer FabricObserver sur vos clusters de test et de production et à l’étendre pour répondre à vos besoins par le biais de son modèle de plug-in ou en le dupliquant et en écrivant vos propres observateurs intégrés. Ce dernier (plug-in) est l’approche recommandée.

Supervision de l’infrastructure (performances)

Maintenant que nous avons couvert les diagnostics dans votre application et sur la plateforme, comment savons-nous que le matériel fonctionne comme prévu ? Le monitoring de l’infrastructure sous-jacente est essentiel pour comprendre l’état de votre cluster et l’utilisation de vos ressources. La mesure des performances système dépend de nombreux facteurs qui peuvent être subjectifs en fonction de vos charges de travail. Ces facteurs sont généralement mesurés via des compteurs de performances. Ces compteurs de performances peuvent provenir de diverses sources, y compris du système d’exploitation, du .NET Framework ou de la plateforme Service Fabric proprement dite. Voici quelques scénarios dans lesquels ils peuvent être utiles :

  • Est-ce que j’utilise efficacement mon matériel ? Voulez-vous utiliser votre matériel à 90 % ou 10 % du processeur ? Cela peut être pratique lors de la mise à l’échelle de votre cluster ou de l’optimisation des processus de votre application.
  • Puis-je prévoir des problèmes d’infrastructure de façon proactive ? - de nombreux problèmes sont précédés de baisses (chutes) soudaines des performances. Vous pouvez donc utiliser des compteurs de performances comme E/S réseau et Utilisation de l’UC pour prédire et diagnostiquer les problèmes de façon proactive.

Vous trouverez la liste des compteurs de performances à collecter au niveau infrastructure dans Métriques de performances.

Les journaux Azure Monitor sont recommandé pour la supervision des événements au niveau du cluster. Après avoir configuré l’agent Log Analytics avec votre espace de travail, vous pouvez collecter :

  • Indicateurs de performance telles que l’utilisation du processeur.
  • Compteurs de performances .NET tels que l’utilisation du processeur au niveau du processus.
  • Compteurs de performances Service Fabric tels que le nombre d’exceptions d’un service fiable.
  • Indicateurs de performances du conteneur telles que l’utilisation du processeur.

Types de ressource

Azure utilise le concept de types de ressources et d’ID pour identifier tout dans un abonnement. Les types de ressource font également partie des ID de ressource pour chaque ressource exécutée dans Azure. Par exemple, le type de ressource pour une machine virtuelle peut être Microsoft.Compute/virtualMachines. Pour obtenir la liste des services et leurs types de ressource associés, consultez Fournisseurs de ressources.

Azure Monitor organise de même manière les données de supervision de base en métriques et journaux en fonction des types de ressources, également appelés espaces de noms. Différentes métriques et journaux sont disponibles pour les différents types de ressource. Votre service peut être associé à plusieurs types de ressource.

Pour plus d’informations sur les types de ressources pour Azure Service Fabric, consultez la référence pour les données de supervision Service Fabric.

Stockage des données

Pour Azure Monitor :

  • Les données de métriques sont stockées dans la base de données des métriques Azure Monitor.
  • Les données de journal sont stockées dans le magasin de journaux Azure Monitor. Log Analytics est un outil du portail Azure qui peut interroger ce magasin.
  • Le journal d’activité Azure est un magasin distinct avec sa propre interface dans le portail Azure.

Vous pouvez aussi envoyer les données des métriques et des journaux d’activité vers le magasin de journaux Azure Monitor. Vous pouvez ensuite utiliser Log Analytics pour interroger les données et les mettre en corrélation avec d’autres données de journal.

De nombreux services peuvent utiliser les paramètres de diagnostic pour envoyer les données des métriques et des journaux vers d’autres emplacements de stockage en dehors d’Azure Monitor. Il peut ainsi s’agit du Stockage Azure, des systèmes partenaires hébergés et des systèmes partenaires non-Azure, en utilisant Event Hubs.

Pour plus d’informations sur la façon dont Azure Monitor stocke les données, consultez Plateforme de données Azure Monitor.

Métriques de plateforme Azure Monitor

Azure Monitor fournit des métriques de plateforme pour de nombreux services. Pour obtenir la liste de toutes les métriques qu’il est possible de collecter pour toutes les ressources dans Azure Monitor, consultez Métriques prises en charge dans Azure Monitor.

Ce service ne collecte pas les métriques de plateforme.

Métriques non basées sur Azure Monitor

Ce service fournit d’autres métriques qui ne sont pas comprises dans la base de données de métriques Azure Monitor.

Métriques de système d’exploitation invité

Les métriques du système d’exploitation invité qui s’exécutent sur des nœuds de cluster Service Fabric doivent être collectées via un ou plusieurs agents qui s’exécutent sur le système d’exploitation invité. Les métriques du système d’exploitation invité comprennent les compteurs de performances, qui effectuent le suivi du pourcentage de processeur et d’utilisation de mémoire du système invité, lesquels sont fréquemment utilisés pour la mise à l’échelle automatique et les alertes.

Il est recommandé d’utiliser et de configurer l’agent Azure Monitor afin d’envoyer les métriques de performance du système d’exploitation invité via l’API de métriques personnalisées dans la base de données de métriques Azure Monitor. Vous pouvez envoyer les métriques du système d’exploitation invité aux journaux d’activité d’Azure Monitor à l’aide du même agent. Vous pouvez ensuite interroger ces métriques et journaux à l’aide de Log Analytics.

Remarque

L’agent Azure Monitor remplace l’extension Diagnostics Azure et l’agent Log Analytics pour le routage du système d’exploitation invité. Pour plus d’informations, consultez Présentation des agents Azure Monitor.

Journaux de ressources Azure Monitor

Les journaux de ressource fournissent des insights sur les opérations effectuées par une ressource Azure. Les journaux sont générés automatiquement, mais vous devez les acheminer vers les journaux d’Azure Monitor pour les enregistrer ou les interroger. Les journaux d’activité sont organisées par catégories. Un espace de noms donné peut avoir plusieurs catégories de journaux de ressources que vous pouvez collecter.

Ce service ne collecte pas les journaux des ressources, mais vous trouverez des informations les concernant dans Supervision des données à partir de ressources Azure.

Journaux et événements Service Fabric

Service Fabric peut collecter les journaux suivants :

  • Pour des clusters Windows, vous pouvez définir la supervision des clusters avec l’agent Diagnostics et les journaux Azure Monitor.
  • Pour des clusters Linux, les journaux Azure Monitor sont également l’outil recommandé pour la supervision de l’infrastructure et de la plateforme Azure. Les diagnostics de plateforme Linux nécessitent une configuration différente. Pour plus d’informations, consultez Événements de cluster Linux Service Fabric dans Syslog.
  • Vous pouvez configurer l’agent Azure Monitor pour envoyer des journaux de système d’exploitation invité aux journaux d’activité Azure Monitor, où vous pouvez les interroger à l’aide de Log Analytics.
  • Vous pouvez écrire des journaux de conteneur Service Fabric dans stdout ou stderr afin qu’ils soient disponibles dans les journaux Azure Monitor.
  • Vous pouvez configurer la solution de surveillance de conteneur pour les journaux d’activité Azure Monitor afin d’afficher les événements de conteneur.

Autres solutions de journalisation

Même si les deux solutions que nous recommandons, les journaux d’activité Azure Monitor et Application Insights, s’intègrent à Service Fabric, de nombreux événements sont écrits par les fournisseurs ETW et peuvent faire l’objet d’une extension avec d’autres solutions de journalisation. Intéressez-vous également à Elastic Stack (notamment si vous envisagez d’exécuter un cluster dans un environnement hors connexion), à Dynatrace ou à toute autre plateforme de votre choix. Pour obtenir la liste des partenaires intégrés, consultez Partenaires de supervision Azure Service Fabric.

Quelle que soit la plateforme que vous choisissez, ses points clés doivent inclure la convivialité de l’interface utilisateur, les fonctions d’interrogation, les visualisations et tableaux de bord personnalisés disponibles, ainsi que les outils supplémentaires qu’elle met à votre disposition pour améliorer votre expérience de supervision.

Journal des activités Azure

Le journal d’activité contient des évènements au niveau de l’abonnement qui suivent les opérations sur chaque ressource Azure qui sont vues comme extérieures à cette ressource, par exemple, la création d’une ressource ou le démarrage d’une machine virtuelle.

Collecte : les évènements de journal d’activité sont générés et collectés automatiquement dans un magasin distinct pour leur consultation dans le portail Azure.

Routage : vous pouvez envoyer les données de journal d’activité aux journaux Azure Monitor afin de pouvoir les analyser en même temps que d’autres données de journal. D’autres emplacements comme le Stockage Azure, Azure Event Hubs et certains partenaires de monitoring de Microsoft sont également disponibles. Pour plus d’informations sur le routage du journal d’activité, consultez Vue d’ensemble du journal d’activité Azure.

Analyser les données de surveillance

Il existe de nombreux outils pour analyser les données de supervision.

Outils Azure Monitor

Azure Monitor prend en charge les outils de base suivants :

Les outils qui permettent une visualisation plus complexe sont notamment :

  • Les tableaux de bord, qui vous permettent de combiner différentes sortes de données dans un même volet du portail Azure.
  • Les workbooks, des rapports personnalisables que vous pouvez créer dans le portail Azure. Les workbooks peuvent inclure du texte, des métriques et des requêtes de journal.
  • Grafana, un outil de plateforme ouvert, parfait pour les tableaux de bord opérationnels. Vous pouvez utiliser Grafana pour créer des tableaux de bord à partir de données de plusieurs sources autres qu’Azure Monitor.
  • Power BI, un service d’analyse métier qui fournit des visualisations interactives pour diverses sources de données. Vous pouvez configurer Power BI pour importer automatiquement les données de journal à partir d’Azure Monitor afin de tirer parti de ces visualisations supplémentaires.

Pour obtenir une vue d’ensemble des scénarios d’analyse de supervision Service Fabric courants, consultez Diagnostiquer les scénarios courants avec Service Fabric.

Outils d’exportation Azure Monitor

Vous pouvez extraire des données d’Azure Monitor dans d’autres outils en utilisant les méthodes suivantes :

Pour bien démarrer avec l’API REST pour Azure Monitor, consultez Procédure pas à pas de l’API REST d’analyse Azure.

Requêtes Kusto

Vous pouvez analyser les données de supervision dans les journaux Azure Monitor ou le magasin Log Analytics à l’aide du langage de requête Kusto (KQL).

Important

Quand vous sélectionnez Journaux dans le menu du service dans le portail, Log Analytics s’ouvre avec l’étendue de requête définie sur le service actuel. Cette étendue signifie que les requêtes de journal ont seulement des données de ce type de ressource. Si vous voulez exécuter une requête qui comprend des données d’autres services Azure, sélectionnez Journaux dans le menu Azure Monitor. Pour plus d’informations, consultez Étendue de requête de journal et intervalle de temps dans la fonctionnalité Log Analytics d’Azure Monitor.

Pour obtenir la liste des requêtes courantes pour n’importe quel service, consultez l’Interface de requêtes Log Analytics.

Exemples de requêtes

Les requêtes suivantes retournent les événements Service Fabric, y compris les actions sur les nœuds. Pour d’autres requêtes utiles, consultez Événements Service Fabric.

Réexécuter les événements opérationnels enregistrés au cours de la dernière heure :

ServiceFabricOperationalEvent
| where TimeGenerated > ago(1h)
| join kind=leftouter ServiceFabricEvent on EventId
| project EventId, EventName, TaskName, Computer, ApplicationName, EventMessage, TimeGenerated
| sort by TimeGenerated

Retournez des rapports d’intégrité avec HealthState == 3 (Erreur) et extrayez d’autres propriétés à partir du champ EventMessage :

ServiceFabricOperationalEvent
| join kind=leftouter ServiceFabricEvent on EventId
| extend HealthStateId = extract(@"HealthState=(\S+) ", 1, EventMessage, typeof(int))
| where TaskName == 'HM' and HealthStateId == 3
| extend SourceId = extract(@"SourceId=(\S+) ", 1, EventMessage, typeof(string)),
         Property = extract(@"Property=(\S+) ", 1, EventMessage, typeof(string)),
         HealthState = case(HealthStateId == 0, 'Invalid', HealthStateId == 1, 'Ok', HealthStateId == 2, 'Warning', HealthStateId == 3, 'Error', 'Unknown'),
         TTL = extract(@"TTL=(\S+) ", 1, EventMessage, typeof(string)),
         SequenceNumber = extract(@"SequenceNumber=(\S+) ", 1, EventMessage, typeof(string)),
         Description = extract(@"Description='([\S\s, ^']+)' ", 1, EventMessage, typeof(string)),
         RemoveWhenExpired = extract(@"RemoveWhenExpired=(\S+) ", 1, EventMessage, typeof(bool)),
         SourceUTCTimestamp = extract(@"SourceUTCTimestamp=(\S+)", 1, EventMessage, typeof(datetime)),
         ApplicationName = extract(@"ApplicationName=(\S+) ", 1, EventMessage, typeof(string)),
         ServiceManifest = extract(@"ServiceManifest=(\S+) ", 1, EventMessage, typeof(string)),
         InstanceId = extract(@"InstanceId=(\S+) ", 1, EventMessage, typeof(string)),
         ServicePackageActivationId = extract(@"ServicePackageActivationId=(\S+) ", 1, EventMessage, typeof(string)),
         NodeName = extract(@"NodeName=(\S+) ", 1, EventMessage, typeof(string)),
         Partition = extract(@"Partition=(\S+) ", 1, EventMessage, typeof(string)),
         StatelessInstance = extract(@"StatelessInstance=(\S+) ", 1, EventMessage, typeof(string)),
         StatefulReplica = extract(@"StatefulReplica=(\S+) ", 1, EventMessage, typeof(string))

Obtenir les événements opérationnels Service Fabric agrégés avec le service et le nœud spécifiques :

ServiceFabricOperationalEvent
| where ApplicationName  != "" and ServiceName != ""
| summarize AggregatedValue = count() by ApplicationName, ServiceName, Computer

Alertes

Azure Monitor vous alerte de façon proactive quand des conditions spécifiques sont détectées dans vos données de monitoring. Les alertes permettent d’identifier et de résoudre les problèmes affectant votre système avant que vos clients ne les remarquent. Pour plus d’informations, consultez Alertes Azure Monitor.

Il existe de nombreuses sources d’alertes courantes pour les ressources Azure. Pour obtenir des exemples d’alertes courantes pour les ressources Azure, consultez Exemples de requêtes d’alerte de journal. Le site Azure Monitor Baseline Alerts (AMBA) fournit une méthode semi-automatisée pour implémenter les alertes, les tableaux de bord et les recommandations associés·es les plus importants·es aux métriques de plateforme. Le site s’applique à un sous-ensemble des services Azure en constante expansion, y compris tous les services qui font partie de la zone d’atterrissage Azure (ALZ).

Le schéma d’alerte commun standardise la consommation de notifications d'alerte pour Azure Monitor. Pour plus d’informations, consultez Schéma d’alerte courant.

Types d'alertes

Vous pouvez définir une alerte sur n’importe quelle source de données de métrique ou de journal dans la plateforme de données Azure Monitor. Il existe de nombreux types d’alertes différents en fonction des services que vous monitorez et des données de monitoring que vous collectez. Les différents types d’alertes ont divers avantages et inconvénients. Pour plus d’informations, consultez Choisir le bon type d’alerte de monitoring.

La liste suivante décrit les types d’alertes Azure Monitor que vous pouvez créer :

  • Les alertes de métrique évaluent les métriques de ressource à intervalles réguliers. Les métriques peuvent être des métriques de plateforme, des métriques personnalisées, des journaux provenant d’Azure Monitor convertis en métriques ou des métriques Application Insights. Les alertes de métriques peuvent également appliquer plusieurs conditions et seuils dynamiques.
  • Les alertes de journal permettent aux utilisateurs d’utiliser une requête Log Analytics pour évaluer les journaux de ressource à une fréquence prédéfinie.
  • Les alertes de journal d’activité sont déclenchées quand un nouvel événement de journal d’activité correspond à des conditions définies. Les alertes Resource Health et les alertes Service Health sont des alertes de journal d’activité qui concernent l’intégrité de votre service et de vos ressources.

Certains services Azure prennent également en charge les alertes de détection intelligente, les alertes Prometheus ou les règles d’alerte recommandées.

Pour certains services, vous pouvez opérer une surveillance à grande échelle en appliquant la même règle d’alerte de métrique à plusieurs ressources du même type qui existent dans la même région Azure. Les notifications individuelles sont envoyées pour chaque ressource supervisée. Pour connaître les services et clouds Azure pris en charge, consultez Monitorer plusieurs ressources avec une seule règle d’alerte.

Règles d’alerte Service Fabric

Le tableau suivant répertorie certaines règles d’alerte pour Service Fabric. Ces alertes ne sont que des exemples. Vous pouvez définir des alertes pour n’importe quelle métrique, entrée de journal ou entrée de journal d’activité répertoriée dans la référence des données de supervision Service Fabric ou dans la liste des événements Service Fabric.

Type d’alerte Condition Description
Événement de nœud Le nœud tombe en panne ServiceFabricOperationalEvent où EventID >= 25622 et EventID <= 25626. Ces ID d’événement se trouvent dans la référence des événements de nœud.
Données des journaux Restauration de la mise à niveau de l’application ServiceFabricOperationalEvent où EventID == 29623 ou EventID == 29624. Ces ID d’événements se trouvent dans la référence des événements d’application.
Intégrité des ressources Service de mise à niveau inaccessible/indisponible Le cluster passe à l’état UpgradeServiceUnreachable.

Recommandations d’Advisor

Pour certains services, si des conditions critiques ou des changements imminents se produisent pendant des opérations de ressources, une alerte s’affiche dans la page Vue d’ensemble du service concerné dans le portail. Des informations supplémentaires et les correctifs recommandés pour l’alerte sont disponibles dans les Recommandations Advisor sous Surveillance dans le menu de gauche. Pendant les opérations normales, aucune recommandation Advisor ne s’affiche.

Pour plus d’informations sur Azure Advisor, consultez Vue d’ensemble d’Azure Advisor.

Maintenant que nous avons passé en revue chaque zone de supervision et les exemples de scénarios, voici un résumé des outils de supervision Azure et de leur configuration nécessaire pour superviser toutes les zones ci-dessus.

Vous pouvez également utiliser et modifier l’exemple de modèle ARM pour automatiser le déploiement de tous les agents et de toutes les ressources nécessaires.

Contenu connexe