openstack/openstack-manuals
Code Issues Proposed changes
ce2c661937
openstack-manuals/doc/admin-guide/source/telemetry-system-architecture.rst
Hanxi Liu 9664f1f8a0 Update telemetry architecture document 
- add note for ceilometer api and collector service
- add Gnocchi storage
- fix an inaccurate word

Reference change:I86d1db391a0983f1ea343fe91807976674fee206

Change-Id: Ifd9845e24e58af02fe9e40e7452185b62f621c48
2016-12-15 08:35:28 +08:00

5.7 KiB
Raw Blame History

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-api

Presents aggregated metering data to consumers (such as billing engines and analytics tools).

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.

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

  1. 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.
  2. The ceilometer-api and ceilometer-collector are no longer supported since the Ocata release.
  3. The ceilometer-alarm-evaluator and ceilometer-alarm-notifier services are removed in Mitaka release.

Except for 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. We recommend Gnocchi for time-series storage.

The list of supported database back ends:

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.

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:

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.

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.