[Nagios-users] Checking for a string with spaces with check_http in 3.5 / 4.0

2013-07-23 Thread Niall O Broin
I am currently running 3.2.1 (version packaged with Debian squeeze) quite 
happily but I want to migrate to a new server so I decided I'd move to 4.0 as 
well. I compiled 4.0.0-beta1 and after a bit of a slog finally have it mostly 
working. I'm currently trying to get check_http to check for strings with 
embedded spaces e.g. check that a page includes the string   My Wonderful Web 
Site  but for the life of me I can NOT get it to work. On 3.2.1 I have this 
command definition

define command{
command_namecheck_http_string
command_line/usr/lib/nagios/plugins/check_http -H $ARG1$ -w $ARG2$ -c 
$ARG3$ -s "$ARG4$"
}

and service definitions which include check_command lines like this:


check_command check_http_string!my.wonderfulwebsite.com!60!90!"\"My Wonderful 
Web Site\""

and that works as expected, but the exact same thing does not work in 4.0.0

I have tried single quotes, and double quotes, in both the command definitions 
and the service definitions. Seeing the error messages in the services seemed 
to indicate that the quotes were getting included in the string, hence not 
matching, I changed to escaping the spaces in the service definitions and this 
worked, somewhat. I'm testing 4 services with check_http_string of which 3 are 
identical frontends to the same website and yet of those 4 services, all but 
one fails, and the one is one of the three identical servers.

As this struck me as more than a little bizarre, I decided to give the latest 
stable Nagios, 3.5.0, a try. With that I was able to use the same config files 
as with 4.0.0 and now, all 4 services pass.


Apart from "what do you expect from beta software" can anybody make any 
suggestions?



Kindest regards,



Niall  O Broin




--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
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 improvement request

2013-07-23 Thread Trond Hasle Amundsen
"John Skarbek"  writes:

> I?ve recently deployed the check_openmanage script and it works very well. 
> Except for hosts that run esxi.  Unless I?m doing something wrong. 

You're not doing anything wrong. Openmanage, when deployed on ESXi,
doesn't have the necessary capabilities for it to work.

> I?ve discovered that Open Manage doesn?t broadcast it?s OID?s through ESXi 
> like
> it would if it were a linux or windows host.  However I did find that the
> iDRAC7 does have similar snmp responses that I?d like to capture.  However 
> when
> pointing check_openmanage to the drac interface, I get the message indicating
> that OMSA must not be installed correctly.  However, looking into the script I
> found:
>
> my $chassisModelName = '1.3.6.1.4.1.674.10892.1.300.10.1.9.1';
>
> Which does indeed NOT exist.  However, a similar OID with the same information
> we are looking for is located here:
>
>$chassisModelName = '1.3.6.1.4.1.674.10892.5.1.3.12.0';

Actually, the OID is 1.3.6.1.4.1.674.10892.5.4.300.10.1.9.1. I've toyed
around with this a bit, and for the most part you can simply replace
"1.3.6.1.4.1.674.10892.1" with "1.3.6.1.4.1.674.10892.5.4". Same goes for
storage OIDs, to a degree.

> After modifying the script a little bit I was able to get past that, but now
> check_openamange is complaining, ?SNMP ERROR [memory]: The requested entries
> are empty or do not exist. ?
>
> I presume the entire set of OID?s is in a different spot when being checked
> through the drac versus the standard windows snmp service.  I would love to
> assist in enhancing this script, but I?m not sure how I should start.  Let me
> know who I should contact, or feel free to reach out to me to assist with this
> awesome plugin.

I have a modified prealpha version for testing, available in the test
branch in git:

  http://git.uio.no/git/?p=check_openmanage.git;a=shortlog;h=refs/heads/test

Note that it's NOT production ready, I have only done some very limited
testing.

I had to simplify some stuff:

  * Storage: The storage OIDs from the iDRAC7 are somewhat different,
compared to Openmanage. Some information that the plugin needs is
not available, such as numbered identifiers for components (used in
blacklisting). There are even some OIDs that aren't present in
Openmanage. In short, it's a mess, and the storage bit is very
simplistic. Perhaps the missing info will be added in a later
firmware release, we can only hope.

  * ESM health OIDs are missing completely, so ESM health check is
omitted. Same for SD card check.

To use the new feature you have to specify '--idrac', like this:

  check_openmanage --idrac -H 

Test it, break it and tell me what you think :)

I've noticed that neither the rollup-status or component-status for
controllers catches that the controller is actually degraded from
out-of-date firmware. Hopefully it's an anomaly that doesn't apply to
other aspects of controllers, or other components.

Cheers,
-- 
Trond H. Amundsen 
Center for Information Technology Services, University of Oslo

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
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