[openstack-dev] [metering] [ceilometer] Multi dimension indexing query syntax

Angus Salkeld asalkeld at redhat.com
Sun Dec 2 11:49:05 UTC 2012

On 01/12/12 16:16 +0100, guillaume pernot wrote:
>https://blueprints.launchpad.net/ceilometer/+spec/multi-dimensions , I
>would like to share my thoughts about a DAP-inspired syntax for queries.
>Data Access Protocol
>defines a way to build quite versatile queries. Its general form is
>`q=<projection>&<selection>`, where <projection> is a coma-separated
>list of wanted meters (possibly aggregated with sum(), max(), count(),
>etc...), and <selection> is an &-separated list of conditions.
> ?q=instance.id&instance.cpu_util>=0.95 : return instances that have a cpu-load superior to 0.95 (eg : red alert)
> ?q=instance.name,instance.cpu_util&instance.cpu_util>=0.85&instance.cpu_util<0.95 }}}: return (instance name, cpu load) for instances where cpu load is between 0.85 and 0.95 (eg : orange warning)
> ?q=instance.id,sqrt(instance.cpu_util) : return (id, square root of cpu load) for each instance (per-element computation). yeah, sqrt(cpu_util) is not really meaningful...
> ?q=avg(instance.cpu_util)?instance.name~=foo.* : return the average cpu load of all instances that name matches regexp "foo.*" (aggregation)
>From the blueprint use cases :
> John should query : ?q=sum(container.objects)&container.name=xxx
> Peter should query : ?q=sum(instance.cpu)&instance.type=yyyy
> Andrew should query : ?q=max(instance.cpu)&instance.id={17,42,128}
> - mongodb knows how to handle this efficiently, taking the best out of map/reduce
> - selective : users query is as much selective as possible (limiting client-side post-processing)
> - versatile : a wide range of computations/selections can be performed this way
> - increased implementation complexity
> - maybe overkill

I have implemented in this style, just not the selection part and I currently only
have support for "=" at the moment, but what you have there looks like a neat extension.

Our current API will look like this:

To totally embrace this might mean waiting until the v2 api.


We will have to see how the other developers like it.

>my 2cts,
>guillaume pernot
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list