summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/source/admin/telemetry-data-collection.rst166
1 files changed, 6 insertions, 160 deletions
diff --git a/doc/source/admin/telemetry-data-collection.rst b/doc/source/admin/telemetry-data-collection.rst
index 192f2038..72b60df9 100644
--- a/doc/source/admin/telemetry-data-collection.rst
+++ b/doc/source/admin/telemetry-data-collection.rst
@@ -12,9 +12,6 @@ Collected data can be stored in the form of samples or events in the
supported databases, which are listed
in :ref:`telemetry-supported-databases`.
-Samples capture a numerical measurement of a resource. The Telemetry service
-leverages multiple methods to collect data samples.
-
The available data collection mechanisms are:
Notifications
@@ -63,141 +60,13 @@ various types of events that happen in the system during normal
operation. Not all these notifications are consumed by the Telemetry
service, as the intention is only to capture the billable events and
notifications that can be used for monitoring or profiling purposes. The
-notification agent filters by the event type. Each notification
-message contains the event type. The following table contains the event
-types by each OpenStack service that Telemetry transforms into samples.
-
-.. list-table::
- :widths: 10 15 30
- :header-rows: 1
-
- * - OpenStack service
- - Event types
- - Note
- * - OpenStack Compute
- - scheduler.run\_instance.scheduled
-
- scheduler.select\_\
- destinations
-
- compute.instance.\*
- - For a more detailed list of Compute notifications please
- check the `System Usage Data wiki page <https://wiki.openstack.org/wiki/
- SystemUsageData>`__.
- * - Bare metal service
- - hardware.ipmi.\*
- -
- * - OpenStack Image
- - image.update
-
- image.upload
-
- image.delete
-
- image.send
-
- - The required configuration for Image service can be found in the
- `Configure the Image service for Telemetry <https://docs.openstack.org/project-install-guide/telemetry/ocata>`__
- section in the Installation Tutorials and Guides.
- * - OpenStack Networking
- - floatingip.create.end
-
- floatingip.update.\*
-
- floatingip.exists
-
- network.create.end
-
- network.update.\*
-
- network.exists
-
- port.create.end
-
- port.update.\*
-
- port.exists
-
- router.create.end
-
- router.update.\*
-
- router.exists
-
- subnet.create.end
-
- subnet.update.\*
-
- subnet.exists
-
- l3.meter
- -
- * - Orchestration service
- - orchestration.stack\
- .create.end
-
- orchestration.stack\
- .update.end
-
- orchestration.stack\
- .delete.end
-
- orchestration.stack\
- .resume.end
-
- orchestration.stack\
- .suspend.end
- -
- * - OpenStack Block Storage
- - volume.exists
-
- volume.create.\*
-
- volume.delete.\*
-
- volume.update.\*
-
- volume.resize.\*
-
- volume.attach.\*
-
- volume.detach.\*
-
- snapshot.exists
-
- snapshot.create.\*
-
- snapshot.delete.\*
-
- snapshot.update.\*
-
- volume.backup.create.\
- \*
-
- volume.backup.delete.\
- \*
-
- volume.backup.restore.\
- \*
- - The required configuration for Block Storage service can be found in the
- `Add the Block Storage service agent for Telemetry
- <https://docs.openstack.org/project-install-guide/telemetry/ocata/cinder/install-cinder-ubuntu.html>`__
- section in the Installation Tutorials and Guides.
+notifications handled are contained under the `ceilometer.sample.endpoint`
+namespace.
.. note::
Some services require additional configuration to emit the
- notifications using the correct control exchange on the message
- queue and so forth. These configuration needs are referred in the
- above table for each OpenStack service that needs it.
-
-Specific notifications from the Compute service are important for
-administrators and users. Configuring ``nova_notifications`` in the
-``nova.conf`` file allows administrators to respond to events
-rapidly. For more information on configuring notifications for the
-compute service, see `Telemetry services
-<https://docs.openstack.org/project-install-guide/telemetry/ocata/install-compute-ubuntu.html>`__ in the
-Installation Tutorials and Guides.
+ notifications. Please see the :ref:`install_controller` for more details.
.. _meter_definitions:
@@ -421,15 +290,9 @@ meters, which is placed on the host machines to retrieve this
information locally.
A Compute agent instance has to be installed on each and every compute
-node, installation instructions can be found in the `Install the Compute
-agent for Telemetry
-<https://docs.openstack.org/project-install-guide/telemetry/ocata/install-compute-ubuntu.html>`__
+node, installation instructions can be found in the :ref:`install_compute`
section in the Installation Tutorials and Guides.
-The compute agent does not need direct database connection. The samples
-collected by this agent are sent via AMQP to the notification agent to be
-processed.
-
The list of supported hypervisors can be found in
:ref:`telemetry-supported-hypervisors`. The Compute agent uses the API of the
hypervisor installed on the compute hosts. Therefore, the supported meters may
@@ -440,10 +303,6 @@ The list of collected meters can be found in :ref:`telemetry-compute-meters`.
The support column provides the information about which meter is available for
each hypervisor supported by the Telemetry service.
-.. note::
-
- Telemetry supports Libvirt, which hides the hypervisor under it.
-
Central agent
~~~~~~~~~~~~~
@@ -451,26 +310,16 @@ This agent is responsible for polling public REST APIs to retrieve additional
information on OpenStack resources not already surfaced via notifications,
and also for polling hardware resources over SNMP.
-The following services can be polled with this agent:
+Some of the services polled with this agent are:
- OpenStack Networking
-
- OpenStack Object Storage
-
- OpenStack Block Storage
-
- Hardware resources via SNMP
-- Energy consumption meters via `Kwapi <https://launchpad.net/kwapi>`__
- framework (deprecated in Newton)
-
-To install and configure this service use the `Add the Telemetry service
-<https://docs.openstack.org/project-install-guide/telemetry/ocata/install-base-ubuntu.html>`__
+To install and configure this service use the :ref:`install_rdo`
section in the Installation Tutorials and Guides.
-Just like the compute agent, this component also does not need a direct
-database connection. The samples are sent via AMQP to the notification agent.
-
.. _telemetry-ipmi-agent:
IPMI agent
@@ -490,9 +339,6 @@ checks for the hardware and if none is available, returns empty data. It
is suggested that you install the IPMI agent only on an IPMI capable
node for performance reasons.
-Just like the central agent, this component also does not need direct
-database access. The samples are sent via AMQP to the notification agent.
-
The list of collected meters can be found in
:ref:`telemetry-bare-metal-service`.