Users Guide
cliquez sur Action Test. Pour un transfert d'interruption dans le même format vers la destination configurée, cliquez
sur Transfert de l'interruption au format d'origine, puis cliquez sur Suivant.
4. Sous Association de gravité, choisissez la gravité d'alerte à associer à cette alerte de transfert d'interruptions, puis
cliquez sur Suivant.
5. Sous Association Catégories-Sources, choisissez la source de catégories d'alertes à associer à cette action de
transfert d'interruptions, puis cliquez sur Suivant.
6. Sous Association de périphérique, choisissez le périphérique ou les groupes de périphériques à associer au
transfert d'interruptions, 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é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.
127