OpenNMS 19 - OTRS 5 - unique alarmid

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

OpenNMS 19 - OTRS 5 - unique alarmid

Steven Vacaroaia
Hi,

I have been trying to understand and consequently solve the issue of not being able to have another OTRS ticket created if an issue occur on the same node due to the fact that alarmid is the same 

It appears the alamrid will stay the same and only have the counter increment if it occurs during a certain period of time ( before it gets "properly" cleared by automation)

If that is the case, all that needs to be done will be to change timing in vaccuum to be more aggressive

Could you please confirm my theory and, if possible, provide some guidance as to which triggers will have to be adjusted ?

Any other suggestions/ advice for creating unique alarmid for every event on the same node will be truly appreciated 


Many thanks 
Steven  

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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 - OTRS 5 - unique alarmid

John Blake
Can you explain more of what you are looking to do?
Maybe I'm misunderstanding what is being stated.
My understanding of what should happen:
If an alarm happens, a ticket is opened. Then each alarm thereafter will just increment the counter (because the issue is still going on).
Once the issue is corrected, the ticket is closed and a "good alarm or ticket closure causes the original alarm to be cleared by the automation.
If another event happens after the clearing ,then a new alarm should be seen.

Are you saying you want a ticket for each alarm instead of a counter being incremented?


John



-----Steven Vacaroaia <[hidden email]> wrote: -----
To: General OpenNMS Discussion <[hidden email]>
From: Steven Vacaroaia <[hidden email]>
Date: 04/10/2017 11:32AM
Subject: [opennms-discuss] OpenNMS 19 - OTRS 5 - unique alarmid

Hi,

I have been trying to understand and consequently solve the issue of not being able to have another OTRS ticket created if an issue occur on the same node due to the fact that alarmid is the same 

It appears the alamrid will stay the same and only have the counter increment if it occurs during a certain period of time ( before it gets "properly" cleared by automation)

If that is the case, all that needs to be done will be to change timing in vaccuum to be more aggressive

Could you please confirm my theory and, if possible, provide some guidance as to which triggers will have to be adjusted ?

Any other suggestions/ advice for creating unique alarmid for every event on the same node will be truly appreciated 


Many thanks 
Steven  
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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 - OTRS 5 - unique alarmid

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

Your response/suggestion was scrubbed / removed 
Please resend in text format 

Many thanks
Steven

On 11 April 2017 at 08:01, <[hidden email]> wrote:
Send opennms-discuss mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/opennms-discuss
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of opennms-discuss digest..."


Today's Topics:

   1. Re: OpenNMS 19 - OTRS 5 - unique alarmid (John Blake)
   2. Link Availability Reporting (Christian Meutes)


----------------------------------------------------------------------

Message: 1
Date: Mon, 10 Apr 2017 17:00:54 +0000
From: "John Blake" <[hidden email]>
Subject: Re: [opennms-discuss] OpenNMS 19 - OTRS 5 - unique alarmid
To: General OpenNMS Discussion <[hidden email]>
Message-ID:
        <[hidden email]>

Content-Type: text/plain; charset="us-ascii"

An HTML attachment was scrubbed...

------------------------------

Message: 2
Date: Mon, 10 Apr 2017 19:35:27 +0200
From: Christian Meutes <[hidden email]>
Subject: [opennms-discuss] Link Availability Reporting
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain;       charset=us-ascii

Hi club,

I have the demand to generate availability reports of circuits. Circuits in this context can mean EoSDH, Ethernet, IPoDWDM, Ethernet transported through unknown infrastructure / Metro things and EoMPLS. As such the variance of transmission infrastructure is quite high, so that we cannot solely depend on interface status to detect the availability of a circuit (link-loss forwarding is not guaranteed / no 100% transparency).

To detect the real availability of a circuit/link we need to implement some generic mechanism. I can basically only imagine mechanism like IPSLA, IGP link-state information, IGP-hellos or BFD beeing able to provide the necessary information for generating reports at the end of the month which can state total up/downtime of all link(s).

I had a look at the IPSLA poller which looked quite interesting. Then I had the idea of creating a node for each link and have only the IPSLA poller service run against those. This node would have a name like circuit-AMS-FRA-123 for example. But with that in place I would run sooner or later into the problem of a real outage of the node itself and *not* an outage of the monitored circuit, or into an reachability issue where OpenNMS  cannot access the node for whatever reason and would lead also to an outage of the circuit, which would obviously lead to wrong statistical data.

Do you guys have an idea how people implement link-availability within OpenNMS or how you would do that with keeping in mind that I need a report just of link-availability at the eom?

Thanks
Christian





------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

------------------------------

_______________________________________________
opennms-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opennms-discuss


End of opennms-discuss Digest, Vol 132, Issue 28
************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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...