[Nagiosplug-devel] perf data gudelines

[Voon, Ton]

> -----Original Message-----
> From: Karl DeBisschop [mailto:karl at debisschop.net] 
> Sent: Friday, September 12, 2003 12:33 PM
> To: Ton Voon
> Cc: NagiosPlug Devel
> Subject: RE: [Nagiosplug-devel] perf data gudelines
> 
> 
> On Fri, 2003-09-12 at 07:08, Voon, Ton wrote:
> 
> > > > I think this is a range issue, rather than a perfdata 
> > > issue. Maybe we need a
> > > > clarification on ranges in the dev guidelines.
> > > 
> > > So the general case for [warn] and [crit] becomes 
> [num]:[num] - makes
> > > parsing a little harder, but I guess it's logical.
> > 
> > This was the reason for using ";" as the delimiters - 
> because ":" was
> > reserved for ranges.
> 
> Good design choice. I kust missed that implication when it 
> was proposed.
> 
> > > > I think we should take the general case for ranges from 
> check_procs:
> > > > 1) alert if metric outside start:end where start < end, 
> > > start (and ":") not
> > > > required if 0
> > > > 2) if end not specified, assume infinity
> > > > 3) if start > end, then alert if inside this range
> > > > 
> > > > (A few thoughts: I don't like the specification for (3) - 
> > > I'd much prefer
> > > > some identifier like "*start:end" to mean "inclusive 
> > > alert"; also how do you
> > > > specify  negative infinity?)
> > > 
> > > When I came up with the rules above, without realizing 
> it, I assumed
> > > that all number were non-negative.
> > > 
> > > Do you have a proposed fix for this that we should try and 
> > > get in before
> > > we relase the 1.4.x alpha with its perf data fields?
> > 
> > I think this is starting to be like those obscure regex 
> rules which no one
> > uses, but makes sense to define for completeness.
> > 
> > I propose changing rule 3 and adding rule 2.5 so that:
> > 3) If range starts with an "@", then alert if inside this range
> 
> Inclusive of the range endpoints?

I say yes. Exclusive takes values inclusive too. I think it will be too
difficult to try and have an inclusive and exclusive option.

> 
> Since we are trying to be consistent with option parsing for the
> plugins, I assume we'd push this idea back into the plugins 
> as well. So
> 3:5 would mean exactly he same as 5:3 ? Or would we retain the old
> syntax (for parsing --crit options) too ?

I don't know about 5:3. I'm picturing a generic function for parsing ranges
and checking thresholds and I reckon 5:3 would be an error.

> 
> > 2.5) to specify negative infinity, use ^
> 
> Why ^ ? Too many regexs, but that makes me thing of 'the beginning'
> whereas 'negatinve infinity' is not a definite number thus cannot be a
> place. Would ~ be OK as instead - I don't know that any 
> symbol would be
> intuitive, but ~ does not feel counterintuitive or as 
> overloaded to me.
> But if you might well have a logic for choosing ^ that I'm missing.

I only thought of ^ as "start", but I guess regex considers this as 0,
rather than negative infinity. ~ is fine with me.

> 
> > Of course, the next step is for a single plugin to have 
> different metric
> > checks (eg, check_http --time-warn= --time-crit= 
> --size-warn= --size-crit=).
> > Sigh.
> 
> That is the step we are at - there is a min-size parameter, it was not
> implemented to look like a general warning threshols, but it 
> clearly is
> a threshold, and I plan to generallize it.
> 
> > > > With the ranges specified, I think a clever 
> > > Nagiosplugins->RRD tool could
> > > > draw the appropriate alert areas in yellow and red with the 
> > > line of data in
> > > > black.
> > > 
> > > The definition of 'clever tool' keeps expanding here. Oh 
> > > well, it won't
> > > be written in any case until there are rules on the inputs.
> > > 
> > 
> > I think if we have good standards, it should be relatively 
> easy to write the
> > tool. I'm just avoiding doing it myself ;o)
> 
> Take away the wink - that's why I'm trying to work this out - someone
> will need to write the tool. I don't know if it will be me, 
> but it could
> be.

Don't mean to overload you with work. I currently have an rrdgraphing tool
in perl that we use internally based on the old style perf data format. I
plan on updating it when we move to r1.4, but I don't know if it is good
enough for publishing.

Do you plan to make this range stuff consistent in r1.4 or leave till r1.5?
I vote to leave till r1.5.

Ton


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
carries out investment business on behalf of Egg and is regulated
by the Financial Services Authority.  
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.