Resource Usage Page table views shows statistics in a wrong way

Bug #1249279 reported by Ladislav Smola
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Fix Released
Medium
Ladislav Smola
Havana
Fix Released
Medium
Julie Pichon

Bug Description

It was pointed out to me that some of the table columns are displayed in a wrong way, also the table heading Average 30 days won't be usable for all statistics.

As I look back on this, almost each column has to be considered separately. So e.g. average over some time make
sense only for gauge maybe delta type. Though for the cumulative type max makes much more sense. Also if I want
to see a total value of a particular timeframe, I will have to do some extra computation (like max - min) to see e.g.
network.incoming.bytes of the last month. (the max is a total of all times)

There is e.g. *storage.objects.outgoing.bytes=Delta* but there is a * network. outgoing.bytes=Cumulative* , so there
can't be unified approach of getting average over some time from them. Not sure why it is like that, but I am sure it has
a good reason. :-)

These table stats will be enhanced by the sparklines. So there it will be much more readable.

The solution
==========

Here comes the list of all used meters and description how each meter should be properly displayed:

Global disk usage
------------------------

"disk.read.bytes",
"disk.read.requests",
"disk.write.bytes",
"disk.write.requests"

All above are cumulative. The best here will be show 'total for last 30 days aggregated by project'. But it will have to load all statistics grouped_by resource, computing (min - max) for each resource (gives the total amount in the time period for the one resource=disk). Then sum of them for each project is what we want. Or there can be average of them, not sure what is better.

GlobalNetworkTrafficUsage
---------------------------------------

"network.incoming.bytes"
"network.incoming.packets"
"network.outgoing.bytes"
"network.outgoing.packets"

Same approach as in Global disk usage will be done.

GlobalNetworkUsage
-----------------------------

"network"
"network_create"
"subnet"
"subnet_create"
"port"
"port_create"
"router"
"router_create"
"ip_floating"
"ip_floating_create"

They all follow pattern of these two:

"network" - Gauge - Duration - I suspect it doesn't return the time up, but rather 1 or 0, depending whether the network was up or down during sampling. Not sure what to show here. Maybe counting a duration of each network of the tenant in last 30 days and then show average up-time of them?

"network_create" - Creation requests: I suspect the samples doesn't show e.g. number of network_creates but there is a one record for each network created. So this should show rather count then avg. The field would show 'total in 30 days aggregated by tenant'

GlobalObjectStoreUsage
----------------------------------

"storage.objects"
"storage.objects.size"
"storage.objects.incoming.bytes"
"storage.objects.outgoing.bytes"

all above are either delta or gauge and it make sense to leave them 'last 30 days average aggregated by tenant' as it is now

Confirmation from Ceilometer
--------------------------------------------

Not sure if I understand all of the meters correctly, eglynn please could you confirm or correct the above?

Tags: ceilometer
Ladislav Smola (lsmola)
Changed in horizon:
assignee: nobody → Ladislav Smola (lsmola)
Revision history for this message
Ladislav Smola (lsmola) wrote :
Revision history for this message
Ladislav Smola (lsmola) wrote :

^^^ above post shows that I can't simply count cumulative stats in one query

There needs to be a research about how each meter acts. "somebody already did that" == "somebody already figured out the logic needed to accurately sum resetable cumulative meters over long durations"? https://launchpad.net/~yolanda.robla

We need to document it in the Ceilometer. then we can build pages like this.

Immediate approach on this will be: *deleting* of table views and keeping just chart, until we figure it out.
----------------------------------------------------------------------------------------------------------------------------------------------------

But most probably, data from these tables will be shown as sparklines in various tables with data it belongs to. Like cpu_util with the list of Nova instances, etc. So there is no need for this centralized statistics tables for now. (later there will be some sort of reports probably)

David Lyle (david-lyle)
Changed in horizon:
milestone: none → icehouse-1
importance: Undecided → Medium
status: New → Confirmed
tags: added: havana-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to horizon (master)

Fix proposed to branch: master
Review: https://review.openstack.org/57676

Changed in horizon:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to horizon (master)

Reviewed: https://review.openstack.org/57676
Committed: http://github.com/openstack/horizon/commit/09677c0de86576c1af6cf7f78b8be4d14ab061f8
Submitter: Jenkins
Branch: master

commit 09677c0de86576c1af6cf7f78b8be4d14ab061f8
Author: Ladislav Smola <email address hidden>
Date: Thu Nov 21 14:45:47 2013 +0100

    Deleting statistics tables from resource usage page

    The tables were interpreting the stats in a wrong way, for some stats
    it's not even easily possible to get those stats. We need to go through
    each statistic separately and document it in the Ceilometer docs first.

    Then it's more likely that these table stats will be distributed in
    various tables in dashboard in the form of sparklines so these pages
    won't be needed.

    Fixes bug 1249279

    Change-Id: Ib8c110f5d66fae50df12f8f0beeb99c2b2d00bf6

Changed in horizon:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in horizon:
status: Fix Committed → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to horizon (stable/havana)

Fix proposed to branch: stable/havana
Review: https://review.openstack.org/60317

Akihiro Motoki (amotoki)
tags: removed: havana-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to horizon (stable/havana)

Reviewed: https://review.openstack.org/60317
Committed: http://github.com/openstack/horizon/commit/1f189a7cdcfaef76dca2a02787e2a09ca2faf2c6
Submitter: Jenkins
Branch: stable/havana

commit 1f189a7cdcfaef76dca2a02787e2a09ca2faf2c6
Author: Ladislav Smola <email address hidden>
Date: Thu Nov 21 14:45:47 2013 +0100

    Deleting statistics tables from resource usage page

    The tables were interpreting the stats in a wrong way, for some stats
    it's not even easily possible to get those stats. We need to go through
    each statistic separately and document it in the Ceilometer docs first.

    Then it's more likely that these table stats will be distributed in
    various tables in dashboard in the form of sparklines so these pages
    won't be needed.

    Fixes bug 1249279

    Conflicts:
     openstack_dashboard/api/ceilometer.py
     openstack_dashboard/dashboards/admin/metering/tabs.py
     openstack_dashboard/dashboards/admin/metering/tests.py

    Change-Id: Ib8c110f5d66fae50df12f8f0beeb99c2b2d00bf6
    (cherry picked from commit 09677c0de86576c1af6cf7f78b8be4d14ab061f8)

Thierry Carrez (ttx)
Changed in horizon:
milestone: icehouse-1 → 2014.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.