openstack/ceilometer
Code Issues Proposed changes

re-org existing manually install notes

Browse Source 
- move enabling service notifications into own section
- clean up copy/paste install instructions
- add note to inform performance boast by disabling message signing
- add note to inform API is not required if Gnocchi is used.
- clean up oslo.messaging items
- remove verbose notes
    - zmq not ready
    - how to use PasteDeploy
- move customisation possibilites into it's own page

Change-Id: Ia42ceec7d2b6c054d065f905b8c0bce1685119aa
This commit is contained in:
gordon chung 2016-04-04 12:56:59 -04:00
parent 6a0f84dcbb
commit 182b4bd42e
4 changed files with 319 additions and 370 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

152
doc/source/install/custom.rst Normal file
View File

@ -0,0 +1,152 @@
..
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
.. _customizing_deployment:
===================================
Customizing Ceilometer Deployment
===================================
Notifications queues
====================
.. index::
double: customizing deployment; notifications queues; multiple topics
By default, Ceilometer consumes notifications on the messaging bus sent to
**topics** by using a queue/pool name that is identical to the
topic name. You shouldn't have different applications consuming messages from
this queue. If you want to also consume the topic notifications with a system
other than Ceilometer, you should configure a separate queue that listens for
the same messages.
Ceilometer allows multiple topics to be configured so that the polling agent can
send the same messages of notifications to other queues. Notification agents
also use **topics** to configure which queue to listen for. If
you use multiple topics, you should configure notification agent and polling
agent separately, otherwise Ceilometer collects duplicate samples.
By default, the ceilometer.conf file is as follows::
[oslo_messaging_notifications]
topics = notifications
To use multiple topics, you should give ceilometer-agent-notification and
ceilometer-polling services different ceilometer.conf files. The Ceilometer
configuration file ceilometer.conf is normally locate in the /etc/ceilometer
directory. Make changes according to your requirements which may look like
the following::
For notification agent using ceilometer-notification.conf, settings like::
[oslo_messaging_notifications]
topics = notifications,xxx
For polling agent using ceilometer-polling.conf, settings like::
[oslo_messaging_notifications]
topics = notifications,foo
.. note::
notification_topics in ceilometer-notification.conf should only have one same
topic in ceilometer-polling.conf
Doing this, it's easy to listen/receive data from multiple internal and external services.
Using multiple dispatchers
==========================
.. index::
double: customizing deployment; multiple dispatchers
The Ceilometer collector allows multiple dispatchers to be configured so that
data can be easily sent to multiple internal and external systems. Dispatchers
are divided between ``event_dispatchers`` and ``meter_dispatchers`` which can
each be provided with their own set of receiving systems.
.. note::
In Liberty and prior, the configuration option for all data was
``dispatcher`` but this was changed for the Mitaka release to break out
separate destination systems by type of data.
By default, Ceilometer only saves event and meter data in a database. If you
want Ceilometer to send data to other systems, instead of or in addition to
the Ceilometer database, multiple dispatchers can be enabled by modifying the
Ceilometer configuration file.
Ceilometer ships multiple dispatchers currently. They are ``database``,
``file``, ``http`` and ``gnocchi`` dispatcher. As the names imply, database
dispatcher sends metering data to a database, file dispatcher logs meters into
a file, http dispatcher posts the meters onto a http target, gnocchi
dispatcher posts the meters onto Gnocchi_ backend. Each dispatcher can have
its own configuration parameters. Please see available configuration
parameters at the beginning of each dispatcher file.
.. _Gnocchi: http://gnocchi.readthedocs.org/en/latest/basic.html
To check if any of the dispatchers is available in your system, you can
inspect the Ceilometer egg entry_points.txt file, you should normally see text
like the following::
[ceilometer.dispatcher]
database = ceilometer.dispatcher.database:DatabaseDispatcher
file = ceilometer.dispatcher.file:FileDispatcher
http = ceilometer.dispatcher.http:HttpDispatcher
gnocchi = ceilometer.dispatcher.gnocchi:GnocchiDispatcher
To configure one or multiple dispatchers for Ceilometer, find the Ceilometer
configuration file ceilometer.conf which is normally located at /etc/ceilometer
directory and make changes accordingly. Your configuration file can be in a
different directory.
To use multiple dispatchers on a Ceilometer collector service, add multiple
dispatcher lines in ceilometer.conf file like the following::
[DEFAULT]
meter_dispatchers=database
meter_dispatchers=file
If there is no dispatcher present, database dispatcher is used as the
default. If in some cases such as traffic tests, no dispatcher is needed,
one can configure the line without a dispatcher, like the following::
event_dispatchers=
With the above configuration, no event dispatcher is used by the Ceilometer
collector service, all event data received by Ceilometer collector will be
dropped.
For Gnocchi dispatcher, the following configuration settings should be added::
[DEFAULT]
meter_dispatchers = gnocchi
[dispatcher_gnocchi]
archive_policy = low
The value specified for ``archive_policy`` should correspond to the name of an
``archive_policy`` configured within Gnocchi.
For Gnocchi dispatcher backed by Swift storage, the following additional
configuration settings should be added::
[dispatcher_gnocchi]
filter_project = gnocchi_swift
filter_service_activity = True
.. note::
If gnocchi dispatcher is enabled, Ceilometer api calls will return a 410 with
an empty result. The Gnocchi Api should be used instead to access the data.

