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?). ____________________________________________ Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. From: Diego Parrilla Santamaría <[email protected]<mailto:[email protected]>> Date: Thursday, February 12, 2015 at 10:23 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: OpenStack Development Mailing List <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested Hi Mash, 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. Cheers Diego -- Diego Parrilla <http://www.stackops.com/>CEO www.stackops.com<http://www.stackops.com/> | [email protected]<mailto:[email protected]> | +34 91 005-2164 | skype:diegoparrilla [http://stackops.s3-external-3.amazonaws.com/STACKOPSLOGO-ICON.png] On Wed, Feb 11, 2015 at 8:37 PM, Maish Saidel-Keesing <[email protected]<mailto:[email protected]>> 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, Maish Saidel-Keesing Platform Architect Cisco _______________________________________________ OpenStack-operators mailing list [email protected]<mailto:[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
