[Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested
sandy.walsh at RACKSPACE.COM
Thu Feb 12 18:41:16 UTC 2015
Yagi  is a really easy way to consume notifications and do stuff with them. We use it as the basis for our STv3 consumption.
Very easy to write a Handler (fill in the handle_events() method) and you're off to the races.
Yagi has a proper worker than can be daemonized and flexible logging. Spawn many for larger loads.
Even easier, but not as battle tested, is notabene  ... here's an example of what it takes to consume notifications 
From: Clint Byrum [clint at fewbar.com]
Sent: Thursday, February 12, 2015 2:28 PM
Subject: Re: [Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested
Excerpts from George Shuklin's message of 2015-02-11 17:59:02 -0800:
> Ceilometer is in sad state.
> 1. Collector leaks memory. We ran it on same host with mongo, and it
> grab 29Gb out of 32, leaving mongo with less than gig memory available.
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.
You would need a more advanced AMQP plugin that understands how to turn
the notifications in OpenStack into collectd values, and then make some
decisions on whether to keep Ceilometer's SQL/MongoDB backend or just
teach Ceilometer to read from the various collectd output formats. I
think the latter will be a bigger win, but the former would be easier
for a more incremental migration.
Anyway, if people are interested in "saving" Ceilometer from being a
bit sluggish, that seems like a good first step in the investigation.
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org
More information about the OpenStack-operators