telemetry-system-architecture to RST
Converts section_telemetry-system-architecture.xml to RST. Implements: blueprint reorganise-user-guides Change-Id: I992606a55e765ba84fe7182e1c933937ca3451e1
This commit is contained in:
Karen Bradshaw
parent
eb82123763
commit
d3d4ebf6af
@ -0,0 +1,169 @@
|
||||
System architecture
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The Telemetry module uses an agent-based architecture. Several modules
|
||||
combine their responsibilities to collect data, store samples in a
|
||||
database, or provide an API service for handling incoming requests.
|
||||
|
||||
The Telemetry module is built from the following agents and services:
|
||||
|
||||
ceilometer-api
|
||||
Presents aggregated metering data to consumers (such as billing
|
||||
engines, analytics tools and so forth).
|
||||
|
||||
ceilometer-polling
|
||||
Polls for different kinds of meter data by using the polling
|
||||
plug-ins (pollsters) registered in different namespaces.
|
||||
|
||||
ceilometer-agent-central
|
||||
Polls the public RESTful APIs of other OpenStack services such as
|
||||
Compute service and Image service, in order to keep tabs on resource
|
||||
existence, by using the polling plug-ins (pollsters) registered in
|
||||
the central polling namespace.
|
||||
|
||||
ceilometer-agent-compute
|
||||
Polls the local hypervisor or libvirt daemon to acquire performance
|
||||
data for the local instances, messages and emits the data as AMQP
|
||||
messages, by using the polling plug-ins (pollsters) registered in
|
||||
the compute polling namespace.
|
||||
|
||||
ceilometer-agent-ipmi
|
||||
Polls the local node with IPMI support, in order to acquire IPMI
|
||||
sensor data and Intel Node Manager data, by using the polling
|
||||
plug-ins (pollsters) registered in the IPMI polling namespace.
|
||||
|
||||
ceilometer-agent-notification
|
||||
Consumes AMQP messages from other OpenStack services.
|
||||
|
||||
ceilometer-collector
|
||||
Consumes AMQP notifications from the agents, then dispatches these
|
||||
data to the appropriate data store.
|
||||
|
||||
ceilometer-alarm-evaluator
|
||||
Determines when alarms fire due to the associated statistic trend
|
||||
crossing a threshold over a sliding time window.
|
||||
|
||||
ceilometer-alarm-notifier
|
||||
Initiates alarm actions, for example calling out to a webhook with a
|
||||
description of the alarm state transition.
|
||||
|
||||
.. note::
|
||||
|
||||
The ``ceilometer-polling`` service is available since the Kilo release.
|
||||
|
||||
Besides the ``ceilometer-agent-compute`` and the ``ceilometer-agent-ipmi``
|
||||
services, all the other services are placed on one or more controller
|
||||
nodes.
|
||||
|
||||
The Telemetry architecture highly depends on the AMQP service both for
|
||||
consuming notifications coming from OpenStack services and internal
|
||||
communication.
|
||||
|
||||
|
|
||||
|
||||
Supported databases
|
||||
-------------------
|
||||
|
||||
The other key external component of Telemetry is the database, where
|
||||
events, samples, alarm definitions and alarms are stored.
|
||||
|
||||
.. note::
|
||||
|
||||
Multiple database back ends can be configured in order to store
|
||||
events, samples and alarms separately.
|
||||
|
||||
The list of supported database back ends:
|
||||
|
||||
- `ElasticSearch (events only) <http://www.elasticsearch.org/>`__
|
||||
|
||||
- `MongoDB <http://www.mongodb.org/>`__
|
||||
|
||||
- `MySQL <http://www.mysql.com/>`__
|
||||
|
||||
- `PostgreSQL <http://www.postgresql.org/>`__
|
||||
|
||||
- `HBase <http://hbase.apache.org/>`__
|
||||
|
||||
- `DB2 <http://www-01.ibm.com/software/data/db2/>`__
|
||||
|
||||
|
|
||||
|
||||
Supported hypervisors
|
||||
---------------------
|
||||
|
||||
The Telemetry module collects information about the virtual machines,
|
||||
which requires close connection to the hypervisor that runs on the
|
||||
compute hosts.
|
||||
|
||||
The list of supported hypervisors is:
|
||||
|
||||
- The following hypervisors are supported via
|
||||
`Libvirt <http://libvirt.org/>`__:
|
||||
|
||||
- `Kernel-based Virtual Machine
|
||||
(KVM) <http://www.linux-kvm.org/page/Main_Page>`__
|
||||
|
||||
- `Quick Emulator (QEMU) <http://wiki.qemu.org/Main_Page>`__
|
||||
|
||||
- `Linux Containers (LXC) <https://linuxcontainers.org/>`__
|
||||
|
||||
- `User-mode Linux
|
||||
(UML) <http://user-mode-linux.sourceforge.net/>`__
|
||||
|
||||
.. note::
|
||||
|
||||
For details about hypervisor support in libvirt please check the
|
||||
`Libvirt API support matrix <http://libvirt.org/hvsupport.html>`__.
|
||||
|
||||
- `Hyper-V <http://www.microsoft.com/en-us/server-cloud/hyper-v-server/default.aspx>`__
|
||||
|
||||
- `XEN <http://www.xenproject.org/help/documentation.html>`__
|
||||
|
||||
- `VMWare
|
||||
vSphere <http://www.vmware.com/products/vsphere-hypervisor/support.html>`__
|
||||
|
||||
|
|
||||
|
||||
Supported networking services
|
||||
-----------------------------
|
||||
|
||||
Telemetry is able to retrieve information from OpenStack Networking and
|
||||
external networking services:
|
||||
|
||||
- OpenStack Networking:
|
||||
|
||||
- Basic network meters
|
||||
|
||||
- Firewall-as-a-Service (FWaaS) meters
|
||||
|
||||
- Loadbalancer-as-a-Service (LBaaS) meters
|
||||
|
||||
- VPN-as-a-Service (VPNaaS) meters
|
||||
|
||||
- SDN controller meters:
|
||||
|
||||
- `OpenDaylight <http://www.opendaylight.org/software>`__
|
||||
|
||||
- `OpenContrail <http://opencontrail.org/>`__
|
||||
|
||||
|
|
||||
|
||||
Users, roles and tenants
|
||||
------------------------
|
||||
|
||||
This module of OpenStack uses OpenStack Identity for authenticating and
|
||||
authorizing users. The required configuration options are listed in the
|
||||
`Telemetry
|
||||
section <http://docs.openstack.org/kilo/config-reference/content/ch_configuring-openstack-telemetry.html>`__
|
||||
in the *OpenStack Configuration Reference*.
|
||||
|
||||
Two roles are used in the system basically, which are the 'admin' and
|
||||
'non-admin'. The authorization happens before processing each API
|
||||
request. The amount of returned data depends on the role the requestor
|
||||
owns.
|
||||
|
||||
The creation of alarm definitions also highly depends on the role of the
|
||||
user, who initiated the action. Further details about alarm handling can
|
||||
be found in this guide.
|
||||
|
||||
.. TODO: (karenb) Add reference to telemetry-alarms.
|
||||
@ -46,16 +46,17 @@ You can retrieve the collected samples in three different ways: with
|
||||
the REST API, with the command line interface, or with the Metering
|
||||
tab on an OpenStack dashboard.
|
||||
|
||||
.. include:: telemetry-system-architecture.rst
|
||||
.. include:: telemetry-best-practices.rst
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
|
||||
telemetry-system-architecture.rst
|
||||
telemetry-best-practices.rst
|
||||
|
||||
|
||||
.. TODO (OL) Translate and add the below files with new name
|
||||
include: telemetry/section_telemetry-system-architecture.xml
|
||||
include: telemetry/section_telemetry-data-collection.xml
|
||||
include: telemetry/section_telemetry-data-retrieval.xml
|
||||
include: telemetry/section_telemetry-alarms.xml
|
||||
|
||||
Loading…
Reference in New Issue
Block a user