Difference between revisions of "Ceilometer/blueprints/multi-dimensions"
Line 2: | Line 2: | ||
* '''Launchpad Entry''': tbd | * '''Launchpad Entry''': tbd | ||
* '''Created''': 27 Nov 2012 | * '''Created''': 27 Nov 2012 | ||
− | * '''Contributors''': Nick Barcet | + | * '''Contributors''': Nick Barcet& Julien Danjou |
== Summary == | == Summary == | ||
− | |||
In order to be able to perform smart and fast aggregation in the API, we need to be able to perform queries that would aggregate counters based on additional keypair values than the simple tenant/user/ressource triplet. This spec proposes to handle meta data in a new and different way that would allow to solve this. | In order to be able to perform smart and fast aggregation in the API, we need to be able to perform queries that would aggregate counters based on additional keypair values than the simple tenant/user/ressource triplet. This spec proposes to handle meta data in a new and different way that would allow to solve this. | ||
== Release Note == | == Release Note == | ||
− | |||
It is now possible to request aggregated value based on additional "dimensions" for each counters/meters in Ceilometer | It is now possible to request aggregated value based on additional "dimensions" for each counters/meters in Ceilometer | ||
== User stories == | == User stories == | ||
− | |||
* John would like to retrieve the aggregated number of objects accross all of his containers named xxx | * John would like to retrieve the aggregated number of objects accross all of his containers named xxx | ||
* Peter would like to know his average cpu usage for all instance type yyyy | * Peter would like to know his average cpu usage for all instance type yyyy | ||
+ | * Andrew would like to retrieve max value of cpu usage for a list of instance-ids | ||
== Assumptions == | == Assumptions == | ||
− | + | * We assume here that the way metadata have been used so has a majority of keypairs at first level in the json, and that this will constitute our future dimensions | |
− | * We assume here that the way metadata have been used so | ||
− | |||
== Design == | == Design == | ||
− | |||
This blueprint assumes 3 changes: | This blueprint assumes 3 changes: | ||
=== 1. Switching from meta-data to dimensions === | === 1. Switching from meta-data to dimensions === | ||
− | The proposal is to | + | The proposal is to assume in the current json formated meta data that all first leve keypairs in the form of <string>:<string> are what we need to consider as dimensions. |
− | |||
− | |||
− | |||
− | |||
=== 2. Adding dimension filters to the API === | === 2. Adding dimension filters to the API === | ||
+ | Each meters related API call would have one additional optional parameter which is a nested conditional expresion o: | ||
− | + | * dimensions -- Nested condition on keypairs as ( (("key1"="value1") & ("key2"="valueN")) | (("key1"="value3") & ("key2"="value4")) ) | |
− | * dimensions -- | ||
− | Which would allow to | + | Which would allow to |
=== 3. Adding an average function === | === 3. Adding an average function === | ||
+ | The following API calls would be added to the API | ||
− | |||
* GET /v1/projects/(project)/meters/(meter)/volume/average | * GET /v1/projects/(project)/meters/(meter)/volume/average | ||
* GET /v1/resources/(project)/meters/(meter)/volume/average | * GET /v1/resources/(project)/meters/(meter)/volume/average | ||
== Implementation == | == Implementation == | ||
− | |||
=== Strorage design === | === Strorage design === | ||
− | |||
In the case of a relational database storage engine, the dimensions would be stored in a separate table as follow | In the case of a relational database storage engine, the dimensions would be stored in a separate table as follow | ||
Line 59: | Line 48: | ||
| EventID |N-----1| EvenID | | | EventID |N-----1| EvenID | | ||
| Key | | ResourceID | | | Key | | ResourceID | | ||
− | | Value | | ..... | | + | | Value | | ..... | |
+------------+ | ..... | | +------------+ | ..... | | ||
</nowiki></pre> | </nowiki></pre> | ||
− | |||
=== Code Changes === | === Code Changes === | ||
− | |||
TBD | TBD | ||
=== Migration === | === Migration === | ||
− | |||
If we decide to modify the structure of the existing meta-data, we need to provide a procedure to translate existing meta-data information to the new format. | If we decide to modify the structure of the existing meta-data, we need to provide a procedure to translate existing meta-data information to the new format. | ||
== Test/Demo Plan == | == Test/Demo Plan == | ||
− | |||
This need not be added or completed until the specification is nearing beta. | This need not be added or completed until the specification is nearing beta. | ||
== Unresolved issues == | == Unresolved issues == | ||
− | |||
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. | This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. | ||
== BoF agenda and discussion == | == BoF agenda and discussion == | ||
− | |||
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. | Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. | ||
---- | ---- | ||
[[Category:Spec]] | [[Category:Spec]] |
Revision as of 15:53, 27 November 2012
- Launchpad Entry: tbd
- Created: 27 Nov 2012
- Contributors: Nick Barcet& Julien Danjou
Summary
In order to be able to perform smart and fast aggregation in the API, we need to be able to perform queries that would aggregate counters based on additional keypair values than the simple tenant/user/ressource triplet. This spec proposes to handle meta data in a new and different way that would allow to solve this.
Release Note
It is now possible to request aggregated value based on additional "dimensions" for each counters/meters in Ceilometer
User stories
- John would like to retrieve the aggregated number of objects accross all of his containers named xxx
- Peter would like to know his average cpu usage for all instance type yyyy
- Andrew would like to retrieve max value of cpu usage for a list of instance-ids
Assumptions
- We assume here that the way metadata have been used so has a majority of keypairs at first level in the json, and that this will constitute our future dimensions
Design
This blueprint assumes 3 changes:
1. Switching from meta-data to dimensions
The proposal is to assume in the current json formated meta data that all first leve keypairs in the form of <string>:<string> are what we need to consider as dimensions.
2. Adding dimension filters to the API
Each meters related API call would have one additional optional parameter which is a nested conditional expresion o:
- dimensions -- Nested condition on keypairs as ( (("key1"="value1") & ("key2"="valueN")) | (("key1"="value3") & ("key2"="value4")) )
Which would allow to
3. Adding an average function
The following API calls would be added to the API
- GET /v1/projects/(project)/meters/(meter)/volume/average
- GET /v1/resources/(project)/meters/(meter)/volume/average
Implementation
Strorage design
In the case of a relational database storage engine, the dimensions would be stored in a separate table as follow
+------------+ +------------+ | Dimensions | | Event | +------------+ +------------+ | EventID |N-----1| EvenID | | Key | | ResourceID | | Value | | ..... | +------------+ | ..... |
Code Changes
TBD
Migration
If we decide to modify the structure of the existing meta-data, we need to provide a procedure to translate existing meta-data information to the new format.
Test/Demo Plan
This need not be added or completed until the specification is nearing beta.
Unresolved issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.