[Nagios-users] Removing 1 inheritance
Hi,
I have a default service, which all my services inherit their
contact_groups from.
Now I want to exclude 1 group from the inheritance, like so:
define service {
use generic-service
contact_groups -ondutypager
}
The - operator doesn't work, whereas the + operator does (add 1 item to
the inheritance), are there any workaround to this?
Thanks
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
[Nagios-users] check_openmanage: Amperage probe 0 [System Board System Level] reads 0 W
Hi, After upgrading OpenManage to version 6.4.0 on a DELL R410, check_openmanage 3.6.4 returns CRITICAL: Amperage probe 0 [System Board System Level] reads 0 W Is this due to OpenManage changing behavior (bug), or is the hardware really faulty? (doubtful) :) I know I could just disable amperage checks, but I'd like not to. Anyone else seen this? Thanks // Tom -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] check_openmanage: 'Amperage probe 0 [System Board System Level] reads 0 W'
On Thu, January 27, 2011 17:43, Trond Hasle Amundsen wrote: Tom Sommer m...@tomsommer.dk writes: After upgrading OpenManage to version 6.4.0 on a DELL R410, check_openmanage 3.6.4 returns CRITICAL: Amperage probe 0 [System Board System Level] reads 0 W Is this due to OpenManage changing behavior (bug), or is the hardware really faulty? (doubtful) :) Most likely this is some sort of bug in OpenManage, or something went wrong during upgrade. You should confirm the fault by running omreport chassis pwrmonitoring # omreport chassis pwrmonitoring Power Consumption Information is not available on this system because all the Power Supply units on your system do not support PMBus or the firmware on your system does not support power monitoring. (Running CentOS) I know I could just disable amperage checks, but I'd like not to. Anyone else seen this? Sorry, no. Very often these problems are resolved simply by restarting OpenManage on the monitored server, or a reboot. The next step is to re-install OpenManage in case something was missed during install/upgrade. If all else fails, contact Dell support. Tried all but the latter - guess it's a DELL bug. Thanks // Tom -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
[Nagios-users] Retry interval on hard states
Hi, I wish to setup the following check interval: Check the service every 5 minutes - If down then check the service every 1 minute for 3 minutes/times - If still down, notify and continue to check the service every 1 minute until it recovers. I'm having a few problems with the last condition. Basically once the notification is sent, Nagios seems to revert to the normal check interval, which is 5 minutes - resulting in a substantial delay for the recovery notification to be sent. My settings are: max_check_attempts 3 check_interval 5 retry_interval 1 Did I miss anything or is the above simply not possible? Using 3.0rc3 Thanks -- Tom Sommer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Retry interval on hard states
Marc Powell wrote: Hi, I wish to setup the following check interval: Check the service every 5 minutes - If down then check the service every 1 minute for 3 minutes/times - If still down, notify and continue to check the service every 1 minute until it recovers. I'm having a few problems with the last condition. Basically once the notification is sent, Nagios seems to revert to the normal check interval, which is 5 minutes - resulting in a substantial delay for the recovery notification to be sent. This is expected behavior. I'm curious, what kind of environment are you in when up to 5 minute delay in notification of recovery is 'substantial'? Well, the current environment/system we run, have the above behavior, and to be honest, I don't understand how it's not default behavior. Normally you would want to know if a service have recovered as soon as possible, I would have it check every 30 seconds if I could. It's especially important for people who are on call, receive a notification, resolve the issue, and then await confirmation of recovery, 5 minutes is a long wait. A simple setting to set this interval sounds trivial and I would think almost required for a monitoring system. -- Tom Sommer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Retry interval on hard states
Would this feature not be best served being in the core? Marcel wrote: here it is: http://nagios.sourceforge.net/docs/3_0/adaptive.html On Fri, Mar 7, 2008 at 3:10 PM, Marcel [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I guess that in 3.0rc3 you can modify service check configuration on-demand. Not implemented yet, but you should be able to do something like changing normal_check_interval until it reaches an OK state. Anyone here already come up with a solution to this problem? Cheers On Fri, Mar 7, 2008 at 10:44 AM, Tom Sommer [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I wish to setup the following check interval: Check the service every 5 minutes - If down then check the service every 1 minute for 3 minutes/times - If still down, notify and continue to check the service every 1 minute until it recovers. I'm having a few problems with the last condition. Basically once the notification is sent, Nagios seems to revert to the normal check interval, which is 5 minutes - resulting in a substantial delay for the recovery notification to be sent. My settings are: max_check_attempts 3 check_interval 5 retry_interval 1 Did I miss anything or is the above simply not possible? Using 3.0rc3 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
