Summarize incorrectly scales X-axis hence invalidating other series' X-axis alignment

[Clayton Bell]

Overview:

Adding a summarize() series causes the X-asix to scale slightly, however the other series in the graph are not scaled by the same amount. This causes the existing series' to be displayed incorrectly along the X-axis.

How to reproduce the issue:

1. Send a few sample data points at 1 hour intervals

test.data 1 1335416400
test.data 1 1335412800
test.data 1 1335409200
test.data 1 1335405600
test.data 1 1335402000
test.data 1 1335398400

Note that the whisper data files are stored @ 1 minute resolution.
The above test data has 3600 seconds (1 hour) between each sample point.

2. Display the data in the web UI using the following target name

/render/?&from=06%3A00_20120426&yMin=0&lineMode=staircase&areaMode=first&until=16%3A30_20120426&lineWidth=2&target=test.data

Note that the events occur exactly aligned on the hour. See graphite-summarize-steps2+3.png top graph.

3. Now add a summarize(test.data,"30min","sum") to the graph so that you have the original data and the summarized version

For reference, use the following URL in the web UI

/render/?&from=06%3A00_20120426&yMin=0&lineMode=staircase&areaMode=first&until=16%3A30_20120426&lineWidth=2&target=test.data&target=summarize(test.data%2C"30min"%2C"sum")

Note that the first series (the un-summarized data) no longer aligns correctly on the hour. See graphite-summarize-steps2+3.png bottom graph.

We are using graphite 0.9.9 on Centos 6.2.

[Michael Leinartas (mleinartas)]

Ugh, this bug was a pain to figure out. It had to do with the way staircase mode works - staircase mode adds an additional point to the width of the graph, the time-length of the point determined by the largest step (in this case 30 min). Since this additional point for the largest step series is multiple points for the smaller steps (30 in this case), the number of seconds per pixel for these series needs to take into account the extra points added on (which dont actually exist in the series). Without taking these into account, the number of seconds per pixel is too large, causing the lines drawn to be more and more shifted as the graph is drawn.

Previously the seconds per pixel was calculated by dividing the number of pixels by the length of the series. Dividing instead by (total timerange / series step) instead gives identical results for non-staircase mode graphs, and fixes the alignment problem for this case.

One note: the whole point of this extra point drawn on the graph is so that the last point gets a flat surface exposed just like the others (rather than sitting on top of the end of the x-axis gridlines and being somewhat hidden). This implementation shifts the graph enough for the 'stair' for the largest step to be drawn fully (a 30 minute wide line in this case). This means however that the smaller steps will stop being drawn before the end of the graph (though accurately).

[Michael Leinartas (mleinartas)]

Thanks for the detailed bug report. Fix committed in r773