[Nagiosplug-devel] Re: Suggested alterations to the Performan ce Protocol (Re: Nagiosplug-devel digest, Vol 1 #653 - 5 msgs)

[Voon, Ton]

So the use of the check_time is because of a log entry?

I'm not sure Nagios (and associated plugins) is the best tool for this. I
think there are two types of alerts: "active checks" (to check that things
are working correctly, like check_disk and check_ping), and "on-demand
alerts" (such as tape needs loading, or an intruder detected via syslog).
Nagios is great for active checks (a sea of green boxes lifts my heart!),
but I don't think is great for on-demand alerts (this requires a different
interface where there are outstanding issues which an operator would
action).

So the use of a plugin to return perfdata as a time (and presumably an
associated error message), doesn't seem to be appropriate use of perf data.
I think this should probably be captured in the status. However, if you
returned the number of failure messages seen in the log file - now that
would be perfdata.

My philosophy is that perfdata must be a measureable range of data, and time
is not.

Agree? Disagree?

Ton

-----Original Message-----
From: Yves Mettier [mailto:ymettier at libertysurf.fr] 
Sent: 08 September 2004 09:28
To: nagiosplug-devel at lists.sourceforge.net
Subject: [Nagiosplug-devel] Re: Suggested alterations to the Performance
Protocol (Re: Nagiosplug-devel digest, Vol 1 #653 - 5 msgs)


>> 2.
>>
>> Suggested by Yves Mettier:  The addition of a special reserved 
>> variable, 'check_time' which records the time at which the plugin 
>> completed the check.
>>
>> I can't remember if units were suggested, but in line with Nagios, 
>> the time as seconds from 01-01-1970 00:00:00 UTC, or standard UNIX 
>> time, may make sense.  If Yves is reading this, he may be able to 
>> comment further.
>
> Firstly, why is this performance data?
>
> Secondly, I think something like this should be done by Nagios, not 
> the plugins. Seems a bit of a waste to code in start/stop times in 
> each plugin when the core execution engine would hold all this 
> information. There needs to be a change to Nagios to pass this data 
> through somehow, but then this would work for every plugin.
>
> (I think "time", which is really "elapsed time", is slightly different 
> as this will remove timings from things that are outside of the core 
> check, so for example check_dns gives the time for the dns lookup, but 
> removes plugin startup, variable parsing, host resolution checks, etc)
>
> However, I like the idea of "special reserved variables" - I think it 
> is worthwhile to add a table with a list of common labels, such as 
> "time". Any comments?

Maybe some explanations.
We have some plugin here (don't ask me what's inside : I have no idea:) that
read some log and transform it to perf data when this can be done. For this
reason, when the plugin runs, we get the date from nagios, not the date of
when the events occured. So the need used to be to add some timestamp for
every perf data. Now, we are thinking about something else. The log is
nothing else than another serviceperf.log file, with another format. We just
need to parse that log file and output some new log file with a nagios
compatible format. Then use the usual tools to parse that file.

Is this still a need ? I think that those who have the same need should
think, like me, if nagios is the good tool to output perf data.

I have no opinion about a table with a list of common labels. Maybe we
should "register" some labels like "time" when needed, with some good
explanation to the spec maintainer ?



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.