Eliminate spikes in graphs

[GoogleCodeExporter]

See issue 36: NaN support works, but there are still cases when spikes
happen (as far as I know) because "Hmm, it seems there are big spikes
because of roll-overs.  If something is restarted and the counter is then
less, Cacti assumes it has rolled past the max value and wrapped around. 
How to work around this, both in terms of making sure wraparounds are
counted, and not having spikes when there is a restart?"

Perhaps the solution to this is to simply run a tool on the RRD files to
remove spikes.

Original issue reported on code.google.com by baron.schwartz on 8 Nov 2008 at 4:40

[GoogleCodeExporter]

An overflowed (roll-over) COUNTER ds shouldn't spike at all. Read rrdcreate(1) 
man 
page about overflow handling.
Is it really happening on COUNTER datasources?

Original comment by fri...@gmail.com on 13 Nov 2008 at 4:14

[GoogleCodeExporter]

Let's take the MySQL network stats graph. "rrdtool dump" mentions two COUNTER 
DS.
I still got a spike when I restarted MySQL (following a configuration change).

"man rddcreate" mentions "When the counter over‐flows, RRDtool checks if the 
overflow
happened at the 32bit or 64bit border and acts accordingly by adding an 
appropriate
value to the result.".

It's worth noting that the reset doesn't happen on 32/64bit border - it just 
happens
when MySQL restarts. This could explain the spikes.

Original comment by sylvain....@gmail.com on 26 Jan 2009 at 10:40

[GoogleCodeExporter]

If you compare Cacti's bundled "Interface traffic" traffic and 
mysql-cacti-template's
"MySQL network traffic", you'll see that the maximum values aren't the same:
1.0000000000e+07 vs. 1.8446744074e+17, the last one being above the 32bit limit
(where does it come from?). It would probably help to use sane max values in the
different graphs.

Alternatively,
https://lists.oetiker.ch/pipermail/rrd-users/2006-May/011188.html
suggests using DERIVE with a minimum value of 0 - not sure about this though.

Original comment by sylvain....@gmail.com on 30 Jan 2009 at 3:43

[GoogleCodeExporter]

It is a sane max value.  MySQL's counters are 64-bit (on 64-bit platforms; 
there is
an option to generate 32-bit templates) and are not the same as the OS network
counters.  I'll have to look into DERIVE with 0.

Original comment by baron.schwartz on 30 Jan 2009 at 7:18

[GoogleCodeExporter]

> [1.8446744074e+17] is a sane max value

Hmmm, do you often get 184 PetaB/s traffic peaks? ;)

Original comment by sylvain....@gmail.com on 3 Feb 2009 at 9:08

[GoogleCodeExporter]

You don't understand max value.  It's max value total, not per second.  It's 
the max
incoming value allowed from the data input.

Original comment by baron.schwartz on 3 Feb 2009 at 1:07

[GoogleCodeExporter]

Dunno, just reading rrdcreate(1):
"Note that min and max always refer to the processed values of the DS. For a
traffic-COUNTER type DS this would be the maximum and minimum data-rate 
expected from
the device."

Original comment by sylvain....@gmail.com on 6 Feb 2009 at 5:58

[GoogleCodeExporter]

Sorry for the long delay on this... I just haven't had much time to work on all 
this.
 I think you are right and I am wrong :)

Original comment by baron.schwartz on 7 May 2009 at 1:48

[GoogleCodeExporter]

No sure if it helps, but when I restart MySQL, most graphs report values show 
14.3M.
I am pretty sure I am not performing 14.3M selects, 14.3M Insert, 14.3M Update, 
14.3M
Deletes etc all at the same time. 

Original comment by pas...@gmail.com on 11 Jun 2009 at 8:38

[GoogleCodeExporter]

The COUNTER data source understands a "reset counter" to be a rollover, no 
matter
what your intent was.  Thus, if the maximum of the DS is defined as 2^64 - 1 
(as is
normal for a 64-bit counter), you're going to see a spike when you restart your 
mysql
daemon, as the counters are reset.

The solution is to use a data source of type DERIVE.  A rollover is going to 
cause a
NaN (or a U) to be inserted into the DS.  The only risk in using a DERIVE DS is 
if
you should ever happen to go over 2^64, as you will have a gap in your graph.

Original comment by thomas.s...@gmail.com on 7 Jul 2009 at 3:17

[GoogleCodeExporter]

I tested DERIVE instead of COUNTER, and it works fine.  I will update the 
templates
and release a new version when I have time.

Original comment by baron.schwartz on 19 Nov 2009 at 4:52

[GoogleCodeExporter]

This is committed in r336.

Original comment by baron.schwartz on 13 Dec 2009 at 5:04

• Changed state: Fixed