The OpenStack Metering Project

5 Nov 2012 @ OpenStack France meetup #2

Julien Danjou


Twitter: @juldanjou


Nick Barcet


Twitter: @nijaba


What About Billing?

  • Billing has been left out of OpenStack core so far as it was not the primary problem and is not a trivial one...
  • Yet almost every OpenStack deployment needs a way to track usage information

Billing: 3 Step Process


Collect usage data


Transform usage data into billable items and calculate costs


Create invoice, collect payment


- Uses a single database accessible to the rating tool.


- Policies are left up to the deployer.

- Billable item * quantity = cost in currency

- Currency often is money, but can be trees, carbon equiv, etc. in case of private clouds


- Emits bills

- Collects funds

- Assigns credits

Ceilometer is for Metering

  • Usages:
    • Billing
    • Auditing
    • Capacity Planning
    • Monitoring (?)
    • Alarms (?)

Data Triggers

Ceilometer inputs are generated three ways

User Action

Creating, modifying, or deleting a resource


Regular audit events stating usage generated by the service


The ceilometer agent asks the service for data periodically

Polling is only used when audit events are not generated by a project for a resource being metered.

Events are preferred because it makes it easier to scale Ceilometer to handle the extra resources

Meter Categories

Ceilometer handles 3 types of meters


Increasing over time (CPU time, disk I/O…)


Discrete items (number of floating IPs, number of image…)


Changing over time (bandwidth)

As we described earlier, Ceilometer is really a system of pluggable components, any of which can be enabled or swapped for a different implementation, depending on your needs.

The collector receives metering event data and writes it to the data store. The data storage API is pluggable, and the current release includes a MongoDB backend. The SQLAlchemy backend to let us store data in MySQL or Postgresql is under development.

Other plugins could be created to write the metering data to your favorite Big Data storage system.

In addition to listening for ceilometer's own metering messages, the collector uses a set of plugins to listen for notification messages coming from other OpenStack services. This lets us recognize, for example, that a new instance has been booted so we can start recording information about it.

Using the existing notification messages lets ceilometer integrate with the other services without requiring any modifications to those services.

For continuous monitoring of resources we have two separate agent processes. The compute agent runs on each hypervisor server and polls the hypervisor for statistics about each instance running there.

This is where we get information such as CPU time, bandwidth, etc. The pollsters are loaded from another set of plugins, so it is possible to write your own custom polling code to run in the compute agent and collect your own statistics.

The compute agent sends metering messages in a standard format to the collector to be processed and stored. The collector scales horizontally so it is possible to run multiple copies attached to the same message bus and distribute load.

Because all of the metering data is traveling over the message bus you can replace the data storage aspect of the collector with your own application, configured to receive the same messages.

The Central Agent runs on a management node and uses a different set of plugins to poll the other OpenStack services such as Glance and Cinder.

This is where we get information about images, for example.

The central agent sends metering messages in that same standard format directly to the collector to be processed and stored.

To use the data collected by ceilometer, a billing or rating system can call the REST-style query API.

The current API is an admin-style API meant specifically to export data in bulk for billing systems.

However, we do plan...

...to implement a user-level API which will also let us integrate with Horizon to present usage details to end users.

In the mean time,...



GET /v1/resources/(resource)/meters/(meter)/volume/sum


GET /v1/resources/(resource)/meters/(meter)/volume/max


GET /v1/resources/(resource)/meters/(meter)/duration

Raw Events

GET /v1/resources/(resource)/meters/(meter)


...the existing API support a variety of queries about the resources being metered and the values of the meters.

Sum - Add volume values from the matching events and return the result

Maximum - Find the largest volume value in the matching events and return it

Duration - Calculate the time range for which matching events exist (used to calculate instance hours, volume lifetime, etc.)

Raw Events - Retrieve the recorded events for more complex processing


That's where the project is right now...





  • Delivered mid-October
  • Collects base metering
    • nova
    • glance
    • cinder
    • quantum
  • Basic API access
  • Incubated Project
  • User accessible API?
  • Integration example with Horizon
  • New agents for other openstack components
    • Swift
    • Heat?
  • New uses of collector?
  • SQLAlchemy storage driver completed
  • Multiple publishers?
  • Core Project
  • TBD

...we have just completed our Folsom release, version 0.1

It includes metering for resources owned by nova (instances), glance (images), cinder (storage), and quantum (networks)

For Grizzly our main goal could be summed up as "better integration," both with the community and with the other OpenStack projects.

We will be working on extending our API, building notification listeners for swift and possibly heat, completing our integration with quantum, and completing the SQLAlchemy storage backend.

Our ultimate goal is being brought in as a core project during the H time frame.

In the mean time, the existing system has a minimum level of functionality that enabled us...


Julien Danjou


Twitter: @juldanjou




Freenode: #openstack-metering

E-mail: openstack-dev [ceilometer]

Nick Barcet


Twitter: @nijaba