Open Stack

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

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/> |  diego.parrilla at stackops.com<mailto:diego.parrilla at stackops.com> | +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 <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,


Maish Saidel-Keesing
Platform Architect
Cisco




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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150212/6ab6f222/attachment.html>