[Nagiosplug-devel] RE: [Nagios-users] performance data from plugins - does it exist?

[Subhendu Ghosh]

Hi Richard

Perfdata is available on a per service check instance basis and the Nagios 
core will do nothing more than pass it on to the perfdata handler or a 
file. Each service check command would have to have appropriate flags 
enabled for the plugin to return the perfdata.

As Karl had mentioned in another thread, contribution on what plugin 
should return what perfdata would be most welcome and would speed the 
process.

-sg


On Wed, 25 Sep 2002, Richard Wu wrote:

> Hi, sg:
> 
> Glad to hear that perfdata will be addressed in the core level. It is
> useful for users to look back for a while and do the trending.  
> However, not every monitor is candidate for perfdata, only some of them
> are interested. So if you can put a perdata configuration per monitor
> level, it will be very helpful.
> 
> Richard Wu
> 
> 
> -----Original Message-----
> From: Subhendu Ghosh [mailto:sghosh at sghosh.org]
> Sent: Wednesday, September 25, 2002 6:38 AM
> To: Karl DeBisschop
> Cc: Jeremy Tinley; nagiosplug-devel at lists.sourceforge.net;
> nagios-users at lists.sourceforge.net
> Subject: Re: [Nagiosplug-devel] RE: [Nagios-users] performance data from
> plugins - does it exist?
> 
> 
> On 14 Sep 2002, Karl DeBisschop wrote:
> 
> <SNIP>
> > 
> > I do feel that performance data should be part of the formal 1.3.0
> > release, although it's never been discussed to my knowlege. I just don't
> > want to spend time logging performance data for every concievable
> > variable on this pass, especailly if it requires tracking new timers and
> > varibles for them, and other ancillary coding. I'd rather focus on
> > getting a formal release that includes an acceptable level of detail
> > done in a way that the most (all?) users and developers feel makes
> > sense.
> > 
> 
> I would prefer to make the performance data part of the 1.3.x release and 
> release 1.3.0 with additional stable plugins.
> 
> It would also be useful to discuss the overall size of the retrun string 
> and its impact in the nagios architecture.  We are currently limited by 
> the size on the non-interleaved pipe message size for passively submitted 
> results.  Do we want to differentiate plugins between active and passive 
> (I would think not..)
> 
> I thinks if a list of parameters to be measured from the existing plugins 
> could be developed (via contributions :) then we could decide on a base 
> set of parameters and naming guidelines for the parameters.
> 
> >From a diskio perspective, I would like to minimize or coordinate diskio 
> as much as possible for the perfdata - does this mean that nagios core 
> would have to support aggregate perfdata in addition to aggregate status?
> 
> 

--