What I'm really trying to get is multi-line output. Nagios/NRPE supports
this (v3.x) e.g.:
TEXT OUTPUT | OPTIONAL PERFDATA
LONG TEXT LINE 1
LONG TEXT LINE 2
This works for NRPE, but not with NSCA, since NSCA can only take a
single line as an argument.
What I'm trying to achieve is sending process monitoring data back
passively like so:
PROCS OK:
Proc1: 3 processes running
Proc2: 1 process running
Proc3: 1 process running
Any ideas?
-Aaron
Aaron Mills
Systems Administrator
Return Path, Inc.
http://www.returnpath.net
[EMAIL PROTECTED]
From: Mike Hamrick <[EMAIL PROTECTED]>
Subject: Re: [Nagios-users] NSCA and long output
To: Nagios Users Mailinglist <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hi Aaron,
You wrote:
> I've been trying to figure out if this is possible for a while. I'm
> using NRPE and $LONGHOSTOUTPUT$ for a number of tests, which is great,
> except for passive monitoring. We have several data centers that run
> their own Nagios boxes and then ship the data back to the master
> Nagios server via NSCA. The problem is that I can't get NSCA to
> utilize the $LONGHOSTOUTPUT$ - this is kind of critical for things
> like log file checks, etc. With NSCA this data doesn't get passed.
Looking at the NSCA sources, common.h has:
#define MAX_PLUGINOUTPUT_LENGTH 512
I'm guessing that's the issue right there. The first thing I'd try is
to bump that up to 4096, and recompile send_nsca and nsca. I haven't
looked very carefully at the source or tried this myself, but it seems
like a good place to start.
Mike
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nagios-users mailing list
[email protected]
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
