Bug 1042338

Summary: [RFE][ceilometer]: Support storing the entire event body.
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/ceilometer/+spec/event-body
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_obsolete
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:23:08 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:48:07 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/ceilometer/+spec/event-body.

Description:

Reference Branch: https://github.com/ramielrowe/ceilometer/tree/event_body

In our experiences with Stacktach, we've found it extremely valuable to store the entire event body so that new datapoints and metrics can be rolled up after the fact. This feature would allow the storing of the entire event body in Ceilometer's database. In Stacktach, event bodies are stored as single JSON strings. Due to that it makes building new metrics a very slow and painful process of selecting large subsets of events, parsing the json to a dictionary and the grabbing the data needed. A better solution would allow the indexed searching of these bodies without too much complexity.

This feature would introduce a new api model called EventBody containing two fields, the event, and the event's body as a dictionary. The reference branch above outlines the beginnings of a SQLAlchemy implementation. In SQLAlchemy, EventBodies are made up of EventBodyEntries. Each entry has four fields, the event, a key (UniqueName), index (Text), and value (Text).

Sample Dictionary with it's corresponding EventBodyEntries:
https://gist.github.com/ramielrowe/6041427

With that model it would be relatively simple to search for and grab all events where 'payload.image_meta.os_type' is 'windows' or 'linux' and add an os_type field to them. Due to the index field, no data is lost about the structure of the body and the dictionary can be rebuilt if the full body is required.

Another thing to note is that EventBodies are not made up of Traits. Traits are values of known types for which we currently see as useful. The EventBodies are made of of values of unknown type and for which we currently don't have a use for. The importance of keeping these values around is so that when a new use is discovered, we can generate that trait for past data.

Specification URL (additional information):

None