[Openstack-operators] [openstack-dev] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested
gordon chung
gord at live.ca
Tue Mar 10 20:34:15 UTC 2015
sorry, i apparently don't know how to format emails...
cheers,
gord
From: gord at live.ca
To: openstack-operators at lists.openstack.org; openstack-dev at lists.openstack.org
Date: Tue, 10 Mar 2015 16:05:47 -0400
Subject: Re: [openstack-dev] [Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested
hi,
just to follow-up, thanks for the input, the usability of ceilometer is obviously a concern of ours and something the team tries to address with the resources we have.
as a quick help/update, here are some points of interests that i think might help:- if using Juno+, DO use the notifier:// publisher rather than rpc:// as there is a certain level of overhead that comes with rpc[1]. you can also configure multiple messaging servers if there are load issues.- a part of the telemetry team has been exploring tsdb and we expect to have a tech preview for Kilo. the project is called Gnocchi[2]- in Kilo, we expanded notification event handling (existing stacktach integration code) and said events can be published to an external source(s) or to a database (ElasticSearch for full-text querying, in addition to mongo, sql)- ceilometer does not configure databases. operators are expected to read up on the db of choice and properly configure db to their needs (ie. don't run default mongo install on a single node with no sharding to store data from 2000 nodes)[3]- DO adjust your pipeline to only store events/meters that you use. by default, ceilometer gives you the world and from there you can filter based on requirements.- it's entirely possible to use ceilometer to gather data and store it externally and avoid ceilometer storage (if you so choose)- DO NOT use SQL backend prior to Juno... for any deployment size... any...- there was some work in Kilo to jitter polling cycle of agents to distribute load.- the agents are designed to scale horizontally to increase bandwidth. also, they work independently so if you want just notifications, it's possible to just deploy the notification agent and nothing else.
we've also been updating -- and still continuing to update -- some of the docs to better reflect some of the changes made to Ceilometer in Juno and Kilo[4][5]. particularly, i'd probably look at the architecture diagram[6] to get an idea of what components of ceilometer you could use to fit your needs.
i'm probably missed stuff but i hope the above helps. as always, community help is always invited. if you have a patch that will improve ceilometer, the community gladly welcomes it.
[1] https://www.rabbitmq.com/tutorials/tutorial-six-python.html[2] http://www.slideshare.net/EoghanGlynn/rdo-hangout-on-gnocchi [3] http://blog.sileht.net/using-a-shardingreplicaset-mongodb-with-ceilometer[4] http://docs.openstack.org/admin-guide-cloud/content/ch_admin-openstack-telemetry.html[5] http://docs.openstack.org/developer/ceilometer/[6] http://docs.openstack.org/developer/ceilometer/architecture.html (self-plug for my amazing diagram skills)
cheers,
gord
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150310/e8d12396/attachment.html>
More information about the OpenStack-operators
mailing list