FWIW, generating status events for anything other than an actual status
change - or even duplicating status events - isn't really so helpful
when it comes to putting stuff into a database. But I can see how it
might be useful in other situations. Anyway, I think I now have enough
understanding so I can filter out the dups relatively efficiently. I'll
post my code and SQL when I have something working, so that people can
hold it over the fire and tell me the flaws.
On Oct 20, 2004, at 10:29 PM, Ethan Galstad wrote:
> Status events allow you to track any changes in the status of a
> host/service. This is useful if you are trying to keep a database
> table updated with the most recent status information.
>
> Service check events let you know when checks get kicked off and when
> they complete. You could use that to store historical information on
> checks if you wanted to do so.
>
> Processing of events is handled serially, so they will be delivered
> to your module in the correct sequence.
>
>
> On 20 Oct 2004 at 21:15, Ben wrote:
>
>> Okay, that's pretty much the conclusion I was coming to. It leaves me
>> confused about the design goals of status events vs. service events,
>> but in any case, It looks like I just might have to deal with
>> duplicate events in my module.
>>
>> Can I at least be guaranteed that ALL the status events for the
>> current state will be delivered before ANY of the status events for
>> the next state? I'm not seeing much threading in nagios other than to
>> handle IO and deal with checks, so I imagine the answer is "yes", but
>> maybe somebody has a ready counter example?
>>
>> On Oct 20, 2004, at 7:31 PM, Ethan Galstad wrote:
>>
>>> Back to your question then. The status events have little to do
>>> with actual checks. Yes, they do occur before and after checks have
>>> occurred, but they're not directly tied to them. Anytime *any* of
>>> the variables/attributes of a host or service are changed, the
>>> status events get generated. This means status events will get
>>> triggered in the following situations (this is not inclusive):
>>>
>>> - A check gets rescheduled
>>> - A check gets initiated
>>> - Check results get processed
>>> - Host/service attributes get changed by external commands
>>> - Attributes get changed by internal logic (i.e. flap detection) -
>>> etc.
>>>
>>>
>>>
>>> On 15 Oct 2004 at 17:00, Ben wrote:
>>>>
>>>>
>>>> In base/checks.c, reap_service_checks calls schedule_service_check
>>>> before it generates the SERVICE_STATUS event.
>>>> schedule_service_check also generates a SERVICE_STATUS event. It
>>>> seems like this might not be right.....
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on
>> ITManagersJournal Use IT products in your business? Tell us what you
>> think of them. Give us Your Opinions, Get Free ThinkGeek Gift
>> Certificates! Click to find out more
>> http://productguide.itmanagersjournal.c ... promo.tmpl
>> _______________________________________________ Nagios-devel mailing
>> list [email protected]
>> https://lists.sourceforge.net/lists/lis ... gios-devel
>>
>>
>
>
>
> Ethan Galstad,
> Nagios Developer
> ---
> Email: [email protected]
> Website: http://www.nagios.org
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> more
> http://productguide.itmanagersjournal.c ... promo.tmpl
> _______________________________________________
> Nagios-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/lis ... gios-devel
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]