Services > Management

OpenStack Ceilometer

Overview

The Ceilometer telemetry service provides usage data for its resources in the noris cloud. This data can be used for billing, system monitoring or alarms. The data is collected by messages sent by the noris cloud components or by querying the underlying infrastructure (e.g. libvirt).

Ceilometer includes a storage service that communicates with authenticated agents through a trusted messaging system to collect and aggregate data. The API server, the central agent, the data storage service and the collection agent are provided in noris cloud management plan on different hosts.

Details

Ceilometer includes the following components:

  • Ceilometer agent compute: An agent running on each compute node to retrieve resource usage statistics. Each Nova-Compute node must have and run a Ceilometer-Compute-Agent.
  • Ceilometer-Agent-Central: An agent running on a central management server to retrieve resource utilization statistics that are not tied to instances or compute nodes.
  • Ceilometer collector: An agent running on one or more central management servers to monitor message queues. Messages are processed and converted into telemetry messages and sent back to the message bus with the corresponding topic. Telemetry messages are written to the data memory without modification.
  • Ceilometer Alarm Evaluator: Alarm service that triggers status transitions on alarms
  • Ceilometer Alarm Notifier: alarm service that performs necessary actions when alarms are triggered
  • Ceilometer-notification: An agent that pushes metrics to the collection service of various OpenStack services
  • Database: For collected usage data of collective agents. Only the collector agents and the API server have access to the database.
  • Ceilometer API: Runs on one or more central management servers to grant access to data in the database.
  • RabbitMQ Server: Provides the AMQP message queue. RabbitMQ handles OpenStack transaction management, including queuing, distribution, security, management, clustering and federation. Messaging becomes especially important when an OpenStack deployment is scaled and its services run on multiple machines.