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.
Il s’agit de la première leçon du Gestion des événements tutoriel.
| Leçon 1 |
|
Vue d’ensemble des événements et des alertes |
| Leçon 2 |  |
|
| Leçon 3 | |
|
| Leçon 4 | |
Votre organisation a déjà un outil de surveillance d’événement en place, tel que Microsoft System Center Operations Manager (SCOM), Nagios, SolarWinds, et autres. Lorsqu’un problème se produit sur votre réseau, tel qu’une panne d’ordinateur ou une défaillance de la base de données, les outils de surveillance d’événements envoient des événements à votre ServiceNow instance. 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 un certain type d’action.
En tant qu’opérateur Gestion des événements , votre rôle consiste à afficher les alertes et, selon la façon dont Gestion des événements elles sont mises en œuvre dans votre organisation, à prendre des mesures pour aider à résoudre le problème sous-jacent ou à notifier quelqu’un qui le peut. Plus loin dans ce didacticiel, vous découvrirez les phases d’un processus typique de gestion des alertes.
Priorité et gravité de l’alerte
- La priorité d’une alerte est un score qui vous aide à déterminer l’importance de l’impact sur les services d’application. Plusieurs facteurs déterminent le score de priorité des alertes. Votre Gestion des événements administrateur peut configurer l’algorithme que l’application utilise pour calculer la Gestion des événements priorité.
- La gravité d’une alerte est un indicateur de la gravité du problème sous-jacent. L’outil de surveillance des événements de votre organisation envoie généralement des valeurs de gravité à l’événement, qui sont ensuite reportées dans l’alerte. Voici les types de gravité par défaut que vous verrez dans ce tutoriel :
Gravité Description 
critiqueLa ressource n'est pas fonctionnelle ou des problèmes critiques sont imminents. 
majeureLa fonctionnalité majeure est gravement altérée ou les performances se sont dégradées. 
Une perte partielle et non critique de fonctionnalité ou une dégradation des performances s’est produite. 
Attention requise, même si la ressource est toujours fonctionnelle. 
OKAucune gravité. Une alerte est créée. La ressource est toujours fonctionnelle. 
EffacerL’alerte n’a plus besoin d’action.
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 vous pouvez les regrouper automatiquement et établir une hiérarchie à deux niveaux avec une alerte racine, appelée alerte primaire, en haut, et d’autres alertes connexes, appelées alertes secondaires, sous l’alerte primaire. Lorsque vous affichez des alertes, les alertes primaires se distinguent par défaut afin que vous sachiez sur quelle alerte vous concentrer sans être distrait par les alertes secondaires.
Dans notre exemple, si un routeur tombe en panne sur votre réseau, la communication réseau est également affectée pour les serveurs connectés, en supposant qu’ils ne peuvent atteindre aucun autre routeur. La panne du routeur devient l’alerte primaire et les alertes générées sur le serveur sont des alertes secondaires qui sont corrélées sous l’alerte du routeur.
Selon l’implémentation de Gestion des événements votre entreprise, les alertes peuvent être regroupées automatiquement en fonction des règles de corrélation configurées par votre administrateur. Votre instance peut également apprendre à améliorer la façon dont elle met en corrélation les alertes en fonction de ces règles. 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. Plus tard dans le tutoriel, vous apprendrez à le faire.
Dans ce didacticiel, vous allez apprendre à corréler manuellement des alertes.
Oscillation d’alerte
Une alerte peut osciller, ce qui signifie qu’elle reçoit plusieurs événements d’ouverture-fermeture en succession rapide. L’oscillation indique que Gestion des événements ne sait pas si les événements sous-jacents sont authentiques ou non. Les événements peuvent révéler de petits problèmes liés à la façon dont les CI sont configurés, ou des problèmes plus importants, tels que des pannes de réseau.
Par exemple, si un serveur qui héberge un service Web a trop de processus actifs, il peut déclencher un événement concernant une utilisation excessive du processeur. Étant donné que l’utilisation du processeur peut fluctuer rapidement en fonction des demandes de service web, plusieurs événements peuvent être déclenchés, conduisant à l’état d’oscillation de l’alerte. En tant qu’opérateur, vous devrez peut-être créer un incident pour redémarrer le serveur, ou quelqu’un devra peut-être reconfigurer le processeur, ou éventuellement apporter une modification matérielle à l’appareil.
Autre exemple, prenons l’exemple d’un câble réseau desserré qui provoque des pannes de réseau momentanées et répétées. Les seuils configurés par votre administrateur peuvent ne pas être optimaux pour ce type d’alerte et Gestion des événements la considère comme une alerte d’oscillation.
Continuer le tutoriel
Passez à la leçon suivante : Services d’application pour Gestion des événements les opérateurs.