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:
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. It is intended to replace ceilometer-agent-central, ceilometer-agent-compute, and ceilometer-agent-ipmi.
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.
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:
Note
DB2 nosql support is deprecated as of Liberty and will be removed in Mitaka as the product is no longer in development.
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:
Note
For details about hypervisor support in libvirt please check the Libvirt API support matrix.
Telemetry is able to retrieve information from OpenStack Networking and external networking services:
This module of OpenStack uses OpenStack Identity for authenticating and authorizing users. The required configuration options are listed in the Telemetry section in the OpenStack Configuration Reference.
The system uses two roles: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 Alarms handling can be found in this guide.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/legalcode.