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

Bug #988702 reported by Clayton Bell
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Graphite
Fix Released
Undecided
Unassigned

Bug Description

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.

Revision history for this message
Clayton Bell (clayton-bell) wrote :
Revision history for this message
Michael Leinartas (mleinartas) wrote :

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).

Revision history for this message
Michael Leinartas (mleinartas) wrote :

Thanks for the detailed bug report. Fix committed in r773

Changed in graphite:
milestone: none → 0.9.10
status: New → Fix Committed
Changed in graphite:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.