Users Guide

L'état de gravité de toute interruption est défini sur normal et pour une action d'alerte réussie, la
combinaison de gravité, catégorie et périphérique doit correspondre aux sélections effectuées au
cours des étapes précédentes.
Scénarios de cas d'utilisation de transferts d'alertes
Cette section décrit des scénarios de transfert d'alertes à l'aide des protocoles SNMP v1 et SNMP v2. Ces
scénarios sont constitués des composants suivants :
un nœud géré par un agent SNMP v1, désigné MN1
un nœud géré par un agent SNMP v2/v2c , désigné MN2
une station 1 gérée par OpenManage Essentials, désignée MS1
une station 2 gérée par OpenManage Essentials, désignée MS2
une station 3 gérée par un logiciel tiers, désignée 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 transmises de MS1 à MS2. Si
vous tentez de récupérer l'hôte distant d'une alerte transmise, il affichera le nom de MNv1 car l'alerte
provient de MN1. MNv1 s'affiche car les standards d'alerte de SNMP v1 vous permettent de définir le nom
de l'agent de 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 transmises de MS1 à MS3. Si
vous tentez de récupérer l'hôte distant d'une alerte transmise depuis MS3, il s'affiche comme MS1
Puisqu'il n'existe, dans une alerte SNMP v2, 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 transmise 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 un OID de .1.3.6.1.6.3.18.1.3.0 et la valeur variable
Adresse d'agent. Ceci a été défini en fonction du OID standard spécifié dans RFC2576-MIB. Lorsque vous
tentez de récupérer l'Adresse de l'agent depuis MS3, elle s'affiche en tant que MN2
REMARQUE : Si l'alerte SNMP v2 est transmise de MS1 à MS2, l'hôte distant s'affiche en tant que
MNv2 parce que MS1 analyse l'OID supplémentaire avec l'interruption transmise.
Scénario 3 —:Transfert d'alertes dans le format OMEssentials à l'aide du protocole SNMP v1
ou SNMPv2
Dans ce scénario, les alertes SNMP v1 sont envoyées de MNv1 à MS1, puis transmises à MS2. Si vous
tentez de récupérer l'hôte distant d'une alerte transmise, il s'affiche comme MS1. La gravité et le message
de l'alerte sont également définis par MS1, n'affichant pas la gravité ni le message d'origine définis par
MNv1.
REMARQUE : Le même comportement s'applique aux interruptions SNMPv2.
Travailler avec des cas d'utilisation d'action d'alerte
exemples
Des exemples d'actions d'alerte sont disponibles pour les actions d'alerte Lancement de l'application, E-
mail, Ignorer et Transfert d'interruption. Les exemples d'actions d'alerte sont désactivés par défaut.
Cliquez sur l'exemple d'action d'alerte pour l'activer.
309