openstack/ceilometer
Code Issues Proposed changes

Merge "move and trim legacy db docs"

Browse Source
This commit is contained in:
Jenkins 2017-01-26 09:15:50 +00:00 committed by Gerrit Code Review
commit 05f4d1b041
1 changed files with 36 additions and 50 deletions

86
doc/source/install/dbreco.rst

@ -19,54 +19,6 @@
Choosing a database backend
============================
.. note::
Ceilometer's native database capabilities is intended for post processing
and auditing purposes where responsiveness is not a requirement. It
captures the full fidelity of each datapoint and thus is not designed
for low latency use cases. For more responsive use cases, it's recommended
to store data in an alternative source such as Gnocchi_. Please see
`Moving from Ceilometer to Gnocchi`_ to find more information.
.. note::
As of Liberty, alarming support, and subsequently its database, is handled
by Aodh_.
.. _Aodh: http://docs.openstack.org/developer/aodh/
Selecting a database backend for Ceilometer should not be done lightly for
numerous reasons:
1. Not all backend drivers are equally implemented and tested. To help you
make your choice, the table below will give you some idea of the
status of each of the drivers available in trunk. Note that we do welcome
patches to improve completeness and quality of drivers.
2. It may not be a good idea to use the same host as another database as
Ceilometer can generate a LOT OF WRITES. For this reason it is generally
recommended, if the deployment is targeting going into production, to use
a dedicated host, or at least a VM which will be migratable to another
physical host if needed. The following spreadsheet can help you get an
idea of the volumes that ceilometer can generate:
`Google spreadsheet <https://docs.google.com/a/enovance.com/spreadsheet/ccc?key=0AtziNGvs-uPudDhRbEJJOHFXV3d0ZGc1WE9NLTVPX0E#gid=0>`_
3. If you are relying on this backend to bill customers, you will note that
your capacity to generate revenue is very much linked to its reliability,
which seems to be a factor dear to many managers.
The following is a table indicating the status of each database drivers:
================== ============================= ===========================================
Driver API querying API statistics
================== ============================= ===========================================
MongoDB Yes Yes
MySQL Yes Yes
PostgreSQL Yes Yes
HBase Yes Yes, except groupby & selectable aggregates
================== ============================= ===========================================
Moving from Ceilometer to Gnocchi
=================================
@ -105,7 +57,41 @@ Example of configuration::
project_id = <ceilometer_project_id>
endpoint = <gnocchi_endpoint>
.. _Gnocchi: http://gnocchi.xyz
.. _here: https://docs.google.com/presentation/d/1PefouoeMVd27p2OGDfNQpx18mY-Wk5l0P1Ke2Vt5LwA/edit?usp=sharing
Legacy Storage
==============
.. note::
Ceilometer's native database capabilities is intended for post processing
and auditing purposes where responsiveness is not a requirement. It
captures the full fidelity of each datapoint and thus is not designed
for low latency use cases. For more responsive use cases, it's recommended
to store data in an alternative source such as Gnocchi_. Please see
`Moving from Ceilometer to Gnocchi`_ to find more information.
.. note::
As of Liberty, alarming support, and subsequently its database, is handled
by Aodh_.
.. note::
As of Newton, event storage support is handled by Panko_.
.. _Aodh: http://docs.openstack.org/developer/aodh/
.. _Panko: http://docs.openstack.org/developer/panko
The following is a table indicating the status of each database drivers:
================== ============================= ===========================================
Driver API querying API statistics
================== ============================= ===========================================
MongoDB Yes Yes
MySQL Yes Yes
PostgreSQL Yes Yes
HBase Yes Yes, except groupby & selectable aggregates
================== ============================= ===========================================