Cloned from launchpad blueprint https://blueprints.launchpad.net/ceilometer/+spec/record-sample-periodicity.

Description:

Currently we do not record the periodicity of samples, leaving that instead to be inferred from the pattern timestamps in the datapoints exposed via the API.

However in many cases the cadence of data acquisition is controlled by ceilometer, via the configured interval in the pipeline.yaml which controls the frequency at which polling occurs (notifications are a different mater, in this case the cadence is outside ceilometer's direct control and may not even be regular, e.g. for life-cycle related events).

It would be useful to record this periodicity directly in the sample data, where known. This would have at least two use-cases:

* detecting mismatches between sample cadence and the evaluation period configured for alarms,  e.g. a cpu_pipeline interval=600s and an alarm on cpu_util with period=60s will flap into the insufficient_data state for much of the time

* recognizing which data have been rolled up and to what granularity

The periodicity would be left unset for notification-derived samples, set from the outset for polling-driven samples, and then set for all data when rolled up.

Specification URL (additional information):

None