Re: [Nagios-devel] RFC/RFP: Service parents
Posted: Wed May 18, 2011 1:45 pm
--001517576bbc896c6804a38dd37f
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 18, 2011 at 3:23 PM, Andreas Ericsson 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 com
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 18, 2011 at 3:23 PM, Andreas Ericsson 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 com
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]