RFC/RFP: Service parents

Andreas Ericsson ae at op5.se
Wed May 18 15:23:07 CEST 2011


On 05/18/2011 01:33 PM, nap wrote:
> 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.
> 

Nested definitions would be neat, but it's a tad weird that you
favour the un-nested service sets while arguing for other 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.
> 

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.

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

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.

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

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.

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

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

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

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

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.

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

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




More information about the Developers mailing list