Table des matières
Configuration des évènements et des alarmes
1. Concepts clefs
La fonction principale d’OpenNMS est de recevoir des traps SNMP. Ces traps SNMP sont décodées à l’aide de fichiers de configuration créés à partir des MIBs SNMP. Les traps SNMP, une fois décodées, sont visibles sous forme d’évènement dans la vue Events et sous forme d’alarme dans la vue Alarms. Ces deux vues peuvent contenir également les évènements internes à OpenNMS.
La vue Events permet de visualiser tous les évènements reçus, elle sert principalement d’historique ou de bac à évènement.
La vue Alarms permet de visualiser les alarmes en cours grâce à deux fonctions principales :
- la déduplication : lorsqu’on reçoit plusieurs fois la même alarme provenant du même équipement, on l’affiche sur une seule ligne avec un compteur qui indique combien de fois on l’a reçu (voir un exemple dans le chapitre 3.4);
- la corrélation début-fin : lorsqu’on reçoit une alarme qui indique la fin d’un problème, on change la couleur de l’alarme reçue précédemment qui indiquait le début du problème (voir un exemple dans le chapitre 3.5);
Le but de cette vue est de montrer le plus synthétiquement possible uniquement les problèmes en cours et d’évacuer ceux qui sont terminés.
2. Outil mib2opennms
L’outil mib2opennms est un outil qui permet de transformer une mib SNMP en fichier de configuration XML compréhensible par OpenNMS.
2.1 Installation
Pour installer l’outil mib2opennms sur un système CentOS, tapez la commande suivante :
shell> yum install mib2opennms
2.2 Utilisation
Exemple d’utilisation pour décoder la mib NET-SNMP-AGENT :
shell> mib2opennms -f /opt/opennms/etc/events/NetSNMP.events.xml -6 -w /usr/share/snmp/mibs/NET-SNMP-AGENT-MIB.txt
Ceci est un exemple. Vous ne devez pas lancer cette commande car le fichier /opt/opennms/etc/events/NetSNMP.events.xml existe déjà !
2.3 Traitement post-exécution
Cet outil effectue une traduction simple de la mib. Certains éléments sont à configurés manuellement comme :
- l’affichage des évènement dans la vue alarms ;
- la déduplication ;
- la corrélation début-fin
3. Fichiers de configuration des évènements
3.1 Localisation
Les fichiers d’évènements sont stockés dans le répertoire /opt/opennms/etc/events.
Le fichier /opt/opennms/etc/eventconf.xml contient :
- Les évènements internes à OpenNMS ;
- Les fichiers d’évènements du répertoire /opt/opennms/etc/events à inclure dans la configuration ;
Lorsqu’un fichier est ajouter au répertoire /opt/opennms/etc/events, il faut insérer à la fin du fichier /opt/opennms/etc/events une ligne identique à celle-ci :
... <event-file>events/NetSNMP.events.xml</event-file> ...
OpenNMS possède en standard de nombreux fichiers d’évènements qu’il est nécessaire d’enrichir (corrélation, déduplication, …). Une liste est disponible ici.
3.2 Syntaxe des fichiers de configuration
Exemple de configuration XML pour l’évènement nsNotifyShutdown dans le fichier /opt/opennms/etc/events/NetSNMP.events.xml :
<event> <mask> <maskelement> <mename>id</mename> <mevalue>.1.3.6.1.4.1.8072.4</mevalue> </maskelement> <maskelement> <mename>generic</mename> <mevalue>6</mevalue> </maskelement> <maskelement> <mename>specific</mename> <mevalue>2</mevalue> </maskelement> </mask> <uei>uei.opennms.org/vendor/netsnmp/traps/nsNotifyShutdown</uei> <event-label>NET-SNMP-AGENT-MIB defined trap event: nsNotifyShutdown</event-label> <descr> <p>An indication that the agent is in the process of being shut down.</p><table></table> </descr> <logmsg dest='logndisplay'>nsNotifyShutdown trap received</logmsg> <severity>Warning</severity> <alarm-data reduction-key="%uei%:%nodeid%:%interface%" alarm-type="1" auto-clean="true" /> </event>
La partie mask permet de sélectionner la trap SNMP qui sera décodé selon :
- l’OID SNMP renseigné après la balise <id>
- l’identifiant SNMP generic renseigné après la balise <generic>
- l’identifiant SNMP specific renseigné après la balise <specific>
Il est également possible d’ajouter un filtrage selon les varbinds de la trap SNMP. Par exemple, pour sélectionner la trap donc la varbind n°1 est égal à 2, il faut rajouter dans la partie mask la configuration suivante :
<varbind> <vbnumber>1</vbnumber> <vbvalue>2</vbvalue> </varbind>
La balise <UEI> (Unique Event Identifier) est utilisé pour spécifier une chaîne de caractère qui identifie de façon unique le type d’évènement dans l’application et plus particulièrement lors de l’utilisation des filtres dans la vue Events et Alarms.
La balise <event-label> permet de spécifier un label pour cet évènement.
La balise <descr> permet de décrire l’évènement de façon plus détaillé. Cette partie sera visible dans la vue Event Detail de l’application. Le code HTML peut être utilisé pour cette partie. L’affichage des varbinds SNMP s’effectue à l’aide des champs %parm[#number]%. %parm[#1]% pour la 1ère varbind par exemple.
La balise <logmsg> est utilisée pour configurer le texte qui sera affiché dans la colonne Log Msg de la vue Events ou Alarms. Le paramètre dest permet de régler l’affichage et le stockage des évènements.
La sévérité de l’évènement est renseignée dans la balise <severity>.
3.2.1 Déduplication / Corrélation début-fin
Lorsque la balise <alarm-data> est présente dans la configuration de l’évènement, celui-ci apparaît dans la vue Alarms.
Configuration pour une alarme indiquant un début de problème :
<alarm-data reduction-key="%uei%:%nodeid%:%interface%" alarm-type="1" auto-clean="true" />
Le champ alarm-type est utilisé pour spécifier le début d’alarme (1) ou la fin d’alarme (2).
Le champ reduction-key est utilisé pour la déduplication. Dans cette exemple, les évènements qui auront le même uei (même identifiant d’évènement), qui concerneront le même équipement (nodeid : identifiant de l’équipement dans la base de données) et qui concerneront la même interface (interface : adresse ip qui indique la source du trap SNMP) seront affichés sur une seule ligne dans la vue alarms. Un compteur sera incrémenté lors de la réception d’une nouvelle alarme.
Configuration pour l’alarme qui indique la fin du problème correspondant :
<alarm-data reduction-key="%uei%:%nodeid%:%interface%" alarm-type="2" auto-clean="true" clear-key="uei.opennms.org/vendor/netsnmp/traps/nsNotifyShutdown:%nodeid%:%interface%" />
Le paramètre clear-key est utilisé pour définir l’alarme qui indique le début du problème et qui est résolue par cette alarme. Dans l’exemple précédent : nsNotifyShutdown = début de problème. nsNotifyStart = fin du problème.
Le champ clear-key de l’alarme nsNotifyStart doit être égal au champ reduction-key de l’alarme nsNotifyShutDown.
Lorsque le paramètre auto-clean est positionné à true, seul le dernier évènement qui a généré une alarme est conservé dans la vue Events. Ceci permet de ne pas encombrer la vue Events (et la table Events par la même occasion) mais supprime certaines données.
3.3 Prise en compte des modifications
Pour que les modifications soient prises en compte, vous devez redémarrer OpenNMS. Pour cela, tapez la commande suivante :
shell> service opennms restart
3.4 Exemple de déduplication
Le déduplication permet sur certains critères configurables de regrouper plusieurs alarmes sur une seule ligne tout en incrémentant un compteur.
Si on génère plusieurs fois le trap nsNotifyShutdown (remplacer 192.168.1.9 par l’adresse IP de OpenNMS) :
shell> snmptrap -v2c -c public 192.168.1.9 0 1.3.6.1.4.1.8072.4.2
Tous les traps s’affichent sur une seule ligne, un compteur indique combien de fois il a été reçu :
3.5 Exemple de corrélation début-fin
Lorsqu’on reçoit une alarme qui indique la fin d’un problème, la règle de corrélation début / fin permet de changer la couleur de l’alarme reçu précédemment qui indiquait le début de ce problème.
3.5.1 Réception de l’alarme de début de problème
On génère le trap nsNotifyShutdown (remplacer 192.168.1.9 par l’adresse IP de OpenNMS) :
shell> snmptrap -v2c -c public 192.168.1.9 0 1.3.6.1.4.1.8072.4.2
3.5.2 Réception de l’alarme de fin de problème (symbolisé par la couleur blanche)
On génère le trap nsNotifyStart (remplacer 192.168.1.9 par l’adresse IP de OpenNMS) :
shell> snmptrap -v2c -c public 192.168.1.9 0 1.3.6.1.4.1.8072.4.1
3.5.3 Corrélation des deux alarmes au bout d’un délai configurable
Ce délai est configuré par défaut à 30 secondes. L’alarme qui indique le début du problème change de couleur :
3.5.4 Suppression des alarmes de sévérité Cleared
A partir d’un délai configurable (5 minutes par défaut) et si aucune nouvelle alarme du même type n’est reçu, les alarmes de sévérité Cleared (de couleur blanche) disparaissent de la vue alarm (mais pas de la vue event, qui permet de garder l’historique des traps SNMP reçus).
3.6 Fichier de log
Le fichier de log utilisé par le démon eventd est par défaut /opt/opennms/logs/daemon/eventd.log.
3.7 Pour aller plus loin
Pour aller plus loin, je vous invite à consulter la page suivante : http://www.opennms.org/wiki/Event_Configuration_How-To
4. Exemple avec des varbinds
4.1 Extrait du fichier de configuration Cisco2.events.xml
<event> <mask> <maskelement> <mename>id</mename> <mevalue>.1.3.6.1.4.1.9.9.13.3</mevalue> </maskelement> <maskelement> <mename>generic</mename> <mevalue>6</mevalue> </maskelement> <maskelement> <mename>specific</mename> <mevalue>7</mevalue> </maskelement> <varbind> <vbnumber>3</vbnumber> <vbvalue>1</vbvalue> </varbind> </mask> <uei>uei.opennms.org/vendor/Cisco/traps/ciscoEnvMonTempStatusChangeNotifNormal</uei> <event-label>CISCO-ENVMON-MIB defined trap event: ciscoEnvMonTempStatusChangeNotif</event-label> <descr> <p>A ciscoEnvMonTempStatusChangeNotif is sent if there is change in the state of a device being monitored by ciscoEnvMonTemperatureState.</p><table> <tr><td><b> ciscoEnvMonTemperatureStatusDescr</b></td><td> %parm[#1]%;</td><td><p;></p></td;></tr> <tr><td><b> ciscoEnvMonTemperatureStatusValue</b></td><td> %parm[#2]%;</td><td><p;></p></td;></tr> <tr><td><b> ciscoEnvMonTemperatureState</b></td><td> %parm[#3]%;</td><td><p;> normal(1) warning(2) critical(3) shutdown(4) notPresent(5) notFunctioning(6) </p></td;></tr></table> </descr> <logmsg dest='logndisplay'><p> Cisco Event: ciscoEnvMonTempStatusChangeNotif trap received ciscoEnvMonTemperatureStatusDescr=%parm[#1]% ciscoEnvMonTemperatureStatusValue=%parm[#2]% ciscoEnvMonTemperatureState=%parm[#3]%</p> </logmsg> <severity>Normal</severity> <alarm-data reduction-key="%uei%:%dpname%:%nodeid%:%interface%:%parm[#1]%" alarm-type="2" auto-clean="false" clear-key="uei.opennms.org/vendor/Cisco/traps/ciscoEnvMonTempStatusChangeNotif:%dpname%:%nodeid%:%interface%:%parm[#1]%" /> </event> <event> <mask> <maskelement> <mename>id</mename> <mevalue>.1.3.6.1.4.1.9.9.13.3</mevalue> </maskelement> <maskelement> <mename>generic</mename> <mevalue>6</mevalue> </maskelement> <maskelement> <mename>specific</mename> <mevalue>7</mevalue> </maskelement> <varbind> <vbnumber>3</vbnumber> <vbvalue>2</vbvalue> </varbind> </mask> <uei>uei.opennms.org/vendor/Cisco/traps/ciscoEnvMonTempStatusChangeNotifWarning</uei> <event-label>CISCO-ENVMON-MIB defined trap event: ciscoEnvMonTempStatusChangeNotif</event-label> <descr> <p>A ciscoEnvMonTempStatusChangeNotif is sent if there is change in the state of a device being monitored by ciscoEnvMonTemperatureState.</p><table> <tr><td><b> ciscoEnvMonTemperatureStatusDescr</b></td><td> %parm[#1]%;</td><td><p;></p></td;></tr> <tr><td><b> ciscoEnvMonTemperatureStatusValue</b></td><td> %parm[#2]%;</td><td><p;></p></td;></tr> <tr><td><b> ciscoEnvMonTemperatureState</b></td><td> %parm[#3]%;</td><td><p;> normal(1) warning(2) critical(3) shutdown(4) notPresent(5) notFunctioning(6) </p></td;></tr></table> </descr> <logmsg dest='logndisplay'><p> Cisco Event: ciscoEnvMonTempStatusChangeNotif trap received ciscoEnvMonTemperatureStatusDescr=%parm[#1]% ciscoEnvMonTemperatureStatusValue=%parm[#2]% ciscoEnvMonTemperatureState=%parm[#3]%</p> </logmsg> <severity>Warning</severity> <alarm-data reduction-key="uei.opennms.org/vendor/Cisco/traps/ciscoEnvMonTempStatusChangeNotif:%dpname%:%nodeid%:%interface%:%parm[#1]%" alarm-type="1" auto-clean="false" /> </event> <event> <mask> <maskelement> <mename>id</mename> <mevalue>.1.3.6.1.4.1.9.9.13.3</mevalue> </maskelement> <maskelement> <mename>generic</mename> <mevalue>6</mevalue> </maskelement> <maskelement> <mename>specific</mename> <mevalue>7</mevalue> </maskelement> <varbind> <vbnumber>3</vbnumber> <vbvalue>3</vbvalue> </varbind> </mask> <uei>uei.opennms.org/vendor/Cisco/traps/ciscoEnvMonTempStatusChangeNotifCritical</uei> <event-label>CISCO-ENVMON-MIB defined trap event: ciscoEnvMonTempStatusChangeNotif</event-label> <descr> <p>A ciscoEnvMonTempStatusChangeNotif is sent if there is change in the state of a device being monitored by ciscoEnvMonTemperatureState.</p><table> <tr><td><b> ciscoEnvMonTemperatureStatusDescr</b></td><td> %parm[#1]%;</td><td><p;></p></td;></tr> <tr><td><b> ciscoEnvMonTemperatureStatusValue</b></td><td> %parm[#2]%;</td><td><p;></p></td;></tr> <tr><td><b> ciscoEnvMonTemperatureState</b></td><td> %parm[#3]%;</td><td><p;> normal(1) warning(2) critical(3) shutdown(4) notPresent(5) notFunctioning(6) </p></td;></tr></table> </descr> <logmsg dest='logndisplay'><p> Cisco Event: ciscoEnvMonTempStatusChangeNotif trap received ciscoEnvMonTemperatureStatusDescr=%parm[#1]% ciscoEnvMonTemperatureStatusValue=%parm[#2]% ciscoEnvMonTemperatureState=%parm[#3]%</p> </logmsg> <severity>Minor</severity> <alarm-data reduction-key="uei.opennms.org/vendor/Cisco/traps/ciscoEnvMonTempStatusChangeNotif:%dpname%:%nodeid%:%interface%:%parm[#1]%" alarm-type="1" auto-clean="false" /> </event>
4.2 Explication
Dans cet exemple, la varbind N°3 de la trap SNMP contient le statut de la température :
normal(1) warning(2) critical(3) shutdown(4) notPresent(5) notFunctioning(6)
On peut donc filtrer les alarmes selon ce paramètre et pouvoir ainsi déterminer la sévérité de l’alarme en fonction de ce paramètre.
4.2.1 Évènement ciscoEnvMonTempStatusChangeNotifCritical
Cet évènement s’affiche lorsqu’OpenNMS reçoit la trap avec l’oid .1.3.6.1.4.1.9.9.13.3.7 et la varbind 3 qui est égale à 3.
Ce filtrage s’effectue à l’aide de la portion suivante :
<varbind> <vbnumber>3</vbnumber> <vbvalue>3</vbvalue> </varbind>
La sévérité de l’alarme est alors Minor.
La balise alarm-data est la suivante :
<alarm-data reduction-key="uei.opennms.org/vendor/Cisco/traps/ciscoEnvMonTempStatusChangeNotif:%dpname%:%nodeid%:%interface%:%parm[#1]%" alarm-type="1" auto-clean="false" />
Le paramètre reduction-key qui permet la déduplication des alarmes contient :
- l’UEI : uei.opennms.org/vendor/Cisco/traps/ciscoEnvMonTempStatusChangeNotif ;
- la variable %dpname% qui correspond au nom du poller qui a reçu l’évènement dans le cas d’une architecture distribuée ;
- la variable %nodeid% qui correspond à l’identifiant de l’équipement sur lequel porte cette trap ;
- la variable %interface% qui correspond à l’adresse IP de l’interface réseau qui a envoyé cette trap ;
- la valeur de la varbind 1 qui correspond à la description de l’alarme (ciscoEnvMonTemperatureStatusDescr) ;
Si pour plusieurs alarmes, les 5 champs précédents sont identiques alors les alarmes sont affichées sur une seule ligne et le compteur est incrémenté.
Le champ alarm-type est égal à 1, cette alarme correspond à un début de problème.
Le champ auto-clean est placé à false, tous les évènements relatifs à cette alarme seront conservés dans la table Events.
4.2.2 Évènement ciscoEnvMonTempStatusChangeNotifWarning
Cet évènement s’affiche lorsqu’OpenNMS reçoit la trap avec l’oid .1.3.6.1.4.1.9.9.13.3.7 et la varbind 3 qui est égale à 2.
Ce filtrage s’effectue à l’aide de la portion suivante :
<varbind> <vbnumber>3</vbnumber> <vbvalue>2</vbvalue> </varbind>
La sévérité de l’alarme est alors Warning.
La balise alarm-data est la suivante :
<alarm-data reduction-key="uei.opennms.org/vendor/Cisco/traps/ciscoEnvMonTempStatusChangeNotif:%dpname%:%nodeid%:%interface%:%parm[#1]%" alarm-type="1" auto-clean="false" />
Le paramètre reduction-key qui permet la déduplication des alarmes est identique à l’alarme précédente.
Ceci a deux conséquences :
- Les alarmes de sévérité Warning et Minor seront affichées sur une seule ligne ;
- L’alarme Normal permettra d’acquitter les alarmes Warning et Minor.
Le champ alarm-type est égal à 1, cette alarme correspond à un début de problème.
Le champ auto-clean est placé à false, tous les évènements relatifs à cette alarme seront conservés dans la table Events.
4.2.3 Évènement ciscoEnvMonTempStatusChangeNotifNormal
Cet évènement s’affiche lorsqu’OpenNMS reçoit la trap avec l’oid .1.3.6.1.4.1.9.9.13.3.7 et la varbind 3 qui est égale à 1.
Ce filtrage s’effectue à l’aide de la portion suivante :
<varbind> <vbnumber>3</vbnumber> <vbvalue>1</vbvalue> </varbind>
La sévérité de l’alarme est alors Normal.
La balise alarm-data est la suivante :
<alarm-data reduction-key="%uei%:%dpname%:%nodeid%:%interface%:%parm[#1]%" alarm-type="2" auto-clean="false" clear-key="uei.opennms.org/vendor/Cisco/traps/ciscoEnvMonTempStatusChangeNotif:%dpname%:%nodeid%:%interface%:%parm[#1]%" />
Le paramètre reduction-key qui permet la déduplication des alarmes contient :
- la variable %uei% qui correspond à l’uei de l’évènement (ici uei.opennms.org/vendor/Cisco/traps/ciscoEnvMonTempStatusChangeNotifNormal) ;
- la variable %dpname% qui correspond au nom du poller qui a reçu l’évènement dans le cas d’une architecture distribuée ;
- la variable %nodeid% qui correspond à l’identifiant de l’équipement sur lequel porte cette trap ;
- la variable %interface% qui correspond à l’adresse IP de l’interface réseau qui a envoyé cette trap ;
- la valeur de la varbind 1 qui correspond à la description de l’alarme (ciscoEnvMonTemperatureStatusDescr) ;
Le champ alarm-type est égal à 2, cette alarme correspond à une fin de problème.
Le champ auto-clean est placé à false, tous les évènements relatifs à cette alarme seront conservés dans la table Events.
Le champ clear-key correspond au champ reduction-key des alarmes qui seront acquittés par celle-ci.
Ici le champ clear-key est identique au champ reduction-key des alarmes ciscoEnvMonTempStatusChangeNotifWarning et ciscoEnvMonTempStatusChangeNotifCritical. Ces deux alarmes seront acquittées lorsque l’alarme ciscoEnvMonTempStatusChangeNotifNormal sera reçue.
4.3 Démonstration
4.3.1 Réception de l'alarme Warning
4.3.2 Réception de l'alarme Critical
4.3.3 Réception de l'alarme Normal
4.3.4 Corrélation début-fin de problème
4.3.5 Suppression des problèmes terminés
4.4 Remarques
Dans cette exemple, l’alarme ciscoEnvMonTempStatusChangeNotifWarning et ciscoEnvMonTempStatusChangeNotifCritical ne possèdent pas chacune leur alarme de fin de problème mais possèdent une seule et même alarme de fin ciscoEnvMonTempStatusChangeNotifNormal.
Ceci pose le problème suivant :
- soit l’alarme de fin corrèle plusieurs alarmes de début de problème et auquel cas on ne peut pas différencier les sévérités
- soit on différencie les sévérités mais l’alarme de fin ne peut corréler qu’une seule alarme de début de problème
La meilleur solution reste lorsque l’équipement envoie une alarme de fin différente en fonction de la sévérité. Il n’y a alors aucun problème pour mettre en place la déduplication et la corrélation début-fin.
