Re: [Nagios-devel] event broker -> SQL questions
Posted: Wed Oct 20, 2004 6:30 pm
Hard as it may be to believe, my life does not revolve around Nagios.
After putting in a full day at work, working on about 5 other
projects I have going on, spending time with my SO, running to the
computer to eagerly read and answer 50+ daily emails sent directly to
me regarding Nagios in addition to all the list messages is not
exactly what I live for. Neither is patching *alpha* code (which you
shouldn't be running in a production environment unless you like
pain) on a daily basis. But I'll leave that matter for another
message...
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.
To head off probably followup questions: No, there is not yet any
documentation on how to write modules or access the internal data
structures effectively. That will come, but not until 2.0 is in
beta. When will that be? When its ready.
On 15 Oct 2004 at 17:00, 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?)
>
> 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 fi
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
After putting in a full day at work, working on about 5 other
projects I have going on, spending time with my SO, running to the
computer to eagerly read and answer 50+ daily emails sent directly to
me regarding Nagios in addition to all the list messages is not
exactly what I live for. Neither is patching *alpha* code (which you
shouldn't be running in a production environment unless you like
pain) on a daily basis. But I'll leave that matter for another
message...
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.
To head off probably followup questions: No, there is not yet any
documentation on how to write modules or access the internal data
structures effectively. That will come, but not until 2.0 is in
beta. When will that be? When its ready.
On 15 Oct 2004 at 17:00, 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?)
>
> 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 fi
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]