Merge "remove install section from contributor guide"
This commit is contained in:
Zuul
Gerrit Code Review
commit
004c37cc3f
doc/source/contributor
@ -28,7 +28,6 @@ Developer reference
|
||||
architecture
|
||||
measurements
|
||||
events
|
||||
install/index
|
||||
configuration
|
||||
plugins
|
||||
new_resource_types
|
||||
|
||||
@ -1,149 +0,0 @@
|
||||
..
|
||||
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.
|
||||
|
||||
.. _publisher-configuration:
|
||||
|
||||
Using multiple publishers
|
||||
=========================
|
||||
|
||||
.. index::
|
||||
double: customizing deployment; multiple publishers
|
||||
|
||||
Ceilometer allows multiple publishers to be configured in pipeline so that
|
||||
data can be easily sent to multiple internal and external 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 into Gnocchi_. If you
|
||||
want Ceilometer to send data to other systems, instead of or in addition to
|
||||
the default storage services, multiple publishers can be enabled by modifying
|
||||
the Ceilometer pipeline.
|
||||
|
||||
Ceilometer ships multiple publishers currently. They are ``database``,
|
||||
``notifier``, ``file``, ``http`` and ``gnocchi`` publishers.
|
||||
|
||||
.. _Gnocchi: http://gnocchi.xyz
|
||||
|
||||
To configure one or multiple publishers 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.
|
||||
|
||||
For the Gnocchi publisher, the archive policy can be defined as a configuration
|
||||
settings. The value specified for ``archive_policy`` should correspond to the
|
||||
name of an ``archive_policy`` configured within Gnocchi.
|
||||
|
||||
To use multiple publishers, add multiple publisher 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:
|
||||
- gnocchi://?archive_policy=low
|
||||
- file://
|
||||
|
||||
|
||||
For the Gnocchi publisher backed by Swift storage, the following additional
|
||||
configuration settings should be added::
|
||||
|
||||
[dispatcher_gnocchi]
|
||||
filter_project = gnocchi_swift
|
||||
|
||||
Custom pipeline
|
||||
===============
|
||||
|
||||
The paths of all pipeline files including ``pipeline.yaml`` and
|
||||
``event_pipeline.yaml`` are located to ceilometer/pipeline/data by default.
|
||||
And it's possible to set the path through
|
||||
``pipeline_cfg_file`` being assigned to another one in ``ceilometer.conf``.
|
||||
|
||||
Ceilometer allow users to customize pipeline files. Before that, copy the
|
||||
following yaml files::
|
||||
|
||||
$ cp ceilometer/pipeline/data/*.yaml /etc/ceilometer
|
||||
|
||||
Then you can add configurations according to the former section.
|
||||
|
||||
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`` to ``False`` in
|
||||
``ceilometer.conf``.
|
||||
@ -1,57 +0,0 @@
|
||||
..
|
||||
Copyright 2013 Nicolas Barcet for eNovance
|
||||
|
||||
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.
|
||||
|
||||
.. _choosing_db_backend:
|
||||
|
||||
============================
|
||||
Choosing a database backend
|
||||
============================
|
||||
|
||||
Ceilometer is a data collection service. It normalizes data across OpenStack
|
||||
and can be configured to persist the normalized data to multiple services.
|
||||
Gnocchi_ is designed to store time-series **measurement data**. Panko_ is
|
||||
intended to capture **event data**. Lastly, Aodh_ provides **alarming**
|
||||
functionality.
|
||||
|
||||
Moving from Ceilometer to Gnocchi
|
||||
=================================
|
||||
|
||||
Gnocchi represents a fundamental change in how data is represented and stored.
|
||||
Installation and configuration can be found in :ref:`installing_manually`.
|
||||
Differences between APIs can be found here_.
|
||||
|
||||
There currently exists no migration tool between the services. To transition
|
||||
to Gnocchi, multiple publishers can be enabled in the Collector to capture
|
||||
data in both the native Ceilometer database and Gnocchi. This will allow you
|
||||
to test Gnocchi and transition to it fully when comfortable. Edit the
|
||||
``pipeline.yaml`` and ``event_pipeline.yaml`` to include multiple publishers::
|
||||
|
||||
---
|
||||
sources:
|
||||
- name: event_source
|
||||
events:
|
||||
- "*"
|
||||
sinks:
|
||||
- event_sink
|
||||
sinks:
|
||||
- name: event_sink
|
||||
publishers:
|
||||
- gnocchi://
|
||||
- database://
|
||||
|
||||
.. _Gnocchi: http://gnocchi.xyz
|
||||
.. _Aodh: https://docs.openstack.org/aodh/latest/
|
||||
.. _Panko: https://docs.openstack.org/panko/latest/
|
||||
.. _here: https://www.slideshare.net/GordonChung/ceilometer-to-gnocchi
|
||||
@ -1,27 +0,0 @@
|
||||
..
|
||||
Copyright 2013 New Dream Network, LLC (DreamHost)
|
||||
|
||||
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.
|
||||
|
||||
.. _install:
|
||||
|
||||
=======================
|
||||
Installing Ceilometer
|
||||
=======================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
dbreco
|
||||
custom
|
||||
upgrade
|
||||
@ -1,104 +0,0 @@
|
||||
..
|
||||
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.
|
||||
|
||||
.. _upgrade:
|
||||
|
||||
==========
|
||||
Upgrading
|
||||
==========
|
||||
|
||||
Ceilometer's services support both full upgrades as well as partial
|
||||
(rolling) upgrades. The required steps for each process are described below.
|
||||
|
||||
|
||||
Full upgrades
|
||||
=============
|
||||
|
||||
The following describes how to upgrade your entire Ceilometer environment in
|
||||
one pass.
|
||||
|
||||
.. _full upgrade path:
|
||||
|
||||
1. Upgrade the database (if applicable)
|
||||
|
||||
Run ceilometer-upgrade to upgrade the storage backend if using one of
|
||||
Ceilometer's databases (see :ref:`choosing_db_backend`). The database does
|
||||
not need to be taken offline. Ideally this should be done during a period of
|
||||
low activity. Best practices should still be followed (ie. back up your
|
||||
data). If not using a Ceilometer database, you should consult the
|
||||
documentation of that storage beforehand.
|
||||
|
||||
2. Upgrade the collector service(s)
|
||||
|
||||
Shutdown all collector services. The new collector, that knows how to
|
||||
interpret the new payload, can then be started. It will disregard any
|
||||
historical attributes and can continue to process older data from the
|
||||
agents. You may restart as many new collectors as required.
|
||||
|
||||
3. Upgrade the notification agent(s)
|
||||
|
||||
The notification agent can then be taken offline and upgraded with the
|
||||
same conditions as the collector service.
|
||||
|
||||
4. Upgrade the polling agent(s)
|
||||
|
||||
In this path, you'll want to take down agents on all hosts before starting.
|
||||
After starting the first agent, you should verify that data is again being
|
||||
polled. Additional agents can be added to support coordination if enabled.
|
||||
|
||||
|
||||
Partial upgrades
|
||||
================
|
||||
|
||||
The following describes how to upgrade parts of your Ceilometer environment
|
||||
gradually. The ultimate goal is to have all services upgraded to the new
|
||||
version in time.
|
||||
|
||||
1. Upgrade the database (if applicable)
|
||||
|
||||
Upgrading the database here is the same as the `full upgrade path`_.
|
||||
|
||||
2. Upgrade the collector service(s)
|
||||
|
||||
The new collector services can be started alongside the old collectors.
|
||||
Collectors old and new will disregard any new or historical attributes.
|
||||
|
||||
3. Upgrade the notification agent(s)
|
||||
|
||||
The new notification agent can be started alongside the old agent if no
|
||||
workload_partitioning is enabled OR if it has the same pipeline
|
||||
configuration. If the pipeline configuration is changed, the old agents
|
||||
must be loaded with the same pipeline configuration first to ensure the
|
||||
notification agents all work against same pipeline sets.
|
||||
|
||||
4. Upgrade the polling agent(s)
|
||||
|
||||
The new polling agent can be started alongside the old agent only if no new
|
||||
pollsters were added. If not, new polling agents must start only in its
|
||||
own partitioning group and poll only the new pollsters. After all old agents
|
||||
are upgraded, the polling agents can be changed to poll both new pollsters
|
||||
AND the old ones.
|
||||
|
||||
.. note::
|
||||
|
||||
Upgrade ordering does not matter in partial upgrade path. The only
|
||||
requirement is that the database be upgraded first. It is advisable to
|
||||
upgrade following the same ordering as currently described: database,
|
||||
collector, notification agent, polling agent.
|
||||
|
||||
|
||||
Developer notes
|
||||
===============
|
||||
|
||||
When updating data models in the database or IPC, we need to adhere to
|
||||
a single mantra: 'always add, never delete or modify.'
|
||||
Loading…
x
Reference in New Issue
Block a user