[Nagiosplug-devel] Perf Data

Ethan Galstad nagios at nagios.org
Wed Feb 19 21:40:06 CET 2003
Previous message: [Nagiosplug-devel] Perf Data
Next message: [Nagiosplug-devel] Perf Data
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 19 Feb 2003 at 3:26, Karl DeBisschop wrote:

> On Tue, 2003-02-18 at 21:16, Richard Colley wrote:
> > It would seem to me that relying on something like atomic write sizes is
> > something of a hack.
> 
> <One Hand>
> 
> Practically speaking, the output has to be viewed on a web page. From
> that point of view, 300 characters is pretty long anyway, unless you are
> urlizing with a fairly long host name.
> 
> So I'm willing to have the restriction imposed. However if we do not
> plan to change the pipes, then I'd want to code for it. At least in
> urlize where truncation can cause html syntax errors.
> 
> </One Hand>
> 
> <The Other Hand>
> 
> Therein lies the rub. I don't think the plugin can code for it - it does
> not know the length of the host/service name. So at best, that can only
> be a guess. And if my quick scan of objects.h is correct, the
> hostname/service can be arbitrarily long.
> 
> On this basis, I'm a little concerned. It has not been a big problem so
> far. And we can take more care to ensure that output length is less than
> about 350 bytes when --verbose is not specified.
> 

You must have missed the first few lines in objects.h :-)


#define MAX_HOSTNAME_LENGTH            		64	/* max. host name length */
#define MAX_SERVICEDESC_LENGTH			64	/* max. service description length */
#define MAX_PLUGINOUTPUT_LENGTH			352	/* max. length of plugin output */


> </The Other Hand>
> 
> In the long run, I guess I don't like trusting to chance. Either
> hostname/servicename should be limited in length so a dependable output
> length calculation is possible, or we should implement something that is
> more completely robust.
> 
> I don't want this to be too complex. I'd be quite happy to limit
> overhead from name lengths.

The daemon enforces the max length of the plugin output it stores 
regardless of how long the plugin output length actually is, so as 
long as output is 351 chars or less things should be fine.  It may 
increase in the future, but at least its a minimum value to work 
with.

The host/service fields are trimmed to 64 chars each when results are 
getting sent back to the parent.  Although I did notice that there 
are no errors/warnings being generated at startup if a host name or 
service description exceeds that length.  I'll have to fix the bug.


> 
> --
> Karl
> 
> > Maybe it is time to wrap the named external command pipe with an API that
> > serialises messages into the pipe.
> > 
> > Also, a simpler way of fixing this issue for the internal non-named pipes
> > from Nagios to children would be to have one pipe per child.  Given the
> > number of children that would normally be active simultaneously, this
> > shouldn't be a major issue.
> > 
> > Richard
> > 
> > 
> > -----Original Message-----
> > From: Ethan Galstad [mailto:nagios at nagios.org] 
> > Sent: Wednesday, 19 February 2003 12:45 PM
> > To: nagiosPlug Devel
> > Subject: Re: [Nagiosplug-devel] Perf Data
> > 
> > 
> > On 18 Feb 2003 at 20:40, Subhendu Ghosh wrote:
> > 
> > > On Tue, 18 Feb 2003, Ethan Galstad wrote:
> > > <snip>
> > > >
> > > > 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.
> > > > 
> > > 
> > > The second pipe - is that a single pipe per running install from the
> > > temp_file var in the config file?
> > > 
> > 
> > Its a single pipe, although its not implemented as a FIFO, so it 
> > doesn't exist anywhere in the filesystem - just in memory.  You can 
> > think of it as a very limited type of socket that you would 
> > read/write from/to for network apps.  It has one reader (the parent 
> > process) and multiple writers (the child processes).  Its implemented 
> > with a call to pipe(2).
> > 
> > 
> > 
> > Ethan Galstad,
> > Nagios Developer
> > ---
> > Email: nagios at nagios.org
> > Website: http://www.nagios.org
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> > The most comprehensive and flexible code editor you can use.
> > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> > www.slickedit.com/sourceforge
> > _______________________________________________
> > Nagiosplug-devel mailing list
> > Nagiosplug-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> > ::: Please include plugins version (-v) and OS when reporting any issue. 
> > ::: Messages without supporting info will risk being sent to /dev/null
> > 
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003
> >  
> > 
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003
> >  
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> > The most comprehensive and flexible code editor you can use.
> > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> > www.slickedit.com/sourceforge
> > _______________________________________________
> > Nagiosplug-devel mailing list
> > Nagiosplug-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> > ::: Please include plugins version (-v) and OS when reporting any issue. 
> > ::: Messages without supporting info will risk being sent to /dev/null
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Nagiosplug-devel mailing list
> Nagiosplug-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> ::: Please include plugins version (-v) and OS when reporting any issue. 
> ::: Messages without supporting info will risk being sent to /dev/null
> 



Ethan Galstad,
Nagios Developer
---
Email: nagios at nagios.org
Website: http://www.nagios.org
Previous message: [Nagiosplug-devel] Perf Data
Next message: [Nagiosplug-devel] Perf Data
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Devel mailing list