EfficientMetering

Efficient Metering in OpenStack Blueprint

Uses cases

• need a tool to collect per customer usage
• need an API to query collected data from existing billing system
• data needed per customer, with an hour level granularity, includes:
  • Compute - Nova:
    • instances (type, availability zone) - hourly usage
    • cpu - hourly usage
    • ram - hourly usage
    • nova volume block device (type, availability zone) - hourly usage
      • reserved
      • used
  • network (data in/out, availability zone) - hourly bytes
    • differentiate between internal and external end-points
    • External floating IP ( - hourly count
• Storage - Swift
  • total data stored - hourly bytes
  • data in/out
  • differentiate between internal and external end-points

^l

Proposed design

Counters

The following is a first list of counters that needs to be collected in order to allow billing systems to perform their tasks. This list must be expandable over time and each administrator must have the possibility to enable or disable each counter based on his local needs.

	Counter name	Component	Volume unit	Secondary
c1	instance	nova computr	minute	type
c2	cpu	nova compute	minute	type
c3	ram	nova compute	Megabyte
v1	bd_reserved	nova volume	Megabyte
v2	bd_used	nova volume	Megabyte
n1	net_in_int	nova network	Kbytes
n2	net_in_ext	nova network	Kbytes
n3	net_out_int	nova network	Kbytes
n4	net_out_ext	nova network	Kbytes
n5	net_float	nova network	count
o1	obj_volume	swift	Megabytes
o2	obj_in_int	swift	Kbytes
o3	obj_in_ext	swift	Kbytes
o4	obj_out_int	swift	Kbytes
o5	obj_out_ext	swift	Kbytes

Note for network counters (n1-n4): the distinction between internal and external traffic requires that internal networks be explicitly listed in the agent configuration.

Agents

• Agent on each nova compute node to accumulate and send counters for c1, c2, c3, n1, n2, n3, n4. The agent is likely to be pulling this information from libvirt.
• Agent on each nova volume node to accumulate and send counters for v1, v2
• Agent on each nova network node to accumulate and send counters for n5 (can this be pulled directly from the nova database?)
• Agent on each swift proxy to forward existing accounting data o1 and accumulate and send o2-o5

Storage

• Data is stored on a per account basis in a db on a per availability zone basis
• Per account records hold
  • account_id (same as keystone’s)
  • account_state (enabled, credit disabled, admin disabled)
• Per event records hold
  • account_id
  • counter_type
  • counter_volume
  • counter_duration
  • counter_datetime
  • message_signature
  • message_id
• db is not directly accessible by any other mean than API
• a process must collect messages from agent and store data
• a process may validate counters against nova event database
• a process may verify that messages were not lost
• a process may verify that accounts states are in sync with keystone

Messaging

• data is sent from agents to storage via a trusted messaging system (RabbitMQ?)
• message queue is separate from other queues
• messages in queue are signed and non repudiable (see link for explanation on this exotic word)

API

• Database can only be queried via a REST API
• Requests must be authenticated (separate from keystone, or only linked to accounting type account)
• API Server must be able to be redundant
• Requests allow to
  • GET account_id list
  • SET account_id state
    • When this is called, the API server transfers the request to the keystone database to ensure account state is in sync
• GET list of counter_type
  • GET list of events per account
    • optional start and end for counter_datetime
    • optional counter_type
• GET sum of (counter_volume, counter_duration) for counter_type and account_id
  • optional start and end for counter_datetime