Bug 1042272

Summary:	[RFE][ceilometer]: Record the periodicity of sample data where known
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	RFEs	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	markmc, yeylon
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/ceilometer/+spec/record-sample-periodicity
Whiteboard:	upstream_milestone_none upstream_status_not-started upstream_definition_superseded
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-19 17:29:13 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description RHOS Integration 2013-12-12 21:36:11 UTC

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