Re: [Nagios-devel] RFC/RFP: Service parents
Posted: Thu May 19, 2011 8:15 am
On 05/18/2011 04:37 PM, nap wrote:
> 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" ?
>
Overloading templates in a non-obvious manner causes confusion. Adding a
new type for it is perfectly legitimate imo.
>>
>>> 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 t
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> 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" ?
>
Overloading templates in a non-obvious manner causes confusion. Adding a
new type for it is perfectly legitimate imo.
>>
>>> 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 t
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]