Open Stack

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.

Subbu

> 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
> 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
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators