-Steve

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