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