Automatically acknowledge services of an acknowledged host

Andreas Ericsson ae at op5.se
Thu Dec 9 12:02:38 CET 2010


On 12/08/2010 11:08 PM, Julien Mathis wrote:
> Hello Andreas,
> 
> On Wed, Dec 8, 2010 at 5:24 PM, Andreas Ericsson<ae at op5.se>  wrote:
> 
>> [...]
>>
>> I think it's a poorly thought out patch. This will indiscriminately ack
>> everything that's on a downed host, no matter if the service problem
>> is related to the host being down or not. If a plugin returns CRITICAL
>> when it can't connect, and then continues returning CRITICAL after the
>> host goes up due to a real problem, that real problem would be hidden
>> by this patch, since it would appear to be acknowledged even though it
>> would actually be the host that's acked.
>>
>>
> I don't see why this patch is poorly designed. Basically, we wanted to add a
> parameter in services or service models, but we thought that "Nagios
> Fathers" would never accept it, because the change was too big.

You're sort of right. Such a change can't go in without a major release, since
it would break module compatibility.

> Thus, we
> chose to put a global option for this feature, which makes the patch easier
> to integrate and therefore easier to be accepted.
> 

I still don't think it's a good idea.

> Moreover I think you should reconsider your plugins. Is it normal for a
> plugin to returns the CRITICAL status when it can not connect?

That depends on the plugin, I suppose. For check_http, it's definitely
appropriate for it to return CRITICAL when it can't connect. The same holds
true for pretty much every plugin that checks a networking server daemon,
and there are lots and lots of those plugins.

> Wouldn't it
> be more appropriate with the UNKNOWN status? When a real CRITICAL Status
> occurs, the status would change and the service would be disacknowledged
> because the user did not use the field "sticky". No?
> 

See above and think again.

> Nevertheless, this feature answers to many large companies and clients'needs
> and thus seems to be useful. Morover, if you don't want to enable this
> feature enabled, you can always disable it. Free choice to users.
> 

You could easily write this as an eventbroker module. Same thing there really.
People either load it or they don't, so it's just one line of text in the main
config file.

> As any open source project, we want to share our patches with other users. I
> think it's the better way to helps opensource project ;)
> 

Agreed, but you'll also have to accept that not all patches are taken aboard by
the upstream project. If I were to accept just any patch without considering any
possible negative ramifications I'd be doing a very poor job indeed.

> I hope we will find a solution to integrate this feature.
> 

It's completely trivial to write it as a broker module. I'd suggest you do that
if you want this to be integrated so tightly. Another option is to make it
configurable on a per-acknowledgement basis, or to add support for multi-selecting
services from a single host and adding acknowledgements to the selected ones.
Then we're back in the UI fiddling department though, which is really where this
belongs. The multi-acknowledge thing is something I'd accept without even blinking,
so I suppose that's one workable solution. Then you can set in cgi.cfg if all of a
hosts services should be marked by default or not and sort of get what you want.

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

------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:

WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com




More information about the Developers mailing list