Ceilometer updates from PTL, Eoghan Glynn.

1. Eoghan Glynn
Ceilometer PTL
OpenStack Telemetry
Kilo Update
1
IRC: eglynn

2. To reliably collect measurements of the utilization of
physical & virtual resources comprising deployed clouds,
persist these data for subsequent retrieval & analysis,
and trigger actions when defined criteria are met.
2
Our Mission ...

3. Priorities and themes for Kilo
● Completion of Time Series Data as a Service
(gnocchi) and migration of ceilometer
● Provide the right kind of test coverage
● More flexible role/tenant segregation
● Contractualized service notifications
● Deployment flexibility
● Event processing improvements
● Collaboration with Monasca
3

4. Time Series Data as a Service …
[recap]
● Goal is to provide efficient metrics storage
○ shorn of snapshot’d resource metadata (as previously
maintained by ceilometer)
○ eagerly pre-aggregated (contrast with on-demand)
● Initial implementation in stackforge/gnocchi
● Envisaged as multi-cycle effort over Juno & Kilo
● Canonical analytics and storage engine provided
via pandas and swift
● Alternative storage drivers based on metrics-oriented
DBs such as InfluxDB & OpenTSDB
4

5. Time Series Data as a Service …
[status]
● Completed:
○ core metrics and resources API
○ pandas+swift storage driver
○ policy-based aggregation/roll-up model
○ API-based dispatch from the ceilometer collector
○ keystone integration (auth & RBAC policies)
● In-progress:
○ storage drivers based on OpenTSDB and InfluxDB
○ custom aggregation - moving average & Holt-Winters
○ cross-entity aggregation
○ optimized direct dispatch model from ceilometer
5

6. Time Series Data as a Service …
[planned for kilo]
● Planned further work for Kilo:
○ recasting ceilometer v2 query API over gnocchi
semantics
○ rebasing ceilometer alarm evaluation on the v3 metrics
API
○ migration of pre-existing metering datastores built up
with classic ceilometer
○ detailed profiling of performance benefit
6

7. Parallel efforts
● The right kind of testing
○ in-tree functional tests
○ declarative HTTP API
○ Rally-based scenario tests
● Richer configuration of tenant/role segregation
○ previously all or nothing for admin versus non-admin
○ adding support for fine-grained RBAC policies
○ leveraging v3 keystone domains in the longer term
● Deployment flexibility
○ merged central and compute agent
○ centralized storage of the pipeline configuration
○ true declarative SNMP metric-gathering
7

8. Parallel efforts
● Contractualize service notifications
○ essentially free-form dicts currently
○ joint effort with the Stacktach project to schematize
○ provide the stable basis for an API-like contract
● Events pipeline
○ split off events database
○ coordination between scaled out notification agents
● Collaboration with Monasca
○ anomaly detection component
8

9. Questions?
Feel free to reach out anytime …
project channel: #openstack-ceilometer
eglynn @freenode (GMT timezone)
weekly meeting 1500UTC on Thursday
mailing list: openstack-dev@openstack.org
9