Re: [Nagios-devel] RFC/RFP: Service parents
Posted: Wed May 18, 2011 12:23 pm
On 05/18/2011 01:33 PM, nap wrote:
> On Wed, May 18, 2011 at 11:50 AM, Andreas Ericsson 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 i
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> On Wed, May 18, 2011 at 11:50 AM, Andreas Ericsson 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 i
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]