[Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested

Chris Dent chdent at redhat.com
Mon Feb 16 12:40:47 UTC 2015


On Thu, 12 Feb 2015, Clint Byrum wrote:

> I wonder how hard it would be to push Ceilometer down the road of being
> an OpenStack shim for collectd instead of a full implementation. This
> would make the problem above go away, as collectd is written in C and is
> well known to be highly optimized for exactly this type of workload.

I think this otherwise interesting idea jumps the gun a bit in a few
different ways.

* We first need to identify what people are actually hoping to do with
   Ceilometer or something like it. In this thread alone we've got talk
   of metering, billing, rating, monitoring, alarming/auto-scaling
   without any of those terms being very well defined. It's obvious
   that any one service is not going to be able to do all of those things
   well but it is not obvious how, without defining the terms, we
   can figure out how to do some small number of them well.

* We also need to identify the parts of Ceilometer that are uniquely
   useful. That is what parts of it are not otherwise covered by
   existing tools that have an associated healthy opensource ecosystem.
   I'm not really sure the answer to this but to toss out some ideas:
   The things that Ceilometer has that make it special are the polling
   and notification agents and the associated pipeline. These are the
   parts that gather and transform events and meters that are unique to
   the openstack environment.

   (Curiously the gatherers are also the parts of Ceilometer that I think
   should be in the repos of other projects as plugins which generate
   notifications but that's a different topic.)

Gnocchi is very interesting because it follows what has become a time
honored style in OpenStack: Create an abstraction layer over a
relatively small area of purpose and provide an easy to replace default
driver. It also does this in a context that is independent from
Ceilometer.

This could get us a few things:

* An improvable storage and reporting backend for Ceilometer that can
   evolve separately from Ceilometer.
* A way to shrink Ceilometer itself so that it can become more
   narrowly focused on whatever its core purpose is defined to be.
   This is not that complex of a task: Ceilometer is already structured
   such that it is quite straightforward to send the results of the
   pipeline wherever we like. Gnocchi is one such destination.

But again: We first need to figure out what people actually want to do
and care about.
-- 
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent



More information about the OpenStack-operators mailing list