Bug 986367

Summary: [RFE] Provide transformer for unit scaling and rate-of-change conversion
Product: Red Hat OpenStack Reporter: Eoghan Glynn <eglynn>
Component: openstack-ceilometerAssignee: Eoghan Glynn <eglynn>
Status: CLOSED ERRATA QA Contact: Kevin Whitney <kwhitney>
Severity: high Docs Contact:
Priority: high    
Version: 4.0CC: ajeain, breeler, eglynn, jruzicka, mlopes, pbrady, sgordon, srevivo
Target Milestone: Upstream M2Keywords: FutureFeature, OtherQA
Target Release: 4.0   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/ceilometer/+spec/transformer-unit
Whiteboard:
Fixed In Version: openstack-ceilometer-2013.2-0.2.b1.el6ost Doc Type: Enhancement
Doc Text:
OpenStack Metering now has "transformers", which are a way of calculating a rate-of-change, or doing unit scaling conversions. Transformers are configurable and the values they produce as output can be emitted as derived meters. This enables derived meters to be calculated from the original observations via configurable rules, for example simple scaling such as conversion from °F to °C, or more involved derivation of gauge rates from cumulative totals. OpenStack Metering now provides a generic transformer for such conversions, that is used out-of-the-box for deriving CPU utilization percentage from cumulative CPU time, and may also be re-used for any additional cumulative-to-gauge conversions required via simple configuration.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-20 00:13:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 973191, 975499, 987450, 1055813    

Description Eoghan Glynn 2013-07-19 15:04:46 UTC
We need the ability to flexibly and efficiently emit derived meters, where the sample values are calculated from a primary meter in the form of a rate-of-change or unit scaling conversion.

This should be achievable via a generic transformer, where the scaling rule is defined in configuration, as opposed to requiring that new pollsters are written on a case-by-case basis.

The canonical example would be the cpu_util meter, which requires that CPU utilization % is calculated on the basis of the first derivative of the cumulative CPU time for an instance.

The existing pollster that currently emits this derived meter should be obsoleted in favour of the generic transformer, appropriately configured:

-
    name: meter_pipeline
    interval: 600
    counters:
        - "*"
    transformers:
    publishers:
        - rpc://
-
    name: cpu_pipeline
    interval: 60
    counters:
        - "cpu"
    transformers:
        - name: "rate_of_change"
          parameters:
              target:
                  name: "cpu_util"
                  unit: "%"
                  type: "gauge"
                  scale: "100.0 / (10**9 * (resource_metadata.cpu_number or 1))"
              replace: False
    publishers:
        - rpc://


Upstream blueprint: https://blueprints.launchpad.net/ceilometer/+spec/transformer-unit

Comment 4 Eoghan Glynn 2013-10-21 15:25:54 UTC
How To Test
===========

0. Install packstack allinone, then spin up an instance in the usual way. 


1. Ensure the old cpu_util pollster is no longer loaded:

  sudo grep cpu_util /usr/lib/python2.?/site-packages/ceilometer-2013*.egg-info/entry_points.txt
  # (no output expected)

whereas the primary cpu pollster is still loaded:

  sudo grep '\<cpu\> /usr/lib/python2.?/site-packages/ceilometer-2013*.egg-info/entry_points.txt


2. Ensure that the cpu and cpu_util meters can be configured with independent cadences:

  sudo sed -i '/^ *name: cpu_pipeline$/ { n ; s/interval: 600$/interval: 60/ }' /etc/ceilometer/pipeline.yaml
  sudo service openstack-ceilometer-compute restart

  sleep 300

  ceilometer sample-list -m cpu
  ceilometer sample-list -m cpu_util

Confirm that the over the most recent time period, the cpu_util is being reported approximately at a ratio of 10:1 in frequency as compared to the cpu meter.

Comment 5 Ami Jeain 2013-10-28 11:50:20 UTC
QANAK'ing due to QE capacity

Comment 11 errata-xmlrpc 2013-12-20 00:13:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2013-1859.html