RFC/RFP: Service parents

nap naparuba at gmail.com
Wed May 18 13:33:49 CEST 2011


On Wed, May 18, 2011 at 11:50 AM, Andreas Ericsson <ae at op5.se> wrote:

> [...]
>
> Because it makes it possible to unify the logic between hosts
> and services in the long run, which will enable us to let a
> service be a parent of a host. Some people have requested that,
> and with service-dependencies it becomes quite difficult unless
> we overload those objects too. There's too much overloading in
> Nagios today, which leads to user confusion and addon-tool
> complexity that simply shouldn't be there.
>
Hi,

Yes, but I think service dep are to complex just because they are external
objects that apply on other objects, and not objects that can be called or
defined nested in host or service. Just like you say a bit later with
self-containted objects.

>
> > For "same host" we can take let a void host_name for same host for
> example.
> > So it will be easy to define same host dependencies, and even external
> ones.
> >
>
> That's already supported, and people still think it's too complicated.
> Parents is a familiar concept that people understand already.
>
But it's not the same logic. Parents for hosts are an OR, when dependencies
are an AND. Will be hard to explain that the same property got different
behavior is you define it on an host or a service. Or if you just want to
use it as a single object link (nrpe with nrpe and nothing else).

But this will not solve dependencies problem (too much difficult to define
an object for each link, it's just a nightmare) when the
service_dependencies can solve both.


>
> > We add this in Shinken, it helps a lot too for managing large
> configuration
> > (dep can be managed with templates with such an option).
> >
>
> Then you'd need separate templates for agent-based services and
> standard network-based ones. I prefer the "parents" directive.
>
It's just an OR or AND relationship after all that make logical and network
relation different. If the logic is different, we should not give the same
name, or use this parent for service as an OR, but it make less sense for a
service than for an host I think.


> One (large) problem of Nagios today is that very few objects are
> self-contained if you want to maintain a proper configuration. A
> service is mentioned in as many as 10-12 different places and all
> of them have to be modified to get rid of the service or change
> its name. The long-term goal of making simple things easy and
> complex things possible starts with making objects more and more
> self-contained, and then adding exceptions for the rare and
> complex cases.
>
It's so true that why we should propose a way so ALL (or at least the
maximum) options are available through templates, so when you define an
host, you can define it in a global way with no more service or other
elements definition.

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.
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.

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? 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.

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.


Jean


>
> --
> Andreas Ericsson                   andreas.ericsson at op5.se
> OP5 AB                             www.op5.se
> Tel: +46 8-230225                  Fax: +46 8-230231
>
> Considering the successes of the wars on alcohol, poverty, drugs and
> terror, I think we should give some serious thought to declaring war
> on peace.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20110518/909014dd/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


More information about the Developers mailing list