check_snmp_load.pl best linux practices

[Gary Every]

I use my 15 minute avg instead of the current, allows for less false
positives. Here is my checkcommand....


/usr/lib/nagios/plugins/check_snmp -H 10.1.1.22 -C REDACTED -o
enterprises.ucdavis.laTable.laEntry.laLoadInt.2,enterprises.ucdavis.laTable.laEntry.laLoadInt.1,enterprises.ucdavis.laTable.laEntry.laLoadInt.3
-w 100 -c 150 -u "is 5min - ,is Current - ,is 15min"

your -w and -c checks are actually 100x the load, so if you want to warn on
a load of 2 or more, then -w would be 200. The output, specified by the -u
switch, outputs:

SNMP OK - 33 is 5min -  33 is Current -  44 is 15min |
UCD-SNMP-MIB::laLoadInt.2=33 UCD-SNMP-MIB::laLoadInt.1=33
UCD-SNMP-MIB::laLoadInt.3=44


Since I'm asking for the second output first
(enterprises.ucdavis.laTable.laEntry.laLoadInt.2) that is what nagios checks
and reacts to. You could put
"enterprises.ucdavis.laTable.laEntry.laLoadInt.3" first to check for the 15
minute avg

Nagios only reports (in the GUI) the info prior to the pipe symbol that is
returned, so it would show:

SNMP OK - 33 is 5min -  33 is Current -  44 is 15min

HTH
g.;


On Fri, Mar 11, 2011 at 9:13 AM, Joe Beck <JBeck at urbn.com> wrote:

> Frank,
>
> This looks like a great addition to my core alerting.
> Any chance you can share the details of your setup--
> Did you make these updates to check_snmp_load.pl & do something similar to
> Robert?
> >> I'm getting good results by using the NETSL option to report load
> averages.
> >> I'm setting '-c 99,4,10' to basically ignore the 1 minute value and
> alarm
> >> on 5 and 15 minutes.
>
> Thx,
> Joe
>
>
> On 3/9/11 9:00 PM, "frank" <ratty at they.org> wrote:
>
> > On my installation I added code to the SNMP load check to count the CPU
> > cores via SNMP and set WARN to 1.25*cores and CRIT to 1.5*cores (for
> > any/all load values). Seems to be working ok. Haven't had any complaints
> > from the NOC for excessive alerting.
> >
> > -f
> >
> > On Wed, 9 Mar 2011, Robert Eden wrote:
> >
> >> Date: Wed, 09 Mar 2011 14:33:13 -0600
> >> From: Robert Eden <rmeden at gmail.com>
> >> Reply-To: Nagios Users List <nagios-users at lists.sourceforge.net>
> >> To: nagios-users at lists.sourceforge.net
> >> Subject: [Nagios-users] check_snmp_load.pl best linux practices
> >>
> >> I'm currently experimenting with using check_snmp_load.pl to alarm on
> system
> >> overload.
> >>
> >> Monitoring CPU usage is giving me a lot of false alarms due to their
> >> instantaneous nature.
> >>
> >> I'm getting good results by using the NETSL option to report load
> averages.
> >> I'm setting '-c 99,4,10' to basically ignore the 1 minute value and
> alarm
> >> on 5 and 15 minutes.
> >>
> >> Unfortunately, unlike the CPU percentages,  the load numbers should be
> based
> >> on the number of processors.  The NETSL option doesn't do that.
> >>
> >> One option is to have a series of service commands based on the number
> of
> >> processors, but  I'm considering writing a new mode that will using the
> >> "STAND" option to get the number of CPUs and then use that as a
> >> multiplication factor for alarms.
> >>
> >> Does that make sense?   Surely others have run into this problem.  How
> do you
> >> alarm on excessive load w/o causing lots of false alarms.
> >>
> >> Robert
> >>
> >>
> >>
> >>
> >>
> >>
>
> ----------------------------------------------------------------------------->>
> -
> >> Colocation vs. Managed Hosting
> >> A question and answer guide to determining the best fit
> >> for your organization - today and in the future.
> >> http://p.sf.net/sfu/internap-sfd2d
> >> _______________________________________________
> >> Nagios-users mailing list
> >> Nagios-users at 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
> >>
> >
> >
> ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > Nagios-users mailing list
> > Nagios-users at 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
>
> Joe
> --
>
> Joe Beck | IT-Open Systems Engineer | urban outfitters inc.
> 5000 South Broad Street | Phila., PA 19112 | 215.454.7737 | jbeck at urbn.com
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at 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
>



-- 
Gary Every
"Pay it Forward!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20110311/dd2c8486/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at 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