Ceilometer

The OpenStack Metering Project

5 Nov 2012 @ OpenStack France meetup #2

Julien Danjou

jd__@freenode

Twitter: @juldanjou

julien@danjou.info

Nick Barcet

nijaba@freenode

Twitter: @nijaba

nick.barcet@canonical.com

5 Nov 2012 @ OpenStack France meetup #2

Julien Danjou

jd__@freenode

Twitter: @juldanjou

julien@danjou.info

Nick Barcet

nijaba@freenode

Twitter: @nijaba

nick.barcet@canonical.com

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

Metering

Collect usage data

Rating

Transform usage data into billable items and calculate costs

Billing

Create invoice, collect payment

Metering

Collect usage data

Rating

Transform usage data into billable items and calculate costs

Billing

Create invoice, collect payment

Metering

- Uses a single database accessible to the rating tool.

Rating

- 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

Billing

- 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

Audit

Regular audit events stating usage generated by the service

Polling

The ceilometer agent asks the service for data periodically

User Action

Creating, modifying, or deleting a resource

Audit

Regular audit events stating usage generated by the service

Polling

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

Cumulative

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

Gauge

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

Delta

Changing over time (bandwidth)

Cumulative

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

Gauge

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

Delta

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,...

Simple REST API

Sum

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

Maximum

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

Duration

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

Raw Events

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

http://ceilometer.readthedocs.org/en/latest/api.html

Sum

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

Maximum

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

Duration

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

Raw Events

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

http://ceilometer.readthedocs.org/en/latest/api.html

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

Parameters:

  • resource – The ID of the resource.
  • meter – The name of the meter.
  • start_timestamp – ISO-formatted string of the earliest time to include in the calculation.
  • end_timestamp – ISO-formatted string of the latest time to include in the calculation.
  • search_offset – Number of minutes before and after start and end timestamps to query to compensate for discrete events falling outside of the true window of interest for a continuous query such as duration.

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

Roadmap

Grizzly

H

Folsom

  • 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

Grizzly

H

Folsom

  • 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...

Questions?

Julien Danjou

jd__@freenode

Twitter: @juldanjou

http://julien.danjou.info

http://launchpad.net/ceilometer

http://ceilometer.readthedocs.org

Freenode: #openstack-metering

E-mail: openstack-dev [ceilometer]

Nick Barcet

nijaba@freenode

Twitter: @nijaba

nick.barcet@canonical.com

Julien Danjou

jd__@freenode

Twitter: @juldanjou

http://julien.danjou.info

http://launchpad.net/ceilometer

http://ceilometer.readthedocs.org

Freenode: #openstack-metering

E-mail: openstack-dev [ceilometer]

Nick Barcet

nijaba@freenode

Twitter: @nijaba

nick.barcet@canonical.com