The sky’s the limit when it comes to redefining Ceilometer.

Active contributor Ildiko Váncsa, OpenStack coordinator at Ericsson, analyzed Ceilometer’s past, present and future at the third OpenStack CEE Day. Váncsa has been at Ericsson for three years and a member of the cloud community for two years. In her time using OpenStack, Váncsa and her team have worked to revive Ceilometer.

She talks about where the project was going, how it got back on track and where your feedback is needed for future improvements. You can get involved with the Ceilometer weekly meetings or join the OpenStack-dev mailing list.

How do you see OpenStack and Ceilometer?

I joined the project late, more than two years ago, and wasn’t there when it started but when I first heard about it I read the developer documentation, and it stated that it was a billing support system. This was more than two years ago.

We had disagreements regarding the difference between metering and monitoring — and after attending the Design Summits we realized that the confusion was not only within Ericsson. When operators wanted to monitor the installation and everything else, problems arose because there weren’t any monitoring services within OpenStack.

It was still a missing component. People wanted to have all the items and needs covered under the OpenStack umbrella, so they started to use Ceilometer for monitoring, which wasn’t its intended use, but no one stopped them. So that’s how Ceilometer went in the wrong direction.



Váncsa at OpenStack CEE Day, photo courtesy Mándi Emese.

What’s being done to improve Ceilometer’s performance issues?

Even within the core team we didn’t have an agreement on what we wanted to do with this component in OpenStack, so we went with “Let’s make users happy.”

Giving Ceilometer multiple responsibilities had some effect on the architecture. We had many issues with the SQL (structured query language) back end. Our models were messed up so it slowed us down a lot, and after a certain amount of data it just timed out. After removing the API v1, which helped to get rid of some dependencies the performance got better and we even further improved it by optimizing the data model.

To solve some of the performance issues (in the Juno Cycle) we started to rethink the data storage layer. Time series database-as-a-service (a small project) – we are trying to change our persistence layer to Gnocchi because it serves our needs better. Users are able to try out Gnocchi as an experimental setup and we are hoping for good feedback.

Currently we are handling a huge amount of metadata stored along with the samples, which is not the most efficient way of handling this extra information. By introducing Gnocchi we have the possibility to optimize.

The separation of the timestamp value pairs and handling the metadata separately will hopefully help increase the performance. During the Vancouver Design Summit we agreed on moving towards a more modular architecture and splitting up the codebase into multiple repositories. We started with the alarming part in Liberty. We are also working on further improving the event support during this cycle.

How much has the code base changed over time?

Ceilometer was more extended as opposed to changed and rewritten, whereas Gnocchi was created from scratch and has its own API. This will be part of the version 3 API of Ceilometer. You still have the old Ceilometer with all the layers, as it was created. Gnocchi can be selected as the persistence layer.

Was Gnocchi developed to be a database back end?

Everyone felt we needed to do something. On one hand, we had to deal with this multiple responsibilities and on the other hand we had this performance problem — the time series database-as-a-service seemed to be a good direction to solve the problem.

Gnocchi will be the new heart of Ceilometer, but it can be used as a stand-alone component too. Currently, we do not really have the infrastructure to try it out on a bigger scale, so we’re fishing for feedback.

Cover Photo by

Thomas // CC BY

NC