Présentation de la corrélation d’alertes

Dernière rubrique modifiée : 2015-03-09

Le moteur de corrélation est le composant central du pack d’administration d’analyse de MicrosoftExchange Server 2010. Le moteur de corrélation a été développé en vue de réduire considérablement le nombre d’alertes déclenchées par le pack d’administration.

Dans le pack d’administration d’Exchange 2007, les alertes ont toujours été déclenchées lorsqu’une analyse passait de l’état vert à l’état rouge. Ce type d’alerte est désactivé dans le pack d’administration d’Exchange Server 2010. Désormais, c’est le moteur de corrélation qui gère les alertes. Il traite les données des analyses du pack d’administration, puis détermine s’il est nécessaire de déclencher une alerte. Le moteur de corrélation aide l’administrateur qui analyse l’environnement Exchange à se concentrer uniquement sur les alertes qui nécessiteront éventuellement une intervention de votre part.

Architecture

Le moteur de corrélation est un service Windows autonome qui utilise l’interface du Kit de développement logiciel (SDK) de Microsoft Operations Manager pour extraire d’abord le modèle d’intégrité (ou espace d’instance), puis gérer les événements liés à un changement d’état. En préservant en mémoire le modèle d’intégrité et en traitant les événements de changement d’état, le moteur de corrélation peut déterminer à quel moment il doit émettre une alerte en fonction de l’état du système.

Ce diagramme montre que plusieurs analyseurs changent d’état en réponse à un problème, et les événements de changement d’état correspondants sont transmis par l’agent au serveur d’administration racine. Une fois reçus sur le serveur d’administration racine, ils sont traités par le moteur de corrélation qui peut émettre une alerte via l’interface du Kit de développement logiciel (SDK) du serveur d’administration racine. Cette alerte est ensuite visible sur la console d’Operations Manager.

Classification des alertes

Les alertes du pack d’administration d’analyse d’Exchange Server 2010 sont classées en trois catégories. Reportez-vous aux instructions suivantes pour comprendre les classifications des alertes.

• Indicateurs clés d’intégrité (KHI)   Les indicateurs clés d’intégrité (KHI) sont des éléments qui affectent l’intégrité du service. La majorité des alertes appartiennent à cette classe (par exemple, « Une base de données de boîtes aux lettres est démontée ».)

• NSI (Non-Service Impacting)   Les analyses NSI permettent de détecter des problèmes susceptibles d’avoir une incidence sur certains utilisateurs, mais pas tous les utilisateurs du système. Un bon exemple de situation NSI est l’utilisation d’une même adresse proxy par deux utilisateurs. Le courrier émis à cette adresse sera retourné comme élément non remis sans que cela nuise au système de transport global.

• Analyse d’investigation   Les analyses d’investigation permettent d’enregistrer des informations pertinentes tout en apportant une solution à un problème mais elles n’indiquent pas nécessairement une panne système importante ou existante. Par exemple, un processeur fonctionnnant à 90 % pendant 5 minutes est un cas de problème d’investigation : il est possible qu’un processus n’applique pas comme il se doit les cycles processeur ou le serveur a peut-être été redémarré et le système se remet lentement à fonctionner de manière normale. Ces analyses sont visibles dans le champ Contexte de l’alerte des propriétés de l’alerte et dans l’Explorateur d’intégrité. Aucune alerte n’est émise pour les analyses d’investigation.

Remarque :
L’état n’est pas mis à jour lorsqu’une seule alerte d’analyse d’investigation est déclenchée. Il peut néanmoins l’être avec l’agrégation des alertes d’analyse d’investigation en cours pour chaque composant.

Gravité des alertes

Les alertes du pack d’administration d’analyse d’Exchange Server 2010 sont également classées en fonction de leur gravité, comme suit :

• Alertes d’erreur   Les alertes d’erreur indiquent un problème grave qui doit être traité immédiatement.

• Alertes d’avertissement   Les alertes d’avertissement signalent l’existence d’une condition susceptible de générer des problèmes.

• Alertes d’information   Les alertes d’information ne sont pas déclenchées par le pack d’administration de Microsoft Exchange 2010.

Facteurs de corrélation

Les actions entreprises par le moteur de corrélation reposent sur plusieurs facteurs, notamment les suivants :

Événements de changement d’état des analyses   Les analyses collectent des informations de diagnostic de l’environnement Exchange, à partir de sources telles que les messages du journal des événements, les seuils des compteurs de performance et les événements de sortie des tâches PowerShell. Elles enregistrent les événements de changement d’état lorsqu’elles détectent un problème qui est survenu ou qui a été supprimé (passage de l’état rouge à l’état vert, et inversement). ou lorsqu’un serveur Exchange ne peut pas être contacté ou lorsqu’un serveur Exchange devient disponible. Enfin, les analyses enregistrent les changements d’état lorsqu’un serveur Exchange est placé en mode maintenance ou retiré du mode maintenance. Dans le pack d’administration d’Exchange 2007, les alertes étaient déclenchées lorsqu’une analyse passait de l’état vert à l’état rouge. Dans le pack d’administration d’Exchange 2010, les alertes ne sont pas automatiquement déclenchées suite à des changements d’état des analyses. Le moteur de corrélation détermine s’il est nécessaire de déclencher une alerte. Le pack d’administration d’Exchange 2010 comprend une règle d’alerte pour chaque analyse. Ainsi, le personnel d’analyse peut utiliser la console Opérateur pour accéder aux propriétés de chaque analyse dans le pack d’administration. Cela lui permet de saisir des notes relatives à l’entreprise pour une analyse donnée dans le champ Base de connaissances de la société, même lorsque l’analyse ne génère pas d’alertes.