2
doc/source/install/dbreco.rst
View File

@ -19,7 +19,7 @@
Choosing a database backend - Legacy
=====================================
.. note:
.. note::
Ceilometer's existing database capabilities is intended for post processing
and auditing purposes where responsiveness is not a requirement. It

1
doc/source/install/index.rst
View File

@ -25,5 +25,6 @@
dbreco
development
manual
custom
upgrade
mod_wsgi

534
doc/source/install/manual.rst
View File

@ -24,22 +24,15 @@
Storage Backend Installation
============================
This step is a prerequisite for the collector, notification agent and API
services. You may use one of the listed database backends below to store
Ceilometer data.
.. note::
Please notice, MongoDB requires pymongo_ to be installed on the system. The
required minimum version of pymongo is 2.4.
..
This step is a prerequisite for the collector and API services. You may use
one of the listed database backends below to store Ceilometer data.
MongoDB
-------
The recommended Ceilometer storage backend is `MongoDB`. Follow the
instructions to install the MongoDB_ package for your operating system, then
start the service. The required minimum version of MongoDB is 2.4.
Follow the instructions to install the MongoDB_ package for your operating
system, then start the service. The required minimum version of MongoDB is
2.4.x. You will also need to have pymongo_ 2.4 installed
To use MongoDB as the storage backend, change the 'database' section in
ceilometer.conf as follows::
@ -50,13 +43,8 @@ MongoDB
SQLalchemy-supported DBs
------------------------
You may alternatively use `MySQL` (or any other SQLAlchemy-supported DB
like `PostgreSQL`).
In case of SQL-based database backends, you need to create a `ceilometer`
database first and then initialise it by running::
ceilometer-dbsync
You may alternatively use any SQLAlchemy-supported DB such as
`PostgreSQL` or `MySQL`.
To use MySQL as the storage backend, change the 'database' section in
ceilometer.conf as follows::
@ -74,7 +62,7 @@ HBase
${HBASE_HOME}/bin/hbase thrift start
The implementation uses `HappyBase`_, which is a wrapper library used to
interact with HBase via Thrift protocol. You can verify the thrift
interact with HBase via Thrift protocol. You can verify the Thrift
connection by running a quick test from a client::
import happybase
@ -86,11 +74,11 @@ HBase
print conn.tables() # this returns a list of HBase tables in your HBase server
.. note::
HappyBase version 0.5 or greater is required. Additionally, version 0.7
is not currently supported.
..
In case of HBase, the needed database tables (`project`, `user`, `resource`,
In the case of HBase, the required database tables (`project`, `user`, `resource`,
`meter`) should be created manually with `f` column family for each one.
To use HBase as the storage backend, change the 'database' section in
@ -115,124 +103,58 @@ HBase
.. _pymongo: https://pypi.python.org/pypi/pymongo/
Installing the notification agent
======================================
=================================
.. index::
double: installing; agent-notification
1. If you want to be able to retrieve image samples, you need to instruct
Glance to send notifications to the bus by changing ``notifier_strategy``
to ``rabbit`` in ``glance-api.conf`` and restarting the
service.
2. If you want to be able to retrieve volume samples, you need to instruct
Cinder to send notifications to the bus by changing ``notification_driver``
to ``messagingv2`` and ``control_exchange`` to ``cinder``, before restarting
the service.
3. If you want to be able to retrieve instance samples, you need to instruct
Nova to send notifications to the bus by setting these values::
# nova-compute configuration for ceilometer
instance_usage_audit=True
instance_usage_audit_period=hour
notify_on_state_change=vm_and_task_state
notification_driver=messagingv2
4. In order to retrieve object store statistics, ceilometer needs
access to swift with ``ResellerAdmin`` role. You should give this
role to your ``os_username`` user for tenant ``os_tenant_name``:
::
$ keystone role-create --name=ResellerAdmin
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| id | 462fa46c13fd4798a95a3bfbe27b5e54 |
| name | ResellerAdmin |
+----------+----------------------------------+
$ keystone user-role-add --tenant_id $SERVICE_TENANT \
--user_id $CEILOMETER_USER \
--role_id 462fa46c13fd4798a95a3bfbe27b5e54
You'll also need to add the Ceilometer middleware to Swift to account for
incoming and outgoing traffic, by adding these lines to
``/etc/swift/proxy-server.conf``::
[filter:ceilometer]
use = egg:ceilometer#swift
And adding ``ceilometer`` in the ``pipeline`` of that same file, right
before ``proxy-server``.
Additionally, if you want to store extra metadata from headers, you need
to set ``metadata_headers`` so it would look like::
[filter:ceilometer]
use = egg:ceilometer#swift
metadata_headers = X-FOO, X-BAR
.. note::
Please make sure that ceilometer's logging directory (if it's configured)
is read and write accessible for the user swift is started by.
5. Clone the ceilometer git repository to the management server::
1. Clone the ceilometer git repository to the management server::
$ cd /opt/stack
$ git clone https://git.openstack.org/openstack/ceilometer.git
6. As a user with ``root`` permissions or ``sudo`` privileges, run the
2. As a user with ``root`` permissions or ``sudo`` privileges, run the
ceilometer installer::
$ cd ceilometer
$ sudo python setup.py install
7. Copy the sample configuration files from the source tree
to their final location.
3. Copy the sample configuration files from the source tree
to their final location::
::
$ mkdir -p /etc/ceilometer
$ cp etc/ceilometer/*.json /etc/ceilometer
$ cp etc/ceilometer/*.yaml /etc/ceilometer
$ cp etc/ceilometer/ceilometer.conf.sample /etc/ceilometer/ceilometer.conf
$ mkdir -p /etc/ceilometer
$ cp etc/ceilometer/*.json /etc/ceilometer
$ cp etc/ceilometer/*.yaml /etc/ceilometer
$ cp etc/ceilometer/ceilometer.conf.sample /etc/ceilometer/ceilometer.conf
4. Edit ``/etc/ceilometer/ceilometer.conf``
8. Edit ``/etc/ceilometer/ceilometer.conf``
1. Configure messaging::
1. Configure messaging
[oslo_messaging_notifications]
topics = notifications
Set the messaging related options correctly so ceilometer's daemons can
communicate with each other and receive notifications from the other
projects.
In particular, look for the ``*_control_exchange`` options and
make sure the names are correct. If you did not change the
``control_exchange`` settings for the other components, the
defaults should be correct.
.. note::
Ceilometer makes extensive use of the messaging bus, but has
not yet been tested with ZeroMQ. We recommend using Rabbit
for now.
[oslo_messaging_rabbit]
rabbit_userid = stackrabbit
rabbit_password = openstack1
rabbit_hosts = 10.0.2.15
2. Set the ``telemetry_secret`` value.
Set the ``telemetry_secret`` value to a large, random, value. Use
the same value in all ceilometer configuration files, on all
nodes, so that messages passing between the nodes can be
validated.
validated. This value can be left empty to disable message signing.
.. note::
Disabling signing will improve message handling performance
Refer to :doc:`/configuration` for details about any other options
you might want to modify before starting the service.
9. Start the notification daemon.
::
5. Start the notification daemon::
$ ceilometer-agent-notification
@ -264,47 +186,31 @@ Installing the collector
$ sudo python setup.py install
3. Copy the sample configuration files from the source tree
to their final location.
to their final location::
::
$ mkdir -p /etc/ceilometer
$ cp etc/ceilometer/*.json /etc/ceilometer
$ cp etc/ceilometer/*.yaml /etc/ceilometer
$ cp etc/ceilometer/ceilometer.conf.sample /etc/ceilometer/ceilometer.conf
$ mkdir -p /etc/ceilometer
$ cp etc/ceilometer/*.json /etc/ceilometer
$ cp etc/ceilometer/*.yaml /etc/ceilometer
$ cp etc/ceilometer/ceilometer.conf.sample /etc/ceilometer/ceilometer.conf
4. Edit ``/etc/ceilometer/ceilometer.conf``
1. Configure messaging
1. Configure messaging::
Set the messaging related options correctly so ceilometer's daemons can
communicate with each other and receive notifications from the other
projects.
[oslo_messaging_notifications]
topics = notifications
In particular, look for the ``*_control_exchange`` options and
make sure the names are correct. If you did not change the
``control_exchange`` settings for the other components, the
defaults should be correct.
[oslo_messaging_rabbit]
rabbit_userid = stackrabbit
rabbit_password = openstack1
rabbit_hosts = 10.0.2.15
.. note::
Ceilometer makes extensive use of the messaging bus, but has
not yet been tested with ZeroMQ. We recommend using Rabbit
for now.
2. Set the ``telemetry_secret`` value.
Set the ``telemetry_secret`` value to a large, random, value. Use
the same value in all ceilometer configuration files, on all
nodes, so that messages passing between the nodes can be
validated.
2. Set the ``telemetry_secret`` value (if enabled for notification agent)
Refer to :doc:`/configuration` for details about any other options
you might want to modify before starting the service.
5. Start the collector.
::
5. Start the collector::
$ ceilometer-collector
@ -339,41 +245,46 @@ Installing the Polling Agent
$ sudo python setup.py install
3. Copy the sample configuration files from the source tree
to their final location.
to their final location::
$ mkdir -p /etc/ceilometer
$ cp etc/ceilometer/*.json /etc/ceilometer
$ cp etc/ceilometer/*.yaml /etc/ceilometer
$ cp etc/ceilometer/ceilometer.conf.sample /etc/ceilometer/ceilometer.conf
4. Configure messaging by editing ``/etc/ceilometer/ceilometer.conf``::
[oslo_messaging_notifications]
topics = notifications
[oslo_messaging_rabbit]
rabbit_userid = stackrabbit
rabbit_password = openstack1
rabbit_hosts = 10.0.2.15
5. In order to retrieve object store statistics, ceilometer needs
access to swift with ``ResellerAdmin`` role. You should give this
role to your ``os_username`` user for tenant ``os_tenant_name``:
::
$ mkdir -p /etc/ceilometer
$ cp etc/ceilometer/*.json /etc/ceilometer
$ cp etc/ceilometer/*.yaml /etc/ceilometer
$ cp etc/ceilometer/ceilometer.conf.sample /etc/ceilometer/ceilometer.conf
$ keystone role-create --name=ResellerAdmin
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| id | 462fa46c13fd4798a95a3bfbe27b5e54 |
| name | ResellerAdmin |
+----------+----------------------------------+
4. Edit ``/etc/ceilometer/ceilometer.conf``
Set the messaging related options correctly so ceilometer's daemons can
communicate with each other and receive notifications from the other
projects.
$ keystone user-role-add --tenant_id $SERVICE_TENANT \
--user_id $CEILOMETER_USER \
--role_id 462fa46c13fd4798a95a3bfbe27b5e54
In particular, look for the ``*_control_exchange`` options and
make sure the names are correct. If you did not change the
``control_exchange`` settings for the other components, the
defaults should be correct.
6. Start the agent::
.. note::
$ ceilometer-polling
Ceilometer makes extensive use of the messaging bus, but has
not yet been tested with ZeroMQ. We recommend using Rabbit
for now.
Refer to :doc:`/configuration` for details about any other options
you might want to modify before starting the service.
5. Start the agent
::
$ ceilometer-polling
6. By default, the polling agent polls the `compute` and `central` namespaces.
7. By default, the polling agent polls the `compute` and `central` namespaces.
You can specify which namespace to poll in the `ceilometer.conf`
configuration file or on the command line::
@ -387,8 +298,10 @@ Installing the API Server
double: installing; API
.. note::
The API server needs to be able to talk to keystone and ceilometer's
database.
database. It is only required if you choose to store data in legacy
database or if you inject new samples via REST API.
1. Clone the ceilometer git repository to the server::
@ -402,46 +315,46 @@ Installing the API Server
$ sudo python setup.py install
3. Copy the sample configuration files from the source tree
to their final location.
to their final location::
::
$ mkdir -p /etc/ceilometer
$ cp etc/ceilometer/api_paste.ini /etc/ceilometer
$ cp etc/ceilometer/*.json /etc/ceilometer
$ cp etc/ceilometer/*.yaml /etc/ceilometer
$ cp etc/ceilometer/ceilometer.conf.sample /etc/ceilometer/ceilometer.conf
$ mkdir -p /etc/ceilometer
$ cp etc/ceilometer/api_paste.ini /etc/ceilometer
$ cp etc/ceilometer/*.json /etc/ceilometer
$ cp etc/ceilometer/*.yaml /etc/ceilometer
$ cp etc/ceilometer/ceilometer.conf.sample /etc/ceilometer/ceilometer.conf
4. Configure messaging by editing ``/etc/ceilometer/ceilometer.conf``::
4. Edit ``/etc/ceilometer/ceilometer.conf``
[oslo_messaging_notifications]
topics = notifications
1. Configure messaging
[oslo_messaging_rabbit]
rabbit_userid = stackrabbit
rabbit_password = openstack1
rabbit_hosts = 10.0.2.15
Set the messaging related options correctly so ceilometer's daemons can
communicate with each other and receive notifications from the other
projects.
5. Create a service for ceilometer in keystone::
In particular, look for the ``*_control_exchange`` options and
make sure the names are correct. If you did not change the
``control_exchange`` settings for the other components, the
defaults should be correct.
$ keystone service-create --name=ceilometer \
--type=metering \
--description="Ceilometer Service"
.. note::
6. Create an endpoint in keystone for ceilometer::
Ceilometer makes extensive use of the messaging bus, but has
not yet been tested with ZeroMQ. We recommend using Rabbit
for now.
$ keystone endpoint-create --region RegionOne \
--service_id $CEILOMETER_SERVICE \
--publicurl "http://$SERVICE_HOST:8777/" \
--adminurl "http://$SERVICE_HOST:8777/" \
--internalurl "http://$SERVICE_HOST:8777/"
Refer to :doc:`/configuration` for details about any other options
you might want to modify before starting the service.
.. note::
5. (Optional) As of the Juno release, Ceilometer utilises Paste Deploy to
manage WSGI applications. Ceilometer uses keystonemiddleware by default but
additional middleware and applications can be configured in api_paste.ini.
For examples on how to use Paste Deploy, refer to this documentation_.
CEILOMETER_SERVICE is the id of the service created by the first command
and SERVICE_HOST is the host where the Ceilometer API is running. The
default port value for ceilometer API is 8777. If the port value
has been customized, adjust accordingly.
.. _documentation: http://pythonpaste.org/deploy/
6. Choose and start the API server.
7. Choose and start the API server.
Ceilometer includes the ``ceilometer-api`` command. This can be
used to run the API server. For smaller or proof-of-concept
@ -463,196 +376,79 @@ Installing the API Server
maintaining a long-running program in the background.
Configuring keystone to work with API
=====================================
Enabling Service Notifications
==============================
.. index::
double: installing; configure keystone
Cinder
------
.. note::
The API server needs to be able to talk to keystone to authenticate.
Edit ``cinder.conf`` to include::
1. Create a service for ceilometer in keystone
[oslo_messaging_notifications]
driver = messagingv2
::
Glance
------
$ keystone service-create --name=ceilometer \
--type=metering \
--description="Ceilometer Service"
Edit ``glance.conf`` to include::
2. Create an endpoint in keystone for ceilometer
[oslo_messaging_notifications]
driver = messagingv2
::
Heat
----
$ keystone endpoint-create --region RegionOne \
--service_id $CEILOMETER_SERVICE \
--publicurl "http://$SERVICE_HOST:8777/" \
--adminurl "http://$SERVICE_HOST:8777/" \
--internalurl "http://$SERVICE_HOST:8777/"
Configure the driver in ``heat.conf``::
.. note::
[oslo_messaging_notifications]
driver=messagingv2
CEILOMETER_SERVICE is the id of the service created by the first command
and SERVICE_HOST is the host where the Ceilometer API is running. The
default port value for ceilometer API is 8777. If the port value
has been customized, adjust accordingly.
Nova
----
Edit ``nova.conf`` to include::
[DEFAULT]
instance_usage_audit=True
instance_usage_audit_period=hour
notify_on_state_change=vm_and_task_state
[oslo_messaging_notifications]
driver=messagingv2
Configuring Heat to send notifications
======================================
Sahara
------
Configure the driver in ``heat.conf``
Configure the driver in ``sahara.conf``::
::
[DEFAULT]
enable_notifications=true
notification_driver=messagingv2
[oslo_messaging_notifications]
driver=messagingv2
Configuring Sahara to send notifications
========================================
Swift
-----
Configure the driver in ``sahara.conf``
Edit ``proxy-server.conf`` to include::
::
[filter:ceilometer]
topic = notifications
driver = messaging
url = rabbit://stackrabbit:openstack1@10.0.2.15:5672/
control_exchange = swift
paste.filter_factory = ceilometermiddleware.swift:filter_factory
set log_level = WARN
enable_notifications=true
notification_driver=messagingv2
and edit [pipeline:main] to include the ceilometer middleware before the application::
Also you need to configure messaging related options correctly as written above
[pipeline:main]
pipeline = catch_errors ... ... ceilometer proxy-server
Also, you need to configure messaging related options correctly as written above
for other parts of installation guide. Refer to :doc:`/configuration` for
details about any other options you might want to modify before starting the
service.
Notifications queues
====================
.. index::
double: installing; notifications queues; multiple topics
By default, Ceilometer consumes notifications on the messaging bus sent to
**notification_topics** by using a queue/pool name that is identical to the
topic name. You shouldn't have different applications consuming messages from
this queue. If you want to also consume the topic notifications with a system
other than Ceilometer, you should configure a separate queue that listens for
the same messages.
Ceilometer allows multiple topics to be configured so that polling agent can
send the same messages of notifications to other queues. Notification agents
also use **notification_topics** to configure which queue to listen for. If
you use multiple topics, you should configure notification agent and polling
agent separately, otherwise Ceilometer collects duplicate samples.
By default, the ceilometer.conf file is as follows::
[DEFAULT]
notification_topics = notifications
To use multiple topics, you should give ceilometer-agent-notification and
ceilometer-polling services different ceilometer.conf files. The Ceilometer
configuration file ceilometer.conf is normally locate in the /etc/ceilometer
directory. Make changes according to your requirements which may look like
the following::
For notification agent using ceilometer-notification.conf, settings like::
[DEFAULT]
notification_topics = notifications,xxx
For polling agent using ceilometer-polling.conf, settings like::
[DEFAULT]
notification_topics = notifications,foo
.. note::
notification_topics in ceilometer-notification.conf should only have one same
topic in ceilometer-polling.conf
Doing this, it's easy to listen/receive data from multiple internal and external services.
Using multiple dispatchers
==========================
.. index::
double: installing; multiple dispatchers
The Ceilometer collector allows multiple dispatchers to be configured so that
data can be easily sent to multiple internal and external systems. Dispatchers
are divided between ``event_dispatchers`` and ``meter_dispatchers`` which can
each be provided with their own set of receiving systems.
.. note::
In Liberty and prior the configuration option for all data was
``dispatcher`` but this was changed for the Mitaka release to break out
separate destination systems by type of data.
By default, Ceilometer only saves event and meter data in a database. If you
want Ceilometer to send data to other systems, instead of or in addition to
the Ceilometer database, multiple dispatchers can be enabled by modifying the
Ceilometer configuration file.
Ceilometer ships multiple dispatchers currently. They are ``database``,
``file``, ``http`` and ``gnocchi`` dispatcher. As the names imply, database
dispatcher sends metering data to a database, file dispatcher logs meters into
a file, http dispatcher posts the meters onto a http target, gnocchi
dispatcher posts the meters onto Gnocchi_ backend. Each dispatcher can have
its own configuration parameters. Please see available configuration
parameters at the beginning of each dispatcher file.
.. _Gnocchi: http://gnocchi.readthedocs.org/en/latest/basic.html
To check if any of the dispatchers is available in your system, you can
inspect the Ceilometer egg entry_points.txt file, you should normally see text
like the following::
[ceilometer.dispatcher]
database = ceilometer.dispatcher.database:DatabaseDispatcher
file = ceilometer.dispatcher.file:FileDispatcher
http = ceilometer.dispatcher.http:HttpDispatcher
gnocchi = ceilometer.dispatcher.gnocchi:GnocchiDispatcher
To configure one or multiple dispatchers for Ceilometer, find the Ceilometer
configuration file ceilometer.conf which is normally located at /etc/ceilometer
directory and make changes accordingly. Your configuration file can be in a
different directory.
To use multiple dispatchers on a Ceilometer collector service, add multiple
dispatcher lines in ceilometer.conf file like the following::
[DEFAULT]
meter_dispatchers=database
meter_dispatchers=file
If there is no dispatcher present, database dispatcher is used as the
default. If in some cases such as traffic tests, no dispatcher is needed,
one can configure the line without a dispatcher, like the following::
event_dispatchers=
With the above configuration, no event dispatcher is used by the Ceilometer
collector service, all event data received by Ceilometer collector will be
dropped.
For Gnocchi dispatcher, the following configuration settings should be added::
[DEFAULT]
meter_dispatchers = gnocchi
[dispatcher_gnocchi]
archive_policy = low
The value specified for ``archive_policy`` should correspond to the name of an
``archive_policy`` configured within Gnocchi.
For Gnocchi dispatcher backed by Swift storage, the following additional
configuration settings should be added::
[dispatcher_gnocchi]
filter_project = gnocchi_swift
filter_service_activity = True
.. note::
If gnocchi dispatcher is enabled, Ceilometer api calls will return a 410 with
an empty result. The Gnocchi Api should be used instead to access the data.