Performance values, what to use? (Was: Docume ntation Error)
Voon, Ton
Ton.Voon at egg.com
Tue Sep 7 16:28:19 CEST 2004
Ben,
Just to comment on:
---
Unfortunately there are holes in this documentation. I have also seen
requests to amend this documentation to add more features, and patch up
the holes.
Which have been, for what ever reason, ignored by these news groups.
---
This request should go to nagiosplug-devel. Please present what you propose
(preferably with a diff of developer-guidelines.sgml in CVS) and the reasons
and we will evaulate it as soon as we can.
Ton
-----Original Message-----
From: Ben Clewett [mailto:Ben at clewett.org.uk]
Sent: 07 September 2004 12:09
To: Stanley Hopcroft
Cc: Ben Clewett; nagios-devel at lists.sourceforge.net
Subject: [Nagios-devel] Performance values, what to use? (Was: Documentation
Error)
I have changed the subject of this thread.
Stanley,
I understand what you say. I am representing PerfParse (PP) which does
not use RRD for it's storage platform. We are lucky that we can store
information in any way we want, although only as 'float' or 'NULL' today.
I think there are two problems here:
1. What value would PP and RRD like to use for a infinite, null or
otherwise bad value. Eg, latency with no connection.
2. How to represent this in the plugin output.
As far as question 1 goes, either no value or a NULL value would be
excellent for PP. Since NULL is not supported, no value would be the
only choice for us. Anything else trying to indicate NULL of INF might
be confusing to the user.
Question 2:
All systems have to use the same format, as specified in the documentation:
http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN185
Unfortunately there are holes in this documentation. I have also seen
requests to amend this documentation to add more features, and patch up
the holes.
Which have been, for what ever reason, ignored by these news groups.
I would personally like to see NULL, -INF and +INF supported as possible
values. Which PP and RRD can use in their own ways. :)
Ben
Stanley Hopcroft wrote:
> Dear Folks,
>
> I am writing to thank you for your letters and say
>
> <something obvious and probably wrong .. get ready>
>
> On Tue, Sep 07, 2004 at 08:36:06AM +0100, Ben Clewett wrote:
>
>>That's right, from A to C. Yes this will be a straight connecting
>>line.
>>
>>I understand your feeling on this being miss-guided. But I see this
>>information as a record of the latency of the plugin, not a check on
>>whether there is a response. That is better taken care of by returning
>> WARNING or CRITICAL from plugin exit code.
>>
>>In PerfParse I am toying with leaving a gap in the graph where a value
>>is expected but not forthcomming, if the user selects some option.
>>However this is difficult as the user may have changed the timeing of
>>the plugin and the gap may be an expected response :)
>>
>>Either way, I would prefure to have no value, than to try and code a
>>response for an infinite value.
>>
>>Unless the people who designed the plugin performance protocol want to
>>give us some valid extensions for coding an infinite value, or coding a
>>NULL value. Something like:
>>
>>| latency=INFms
>>
>>or
>>
>>| latency=NULLms
>>
>>But this is a better question for another news group, to which I'll
>>make
>>a posting now :)
>
>
> Firstly, I haven't been paying much attention here so I prob should
> desist but if the data is going in an RRD then isn't 'U' a reasonable
> value because
>
> 1 plugin can always replace 'don't know' or nothing with 'U'
>
> 2 RRD deals with an 'unknown' value by interpolation. In this case,
> however a 'U' is an NaN, which it also is able to deal with.
>
> 3 attempting to scale a large or small value is probably infeasable -
> reading MAX and MIN values from the RRD is feasable in a plugin
> class/framework environmnt which doesn't exist at the moment ...
>
> Even after having considered again that a graph looks better with a
> max
> latency in the case of no response, it still is wrong and bad to do so -
> drop data such as this by Using U.
>
> </something obvious and probably wrong>
>
>>Regards, Ben.
>>
>
>
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel
This private and confidential e-mail has been sent to you by Egg.
The Egg group of companies includes Egg Banking plc
(registered no. 2999842), Egg Financial Products Ltd (registered
no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
is authorised and regulated by the Financial Services Authority. Egg
Investments Ltd. is entered in the FSA register under number 190518.
Registered in England and Wales. Registered offices: 1 Waterhouse
Square, 138-142 Holborn, London EC1N 2NA.
If you are not the intended recipient of this e-mail and have received
it in error, please notify the sender by replying with 'received in
error' as the subject and then delete it from your mailbox.
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
More information about the Developers
mailing list