Summary

Nova administrators want data on system usage for billing, chargeback, or monitoring purposes.

Release Note

System usage data is emitted from Nova in the form of usage events from Nova's NotificationSystem. The notifications system can be configured to emit events either through nova's logging facility, or send them to a series of AMQP queues (one per notification priority). System usages are emitted as notification events with the INFO priority. Different types of usage events are distinguished via the notifications' event_type, which is a hierarchical dotted string such as compute.instance.create, which allows usages to be easily grouped for aggregation. Usage notifications can be immediate, created when a specific increment of usage occurs (such as creation of an instance) or periodic, generated by a periodic task, like a cron job, and covering usage for a certain period of time. Besides the standard Nova Notification priority, notification timestamp, and event_type, usage notifications contain a payload of data that will vary depending on the event_type. This is presented as a json-formatted hash of key-value pairs. Some of the keys, such as tenant_id will always be present in any usage notification, others will be data relevent to that event_type (For example, instance related notifications will contain data describing the instance.)

For more indepth examples see NotificationEventExamples.

An external application (https://github.com/Cerberus98/yagi) is available that can read notifications from AMQP queues and provide an Atom API. This application generates Atom feeds of the notifications, and can publish feeds via PubSubHubbub (PSH) for efficient distribution of data to subscribers.

Rationale

As a systems integrator, we need the ability for 3rd party systems to query usage information from Nova to determine how to charge customers for use of the platform.

Enterprise customers also need the ability to determine usage data, though for different reasons. For example, a cloud administrator may want to determine VMs that have not been used in several month so that they can be reclaimed and the resources reallocated. Some IT departments may implement a quota system for their users.

Note that Nova itself should not be concerned with billing, but it needs to present a feed of usage data that an external application could use to aggregate the billing data for a requested time period.

User stories

  1. As a systems integrator, I need to retrieve usage data so that I can properly bill my customers.
  2. 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.
  3. 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.
  4. As a systems integrator, I need to provide usage data to multiple third-party systems without building custom interfaces to each one so that I can efficiently utilize my manpower.

Assumptions

Usage data can be aggregated by Tenant ID (as defined in the openstack-accounting blueprint).(i.e. Tenant ID is always present)

There is a billing system that is not a part of OpenStack. Invoicing, billing, and customer management are handled externally to OpenStack/Nova. Nova only has knowledge of an "tenant ID" (as per the openstack-accounting blueprint).

The Tenant ID is the same as the tenant id concept in Keystone, and is known internally to Nova as the "Project ID".

If Nova is installed in multiple regions (aka "zones"), usage data will not span zones; even if the same tenant ID is used in multiple zones, that data must be aggregated external to Nova.

Design and Implementation

There are two events generated for every activity. Previously, events were only generated on activity completion, but now there is an event when the activity starts and, as before, when the activity ends. These are marked as 'compute.instance.<activity>.start' and 'compute.instance.<activity>.end'. The '.end' event is the same as the event previously expected.

Event Types and Payload data:

compute.instance.create.start/.end:

compute.instance.delete.start/.end:

compute.instance.rebuild.start/.end:

compute.instance.resize.prep.start/.end:

compute.instance.resize.confirm.start/.end:

compute.instance.resize.revert.start/.end:

compute.instance.exists:

There is no .start/.end event for this activity ... just the 'compute.instance.exists' event.

compute.instance.update (PROPOSED):

There is no .start/.end event for this activity ... just the 'compute.instance.update' event.

additional events

These are generated for operations monitoring/profiling purposes and shouldn't directly affect usage/billing. They all follow the same signature as the above calls. Some of these notifications may be called from the above operations (for example, shutdown from delete).

compute.instance.shutdown.start/.end

compute.instance.power_off.start/.end

compute.instance.power_on.start/.end

compute.instance.snapshot.start/.end

compute.instance.resize.start/.end

compute.instance.finish_resize.start/.end

Wiki: SystemUsageData (last edited 2012-05-10 16:23:33 by belliott)