Customizing Ceilometer Deployment¶
Notifications queues¶
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¶
Ceilometer allows multiple dispatchers to be configured in pipeline 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. Ceilometer allows to set two
types of pipelines. One is pipeline.yaml
which is for meters, another is event_pipeline.yaml
which is for events.
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.
To check if any of the dispatchers is available in your system, you can
inspect the Ceilometer setup.cfg
file for the dispatcher parts, or you
can scan them using entry_point_inspector:
$ pip install --user entry_point_inspector
$ epi group show ceilometer.dispatcher.meter
$ epi group show ceilometer.dispatcher.event
To configure one or multiple dispatchers for Ceilometer, find the Ceilometer
configuration file pipeline.yaml
and/or event_pipeline.yaml
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, add multiple dispatcher lines in pipeline.yaml
and/or
event_pipeline.yaml
file like the following:
---
sources:
- name: source_name
events:
- "*"
sinks:
- sink_name
sinks:
- name: sink_name
transformers:
publishers:
- database://
- gnocchi://
- file://
database://
and gnocchi://
are explicit publishers. You can choose
dispatchers which you need to be configured under publishers
parameter.
Note
If there is no dispatcher present, database dispatcher is used as the
default on condition that you may use direct://
as a publisher. But
direct publisher is deprecated, use an explicit publisher instead.
For Gnocchi dispatcher, the following configuration settings should be added into /etc/ceilometer/ceilometer.conf:
[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.
Efficient polling¶
- There is an optional config called
shuffle_time_before_polling_task
in ceilometer.conf. Enable this by setting an integer greater than zero to shuffle polling time for agents. This will add some random jitter to the time of sending requests to Nova or other components to avoid large number of requests in a short time period. - There is an option to stream samples to minimise latency (at the
expense of load) by setting
batch_polled_samples
toFalse
inceilometer.conf
.