[Nagiosplug-devel] perf data gudelines

[Karl DeBisschop]

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?

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 ?

> 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.

> 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.

--
Karl