ceilometer/doc/source/admin/telemetry-system-architecture.rst

System architecture

The Telemetry service 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 service is built from the following agents and services:

ceilometer-polling

Polls for different kinds of meter data by using the polling plug-ins (pollsters) registered in different namespaces. It provides a single polling interface across different namespaces. The compute namespace polls the local hypervisor to acquire performance data of local instances. The central namespace polls the public RESTful APIs of other OpenStack services such as Compute service and Image service. The ipmi namespace polls the local node with IPMI support, in order to acquire IPMI sensor data and Intel Node Manager datahost-level information.

ceilometer-agent-notification

Consumes AMQP messages from other OpenStack services, normalizes messages, and publishes them to configured targets.

Note

The ceilometer-polling service provides polling support on any namespace but many distributions continue to provide namespace-scoped agents: ceilometer-agent-central, ceilometer-agent-compute, and ceilometer-agent-ipmi.

Except for the ceilometer-polling agents polling the compute or ipmi namespaces, 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. Each of the data models have their own storage service and each support various back ends.

The list of supported base back ends for measurements:

• gnocchi

The list of supported base back ends for alarms:

• MySQL
• PostgreSQL

The list of supported base back ends for events:

• ElasticSearch
• MongoDB
• MySQL
• PostgreSQL
• HBase

Supported hypervisors

The Telemetry service collects information about the virtual machines, which requires close connection to the hypervisor that runs on the compute hosts.

The following is a list of supported hypervisors.

• The following hypervisors are supported via libvirt

  • Kernel-based Virtual Machine (KVM)
  • Quick Emulator (QEMU)
  • Linux Containers (LXC)
  • User-mode Linux (UML)

  Note

  For details about hypervisor support in libvirt please check the Libvirt API support matrix.

• Hyper-V

• XEN

• VMware vSphere

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
  • Load-Balancer-as-a-Service (LBaaS) meters
  • VPN-as-a-Service (VPNaaS) meters
• SDN controller meters:
  • OpenDaylight
  • OpenContrail

Users, roles, and projects

This service 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. Alternatively, gnocchi can be configured without authentication to minimize overhead.

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 telemetry-alarms handling can be found in this guide.