Event ID - reference older threads

[Scott Nixon]

Hi,

This message refers to a particular older thread, as well as several
others.  I'm basically seeking the answer as to whether and how you can
integrate Nagios with a ticketing system such that once a service event
goes into a non-OK state...all subsequent events and notifications for
that service are grouped into the same ticket until the service returns
to an OK state.  Seems the best way to do this is to incorporate some
sort of persistent and unique event id.

In this link:
https://sourceforge.net/mailarchive/message.php?msg_id=8873121

James Kingston says he is doing that.
"We use hostname-(servicename|hostalert)-timet (although we re-use the
 same id until the host/service recovery)"

The one part that I don't understand is the "timet".  I assume he's
using the TIMET macro...but if I am sending out multiple notifications
(as in an escalation tree) wouldn't the TIMET of each notification be
different?  How is he re-using this id on subsequent notifications? 

I'm new to this mailing list and in searching the archives, I've seen
similar questions posed over the past couple of years but have never
seen a definitive answer.  Perhaps I've missed it though?

Any help on this would be greatly appreciated!

-Scott








-- 
______________________________________             
D. Scott Nixon

           LSSi Corp. 
  email:   nixon at lssi.net
    url:   http://www.lssi.net/~snixon
  phone:   (919) 466-6834
    fax:   (919) 466-6810
______________________________________



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null