Ceilometer

Add Reporting Capabilities to Ceilometer

Registered by Thomas Maddox

As part of StackTach integration, Ceilometer should have a similar feature to StackTach's reporting, where we can leverage the stored event and sample data to summarize the event stream we're monitoring. Things like Nova operation failures, state transition timings, etc. should be summarized and reported on to provide operators more insight into the health of their cloud, as well as problem areas to focus on (especially helpful when contributing back to OpenStack).

The reporting capability needs to be easily extendable, which seems handled well by the trigger manager and event pipelines to come. We will be able to summarize as we go and keep the report piece itself pretty thin. For example, instead of the report determining a failed build like it currently does in StackTach, we can instead just trigger a instance.build.failed event or sample when the event stream processing finds that a build has failed. Then, in the report, we can just count the number of failed builds and successful builds to report on build failure percentage.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
Thomas Maddox
Direction:
Needs approval
Assignee:
Thomas Maddox
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
gordon chung

Related branches

Sprints

Whiteboard

(thomas) Depending on how we set up the trigger and event definitions, we could get information like which task operations most commonly fail at. We could also get the timing at each state/task transition for a given operation and see where development (contributing to OpenStack) ought to work to collapse operation times, by targeting the most expensive tasks. Seems VERY powerful to automate for a CI work stream.

(thomas)
1. service (ceilometer-reporter?)
2. storage (event/trait) - impl_sqlalchemy.Connection.store_report(...)
4. report models (just need a summary table model, really; should be generic enough that we don't need anything more specific, just a model that represents columns (headings), rows, and a footer row with summary info)
5. generator (pulls from DB and calls models.from_json(...))
6. template (uses given report model to make a report section, depending on requested format
7. expose via API
    a. http://localhost:8777/v2/report?period_start=<period_start>&period_end=<period_end>&created=<created_date>
    b. http://localhost:8777/v2/report/<report-slug>?period_start=<period_start>&period_end=<period_end>&created=<created_date>&format=[html, xml, json]
8. E-mail delivery? Marconi?

reporting is probably outside the scope of ceilometer. marking obsolete as the original integration was abandoned by RAX... we can look to hook up current implementation with atom hopper solution -- gordc (17.6.15)

(?)

Work Items

Work items:
Service: TODO
Storage: TODO
Report Models: TODO
Report Generator: TODO
Template: TODO
Expose via API: TODO

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.