"It now appears that I can put check_megaraid in /usr/local/nagios/libexec and 
build my service check directly on the monitor. The real question is, what are 
the implications of doing so?"
>From my experience an Opsview upgrade will not remove custom checks in the 
>libexec folder, in our case we have a subfolder with custom code with 
>softlinks to libexec folder and it all seem to survive upgrades.
You would want to be sure the plugin has the correct user/group rights, I think 
I ran into an issue before where a plugin didn't display or I had some sort of 
error because user Nagios didn't have rights to the plugin.


Other than that your issue seems pretty straightforward.

James Whittington
VC3, Inc.

From: [email protected] 
[mailto:[email protected]] On Behalf Of Sean R. 
Kirkpatrick
Sent: Wednesday, December 22, 2010 4:42 PM
To: 'Opsview Users'
Subject: Re: [opsview-users] plugin not found in 
/usr/local/nagios/libexec/nrpe_local

Hi again.

In doing some playing around with this, I realized that my original description 
of the problem didn't well communicate my circumstances.

The Opsview monitor servers are different boxes than the ones whose RAID 
controllers I want to monitor. From either of the monitor machines, call them 
monA and monB, I can say on the command line 'check_megaraid -H <target> -C 
<community>'. <target> is, of course, either of the two machines of interest, 
call the targetC and targetD.

Fortunately, the check_megaraid script knows how to talk to the target machines 
via SNMP, so as long as the appropriate firewall ports are configured, I'm good 
to go.

>From your reply, Ton, I see that you are suggesting that we install the NRPE 
>daemon on each of monA and B along with whatever pieces of Nagios is necessary 
>to execute the check_megaraid remotely. However, because I check_megaraid 
>directly from the monitors, I have no need for remote execution, and indeed, 
>since the target machines are hosts for other VMs, I'd rather not burden them 
>with any other additional s/w overhead - it's sufficient for my purposes that 
>I can do it from the monitors.

It now appears that I can put check_megaraid in /usr/local/nagios/libexec and 
build my service check directly on the monitor. The real question is, what are 
the implications of doing so? Will Opsview delete the libexec contents on 
upgrade possibly breaking my service check? If so, that may be a problem. If 
not, all seems well.

Thanks for your help.

                Sean

From: [email protected] 
[mailto:[email protected]] On Behalf Of Ton Voon
Sent: Wednesday, December 22, 2010 06:05
To: Opsview Users
Subject: Re: [opsview-users] plugin not found in 
/usr/local/nagios/libexec/nrpe_local


On 21 Dec 2010, at 20:53, Sean R. Kirkpatrick wrote:

I've got two instances of opsview running. Both machines have Dell Perc 4i RAID 
controllers and I wanted to start monitoring their health using the 
'check_megaraid' plugin. The instructions for adding a new plugin here 
http://docs.opsview.org/doku.php?id=opsview3.10:unix_customise_agentseemed 
straight forward and so I set out to make it work.

Unfortunately, it doesn't. When the plugin is placed in 
/usr/local/nagios/libexec/nrpe_local with the appropriate config file entry in 
/usr/local/nagios/etc/nrpe_local/override.cfg pointing to the script, the 
script is never found - it does not show in the plugin dropdown list when 
adding a new service check. Note that I have stopped and restarted 
opsview-agent as well as nagios (opsview) itself.

So your issue is that the plugin does not get listed in the service check edit 
pages in the drop down list?

This is not possible because this is a "local" plugin, so it doesn't make sense 
for it to run from the Opsview master. You have to use check_nrpe to execute 
it, so it will not show on the Opsview master (if the plugin was, say, an 
OS/400 check, there's no way the Opsview master would be able to represent 
that).

Your process of putting it in nrpe_local with an appropriate 
command[check_megaraid] is the way to go. However, we don't do anything with 
regards to distributing this new agent to your remote hosts.

Ton

_______________________________________________
Opsview-users mailing list
[email protected]
http://lists.opsview.org/lists/listinfo/opsview-users

Reply via email to