2. Ceilometer project is the cloud metering component for
OpenStack based clouds. It will provide an API to query
collected data from the existing billing system.
4. Administrators wanted data on system usage for billing,
chargeback, or monitoring purposes.
● As a systems integrator, I need to retrieve usage data so that
I can properly bill my customers.
● As a systems integrator or enterprise cloud administrator, I
want to monitor usage data over time so that I can optimize
the utilization of my resources.
● As an business or agency that supports multiple projects, I
need to account for the resources consumed by each project
so that I can properly meet accounting and budget standards.
● As a systems integrator, I need to provide usage data to
multiple third-party systems without building custom
interfaces.
6. ● Ceilometer provide efficient collection of metering data i.e.
CPU and Network costs.
● Allow deployers to integrate with the metering system directly
or by replacing components.
● Data may be collected by notifications send by the existing
system or by polling the infrastructure.
● Allow deployers to configure the type of data collected to
meet their operating requirements.
● The data collected by the metering system is made visible to
some users through REST API.
● Signed and non-repudiable metering messages.
8. System Data
● System usage data is emitted from Nova in the form of usage events from
nova's notification system.
● System usages are emitted as notification events with the INFO priority.
● A storage daemon communicates with the agents to collect their data and
aggregate them.
● The agents collecting data are authenticated to avoid pollution of the
metering service.
● The data is sent from agents to the storage daemon via a trusted
messaging system.
● The data / messages exchanged between agents and the storage daemon
use a common messages format The content of the storage is made
available thru a REST API providing aggregation
9. Five basic components of Ceilometer.
➢ Compute Agent
➢ Central Agent
➢ Collector
➢ Data Store
➢ API Server
10. Compute Agent
A compute agent runs on each compute node and polls
for resource utilisation statistics.
11. Central Agent
A central agent runs on a central management server to poll
for resource utilisation statistics for resources not tied to
instances or compute nodes.
12. Collector
A collector runs on one or more central management
servers to monitor the message queues. Notification
messages are processed and turned in to metering
messages and sent back out on to the message bus
using the appropriate topic.Metering messages are
written to the data store without modification.
13. Data Store
A data store is a database capable of handling
concurrent writes from one or more collector instances
and reads (from the API server).
14. API SERVER
An API server runs on one or more central management
servers to provide access to the data from the data store.
Only the collector and API sever have access to the
datastore.
15. Plugin System
● A plugin system based on setup tools entry points makes it to easy to add new
monitors in the collector or subagents for polling.
● Installing a plugin automatically activates it the next time, the ceilometer daemon
starts.
● A global configuration option can be used to disable the installed plugins.
● Plugins may disable themselves at runtime based on configuration settings. For
example , the plugin for polling libvirt does not run if it sees that the system is
configured using some other virtualization tool.
16. POLLING
● Metering data comes through notifications built in to existing openstack
components and by polling the infrastructure(such as libvirt).
● Polling for compute resources is handled by an agent running on the compute
node where communication with the hypervisor is more efficient.
● Polling for resources not tied to the compute node is handled by the central agent.
● The central agent daemon is configured to run one or more pollster plugins using
the ceilometer.poll.central namespace
