rrdtool create newdata.rrd --step 300 \

DS:upDown:GAUGE:0:U:U \

RRA:AVERAGE:0.5:1:525960

Is what I come up with. I'm not sure why averaged values are ending up in there.

Steve:

In the mean time, share a laugh- http://www.happyplace.com/9907/david-thorne-makes-co-workers-life-a-living-hell

Steve:

"You can cause the normalisation to be a null operator by

ensuring that you update on every step boundary - not a second early

or late - and do no consolidation. "

"Don't expect values.  Expect rates. Values are used by rrdtool to

compute rates.  It are these rates that are normalized, consolidated

and displayed.

Depending on your counter type, and your input, rrdtool will

'modify your values' (compute a rate from them).

If you think you are dealing with values instead of rates, at some

point in time you are going to be disappointed"

Looks like it all comes down to 1:1 step per period and always updating on step/period boundaries.

Steve:

Sorry I don't have a better answer for you.

Steve:

Thats pretty much the case.

I think in this case, (depending on other factors certainly), I might consider not using zenperfsnmp to gather the data - i.e. for a binary value with 2 or 3 possible states, and/or you don't need to graph it -  don't store the values in an RRD. It's probably a hack, but when I want to check on a polled value that is a "yes/no" sort of thing, I usually use a command datasource, and store values if I need to in a file my script creates.

Not to say that's a good way to do it, but maybe a bit of figuring out a correct tool for the job. I don't know all the context of what you're doing though, so this may be totally useless.

Potentially for some of the community devs who are adept at writing perf daemons, maybe it would be worthwhile putting on a "nice to have" list something that's like zenperfsnmp but gives the option if storing data in (something) other than RRD for non-graphing uses.

--

James Pulver

Information Technology Area Supervisor

LEPP Computer Group

Cornell University