Ceilometer
(Metereing in OpenStack.)
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.
Why Ceilometer ?
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.
What Ceilometer aims to provide ?
●   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.
CEILOMETER ARCHITECTURE
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
Five basic components of Ceilometer.
➢   Compute Agent

➢   Central Agent

➢   Collector

➢   Data Store

➢   API Server
Compute Agent

A compute agent runs on each compute node and polls
for resource utilisation statistics.
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.
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.
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).
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.
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.
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
References
●   http://wiki.openstack.org/EfficientMetering

●   http://ceilometer.readthedocs.org/en/latest/index.html

●   http://wiki.openstack.org/EfficientMetering/ArchitectureProposalV1
THANKS...



            Syed Armani
            Twitter: @syedarmani

OpenStack Ceilometer

  • 1.
  • 2.
    Ceilometer project isthe cloud metering component for OpenStack based clouds. It will provide an API to query collected data from the existing billing system.
  • 3.
  • 4.
    Administrators wanted dataon 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.
  • 5.
  • 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.
  • 7.
  • 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 componentsof Ceilometer. ➢ Compute Agent ➢ Central Agent ➢ Collector ➢ Data Store ➢ API Server
  • 10.
    Compute Agent A computeagent runs on each compute node and polls for resource utilisation statistics.
  • 11.
    Central Agent A centralagent 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 runson 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 datastore is a database capable of handling concurrent writes from one or more collector instances and reads (from the API server).
  • 14.
    API SERVER An APIserver 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
  • 17.
    References ● http://wiki.openstack.org/EfficientMetering ● http://ceilometer.readthedocs.org/en/latest/index.html ● http://wiki.openstack.org/EfficientMetering/ArchitectureProposalV1
  • 18.
    THANKS... Syed Armani Twitter: @syedarmani