Re: [Nagios-devel] Subservice Definations

[Sam S. <sa...@sp...>]

Hi John,

Thanks for you reply. I haven't yet started looking into the internals of
nagios yet (particulary as I gather 2.0 is very different). Do you have any
idea how difficult something like this would be to write? eg. Is it going to
slide in nicely, or is it going to require some major restructuring? If it's
the former I'm happy to have a go at writing it, and even it doesn't get
accepted into the core I can maintain a patch. If it's more the later then
obviously I'd need some feedback from the core developers.

I also remember reading a while back something about version 2 supporting
the dynamic insertion of new services? I'll have to dig through the
archives. That and some kind of container-subservice relationship between
services (a seperate relationship to service dependancies), would seem to be
a reasonable starting point.

Sam

----- Original Message -----
From: "John P. Rouillard" <ro...@cs...>
To: <nag...@li...>
Cc: <nag...@li...>
Sent: Saturday, December 13, 2003 1:10 AM
Subject: Re: [Nagios-devel] Subservice Definations


>
> In message <07b801c3bb42$33585b10$fb0...@of...>,
> "Sam Stickland" writes:
> >SNMP traps are submitted as passive service checks. All the examples show
> >the a single service defination for the traps - this has the unfortunate
> >effect of the next SNMP trap overwriting the previous. I'd like to have
> >different services definations for different SNMP traps on our networking
> >equipment, but that would result in a LOT of service definations.
> >
> >It would be nice if there was a sub-service id that could be submitted
with
> >passive checks, that effectively divides a single service into multiple
> >services on demand, without the need for 1000's of service definations.
> >
> >Is there a solution to this that I've missed, or is it going to require
> >changes to Nagios? I'm a fair programmer so I'm happy to make these
changes
> >myself, but others might not consider this a good solution to this
problem.
>
> Actually I had come to the same conclusion. Having page after page
> after page of services to navigate through (not to mention set up)
> when the majority of them are OK is a pain. My planned implementation
> was to take passive services of the form service::subservice and
> display them only if they were in a non-ok state.
>
> The base service would have to be defined (e.g. snmp) in order for the
> dynamic subservices to be displayed. The base service would act as a
> template for the dynamic services as far as notification, max_retries
> etc. If needed, you could define the service with the :: if you needed
> different settings.
>
> This service::subservice also opens the possibility of "rolling up"
> the subservice states into an overall service state.
>
> One difference is that I had considered it for both the passive and
> active polling case as I could have temperature, temperature::disk1,
> temperature::disk2, temperature::motherboard items that wouldn't
> overwrite each other. The only difference from the normal services is
> that :: services wouldn't be displayed unless they were non-ok or
> pending.
>
> -- rouilj
> John Rouillard
>
===========================================================================
> My employers don't acknowledge my existence much less my opinions.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Nagios-devel mailing list
> Nag...@li...
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>