Re: [Nagios-devel] event broker -> SQL questions
Posted: Sun Oct 17, 2004 4:07 am
Ben wrote:
> So I've noticed this error with services too, and to something else. I
> don't know nearly enough about nagios' logic to understand if this is a
> bug in the code or in my expectation, but I'm expecting the latter and
> hoping somebody can set me straight. (BTW, I've been reading this list for
> a few weeks now and I've only seen one appearance of the elusive Ethan. Is
> he Just That Busy?)
>
I wouldn't know. If you have a look at
http://sourceforge.net/mailarchive/foru ... um_id=7906 you can see
the CVS activity. It's about one checkin/month so it's not completely
stopped, but not very active either.
Karl De Bisschop hasn't committed anything for nagios or nagiosplug in a
very long time, so he might have abandoned both projects, but I don't know.
Ethan; How about adding a couple of people to the developer list so we
can check in bugfixes and patches? It should speed up development
tremendously so Nagios 2 can be out of alpha state sometime this year.
There are ~600 subscribers to nagios-devel. I think there should be some
among those that could give a hand in development. I know I could, and
I've got the feeling that the Ben and Titus could handle it as well.
> 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.....
>
> On Wed, 13 Oct 2004, Titus Anderson wrote:
>
>
>>Hmmm... Well, HOST_STATUS events get triggered in the update_host_status
>>function. It appears that if a host enters or leaves a soft error state,
>>update_host_status will be called twice from the check_host function; once in
>>the block that handles the error or recovery and again because it's always
>>called whenever check_host is called. That could explain the duplicate events.
>>
>>--Titus
>>
>>--- Ben wrote:
>>
>>
>>>Thanks for these so far.
>>>
>>>I've noticed that using your example NEB module, occasionally there are
>>>duplicate HOST_STATUS events. Maybe identical events are supposed to be
>>>generated by the event broker and dispatched at the same time, but I don't
>>>know why that would be. Has anybody else seen this, and is it a bug?
>>>
>>>On Wed, 13 Oct 2004, Titus Anderson wrote:
>>>
>>>
>>>>>So I'm looking into how to turn event broker events into SQL statements,
>>>>>and I have some questions about the following fields found in both
>>>>>HOST_STATUS and SERVICE_STATUS events. I'm hoping somebody else has
>>>>>already digested the code and can clear up my confusion.
>>>>>
>>>>>modified_attributes appears to be redundant, because there are other
>>>>>fields for the flags it is used to carry (active_checks_enabled,
>>>>>notifications_enabled, etc.). Or maybe it's that those other fields are
>>>>>redundant? Or maybe I'm just missing something?
>>>>
>>>>Well, this part is easy to answer, just glancing through the code. It
>>>
>>>appears
>>>
>>>>that the flags are set (but never cleared) whenever an external command
>>>
>>>alters
>>>
>>>>a field of a host or service. For example, when you execute a
>>>>CHANGE_NORMAL_HOST_CHECK_INTERVAL command via the external commands file,
>>>
>>>the
>>>
>>>>MODATTR_NORMAL_CHECK_INTERVAL flag is set in the modified_attributes field
>>>
>>>for
>>>
>>>>that host.
>>>>
>>>>The rest is somewhat guesses, but here goes:
>>>>
>>>>
>>>>>When are these filled out, and with what?
>>>>>event_handler - the event handler for this host or service; set at
>>>
>>>startup
>>>
>>>>>performance_data - most recent performance data from a check; set with
>>>
>>>each
>>>
>>>>check
>>>>
>>>>>problem_has_been_acknowledged - true or false; set if a problem has been
>>>>
>>>>acknowledged; I presume it is cleared when the problem goes away
>>>>
>>>>>acknowledgement_type - either ACKNOWLEDGEMENT_STICKY or
>>>>
>>>>ACKNOWLEDGEMENT_NORMAL; also set when the problem is acknowledged; don't
>>>
>>>know
>>>
>>>>what the default value is, though
>>>>
>>>>No ideas on the rest. Haven't dug that deep yet.
>>>>
>>>>
>>>>>What i
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> So I've noticed this error with services too, and to something else. I
> don't know nearly enough about nagios' logic to understand if this is a
> bug in the code or in my expectation, but I'm expecting the latter and
> hoping somebody can set me straight. (BTW, I've been reading this list for
> a few weeks now and I've only seen one appearance of the elusive Ethan. Is
> he Just That Busy?)
>
I wouldn't know. If you have a look at
http://sourceforge.net/mailarchive/foru ... um_id=7906 you can see
the CVS activity. It's about one checkin/month so it's not completely
stopped, but not very active either.
Karl De Bisschop hasn't committed anything for nagios or nagiosplug in a
very long time, so he might have abandoned both projects, but I don't know.
Ethan; How about adding a couple of people to the developer list so we
can check in bugfixes and patches? It should speed up development
tremendously so Nagios 2 can be out of alpha state sometime this year.
There are ~600 subscribers to nagios-devel. I think there should be some
among those that could give a hand in development. I know I could, and
I've got the feeling that the Ben and Titus could handle it as well.
> 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.....
>
> On Wed, 13 Oct 2004, Titus Anderson wrote:
>
>
>>Hmmm... Well, HOST_STATUS events get triggered in the update_host_status
>>function. It appears that if a host enters or leaves a soft error state,
>>update_host_status will be called twice from the check_host function; once in
>>the block that handles the error or recovery and again because it's always
>>called whenever check_host is called. That could explain the duplicate events.
>>
>>--Titus
>>
>>--- Ben wrote:
>>
>>
>>>Thanks for these so far.
>>>
>>>I've noticed that using your example NEB module, occasionally there are
>>>duplicate HOST_STATUS events. Maybe identical events are supposed to be
>>>generated by the event broker and dispatched at the same time, but I don't
>>>know why that would be. Has anybody else seen this, and is it a bug?
>>>
>>>On Wed, 13 Oct 2004, Titus Anderson wrote:
>>>
>>>
>>>>>So I'm looking into how to turn event broker events into SQL statements,
>>>>>and I have some questions about the following fields found in both
>>>>>HOST_STATUS and SERVICE_STATUS events. I'm hoping somebody else has
>>>>>already digested the code and can clear up my confusion.
>>>>>
>>>>>modified_attributes appears to be redundant, because there are other
>>>>>fields for the flags it is used to carry (active_checks_enabled,
>>>>>notifications_enabled, etc.). Or maybe it's that those other fields are
>>>>>redundant? Or maybe I'm just missing something?
>>>>
>>>>Well, this part is easy to answer, just glancing through the code. It
>>>
>>>appears
>>>
>>>>that the flags are set (but never cleared) whenever an external command
>>>
>>>alters
>>>
>>>>a field of a host or service. For example, when you execute a
>>>>CHANGE_NORMAL_HOST_CHECK_INTERVAL command via the external commands file,
>>>
>>>the
>>>
>>>>MODATTR_NORMAL_CHECK_INTERVAL flag is set in the modified_attributes field
>>>
>>>for
>>>
>>>>that host.
>>>>
>>>>The rest is somewhat guesses, but here goes:
>>>>
>>>>
>>>>>When are these filled out, and with what?
>>>>>event_handler - the event handler for this host or service; set at
>>>
>>>startup
>>>
>>>>>performance_data - most recent performance data from a check; set with
>>>
>>>each
>>>
>>>>check
>>>>
>>>>>problem_has_been_acknowledged - true or false; set if a problem has been
>>>>
>>>>acknowledged; I presume it is cleared when the problem goes away
>>>>
>>>>>acknowledgement_type - either ACKNOWLEDGEMENT_STICKY or
>>>>
>>>>ACKNOWLEDGEMENT_NORMAL; also set when the problem is acknowledged; don't
>>>
>>>know
>>>
>>>>what the default value is, though
>>>>
>>>>No ideas on the rest. Haven't dug that deep yet.
>>>>
>>>>
>>>>>What i
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]