[Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested
subbu at subbu.org
Mon Feb 16 22:46:40 UTC 2015
You bring up a very good point. What are the parts that are uniquely useful? Here are two key reasons why we chose to bite the bullet and operationalize Ceilometer at work:
1. Stable set of APIs for tenants to access and publish metrics and alarms
2. An unobtrusive way for providers to collect metrics of tenant resources
There are a ton of tools out there to gather metrics, to store, to process, to raise alarms etc. However, without stable set of interfaces, it is tough to build large ecosystems.
My 2 cents.
> On Feb 16, 2015, at 4:40 AM, Chris Dent <chdent at redhat.com> wrote:
> 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
> 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
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
More information about the OpenStack-operators