Aggregation transformer sometimes produces incorrect values
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ceilometer |
Fix Released
|
Undecided
|
Dan Travis |
Bug Description
When chaining the aggregation transformer with the rate of change transformer, there appears to be a case where ceilometer will produce incorrectly transformed samples.
This issue was discovered while attempting to forward high rate data to an external system, while collecting aggregated data in Ceilometer's storage system. The attached pipeline.yaml below demonstrates this type of configuration.
This appears to occur due to the fact that the aggregation transformer uses the timestamp of the first sample received for a meter type rather than the last. Consider this test case (with an explanation in comments):
class AggregatorTrans
SAMPLE = sample.Sample(
name='cpu',
unit='ns',
)
def test_rate_
resource_id = ['1ca738a1-
aggregator = conversions.
sample_time = timeutils.
for offset in range(2):
sample = copy.copy(
"""
sample aggregated, but the timestamp from the first sample.
"""
for offset in range(2):
sample = copy.copy(
"""
resource, and one from our first resource.
"""
for sample in aggregated_samples:
if sample.resource_id == resource_id[0]:
"""
Given that for each sample the time was incremented by 1 second and
the volume was incremented by 1, you would expect a rate of change
of 1. However, the value 0.5 is calculated. This is because the
first aggregated point passed to the rate of change transformer
containted the timestamp from the first point and the value from the
second. This effected the time delta used in the rate of change
"""
I believe there's a fairly straightforward resolution to this. Basically, add an additional parameter to the constructor to allow the user to selectively include the timestamp from either the first or last sample provided to the aggregation transformer.
Fix proposed to branch: master /review. openstack. org/273672
Review: https:/