Summation of non-bandwidth data - code included

[Neptune]

raX - great work! Cacti is very cool. Thanks for making your work public.

I made some cumulative Gigabyte graphs and noticed the 'sum' function multiplies the sum by the Data Source step - which is great for interpolating a continuous function, but does not add up single atomic values accurately.

I coded the following to add another option to the sum function. A tag like so will now sum all the data points in a graph and provide a total of each, discrete point without interpolation.

Code: Select all

|sum:0:atomic:2:auto|

Code: Select all

diff graph_variables.php graph_variables.php.orig
85a86
>
228,231d228
<       }elseif ($regexp_match_array[2] == "atomic") {
<               if (!isset($summation_cache{$graph_item["local_data_id"]})) {
<                       $summation_cache{$graph_item["local_data_id"]} = bandwidth_summation($graph_item["local_data_id"], $summation_timespan_start, $graph_end, $rra_step, 1);
<               }
243c240
<       if ($regexp_match_array[2] == "current" or $regexp_match_array[2] == "atomic") {
---
>       if ($regexp_match_array[2] == "current") {

Code: Select all

diff rrd.php rrd.php.orig
735c735
<                       if (preg_match_all("/\|sum:(\d|auto):(current|total|atomic):(\d):(\d+|auto)\|/", $graph_variables[$field_name][$graph_item_id], $matches, PREG_SET_ORDER)) {
---
>                       if (preg_match_all("/\|sum:(\d|auto):(current|total):(\d):(\d+|auto)\|/", $graph_variables[$field_name][$graph_item_id], $matches, PREG_SET_ORDER)) {

[raX]

This looks like a good idea, but I don't completely understand its purpose. Can you give me a real world example of where you would want to use this functionality? The first thing that comes to my mind is GAUGE data source items which do not continuously increment. Even when using the 'atomic' summation type, the calculated sum will be affected by the data source steps (that is, the frequency of available samples).

Perhaps I am missing something .

-Ian

[Neptune]

The real world example I'm using it for is 5 minute samples of Gigabytes dowloaded in the past window (as calculated from usage records in a MySQL database).

So at 5 minutes - say 1000 bytes, 1000 total
10 minutes - say 2000 bytes, 3000 total
15 minutes - 1000 bytes, 4000 total
20 minutes - 3000 bytes, 7000 total
and so on


Note how in the modified code, the ds_step is set explicitly to 1 in the bandwidth_summation call when 'atomic' is called. That allows each sum to only reflect the each sample, not the integral of the period.

Now I may be missing the point if this functionality already exists, but I couldn't get it to work right as my sum's would always be 300-1000 times larger than I expected.

[raX]

It is pretty clear that this modification is useful in your situation. I wonder how often you get to graph something that updates exactly every five minutes though. Either way, I added your patch since the inclusion of this feature certainly won't hurt anything. I also made a note to myself to update the manual at some point so users know it's there.

-Ian

[Neptune]

Thanks, I think some more situations will emerge where it could be useful. Probably COUNTERS/GAUGES where you want to know "how many total ticks this period"

(Money saved this year, inches of rain this month, etc)

Anyway, thanks for adding it