RFC/RFP: Service parents

[nap]

On Wed, May 18, 2011 at 3:23 PM, Andreas Ericsson <ae at op5.se> wrote:

>  [...]
> Nested definitions would be neat, but it's a tad weird that you
> favour the un-nested service sets while arguing for other objects.
>
> I try to use existing one to be more complete for the use property than
create new ones if we can avoid it ;)

>
> Based on ~250 nagios configurations, I've verified that 99.67% of
> all servicedependencies are created to suppress notifications when
> the agent goes offline. In that case, parents will do just fine
> for this very, very, very common case.
>
But so we should look at why users are not using it fot other interesting
cases, like don't notify (I think we are all ok to say only the notification
options are really useful) for a webservice if the database is down or such
other "logical" stuff that we've got now we all N tiers applications?
Is that just useless, or is it just too hard to define? I don' have as much
installation that you, but I think this can be very, very useful.


>
>
> >>[..]
>
> With just one parent/dependency in the common case, there's very
> little reason to care about whether the logic is an OR or an AND.
> Quite simply put; I want to make it exceedingly easy for basic
> users to get very useful functionality without having to learn
> about service dependencies. Dependencies and escalations fall into
> the "complex" category which the average user evaluating Nagios
> has no clue about.
>
Yes, it's complex, but the "parent" is the same logic to explain after all?
It's just a matter of syntax if we allow user to do more or not. We can
still explain them with simple example like local agent dependency.

>
> >
> > [...]
>
> Ignore templates. Most object parameter shouldn't even have to be
> defined, and Nagios should provide sensible defaults for everything
> except object identifier and actions on state-changes. That would
> make templates more or less redundant for everything besides altering
> defaults.
>
 Yes, we do not have to change a lot of things in most of the cases. The
main activity is :
* define how the host element is checked, warn X contacts and do not warn if
X is already down.
* link N services with it. And we got the same need as hosts for services
(how to check, warn X contacts and not if others elements are already dead)

It's all what we are talking about, and templates help user to do not define
all theses property again and again. In a perfect world, you just need to
"describe" the host and all is done (so host AND services). So the question
is : is there one or more way to "describe" ?

>
> > We should add very few "host elements" to the service. Like if the host
> is
> > an Oracle server, who need to have the information "this server got PROD,
> > QUAL and DEV base"? It's not a service that is an external element from
> this
> > host, but the host element itself.
>
> Huh? Where does host elements get added to the service?
>

> > That where I like the duplicate_foreach property we use in shinken that
> came
> > from one of your idea from self-contained elements (can be resumed in
> "for
> > each host property you create a service") : all host data are in the
> host.
> >
>
> Agreed. I'll most likely do something similar for service sets,
> although they'll be added as arguments to the service sets so
> it'll look something like this (thinking loosely):
>
> define host {
>        host_name oracle-on-windows
>        service_sets    oracle(databases=foo,bar,xyzzy),windows(disks=C-E)
> }
>
> Final format is nowhere near complete though.
>
Yes, it's the same idea here (host get data, not services). It's just you do
not give parameters to sets, just as classic _macros that will be used for
services creation.

>
> > And here the service_dependencies is just like this : the service is the
> > element that "got" this dependency after all. Yes add a "parent" with
> less
> > "power" than true dependency is possible, but why not kill two birds with
> a
> > unique stone?
>
> Because it's more complicated. Adding something with 100 points of
> value that 20% of all users understand and use is worth 1/3 as much
> as adding something with 60 points of value that 100% of all users
> understand and find useful.
>
> Or perhaps I just don't understand you.
>
If nearly all users are using dep for bad agent notification disable, your
version if more simple, so better.
But if users are not using dep because it's too complex for
not-the-same-host configuration, it's not optimal.


It solve hard service dependency definition (99% of the case
> > do not need a specific timeperiod or specific options) and solve your
> parent
> > behavior that is in the end a dependency (don't cry if a nrpe services
> based
> > is critical and the nrpe agent is down).
> > I think people hate service dep not because it's too hard to understand
> > (it's a AND when parents are an OR, quite simple :) ), but because it's a
> > nightmare to configure in a large environment and that can't be used with
> > templates.
> >
>
> Try explaining the difference between AND and OR to someone who's
> never intended to add more than one element anyway and he'll just
> consider you crazy.
>
Yes, if he just need one agent case, he just don't care :)

>
> > The only problematic point is to have a service parent of an host (and
> with
> > both definitions if I'm not wrong), but I've got problem to find a case
> > where it's useful in fact.
> >
>
> When you have a virtual switch with multiple addresses and you want
> a specific port on one service to be the parent of the host connected
> to that particular port, for instance. Or when you want a service on a
> virtualization server to be the parent of a hostcheck.
>
If I understand the first one, I use business process elements to get such a
dependent host, then use classic parents with this host.

For the second, it's true that the only way from now if to get the
virtualization server host check as this service check and not a classic
ping check, then use host dep it's true.

>
> Others have suggested those ideas though, and I have no idea how
> to implement it sanely yet, but letting services have parents and
> unifying how the two objects are handled in many of the API's have
> more benefits than just this one feature.
>
But I don't see how the parents definition will handle the both objects?
It's true that get a unique dependency tree management can be far more easy
to parse on run for sending or not notifications ;)


Jean


>
> --
> Andreas Ericsson                   andreas.ericsson at op5.se
> OP5 AB                             www.op5.se
> Tel: +46 8-230225                  Fax: +46 8-230231
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20110518/2d3245e3/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel