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-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. ceilometer-agent-compute Polls the local hypervisor or libvirt daemon to acquire performance data for the local instances, messages and emits these data as AMQP messages. ceilometer-agent-notification Consumes AMQP messages from other OpenStack services. ceilometer-agent-ipmi Polls compute node with IPMI support, in order to acquire IPMI sensor data and Intel Node Manager data. ceilometer-collector Consumes AMQP notifications from the agents, then dispatches these data to the metering 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. Besides the ceilometer-agent-compute service, 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 the samples, alarm definitions and alarms are stored. Multiple database back ends can be configured in order to store samples and alarms separately. The list of supported database back ends: MongoDB MySQL PostgreSQL HBase 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: Kernel-based Virtual Machine (KVM) Quick Emulator (QEMU) Linux Containers (LXC) XEN User-mode Linux (UML) For details about hypervisor support in Libvirt please check the Libvirt API support matrix. Hyper-V VMWare vSphere
Supported networking services Telemetry is able to retrieve information from OpenStack Networking and external networking services: OpenStack Networking: Basic network metrics Firewall-as-a-Service (FWaaS) metrics Loadbalancer-as-a-Service (LBaaS) metrics VPN-as-a-Service (VPNaaS) metrics SDN controller metrics: OpenDaylight OpenContrail
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 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 in this guide.