Re: [Nagios-devel] event broker -> SQL questions
Posted: Fri Oct 15, 2004 4:00 pm
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?)
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 is the logic behind these values?
> > > > has_been_checked
> > > > should_be_scheduled
> > > > current_notification_number
> > > >
> > > > What are these good for?
> > > > failure_prediction_enabled
> > > > percent_state_change
> > > > scheduled_downtime_depth
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > > ______
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
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?)
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 is the logic behind these values?
> > > > has_been_checked
> > > > should_be_scheduled
> > > > current_notification_number
> > > >
> > > > What are these good for?
> > > > failure_prediction_enabled
> > > > percent_state_change
> > > > scheduled_downtime_depth
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > > ______
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]