[Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested
Kris G. Lindgren
klindgren at godaddy.com
Thu Feb 12 18:04:01 UTC 2015
We have also dropped ceilometer.
Between the load that it generated on the API's. Was causing nova queries to take over 30 seconds and time outs - because they were all backing up on neutron trying to get vm netowrk info. Also, the fact that a simple meter list resulted in 100% cpu usage of both ceilometer and the ceilometer-client and took over a minute to return any data. In the end, it was simply unusable for people to integrate with.
Though we are considering re-enabling it for the notifications -> kafka portion only. I think like others before, we ended up gathering the meteric-stuff outside of openstack, we used diamond -> graphite. Though in the future we might switch from graphite to something else (opentsdb?).
Senior Linux Systems Engineer
From: Diego Parrilla Santamaría <diego.parrilla.santamaria at gmail.com<mailto:diego.parrilla.santamaria at gmail.com>>
Date: Thursday, February 12, 2015 at 10:23 AM
To: "maishsk+openstack at maishsk.com<mailto:maishsk+openstack at maishsk.com>" <maishsk+openstack at maishsk.com<mailto:maishsk+openstack at maishsk.com>>
Cc: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: Re: [Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested
we dropped Ceilometer as the core tool to gather metrics for our rating and billing system. I must admit it has improved, but I think it's broken by design: a metering and monitoring system is not the same thing.
We have built a component that directly listens from rabbit notification tools (a-la-Stacktach). This tool stores the all events in a database (but anything could work, it's just a logging system) and then we process these events and store them in a datamart style database every hour. The rating and billing system reads this database and process it every hour too. We decided to implement this pipeline processing of data because we knew in advance that processing such an amount of data was a challenge.
I think Ceilometer should be used just to trigger alarms for heat for example, and something else should be used for rating and billing.
www.stackops.com<http://www.stackops.com/> | diego.parrilla at stackops.com<mailto:diego.parrilla at stackops.com> | +34 91 005-2164 | skype:diegoparrilla
On Wed, Feb 11, 2015 at 8:37 PM, Maish Saidel-Keesing <maishsk at maishsk.com<mailto:maishsk at maishsk.com>> wrote:
Is Ceilometer ready for prime time?
I would be interested in hearing from people who have deployed OpenStack clouds with Ceilometer, and their experience. Some of the topics I am looking for feedback on are:
- Database Size
- MongoDB management, Sharding, replica sets etc.
- Replication strategies
- Database backup/restore
- Overall useability
- Gripes, pains and problems (things to look out for)
- Possible replacements for Ceilometer that you have used instead
If you are willing to share - I am sure it will be beneficial to the whole community.
Thanks in Advance
With best regards,
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators