Gnocchi, what it is and how we can bill against it

What we'll cover

• Ceilometer and where it is now
• Gnocchi and what problem it solves
• Leveraging Gnocchi to use for simplistic billing

Ceilometer

Ceilometer originated as the Telemetry component for OpenStack. It soon became a monolithic project responsible for all things measurement in the OpenStack ecosystem. This organic growth became a pain point in performance at scale.

That's a lot to handle!

Essentially Ceilometer is responsible for:

• Polling different interfaces (libvirt, ipmi, switches etc..)
• Listening to notifications on the message bus (Compute, Network, Volume, Image, Object Storage etc...)
• Storing all this data as metrics and events
• Storing and evaluating alarms for Heat (commonly used for autoscaling, monitoring etc...)

Time to decouple the responsibilities

Modern Ceilometer Architecture

Gnocchi

• Takes over the metric storage for OpenStack
• Using time series database storage
• Comprehensive metrics available across
  OpenStack projects
• Much more efficient data structures
• Drastic improvement in data usage and
  performance over Ceilometer. Previously computational complexity was of O(n) where n is the number of samples recorded. Gnocchi is O(1)!
• Hyperlinked RESTful API
• Filtering by metadata attributes (fine-grained filtering)

Source: https://julien.danjou.info/blog/2015/gnocchi-benchmarks

Resource Types

Stores many different resources logically grouped by associated metadata.

Url: http://os.dev.digitalpacific.com.au:8041/v1/resource

VM Instance

Metadata

Metrics

Url: http://os.dev.digitalpacific.com.au:8041/v1/resource/
instance/0d5...4ab

VM Instance Network Interface

Metadata

Metrics

Url: http://os.dev.digitalpacific.com.au:8041/v1/resource/instance_network_interface/8a0...f97

VM Instance Volume

Metadata

Metrics

Url: http://os.dev.digitalpacific.com.au:8041/v1/resource/instance_disk/4e7...e28

Image

Metadata

Metrics

Url: http://os.dev.digitalpacific.com.au:8041/v1/resource/image/017...748

Metric Details

Data is stored based on archive policies.
Each archive policy will store the data for a timespan which equals the granularity times the points. When the timespan passes, the data will be removed.

An archive policy can be applied across any metric. This means that we can created archive policies defined for hourly billing eg. 1 hour granularity for a timespan of 3 months for auditing.

Url: http://os.dev.digitalpacific.com.au:8041/v1/resource/instance/
0d5...4ab/metrics/memory.usage

Metric Measurements Example -

We can bill this! 

Start time of measurement

Measurement length (granularity)
in seconds (30 minutes)

Data value (total bytes)

Url: http://os.dev.digitalpacific.com.au:8041/v1/resource/instance_network_interface/
8a0...f97/metrics/network.incoming.bytes/measures/

Contador

• Simple browsable RESTful API
• Minimal persistence layer (Only billing rules are stored) means very light architecture
• Plugs into Gnocchi natively
• Django REST framework (DRF) app
• Keystone v3 token access (Works as a passthrough to Gnocchi for auth)
• Only the fly report building acheivable through leveraging Gnocchi performance

Contador - Billing Policies

• Applies billing to a Gnocchi metric
• Cost applied per metric unit
• Can charge metrics by time
• Measurements can be charged at a flat rate over time, or by quantity
• Applies to specific resource
• Can filter resources by resource metadata attributes
• Puts the ownice of the data format on Gnocchi's Archive Policies
• Grandfathering of billing policy changes

Contador - Billing Resources

• Groups metrics via Heat resources
• Useful for predictive billing and grouping billing policies
• You can describe abstract deployments using Heat resources. This is also good for grouping OpenStack resources

Contador - Building a report

• Accepts a date range with access token and returns costs for that period (in this case a project-scoped token)
• Runs through the defined billing policies and looks for measures which match the billing policy filtering, metric name and date range

What can we improve?

• Pluggable output formatters
• Implement Keystone auth directly
• Port to use pecan & oslo
• Abstract logical grouping of billing policies
• Filtering by foreign key relations

Questions?