Open Stack

We've been working with Ceilometer since Grizzly and our experience has been positive, albeit with a couple of caveats.  Our product, OpenBook, depends upon Ceilometer for the metering data to drive rating and billing.  As with most things in OpenStack today, we've taken advantage of what Ceilometer does well and been able to work around those things that could use some improvement.  What Ceilometer does very well is be a funnel for provisioning, state change and consumption data from OpenStack.  We would not have been able to make the progress we did with our solution if Ceilometer didn't exist as a data provider within OpenStack.  What it doesn't do very well today is be a scalable long-term repository of raw and aggregated data.  In our case, we already had a model where we collected data from multiple sources, and normalized and aggregated this data before storing it locally, so this shortcoming didn't present a problem for us.  So, YMMV depending on your use case, but for us and our customers, Ceilometer gets the job done.

--Sanjay

-----Original Message-----
From: Allamaraju, Subbu [mailto:subbu at subbu.org] 
Sent: Monday, February 16, 2015 4:47 PM
To: Chris Dent
Cc: openstack-operators
Subject: Re: [Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested

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-operator
> s


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators