OpenNMS 19 unique alarmid for each incident

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenNMS 19 unique alarmid for each incident

Steven Vacaroaia
Hello,

I am trying to "convince"  OpenNMS to issue unique alarmid for each incident on the same node
This is needed so that OTRS tickets are automatically created for each incident

The way it works by default is that, due to reduction key being the same, alarmid is being reused 

If I add %time% to reduction-key, the alarm is "too unique" and will not be automatically closed when the outage  ends

I used %param[all]% to see if there is anything else I could add to the reduction-key specific to each incident but the only think I got was the FQDN of the node 


How can one create a reduction-key that is unique enough bit not too unique ?

Or maybe I have approached this issue wrongly ?

The goal is to have unique alarmid for every incident of the same node

thanks
Steven  

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenNMS 19 unique alarmid for each incident

Keaney, Will

Hi Steven,

 

I use a couple of different techniques for this.

First, I compose the reduction key with uei:nodeId:<some unique parm for the type of event>. This gets me as far as “each type of event on a host gets its own Alarm”.

Second, when I Clear an Alarm, I update the reduction key to include the current timestamp. Subsequent events will not reduce against this alarm anymore.

 

The first is pretty easy to do within the event configuration XML. The second requires a little more work on the automation. I do it in Drools, but it could probably be done from vacuumd or actiond.

 

Hope this helps.

 

--Will

 

From: Steven Vacaroaia [mailto:[hidden email]]
Sent: Tuesday, March 07, 2017 12:14
To: General OpenNMS Discussion
Subject: [opennms-discuss] OpenNMS 19 unique alarmid for each incident

 

Hello,

 

I am trying to "convince"  OpenNMS to issue unique alarmid for each incident on the same node

This is needed so that OTRS tickets are automatically created for each incident

 

The way it works by default is that, due to reduction key being the same, alarmid is being reused 

 

If I add %time% to reduction-key, the alarm is "too unique" and will not be automatically closed when the outage  ends

 

I used %param[all]% to see if there is anything else I could add to the reduction-key specific to each incident but the only think I got was the FQDN of the node 

 

 

How can one create a reduction-key that is unique enough bit not too unique ?

 

Or maybe I have approached this issue wrongly ?

 

The goal is to have unique alarmid for every incident of the same node

 

thanks

Steven  




This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenNMS 19 unique alarmid for each incident

Steven Vacaroaia
In reply to this post by Steven Vacaroaia
Hi Will,

Thanks for your advice

Would you be able to provide an example of a  "reduction key with uei:nodeId:<some unique parm for the type of event> " ?

I cannot figure out what can be used that is unique for every outage on the same node 

Is it "cosmicClear" the  vaccum trigger that should be modified to include timestamp  ?

Many thanks
Steven

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenNMS 19 unique alarmid for each incident

Keaney, Will

It’ll depend on what your events look like, and what information they contain.

 

I’m working with events that are generated outside of OpenNMS and sent in via XML-TCP or ReST. I’ve structured the UEI themselves to be fairly specific, and beyond that there’s usually a parm with an error code or some other unique event facet that I can use.

One of my event sources includes a parm, ‘situation_name’, so my reduction key for events from that source is <uei>:<nodeId>:%parm[situation_name]%.

 

Can you provide a (sanitized) example of one of the events with which you’re having trouble?

 

--Will

 

From: Steven Vacaroaia [mailto:[hidden email]]
Sent: Wednesday, March 08, 2017 08:32
To: General OpenNMS Discussion
Subject: Re: [opennms-discuss] OpenNMS 19 unique alarmid for each incident

 

Hi Will,

 

Thanks for your advice

 

Would you be able to provide an example of a  "reduction key with uei:nodeId:<some unique parm for the type of event> " ?

 

I cannot figure out what can be used that is unique for every outage on the same node 

 

Is it "cosmicClear" the  vaccum trigger that should be modified to include timestamp  ?

 

Many thanks

Steven




This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenNMS 19 unique alarmid for each incident

Steven Vacaroaia
In reply to this post by Steven Vacaroaia
Hi,

Please find below an example of an nodeDown event - it is generic / vannila event created using default OpenNMS configuration
 
How can I "enrich" this event to be unique ( but not too unique so that it can still be cleared automatically ) for each outage on same node ?

Thanks


select * from events where eventid = 533126;
 eventid |            eventuei            | nodeid |         eventtime          | eventhost |            eventsource            | ipaddr | eventsnmphost | serviceid | eventsnmp |                      eventparms                      |
    eventcreatetime       |                                          eventdescr                                           | eventloggroup |                                      eventlogmsg                                      | eventse
verity | eventpathoutage | eventcorrelation | eventsuppressedcount | eventoperinstruct | eventautoaction | eventoperaction | eventoperactionmenutext | eventnotification | eventtticket | eventtticketstate | eventforward | eventmouseover
text | eventlog | eventdisplay | eventackuser | eventacktime | alarmid | ifindex |               systemid
---------+--------------------------------+--------+----------------------------+-----------+-----------------------------------+--------+---------------+-----------+-----------+------------------------------------------------------+--
--------------------------+-----------------------------------------------------------------------------------------------+---------------+---------------------------------------------------------------------------------------+--------
-------+-----------------+------------------+----------------------+-------------------+-----------------+-----------------+-------------------------+-------------------+--------------+-------------------+--------------+---------------
-----+----------+--------------+--------------+--------------+---------+---------+--------------------------------------
  533126 | uei.opennms.org/nodes/nodeDown |    393 | 2017-03-07 13:50:59.648-05 | nms       | OpenNMS.Poller.DefaultPollContext |        |               |           |           | nodelabel=puppetmaster.tor.medavail.net(string,text) | 2
017-03-07 13:50:59.712-05 | <p>All interfaces on node puppetmaster.tor.medavail.net are                                  +|               | Node puppetmaster.tor.medavail.net is down at Tuesday, March 7, 2017 1:50:59 PM EST.  |
     6 |                 |                  |                      |                   |                 |                 |                         |                   |              |                   |              |
     | Y        | Y            |              |              |   23193 |         | 00000000-0000-0000-0000-000000000000
         |                                |        |                            |           |                                   |        |               |           |           |                                                      |
                          |       down at Tuesday, March 7, 2017 1:50:59 PM EST.</p> <p>This event is generated when node+|               |                                                                                       |
       |                 |                  |                      |                   |                 |                 |                         |                   |              |                   |              |
     |          |              |              |              |         |         |
         |                                |        |                            |           |                                   |        |               |           |           |                                                      |
                          |       outage processing determines that all interfaces on the node                           +|               |                                                                                       |
       |                 |                  |                      |                   |                 |                 |                         |                   |              |                   |              |
     |          |              |              |              |         |         |
         |                                |        |                            |           |                                   |        |               |           |           |                                                      |
                          |       are down.</p> <p>New outage records have been                                          +|               |                                                                                       |
       |                 |                  |                      |                   |                 |                 |                         |                   |              |                   |              |
     |          |              |              |              |         |         |
         |                                |        |                            |           |                                   |        |               |           |           |                                                      |
                          |       created and service level availability calculations will be                            +|               |                                                                                       |
       |                 |                  |                      |                   |                 |                 |                         |                   |              |                   |              |
     |          |              |              |              |         |         |
         |                                |        |                            |           |                                   |        |               |           |           |                                                      |
                          |       impacted until this outage is resolved.</p>                                             |               |                                                                                       |
       |                 |                  |                      |                   |                 |                 |                         |                   |              |                   |              |
     |          |              |              |              |         |         |


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenNMS 19 unique alarmid for each incident

David Hustace

> On Mar 10, 2017, at 8:25 AM, Steven Vacaroaia <[hidden email]> wrote:
>
> How can I "enrich" this event to be unique ( but not too unique so that it can still be cleared automatically ) for each outage on same node ?

NodeDown is a node correlated alarm.  If you have a NodeDown, there should will be no other alarms created for the service outages so there will be no other alarms to clear.

The outages related to alarms will resolve themselves by the Poller and a NodeUp event and clearing alarm will be generated when either any or all of a node’s interfaces come up.  Interfaces come up when either the critical service (generally ICMP) or all of the services on the interface regain service availability (InterfaceUp and NodeRegainedService events/alarms).

:David


David Hustace
The OpenNMS Group, Inc.

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenNMS 19 unique alarmid for each incident

Keaney, Will
To expand on David's answer a little bit, the Cosmic Clear automation will remove any cleared alarms within a minute or two, so the next NodeDown event will create a new alarm.

--Will

-----Original Message-----
From: David Hustace [mailto:[hidden email]]
Sent: Friday, March 10, 2017 08:38
To: DiscussionList List
Subject: Re: [opennms-discuss] OpenNMS 19 unique alarmid for each incident


> On Mar 10, 2017, at 8:25 AM, Steven Vacaroaia <[hidden email]> wrote:
>
> How can I "enrich" this event to be unique ( but not too unique so that it can still be cleared automatically ) for each outage on same node ?

NodeDown is a node correlated alarm.  If you have a NodeDown, there should will be no other alarms created for the service outages so there will be no other alarms to clear.

The outages related to alarms will resolve themselves by the Poller and a NodeUp event and clearing alarm will be generated when either any or all of a node’s interfaces come up.  Interfaces come up when either the critical service (generally ICMP) or all of the services on the interface regain service availability (InterfaceUp and NodeRegainedService events/alarms).

:David


David Hustace
The OpenNMS Group, Inc.

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition.
https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_oxford&d=DwIGaQ&c=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE&r=MUNnOCP7Z00lzwVx4s0AE5GmtDEijq4sU77LnbG5In0&m=6D0cEAtobpJvE3MeMyedN2RCIkU1kZ0otxG-tW46Y68&s=RFbUJ_Vn74hYvwCsdUr0yx-VwwOpdAJxMcr2LWc1LCA&e=
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.opennms.org_index.php_Mailing-5FList-5FFAQ&d=DwIGaQ&c=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE&r=MUNnOCP7Z00lzwVx4s0AE5GmtDEijq4sU77LnbG5In0&m=6D0cEAtobpJvE3MeMyedN2RCIkU1kZ0otxG-tW46Y68&s=f0Ilk5Jstk3Cz3LzAEvSWiSujgsmOplsOM_5Bg2r3ac&e=

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_opennms-2Ddiscuss&d=DwIGaQ&c=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE&r=MUNnOCP7Z00lzwVx4s0AE5GmtDEijq4sU77LnbG5In0&m=6D0cEAtobpJvE3MeMyedN2RCIkU1kZ0otxG-tW46Y68&s=zmBuOcV3k5WW6r-hocgUWNmXY-z6xjLgjDm18yGlR00&e=

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Loading...