The OpenStack Metering Project
5 Nov 2012 @ OpenStack France meetup #2
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
- Capacity Planning
- Monitoring (?)
- Alarms (?)
Ceilometer inputs are generated three ways
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
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,...
Simple REST API
...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
- 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...
- Delivered mid-October
- Collects base metering
- Basic API access
- Incubated Project
- User accessible API?
- Integration example with Horizon
- New agents for other openstack components
- New uses of collector?
- SQLAlchemy storage driver completed
- Multiple publishers?
- Core Project
...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...
E-mail: openstack-dev [ceilometer]