Automatically acknowledge services of an acknowledged host

Mathieu Gagné mgagne at iweb.com
Thu Dec 9 03:01:35 CET 2010


Hi,

On 12/8/10 5:08 PM, Julien Mathis wrote:
>
> Moreover I think you should reconsider your plugins. Is it normal for a
> plugin to returns the CRITICAL status when it can not connect? Wouldn't
> it be more appropriate with the UNKNOWN status?

Which plugins are we talking about?

For example, if I use "check_http" and the port isn't opened for 
whatever reason (service is crashed, firewall, etc.), it is CRITICAL to 
me, not UNKNOWN. This is my business need. (but hey, to each his own)

You can use negate if you aren't satisfied. However you won't be able to 
distinguish "timeout" from "pattern not found" or ever have CRITICAL 
status (since they will all be translated to UNKNOWN).

That said, I still do not fully understand what you want to achieve or 
what you really need. We do agree that you are proposing a "solution" to 
a unknown/unclear problem. (to us)

When the host is DOWN, service problems are silenced and NO 
notifications are sent, they are "muted". Why would you want to 
acknowledge a service problem if there isn't any notifications sent to 
contacts?

Is there any particular issue you are encountering? What are the course 
of events and what is the expected behavior?

Are service notifications sent to contacts when the host is back UP? Do 
you want to acknowledge service problems for display purposes only?


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

IMO, the patch won't be taken seriously because it is a solution to a 
badly analyzed problem, where every solutions haven't been considered.


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

To my knowledge, acknowledgments are removed on status changes 
(UNKNOWN->CRITICAL, WARNING->CRITICAL, etc.)

If you are talking about service notifications, I still do not 
understand your need or problem. Service notifications aren't sent when 
the host is DOWN. Why is acknowledging the service problem important for 
you?

If we disregard the "auto-acknowledge" and focus on your other need 
where timeouts should be considered UNKNOWN instead of CRITICAL, you 
should write your own plugin to answer your own business needs.

Those business needs seem to be particular to your business and not 
necessary shared by everybody else. You don't need to modify the core of 
Nagios if you can only adapt a plugin to your own needs. The only place 
where I could see a place for change is in the plugin itself, not the 
core of Nagios.


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

Using the "free choice" argument isn't a valid reason or "magic 
argument" to introduce anything in Nagios or any open source project 
without merit. Otherwise I could introduce sillier patches in Nagios 
based on this argument. (like a "word of the day" in the Nagios logs)

Since your needs aren't clear, I do agree with Andreas Ericsson's 
opinion: this patch looks badly thought. Sorry.


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

"I hope we will find a solution to [my need/problem]". FTFY.

I'm sure we can find an alternative to your solution. :)

Last minute thought: Would a NEB module be a good alternative? 
Acknowledgments on hosts could be intercepted and/or new ones issued on 
services when they go DOWN.

-- 
Mathieu

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