Modèle d’intégrité   La hiérarchie de classes importée dans Operations Manager par le pack d’administration d’Exchange 2010 inclut des relations de classes qui définissent les dépendances des composants dans l’ensemble du système. La définition de ces dépendances permet au pack d’administration d’Exchange 2010 de mieux comprendre l’intégrité de l’organisation Exchange. Par exemple, si le pack d’administration d’Exchange 2010 identifie Active Directory comme étant en mode hors connexion, il signalera également que la messagerie Exchange ne fonctionne pas pleinement.

Calcul du temps Le moteur de corrélation fonctionne par intervalles de 90 secondes. Lorsque des événements de changement d’état de plusieurs analyses surviennent en même temps, le moteur de corrélation attend de voir si des éléments potentiellement liés à la panne peuvent être détectés afin de déterminer au mieux la cause première du problème.

Algorithme de corrélation

Présentation du processus du moteur de corrélation

1. Le moteur de corrélation se connecte au service SDK d’Operations Manager pour télécharger la hiérarchie du modèle d’intégrité et l’état de l’instance. Cela se produit au démarrage du service uniquement ou selon les besoins si des erreurs l’exigent.

2. Le moteur de corrélation interroge Operations Manager sur les derniers événements de changement d’état associés à des entités dans le pack d’administration d’Exchange.

3. Si de nouveaux changements d’état NSI sont détectés, il émet des alertes à leur sujet.

4. Le moteur de corrélation isole les données pour toutes les analyses d’indicateurs clés d’intégrité dont l’état est rouge. Il rassemble ces données dans des regroupements logiques qui affichent chaque processus en fonction de ceux dont il dépend et de ceux qui dépendent de lui. Ces regroupements sont communément appelés « chaînes d’indicateurs clés d’intégrité ». Chaque chaîne indique où une dépendance a échoué et si elle concerne un ou plusieurs processus dépendants.

5. Le moteur de corrélation déclenche une alerte pour chaque chaîne d’indicateurs clés d’intégrité. Chaque alerte déclenchée par le moteur de corrélation identifie la cause première de chacun des problèmes.

6. Le moteur de corrélation attend 90 secondes, puis redémarre à l’étape 2.

Informations supplémentaires sur le processus du moteur de corrélation

• Si la chaîne des indicateurs KHI comprend à la fois des analyses d’erreur et d’avertissement, l’alerte est déclenchée en tant qu’erreur, quelle que soit la classe de l’analyse à l’origine du problème. Par exemple, si un processus de niveau supérieur définit une analyse d’erreur pour identifier des pannes et s’il est associé à une analyse d’avertissement au sein d’une dépendance, l’alerte est déclenchée par rapport à la dépendance. mais elle apparaîtra sous la forme d’une erreur et non d’un avertissement.

• Toutes les relations de classes ne sont pas utilisées pour la corrélation des alertes. Consultez la section Annexe : hiérarchie de classes plus loin dans ce guide pour connaître les relations spécifiques employées par le moteur de corrélation.

• La chaîne KHI, y compris les analyses d’investigation, est incluse dans le champ Contexte de l’alerte qui figure dans les propriétés de l’alerte finale. L’administrateur peut alors passer en revue les analyses associées à l’alerte concernée. Les alertes déclenchées à partir des analyses de dépendance doivent également être inspectées pour déterminer la panne spécifique référencée par l’alerte.

Éléments affectés et non affectés par la corrélation d’alertes

Il est important de comprendre les éléments affectés ou non par le moteur de corrélation.

Les éléments suivants diffèrent dans le pack d’administration d’Exchange 2010 en raison de la présence du moteur de corrélation :

• Les analyses n’émettent pas automatiquement une alerte lors d’événements de changement d’état. Le moteur de corrélation peut ainsi déterminer la meilleure alerte à déclencher.

• Le pack d’administration d’Exchange 2010 ne déclenche pas d’alertes relatives à l’intégrité de votre environnement Exchange lorsque vous arrêtez le moteur de corrélation. En cas d’arrêt du moteur de corrélation, une alerte générale est déclenchée pour vous informer que le moteur de corrélation n’est pas en cours d’exécution.

Les éléments suivants ne changent pas en présence du moteur de corrélation :

• Les remplacements fonctionnent toujours comme prévu. Vous pouvez modifier certaines valeurs ou désactiver des analyses comme vous le faites actuellement.

• Les analyses et objets en mode maintenance sont ignorés par le moteur de corrélation. Aucune attention particulière n’est requise puisque les analyses ne déclenchent pas d’événements de changement d’état.

• La présence du moteur de corrélation n’a aucun impact sur d’autres packs d’administration.

Notes opérationnelles

Le moteur de corrélation doit mémoriser l’espace d’instance du groupe d’administration afin de déterminer les analyses et alertes associées. Par conséquent, plus vous disposez de serveurs et de bases de données Exchange, plus la mémoire requise par le moteur de corrélation sera importante.

Le moteur de corrélation requiert approximativement 5 mégaoctets de mémoire par serveur Exchange analysé. Ces facteurs peuvent faire augmenter ou baisser ce chiffre, mais c’est un bon point de départ pour comprendre l’impact des ressources sur le serveur qui héberge le service.

Réinitialisation automatique des observateurs d’événements dans le pack d’administration d’Exchange 2010

Dans le pack d’administration d’Exchange 2010, la plupart des observateurs d’événements sont automatiquement réinitialisés par le moteur de corrélation. La réinitialisation automatique a été ajoutée à ces analyseurs afin que les problèmes soient systématiquement détectés dès qu’ils se reproduisent. Le tableau suivant répertorie les observateurs d’événements qui ne sont pas réinitialisés automatiquement.