Open Stack

> > Would we have also have some 'misses' with the cumulative approach
> > when the ceilometer agent was down?
> 
> No, unless the counter resets several times while your agent is down.
> But delta has the same issue.
> 
> > If I understood the (\Sigma local maxima)-first idea correctly,
> > the usage up to the first polling cycle would always be
> > discounted from any duration.
> 
> No, because if you have:
> 
> Time | Value
> 0    | 10
> 1    | 30
> 2    | 50
> 3    | 80
> 4    | 100
> 
> If your delta-pollster is down at 1 and 2, you restart at 3,
> therefore
> at 4 you'll send "20" as usage (100 minus 80). So you miss the delta
> between 10 (time 0) and 80 (time 3) (therefore 70 for free!).
> If you send right away 80 at time 3 when restarting, the API will be
> able to guess that between 0 and 3 the value went from 10 to 80.
> With delta approach, the API cannot guess that.

Yep the sum of local maxima is not lossy as long as the requested
duration completely encapsulates the compute agent outage (and the
instance doesn't restart during the outage).

However I was more thinking of the scenario where the duration
requested  via the API is say t1..t4 in your example above.

In any case, do we need a new measurement type, in addition to the
existing CUMULATIVE type, that captures the non-monotonic nature of
the measure and alerts the API that special handling is required to
compute say max-min?

Something like TRANSIENT_CUMULATIVE, if that's not too much of a
mouthful.

> > A more pernicious problem would occur if the instance was being
> > regularly restarted with a higher frequency than the polling
> > period.
> 
> Yes, but in that case, whatever counting method you use, you're
> screwed.
> :)

True that.

Cheers,
Eoghan