AW: NEB: Difference between event types

[Andreas Ericsson]

Mohr James wrote:
> Read the source. Read the source. Read the source. All they ever tell
> me is "Read the source." ;-)
> 
> I started doing just that (ie. Backtracing the functions), but
> stopped after a while because my C is so rusty and I lost the flow a
> couple of times. However, I think you are right with the key
> functions being broker.c and checks.c. I'm a visual person, so I
> think the best thing for me is to draw out the connections.
> 
> I started putting my notes together here:
> 
> http://www.linux-tutorial.info/nagios_event_broker.htm
> 

Excellent stuff!

Just one thing though: Can you rephrase "plugin modules" to something 
like "dynamic shared objects (dso's), or modules for short" or some 
such. People will get the wrong idea about modules and plugins and, for 
now, modules can't be used to run checks (well, they can, but the core 
engine will go ahead and run the regular check anyways).


> If there is anything wrong, please let me know, but keep in mind that
> it is an work in progress. It's not accessable from the homepage, so
> you'll have to use the direct link.
> 
> Regards,
> 
> Jim Mohr
> 
> 
>>> -----Ursprüngliche Nachricht----- Von: Andreas Ericsson
>>> [mailto:ae at op5.se] Gesendet: Montag, 24. Oktober 2005 22:13 An:
>>> Mohr James Cc: Nagios-users at lists.sourceforge.net Betreff: Re:
>>> [Nagios-users] NEB: Difference between event types
>>> 
>>> Mohr James wrote:
>>> 
>>>> What is the difference between these event types?
>>>> 
>>>> NEBCALLBACK_SERVICE_STATUS_DATA NEBCALLBACK_SERVICE_CHECK_DATA
>>>> 
>>>> Is the CHECK_DATA when Nagios starts a check is this is the
>>>> status data for the step of actually doing the check, whereas
>>> 
>>> STATUS_DATA is
>>> 
>>>> the data returned by the check or sent by send_nsca?
>>>> 
>>> 
>>> I think STATUS_DATA is what Nagios passes to the module when it
>>> updates the logged status of the service. This happens once for
>>> all services at load-time and once when max_attempts have been
>>> reached.
>>> 
>>> 
>>>> So, for example, if I was only interested in the data
>>> 
>>> returned by the
>>> 
>>>> check or sent by send_nsca I would need a callback for the 
>>>> NEBCALLBACK_SERVICE_CHECK_DATA event. Is that right?
>>>> 
>>> 
>>> I should think so, yes. You can check broker.c for confirmation
>>> though. If you backtrace the function flow scheme you'll find how
>>>  it's called from checks.c (I think).
>>> 
>>> -- Andreas Ericsson                   andreas.ericsson at op5.se OP5
>>> AB                             www.op5.se Tel: +46 8-230225
>>> Fax: +46 8-230231
>>> 
> 
> 
> 
> ------------------------------------------------------- This SF.Net
> email is sponsored by the JBoss Inc. Get Certified Today * Register
> for a JBoss Training Course Free Certification Exam for All Training
> Attendees Through End of 2005 Visit
> http://www.jboss.com/services/certification for more information 
> _______________________________________________ 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
> 

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
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