[Nagios-users] pfSense Event Handler
Hello list, I was wondering if anyone ever had the need of creating an event handler for Nagios, which restarts an IPsec VPN tunnel (in pfSense), after a DOWN HARD state occurs. Thanks, Bruno Martins -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512___ 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] Version Check Incorrect
On 1/15/2013 12:24 AM, Mark Elsen wrote: Nagios version incorrect, Tx for your efforts - yet the download menu for Nagios Core, advertises 3.4.4. as being 3.4.3; - The ChangeLog file does not contain any 3.4.4. information Updates made, thanks for the heads up! (ref : http://www.nagios.org/download/core/thanks?t=1358230874) M. On Mon, Jan 14, 2013 at 9:09 PM, Mike Guthrie mguth...@nagios.com mailto:mguth...@nagios.com wrote: Should be fixed now, thanks! On 1/14/2013 1:43 PM, Steve Jenkins wrote: Just installed 3.4.4 and noticed this: http://www.nagios.org/checkforupdates/?version=3.4.4product=nagioscore SteveJ -- Master Visual Studio, SharePoint, SQL,ASP.NET http://ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net mailto: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 -- Mike Guthrie Technical Team ___ Nagios Enterprises, LLC Email:mguth...@nagios.com mailto:mguth...@nagios.com Web:www.nagios.com http://www.nagios.com -- Master Visual Studio, SharePoint, SQL, ASP.NET http://ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net mailto: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 -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ 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 -- Mike Guthrie Technical Team ___ Nagios Enterprises, LLC Email: mguth...@nagios.com Web:www.nagios.com -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512___ 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] Service check goes HARD too quick if multiple service are in problem state
Hi, I have had this problem previously and posted here but not go nowhere with it. Ill have another bash. Basically my nagios machine is checking too frequently and firing out alerts too quickly Its ignoring the retry_interval value, the max_check_attempts value and ingoring the notification_interval value in the escalations. I have check interval of 5 minutes in OK state Retry interval of 3 minutes when in problem state Notification interval of 3 minutes I believe that below is the problem and multiple service checks in problem state at the same time is casuing this. Ive just seen this on 1 of my hosts: It appears its accumulating the service checks (even though they are different checks) into a final HARD state. Prior to 17:18 all was fine on this host!!! Then at 17:18 a SQL check went to warning state and to SOFT 1 Checked again at 17:21 which is the 3 minute interval I have told it too when in problem and its still warning so onto SOFT2 Then a different service check on that host goes critical - but for the first time 17:22 memory usage and it puts this to HARD 3 - even though this actual check for memory should be SOFT1 An alert then got sent straight out for the Memory check even though it was actually only check 1/3 on that particular service Here is the copy and past from the History of the host [01-15-2013 17:18:24] SERVICE ALERT: SERVER;SQL LOCK TIMEOUTS;WARNING;SOFT;1;WARNING - 2.3067 lock timeouts / sec for _Total, 2.0667 lock timeouts / sec for Key, 0. lock timeouts / sec for RID, 0.2400 lock timeouts / sec for Page, 0. lock timeouts / sec for Object, 0. lock timeouts / sec for Metadata, 0. lock timeouts / sec for HoBT, 0. lock timeouts / sec for File, 0. lock timeouts / sec for Extent, 0. lock timeouts / sec for Database, 0. lock timeouts / sec for Application, 0. lock timeouts / sec for AllocUnit [01-15-2013 17:21:24] SERVICE ALERT: SERVER;SQL LOCK TIMEOUTS;WARNING;SOFT;2;WARNING - 1.3056 lock timeouts / sec for _Total, 1.1833 lock timeouts / sec for Key, 0. lock timeouts / sec for RID, 0.1222 lock timeouts / sec for Page, 0. lock timeouts / sec for Object, 0. lock timeouts / sec for Metadata, 0. lock timeouts / sec for HoBT, 0. lock timeouts / sec for File, 0. lock timeouts / sec for Extent, 0. lock timeouts / sec for Database, 0. lock timeouts / sec for Application, 0. lock timeouts / sec for AllocUnit [01-15-2013 17:22:04] SERVICE ALERT: SERVER;MEMORY USAGE;CRITICAL;HARD;3;CRITICAL: physical memory: Total: 10G - Used: 9.81G (98%) - Free: 192M (2%) critical Does anybody please have any idea why my server is checking too frequently and alerting too frequently and why its totting up different service checks? This machine has done nothing but not work right since it was loaded a couple months ago. Im using the come config files on it as I did on the previous box I had - only difference was that was running 3.3.1 - I had none of these problems on that install. This is a Nagios 3.4.1 install on a Ubuntu 12.04 desktop 32 bit OS Thanks in advance -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512___ 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] Service check goes HARD too quick if multiple service are in problem state
You could check that the check intervals show up right in objects.cache. You could also try stopping nagios (check with ps that you don't have multiple daemons running), removing the generated files and restarting (note that this will cause notifications to be sent from scratch; you may want to disable them first). /var/cache/nagios3/ objects.cache status.dat /var/lib/nagios3/ retention.dat On Tue, Jan 15, 2013 at 05:51:35PM +, Andrew Thompson wrote: Hi, I have had this problem previously and posted here but not go nowhere with it. Ill have another bash. Basically my nagios machine is checking too frequently and firing out alerts too quickly Its ignoring the retry_interval value, the max_check_attempts value and ingoring the notification_interval value in the escalations. I have check interval of 5 minutes in OK state Retry interval of 3 minutes when in problem state Notification interval of 3 minutes I believe that below is the problem and multiple service checks in problem state at the same time is casuing this. Ive just seen this on 1 of my hosts: It appears its accumulating the service checks (even though they are different checks) into a final HARD state. Prior to 17:18 all was fine on this host!!! Then at 17:18 a SQL check went to warning state and to SOFT 1 Checked again at 17:21 which is the 3 minute interval I have told it too when in problem and its still warning so onto SOFT2 Then a different service check on that host goes critical - but for the first time 17:22 memory usage and it puts this to HARD 3 - even though this actual check for memory should be SOFT1 An alert then got sent straight out for the Memory check even though it was actually only check 1/3 on that particular service Here is the copy and past from the History of the host [01-15-2013 17:18:24] SERVICE ALERT: SERVER;SQL LOCK TIMEOUTS;WARNING;SOFT;1;WARNING - 2.3067 lock timeouts / sec for _Total, 2.0667 lock timeouts / sec for Key, 0. lock timeouts / sec for RID, 0.2400 lock timeouts / sec for Page, 0. lock timeouts / sec for Object, 0. lock timeouts / sec for Metadata, 0. lock timeouts / sec for HoBT, 0. lock timeouts / sec for File, 0. lock timeouts / sec for Extent, 0. lock timeouts / sec for Database, 0. lock timeouts / sec for Application, 0. lock timeouts / sec for AllocUnit [01-15-2013 17:21:24] SERVICE ALERT: SERVER;SQL LOCK TIMEOUTS;WARNING;SOFT;2;WARNING - 1.3056 lock timeouts / sec for _Total, 1.1833 lock timeouts / sec for Key, 0. lock timeouts / sec for RID, 0.1222 lock timeouts / sec for Page, 0. lock timeouts / sec for Object, 0. lock timeouts / sec for Metadata, 0. lock timeouts / sec for HoBT, 0. lock timeouts / sec for File, 0. lock timeouts / sec for Extent, 0. lock timeouts / sec for Database, 0. lock timeouts / sec for Application, 0. lock timeouts / sec for AllocUnit [01-15-2013 17:22:04] SERVICE ALERT: SERVER;MEMORY USAGE;CRITICAL;HARD;3;CRITICAL: physical memory: Total: 10G - Used: 9.81G (98%) - Free: 192M (2%) critical Does anybody please have any idea why my server is checking too frequently and alerting too frequently and why its totting up different service checks? This machine has done nothing but not work right since it was loaded a couple months ago. Im using the come config files on it as I did on the previous box I had - only difference was that was running 3.3.1 - I had none of these problems on that install. This is a Nagios 3.4.1 install on a Ubuntu 12.04 desktop 32 bit OS -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ 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] Nagios Update Check Is Not Running
I noticed that the main.php page update_available blue flag never appears for
me when a new version of Nagios is available. I do have check_for_updates=1,
but I see the following at the top of the Nagios status.dat file:
info {
created=1358284500
version=3.4.1
last_update_check=1340002591
update_available=1
last_version=3.3.1
new_version=3.4.1
}
What that tells me is that the Nagios function (that checks to see if there
is an update available) hasn't run since 6/18.2012 6:56:31 GMT (1340002591). I
am seeing similar indications on my other Nagios servers.
1) Is there a way to force Nagios to CHECK NOW?
2) Does the update_check log it's results somewhere?
3) Do you have any recommendations on how I should approach this problem?
I am running Nagios v3.4.1 on one server and v3.4.3 on the other two. They
are running on SLES 10 SP3 64-bit.
Jon Adcock
Network Systems Administrator
Leon County MIS
301 S. Monroe St.
Tallahassee, FL 32301
Office: (850) 606-5518
http://www.leoncountyfl.gov
People Focused. Performance Driven.
Thank you for your e-mail. Please note that under Florida's Public Records
laws, most written communications to or from county staff or officials
regarding county business are public records available to the public and
media upon request. Your e-mail communications may therefore be
subject to public disclosure.
--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512___
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] Nagios Update Check Is Not Running
On 01/15/2013 10:42 PM, Jon Adcock wrote:
I noticed that the main.php page update_available blue flag never appears
for me when a new version of Nagios is available. I do have
check_for_updates=1, but I see the following at the top of the Nagios
status.dat file:
info {
created=1358284500
version=3.4.1
last_update_check=1340002591
update_available=1
last_version=3.3.1
new_version=3.4.1
}
What that tells me is that the Nagios function (that checks to see if
there is an update available) hasn't run since 6/18.2012 6:56:31 GMT
(1340002591). I am seeing similar indications on my other Nagios servers.
Yes. This is my fault. I'm one of the core maintainers, but I also take care
of maintaining the nagios package for op5. Pretty much the only thing we
change in our version is to disable update checks with a hardcoded return
statement in the function that issues the actual check, since our customers
get their updates from us in the form of RPM packages. Once upon a time a
patch spilled over to the Nagios repository that had that change, so the
update check was broken sometime between 3.3.1 and 3.4.4.
I believe it's fixed in 3.4.4 though, with kudos to Eric Stanley for fixing
the problem.
1) Is there a way to force Nagios to CHECK NOW?
Not that I know of, and it wouldn't work with the hardcoded avoid update
checks at all cost patch in place anyway.
2) Does the update_check log it's results somewhere?
Only in the status_file.
3) Do you have any recommendations on how I should approach this problem?
Upgrade to the latest version manually and then the update checks should
start working again.
I'm really sorry for the inconvenience.
--
Andreas Ericsson andreas.erics...@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.
--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
___
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
