Users Guide

Liens connexes
Journaux d'alertes
Champs des journaux d'alertes
Paramètres du journal d'alertes
Gravité
Transfert d'alertes
Vous pouvez être amené à réunir les alertes de plusieurs postes de gestion sur un seul poste de gestion. C'est le cas si vous
possédez des postes de gestion sur plusieurs sites géographiques, et que vous souhaitez acher leur état et eectuer des actions
depuis un unique emplacement. Pour plus d'informations concernant le comportement d'alertes transférées, consultez la section Cas
d'utilisation de transfert d'alertes.
Pour créer des transferts d'alertes, procédez comme suit :
1. Sélectionnez Gérer → Alertes → Tâches communes → Nouvelle action de transfert d'interruption d'alertes.
2. Sous Nom et Description, indiquez un nom et une description pour le transfert d'interruptions, puis cliquez sur Suivant.
3. Sous Conguration du transfert d'interruptions, fournissez le nom d'hôte ou l'adresse IP de destination et les informations sur
la communauté, an d'envoyer une interruption test au poste de gestion de destination, puis cliquez sur Action de test. Pour
transférer l'interruption au même format vers la destination congurée, cliquez sur Transfert de l'interruption dans le format
original et cliquez sur Suivant.
4. Sous Association de gravité, choisissez la gravité d'alerte à associer à cette alerte de transfert d'interruption, puis cliquez sur
Suivant.
5. Sous Association Catégories-Sources, choisissez la source de catégories d'alertes à associer à cette alerte de transfert
d'interruption, puis cliquez sur Suivant.
6. Sous Association de périphérique, choisissez le périphérique ou les groupes de périphériques à associer à l'alerte de transfert
d'interruption, puis cliquez sur
Suivant.
7. Par défaut, l'action Transfert d'interruption est toujours active. Pour limiter son activité, dans Association de date et d'heure,
entrez une plage de dates, une plage horaire ou des jours, puis cliquez sur Suivant.
8. Sous Résumé, passez votre saisie en revue, puis cliquez sur Terminer.
L'état de gravité de toute interruption est déni sur normal et pour une action d'alerte réussie, la combinaison de gravité, de
catégorie et de périphérique doit correspondre aux sélections eectuées au cours des étapes précédentes.
Scénarios de cas d'utilisation de transfert d'alertes
Cette section présente les scénarios de transfert d'alertes à l'aide des protocoles SNMP v1 et SNMP v2. Les scénarios sont
constitués des composants suivants :
• nœud géré avec un agent SNMP v1, appelé MNv1
• nœud géré avec un agent SNMP v2/v2c, appelé MNv2
• poste 1 géré avec OpenManage Essentials, appelé MS1
• poste 2 géré avec OpenManage Essentials, appelé MS2
• poste 3 géré avec un logiciel tiers, appelé MS3
Scénario 1 : Transfert d'alertes au format d'origine à l'aide du protocole SNMP v1
Dans ce scénario, les alertes SNMP v1 sont envoyées de MNv1 à MS1, puis transférées de MS1 à MS2. Si vous tentez de récupérer
l'hôte distant de l'alerte transférée, il ache le nom MNv1 car l'alerte provient de MNv1. MNv1 s'ache car les standards d'alerte
SNMP v1 vous permettent de dénir le nom de l'agent dans l'alerte SNMP v1.
Scénario 2 : Transfert d'alertes au format d'origine à l'aide du protocole SNMP v2/v2c.
Dans ce scénario, les alertes SNMP v2 sont envoyées de MNv2 à MS1, puis transférées de MS1 à MS3. Si vous tentez de récupérer
l'hôte distant de l'alerte transférée à partir de MS3, le nom aché est MS1
Puisqu'une alerte SNMP v2 ne présente aucun champ permettant d'indiquer le nom de l'agent, l'hôte qui envoie l'alerte est considéré
comme l'agent. Lorsqu'une alerte SNMP v2 est transférée de MS1 à MS3, MS1 est considéré comme la source du problème. Pour
résoudre ce problème, lors du transfert des alertes SNMP v2 ou v2c, un varbind est ajouté avec l'OID .1.3.6.1.6.3.18.1.3.0 et la valeur
variable Adresse de l'agent. Ceci a été déni en fonction de l'OID standard indiqué dans RFC2576-MIB. Lorsque vous tentez de
récupérer l'adresse de l'agent depuis MS3, le nom qui s'ache est MNv2.
264