Bug 1042356 - [RFE][ceilometer]: Add an "uptime" measurement.
Summary: [RFE][ceilometer]: Add an "uptime" measurement.
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/ceil...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 21:51 UTC by RHOS Integration
Modified: 2015-03-19 17:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 17:12:28 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description RHOS Integration 2013-12-12 21:51:21 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/ceilometer/+spec/uptime-measurement.

Description:

It would be great to be able to determine the uptime of a machine in a given period of time.

Currently, an "instance" measurement is available. It doesn't exactly address this issue, since it does not give information about the uptime/downtime of a VM. It is more of an "instance existence time".

Possible solution:
-------------------
Nova sends notifications when a vm is started/stopped/suspended/resumed (this patch is needed : https://review.openstack.org/#/c/38485/). Ceilometer could keep this information, and upon a user request, compute the result expected by the user.

Currently, a user may compute the uptime of a VM during a [t1;t2] period of time using something like this pseudo-code:

    active = None
    latest_start_timestamp = None # Last time the VM was brought up.
    total_uptime = 0.0 # In seconds.

    for sample in samples:
        state = sample['resource_metadata']['state']
        if state in ['active']:
            if not active:
                active = True
                latest_start_timestamp = sample['timestamp']
        elif state in ['stopped', 'suspendend']:
            if active:
                active = False
                total_uptime += sample['timestamp'] - latest_start_timestamp
        else:
            raise ValueError(state) # This state is not handled yet.

    if active:
        total += t2 - samples[-1]['timestamp']

Note that here, the time spent between t1 and sample[0]['timestamp'] is not taken into account. We have to find a way to know the state of the VM in [t1;sample[0]['timestamp']]. This can probably be done by looking at the 'event_type' field and/or by retrieving one older statement.

This could probably be nicely implemented in Ceilometer. The downtime could be computed the same way if necessary.

Another way of solving this issue would be to add a more generic meter (such as 'durations'), that would return the time spent in each state:

    {
        total: 42,
        active: 30,
        building: 4,
        scheduling: 2,
        stopped: 4,
        suspended: 2
    }

The computation of each state duration could be done as previsouly described.



Technical details
---------------------
* Add q.metadata_field, to be able to run queries that use a filter one a resource_metadata[X] field:
        q.metadata_field=state, q.op=eq, q.value=active

* The stats should return a "duration with resource_metadata[X] == Y" column when q.metadata_field is specified.

* Caching the results.
It seems hard to keep the current value, since it depends on the time interval given in each query. We should probably not worry too much about caching right away. Anyway, this would only be a problem when querying statistics over a very large amount of time, and with a lot of notifications to process.

* Other use cases
For how long has a VM been using a given kernel ?
    q.metadata_field=kernel_id&q.op=eq&q.value=HASH
    In order to do this, we would need Nova to send us a notification when a
    new kernel is installed.

For how long has a VM been using N cpus ?
    q.metadata_field=vcpus&q.op=eq&q.value=N
    In order to do this, we would need Nova to send us a notification when the 
    number of vcpus changes


Specification URL (additional information):

None


Note You need to log in before you can comment on or make changes to this bug.