[Nagiosplug-devel] Perf Data

[Ethan Galstad]

On 18 Feb 2003 at 19:53, Subhendu Ghosh wrote:

> On 18 Feb 2003, Karl DeBisschop wrote:
> 
> > On Tue, 2003-02-18 at 18:04, Russell Scibetti wrote:
> > > If it would be helpful, this is something I can work on in parallel
> > > and submit a patch as I add to each plugin.
> > 
> > It would be very helpful, but in no case are we adding perf data before
> > the release. We are in feature freeze.
> > 
> > > Would it better to have the plugins output perfdata by default, or
> > > require a cmdline arg?  I want to be as consistent between plugins as
> > > possible.
> > 
> > So far, it has been enabled by default.
> > 
> > Not sure if that is the right decision, however.
> > 
> > If there were not size limits on the nagios data pipe, I'd send it by
> > default. But I'd hate to deserialize the pipe for an added few bytes of
> > perf data that wasn't even wanted.
> > 
> > Thoughts anyone?
> 
> I think Russell raised this question earlier about the pipe msg size.  If 
> Nagios is spawning a separate process and doing a spopen - then the pipe 
> for each plugin invocation should be distinct.
> 
> Perhaps we need to confirm this as a feature with Ethan.
> 
> The impact would be on passive checks where the results are submitted 
> through the named pipe.  If there is another way to do the passive checks
> I'd be interested.
> 

There are two pipes of interest.  One is the external command file, 
which is implemented as a FIFO and is restricted by the PIPE_BUF 
limit (512 bytes minimum for POSIX).  Passive checks have to deal 
with this limit, but not active checks.

The other pipe is used for IPC between the main (parent) Nagios 
process and the child processes.  Each child writes the results of a 
plugin check (along with host/service name) to the pipe, at which 
point the parent reads it and process it.  This pipe is also 
restricted by the PIPE_BUF limit.  With host/service name overhead, 
you're left with about 350 bytes useable for plugin output+perfdata.  
It should be noted that *both* active and passive checks have results 
sent through this pipe.  Passive checks enter through the FIFO and 
then get dumped into this pipe.

If the size of the pipe becomes a real issue, we can probably break 
with POSIX compliance on most systems.  The POSIX standard states a 
minimum of 512 bytes, but Linux has a 4K atomic write limit, while 
Solaris may have an 8K limit (I don't recall offhand).  I guess I'll 
have to deal with it if and when it comes up.



Ethan Galstad,
Nagios Developer
---
Email: nagios at nagios.org
Website: http://www.nagios.org