Difference between revisions of "RichMeters"
m (Text replace - "__NOTOC__" to "") |
|||
| Line 1: | Line 1: | ||
| − | + | ||
The current Ceilometer meters have the following columns (with no defined indices beyond the primary keys on the denormalized tables) | The current Ceilometer meters have the following columns (with no defined indices beyond the primary keys on the denormalized tables) | ||
Latest revision as of 23:30, 17 February 2013
The current Ceilometer meters have the following columns (with no defined indices beyond the primary keys on the denormalized tables)
*source *user_id *project_id *resource_id *message_id counter_name counter_type counter_unit counter_volume timestamp resource_metadata
But for SLA/KPI measurements and effective debugging, we've found the following additional columns to be critical (and fully indexed):
*cell
*routing_key
*state
*old_state
*task
*publisher
*event
*service
*host
*request_id
Our first order of business would be to add this Meter type to Ceilometer and use it as a basis for backfilling the StackTach functionality.
The question is, should we extend the existing model to include tables for each of these other objects or keep the table denormalized but indexed? Or is this a separate/new data type?
It would be good to store the raw json payload as well for other groups to use (like a company's "analytics" group) ... they may want access to data that we don't find important yet. Dropping data prematurely is like serving a photo of a steak dinner.
