Thanks for your response. Howabout if i have normal check = 5mins and retry
check = 2mins, and max check attempt = 4. means its (2min X 4) bigger than than
than normal check.
I tried this conif and dont see any issues.
Whats your opinion on same.
Thanks in advance.
Nair.
On Mon, 02 Jul 2012 23:52:46 +0530 wrote
>The retry check interval should be smaller value than the normal check
>interval. When a problem is detected, you don't want to delay the check even
>more, you want to retry the check and find out if there really is a problem.
>Here is a good reference for you:
http://nagios.sourceforge.net/docs/3_0/statetypes.html
-TR
On Mon, Jul 2, 2012 at 9:12 AM, Nair wrote:
Thanks Wolf for the response. Howwver i am curious to know whether we can set a
retry check interval greater than normal check interval. I dont see any mention
about the same in the docs.
Thanks
Nair
On Mon, 02 Jul 2012 16:14:37 +0530 wrote
>
On Mon, Jul 2, 2012 at 12:39 AM, Nair wrote:
Hi All
Is there any harm is setting retry check interval plus max check attempt
greater than normal check interval.
Say like configs below:
Config#1
normal_check_interval=10min
retry_check_interval=5min
max_check_attempt=4
Config#2
normal_check_interval=5min
retry_check_interval=10min
max_check_attempt=3
Thank you in advance.
Regards
Nair
Follow Rediff Deal ho jaye! to get exciting offers in your city everyday.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
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
Nair,
As all good consultants would say, "It depends."
There is a small network load for every test so setting shorter intervals
increases the load. If you double the number of tests in an hour, you double
the load. So if you have a large number of tests on a large number of
machines, doubling the frequency of the tests is probably a bad idea. What
value do you think would accrue from increasing the frequency of tests?
In my network, Nagios is set to start sending email notifications if the
failure condition persists more than 3 test periods, i.e., the remote disk root
partition is unreachable for longer than 30 minutes. This particular test
fails on my ftp server during large file transfers, with the message, plug-in
timed out. This has not turned out to be an actual problem, but is an artifact
of flooding the network with file-transfer traffic. In this case it is more
sensible to let the file transfers go through than to know to an utmost
certainty that the drive is not too full.
YMMV
Wolf
--
This Apt Has Super Cow Powers - http://sourcefreedom.com
Open-Source Software in Libraries - http://FOSS4Lib.org
Advancing Libraries Together - http://LYRASIS.org
Apache Open Office Developer wolfhal...@apache.org
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
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
Follow Rediff Deal ho jaye! to get exciting offers in your city everyday.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
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
