This PR rewrites the smartSummarize function in order to correct two issues that were discovered (similar to the recent fix to hitcount, see #132).
When the interval parameter was set to a value smaller than the fetched data's step between data points, it results were incorrect. The results were a copy of the data points for each series in the list. For example:
smartSummarize(metric1,'6m','sum', 'minutes')
[]*types.MetricData{{"metric1", 0, 1}: {types.MakeMetricData("metric1", []float64{2, 4, 6}, 600, 0)},} // 10m step
The result will be []float64{2, 4, 6}. Issuing the same query with the same data in Graphite-web yielded results of [2, 4, None, 6, None]. This is due to the interval being smaller than the step, and therefore some resulting values will be NaN.
Additionally, in Graphite-web's implement of smartSummarize, the start time of the request is adjusted based on the alignTo value, and the data is re-fetched. In CarbonAPI, the start time was adjusted, but data was not re-fetched.
Major changes in this PR:
The smartSummarize function was completely rewritten to match the behavior of Graphite web, as well as adding some optimizations in the algorithm. This helps address the issue with intervals smaller than the data's step, as well as fixes discrepancies in results that were occurring with CarbonAPI tests that were tested in Graphite web.
The Metrics() function in pkg/parser.go was updated to adjust the start time of a metric request with a target of smartSummarize, so that the start time reflects the alignTo parameter's value. This is intended to prevent needing to re-fetch the data during smartSummarize function execution as is done in Graphite web. Additionally, previously, only 'minutes', 'hours', and 'days' was supported, so support was extended for seconds, weeks, months and years.
More testcases were added, including ones that cover the situation where the specific interval is smaller than the fetched data's step, as well as test cases translated from Graphite web for smartSummarize.
This PR rewrites the smartSummarize function in order to correct two issues that were discovered (similar to the recent fix to hitcount, see #132).
When the interval parameter was set to a value smaller than the fetched data's step between data points, it results were incorrect. The results were a copy of the data points for each series in the list. For example: smartSummarize(metric1,'6m','sum', 'minutes') []*types.MetricData{{"metric1", 0, 1}: {types.MakeMetricData("metric1", []float64{2, 4, 6}, 600, 0)},} // 10m step
The result will be []float64{2, 4, 6}. Issuing the same query with the same data in Graphite-web yielded results of [2, 4, None, 6, None]. This is due to the interval being smaller than the step, and therefore some resulting values will be NaN.
Additionally, in Graphite-web's implement of smartSummarize, the start time of the request is adjusted based on the alignTo value, and the data is re-fetched. In CarbonAPI, the start time was adjusted, but data was not re-fetched.
Major changes in this PR:
The smartSummarize function was completely rewritten to match the behavior of Graphite web, as well as adding some optimizations in the algorithm. This helps address the issue with intervals smaller than the data's step, as well as fixes discrepancies in results that were occurring with CarbonAPI tests that were tested in Graphite web.
The Metrics() function in pkg/parser.go was updated to adjust the start time of a metric request with a target of smartSummarize, so that the start time reflects the alignTo parameter's value. This is intended to prevent needing to re-fetch the data during smartSummarize function execution as is done in Graphite web. Additionally, previously, only 'minutes', 'hours', and 'days' was supported, so support was extended for seconds, weeks, months and years.
More testcases were added, including ones that cover the situation where the specific interval is smaller than the fetched data's step, as well as test cases translated from Graphite web for smartSummarize.