[xymon] TRACKMAX feature in 4.3.0b3 - help/info wanted

[Henrik Størner]

On Mon, 29 Nov 2010 16:54:38 -0500, Stephen wrote:

> First,  thanks for the new release!

Well, it's a beta-release so not quite a "release" yet. But thanks 
anyway :-)


> I ask for more detail and maybe procedural examples to the TRACKMAX
> feature.  Built-in TRACKMAX is something I hope will solve the beating
> I've been taking.
> 
> QUESTIONS:
> 
> -"This only works for the NCV backend"

Where does this text come from ? A quick grep of the 4.3.0 sources/docs 
doesn't find it.

TRACKMAX was in fact something that was added in 4.2.2, and then removed
again in the first 4.3.0 beta because I opted for a more general solution 
of configuring what to save in your RRD files. So TRACKMAX is only 
referred to in the 4.3.0-beta3 RELEASENOTES file:


TRACKMAX feature removed
------------------------
For users of the TRACKMAX feature present in 4.2.2 and
later 4.2.x releases: This feature has been dropped. Instead,
you should add a definition for the tests that you want to track
max-values for to the rrddefinitions.cfg file. E.g. to
track max-values for the "mytest" status column:

[mytest]
        RRA:MAX:0.5:1:576
        RRA:MAX:0.5:6:576
        RRA:MAX:0.5:24:576
        RRA:MAX:0.5:288:576



>  .... does this mean only the
> addition client tests we add, not the CPU/Mem/vmstat built-ins ? -Do we
> have to loop through out RRD files and resize, it it advisable to do so?
> (I'm thinking I should)
> -Do we have to loop through our RRD files and mod settings to match/sync
> with TRACKMAX settings?
> 
> The referenced link to a note and discussion don't work, but I did find
> some discussions, and sorry to say I wouldn't be able to figure out what
> to do from them.  My goal is to have 60days of detailed data without too
> much granularity loss or smoothing.  I got space and plenty of
> horsepower.  Anything to get the suits off my back about the "bad data"
> (their words!).


I'm not sure your understanding of the old TRACKMAX feature is correct. 
It was NOT a way of defining how much data was stored in the RRD file; it 
was a way of configuring your RRD files to save the minimum/maximum 
values of the individual measurements instead of only saving a rolling 
average.

What you're asking for appears to be a way of saving the most detailed 
data for a longer period than the default 48 hours. However, the solution 
is in the same configuration file - rrddefinitions.cfg. It has the 
default setting for how many datapoints to store for each time resolution:

        # 576 datapoints w/ 5 minute interval = 48 hours @ 5 min avg.
        RRA:AVERAGE:0.5:1:576
        # 576 datapoints w/ 6*5 minute averaged = 12 days @ 30 min avg.
        RRA:AVERAGE:0.5:6:576
        # 576 datapoints w/ 24*5 minute averaged = 48 days @ 2 hour avg.
        RRA:AVERAGE:0.5:24:576
        # 576 datapoints w/ 288*5 minute averaged = 576 days @ 1 day avg.
        RRA:AVERAGE:0.5:288:576

If you want to save 60 days of detailed data - assuming you mean 5-minute 
data - then that will require
	60 days*24 hours/day*(60/5 measurements/hour) = 17280 data points
to be saved. So you can simply change the first RRA definition to

	RRA:AVERAGE:0.5:1:17280

and drop the 12- and 48-hour definitions. I don't know what you want to 
do when going back further in time - jumping from a 5-minute resolution 
for day 59 to a 24-hour resolution for day 60 might be a rather large 
loss of resolution. But that's for you to decide - you can setup whatever 
resolutions you like with one or more RRA definitions.

Your RRD files will of course be larger - at least 7.5 times larger than 
now since you'll have 17280 data points instead of the current 4*576.

Note that these definitions are only applied when the RRD-file is created. 
So for existing RRD-files, you'll have to use the "rrdresize" command to 
increase the number of datapoints stored in the RRD-file.


Regards,
Henrik