[Nagiosplug-devel] Perf Data

[Ethan Galstad]

On 20 Feb 2003 at 1:18, Karl DeBisschop wrote:

> On Thu, 2003-02-20 at 00:47, Ethan Galstad wrote:
> > On 19 Feb 2003 at 13:16, Richard Colley wrote:
> > 
> > > It would seem to me that relying on something like atomic write sizes is
> > > something of a hack.
> > 
> > Agreed, but its simple. :-)
> > 
> > > 
> > > Maybe it is time to wrap the named external command pipe with an API that
> > > serialises messages into the pipe.
> > 
> > That could get pretty ugly and you would loose the benefit of a 
> > simple interface for external apps to use.  A better solution would 
> > probably be to implement it as a unix domain socket instead of a 
> > FIFO.
> > 
> > > 
> > > 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.
> > 
> > Yep, I'll take a look at implementing this in 2.0
> 
> In a sense, this doesn't help though. Since the named pipe still has the
> limits, the plugins still need to check their length, right?
> 
> I know nagios will truncate. but that is a problem if truncation leads
> to unbalance HTML, or to altered perf data.
> 
> --
> Karl
> 
> 

If the external command file is implemented as a unix domain socket 
and the interal pipe is changed so that there is one pipe per child, 
there is no problem.  The problem that exists now is due to the fact 
that there are multiple writers per pipe, so I need to worry about 
atomic write sizes.  With one pipe per child for the internal stuff, 
there will be no theoretical limit as to how much data can be passed 
back to the daemon.  The unix domain socket is essential the same as 
a network socket (each writer has its own connection), so there 
shouldn't be any limits there either.

As far as developing for limits, I'd use the current ~350 char limit 
for plugin output+perf data.  So much is changing internally right 
now that I can't guarantee I'll pull off the pipe/socket changes in 
2.0.


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