Présentation des alertes pour les opérateurs de Gestion des événements

En tant qu'opérateur de Gestion des événements , vous devez comprendre la façon dont une alerte est générée à partir d'un événement, les éléments à rechercher dans une alerte et le mode de regroupement des alertes.

Cette leçon est la première du didacticiel Gestion des événements.

Leçon 1		Présentation des événements et des alertes
Leçon 2		Présentation des services d'application
Leçon 3		Gestion des événements Postes de travail de l’opérateur
Leçon 4		Activités des opérateurs

Votre organisation dispose déjà d'un outil de surveillance d'événement, tel que Microsoft System Center Operations Manager (SCOM), Nagios, SolarWinds, etc. Lorsqu'un problème se produit sur votre réseau (panne d'un ordinateur ou défaillance de la base de données), les outils de surveillance d'événement envoient des événements à votre instance ServiceNow. L'application Gestion des événements traite les événements en fonction des paramètres configurés par votre administrateur, puis génère des alertes. Une alerte indique que le problème nécessite une action spécifique.

Figure 1. Génération d'alertes

En tant qu'opérateur Gestion des événements, votre rôle est d'afficher les alertes et, selon la façon dont l'application Gestion des événements est implémentée dans votre organisation, de prendre une action pour résoudre le problème sous-jacent ou d'informer une autre personne de le faire. Plus tard dans ce didacticiel, vous analyserez les différentes phases d'un processus de gestion des alertes standard.

Priorité et gravité de l'alerte

Les deux caractéristiques les plus courantes d'une alerte sont la priorité et la gravité.

• La priorité d’une alerte est un score qui vous aide à déterminer l’importance de l’impact pour les services d’application. Plusieurs facteurs déterminent le score de priorité de l'alerte. Votre administrateur Gestion des événements peut configurer l'algorithme que l'application Gestion des événements utilise pour calculer la priorité.
• La gravité d'une alerte est un indicateur de la gravité du problème sous-jacent. L'outil de surveillance d'événement de votre organisation envoie généralement des valeurs de gravité avec l'événement, qui est ensuite reporté dans l'alerte. Voici les types de gravité par défaut abordés dans ce didacticiel :

  Gravité	Description
  Critique	La ressource n'est pas fonctionnelle ou des problèmes critiques sont imminents.
  Majeure	La fonctionnalité majeure est gravement altérée ou les performances se sont dégradées.
  Mineure	Une perte partielle et non critique de fonctionnalité ou une dégradation des performances s'est produite.
  Avertissement	Surveillance requise, même si la ressource est toujours fonctionnelle.
  OK	Aucune gravité. Une alerte est créée. La ressource est toujours fonctionnelle.
  Effacer	Plus aucune action n'est nécessaire sur l'alerte.

Alertes corrélées

Certaines alertes sont liées les unes aux autres. Par exemple, si un routeur tombe en panne, plusieurs alertes distinctes peuvent être générées, une pour chaque serveur connecté au routeur. Toutes ces alertes sont liées ou corrélées. Pour vous aider à gérer les alertes corrélées, Gestion des événements peut les regrouper automatiquement et établir une hiérarchie à deux niveaux avec une alerte racine au sommet, appelée alerte primaire, et d'autres alertes connexes sous l'alerte primaire, appelées alertes secondaires. Lorsque vous consultez des alertes, les alertes primaires sont par défaut mises en évidence afin que vous puissiez vous concentrer sur les alertes importantes sans être distrait par les alertes secondaires.

Dans notre exemple, si un routeur tombe en panne sur votre réseau, cette panne a également une incidence sur la communication réseau avec les serveurs connectés, en supposant que ces derniers ne peuvent accéder à aucun autre routeur. La panne du routeur devient l'alerte primaire, et les alertes générées sur le serveur sont les alertes secondaires corrélées sous l'alerte de routeur.

Figure 2. Génération d'alertes secondaires

Selon l'implémentation de Gestion des événements dans votre organisation, les alertes peuvent être regroupées automatiquement en fonction des règles de corrélation que votre administrateur configure. Votre instance peut également apprendre à améliorer son mode de corrélation des alertes en fonction de ces règles et des commentaires que vous fournissez. En tant qu'opérateur, vous devez toujours vérifier l'exactitude de la corrélation et, si nécessaire, corréler manuellement les alertes supplémentaires avec l'alerte primaire. Vous apprendrez à effectuer cette tâche plus tard dans le didacticiel.

Dans ce didacticiel, vous apprendrez à corréler manuellement les alertes. Dans une rubrique avancée, vous découvrirez comment fournir des commentaires afin que votre système puisse améliorer le processus de corrélation automatique des alertes.

Bagottement d'alerte

Une alerte peut bagotter, c'est-à-dire obtenir plusieurs événements successifs d'ouverture/de fermeture. Le bagottement indique que Gestion des événements ne parvient pas à déterminer l'authenticité des événements sous-jacents. Les événements peuvent indiquer des problèmes mineurs liés au mode de configuration des CI, ou des problèmes plus importants, par exemple des pannes de réseau.

Figure 3. Bagottement d'alerte

Par exemple, si un trop grand nombre de processus sont actifs sur le serveur qui héberge un service Web, un événement d'utilisation excessive du processeur peut se déclencher. Dans la mesure où l'utilisation du processeur peut fluctuer rapidement en fonction des demandes de service Web, plusieurs événements peuvent être déclenchés et mettre l'alerte à l'état d'oscillation. En tant qu'opérateur, vous devrez peut-être créer un incident pour solliciter le redémarrage du serveur, ou une autre personne devra peut-être reconfigurer le processeur ou effectuer un changement matériel sur l'appareil.

Comme autre exemple, supposons qu'un câble réseau lâche provoque des pannes de réseau momentanées et répétées. Il est possible que les seuils configurés par votre administrateur ne soient pas optimaux pour ce type d'alerte et que Gestion des événements considère qu'il s'agit d'une alerte d'oscillation.

Poursuivre le didacticiel

Passez à la leçon suivante : Services d’application pour Gestion des événements les opérateurs.