[openstack-dev] [Ceilometer] Simplifying the definition of Meters in Ceilometer

Sandy Walsh sandy.walsh at RACKSPACE.COM
Mon May 20 19:38:27 UTC 2013


Hey!

Currently all the Meters in Ceilometer are defined programmatically. That is, there is specific code in the product to define Meters for Nova, Glance, Quantum, etc. 

These are all outlined here:
http://docs.openstack.org/developer/ceilometer/measurements.html

Any time a new Metric is desired in Ceilometer a code change is required (and all the downstream ramifications of that). 

Some of these meters are populated via Ceilometer's Pollsters and some by processing Notifications, but the flow is the same:

1. Data comes in from somewhere (an Event)
2. Parts of the Event are extracted and a Meter record is populated
3. The Meters are persisted

A large portion of this Meter information is invariant (Meter name, type, units of measure, etc). The rest are essentially Traits/Metadata/Attributes on the Meter. Some attributes are required, but most are optional. 

I'd like to see these Meters defined via some form of configuration file. 

We should adopt the Oslo Notification as the incoming Event data format and then offer a generic way to extract the fields from this structure and stuff them into a Meter. Versioning for these events is underway already. Ceilometer could ship with a set of .conf files for each OpenStack component and we would only need to modify the Pollsters to spit out a Notification-like format.  

The configuration format could optionally point to a piece of code if complex parsing is required, but I'm sure 90% of the cases could be handled with simple drivers. 

Let's say an event looks like this:

Event 
{
'name' : 'Foo',
'generated': <datetime>,
'host': 'host_29',
'service': 'api'
'payload' : { ... specific stuff ... }
...
}


Our nova_meters.conf might be something like: 

event:
	'nova.compute.run_instance.end'

meter: compute.instances
type: counter
units: num
	
mapping:
	'payload.image.type' -> 'image_type'
	'payload.network.ip4 -> 'ip_address'
	...

parser:
	ceilometer.parser.dict_extractor # likely the default


It would probably even be possible to use a format that could auto-generate the docs for these Meters.

This could dramatically reduce the amount of code in Ceilometer today and greatly increase the ability for installers to customize it without code changes.

Thoughts?

-S



More information about the OpenStack-dev mailing list