[rrd-users] Empty sections in AREA on graph, but values in database

Alex van den Bogaerdt alex at vandenbogaerdt.nl
Wed Aug 27 10:29:59 CEST 2014


please... keep it on list, or hire me.

----- Original Message ----- 
From: "Thomas Brinkmann" <thomas.brinkmann at email.de>
To: "Alex van den Bogaerdt" <alex at vandenbogaerdt.nl>
Sent: Wednesday, August 27, 2014 9:10 AM
Subject: Aw: Re: [rrd-users] Empty sections in AREA on graph, but values in 
database


> Hello Alex,
>
> thanks for your answer.
> i have added the two lines and created a new graph.
> http://img26.dreamies.de/img/671/b/2lah6n0u5g0.gif

Nice continuous line.  So the problem is not in stufe, it is in how things 
are processed while graphing.

> Here is the output from "rrdtool fetch kwl.rrd LAST"
> The 6th column "0,0000000000e+00" is "bypass"
> The Last column "2,0000000000e+00" is "stufe"
>
> As you can see, the values are "0,0000000000e+00", "2,0000000000e+00" and 
> "3,0000000000e+00" without interruption or normalization - so there 
> shouldn't be any empty areas in the graph ? (as far as i understand this).

I am not sure if, at graphtime, RRDtool would consolidate {2,3}  into 2.5 
(the average) or into 3 (because of LAST).
This graph time consolidation does not happen in fetch, so it is mostly 
useless to compare.

What you can try for further debugging:

Good practice anytime:
Make sure start time, end time, CDP size and number of pixels match.
--start { timestamp for 00:00 goes here }
--end start+86399
--width { amount of CDPs used for 24 hours, multiplied by a whole integer 
1..n }
e.g. if the amount of time in your RRA is 5 minutes per row, graph width is 
288 or 576 or 864 or ....

While debugging this problem:
Remove the elements not needed to look at this problem. It just distracts.
(ofcourse you are working with a copy of your script... change the copy, not 
the original)

Maybe, for a yet to be discovered reason, the elements interact with 
eachother.  Remove all but one element, e.g. only graph stufe1. Compare to 
the original. Does the problem go away?  If so, add one more element e.g. 
stufe2. Repeat.

Try adding: CDEF:stufe_debug=stufe,UN,75,stufe,IF
and graph this as a line or area. Does it go up to 75? Then you have 
unknowns in the data.

Currently you are not interested in the cases where stufe is 0,1,2 or 3. 
After all, you would not be debugging if everything worked.
So try adding 
CDEF:stufe_debug=10,stufe,25,*,stufe,1,EQ,stufe,2,EQ,stufe,3,EQ,stufe,0,EQ,+,+,+,IF
(by the way: everything is untested, you make it work should changes be 
required)
This should work like so: 4 compares which return 1 for true or 0 for false. 
If any of them is true, the IF will return the first value (10), else the 
second value (stufe*25).
Possible outcomes could be:
unknown (blank) in case stufe is unknown  <== there's your problem
10, in case stufe is 0,1,2 or 3 <== expected result, which we do not want to 
see while hunting for this bug
25*stufe if stufe is different <== there's your problem



More information about the rrd-users mailing list