Bug 536212 - (RHQ-587) RFE: tabular data measurement type
RFE: tabular data measurement type
Status: NEW
Product: RHQ Project
Classification: Other
Component: Monitoring (Show other bugs)
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2008-06-17 11:37 EDT by John Mazzitelli
Modified: 2014-05-14 10:13 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Mazzitelli 2008-06-17 11:37:00 EDT
There are currently three types of measurement data: dynamic, trait and calltime.

We need a fourth - "tabular".

This would allow a measurement to report a table of data, rather than just an individual value or a min/max/avg set of values.

I'm not quite sure exactly how I would propose this to be used but I know I need it :)

Think things like: "users that accessed my app in the past 10 minutes" where the tabular data has columns "USER_ID", "NUMBER OF HITS":

john : 4
bob : 6
jim : 1

Tells me John hit the app 4 times during this 10-minute time bucket, bob 6 times and jim 1 time.

The UI could then smartly render the tabluar data across time sorted on one of the columns in the table.  For example, I would want to sort on NUMBER OF HITS and only see a page of size 2, in which case the UI would show me:

bob : 6
john : 4

If I had more measurements over time, we could aggregate the tablular data somehow (numerical data could be summed, unsure how you would aggregate String values).  So if in the next time slice we got this measurement:

mary : 10
jim : 1
bob : 5

The UI could show

bob : 11  (the sum of the 6 from the first time slice and 5 from the second)
mary : 10 (she wasn't in the first time slice but is in the second).

That's probably a hokey example above, I'm sure greg can think of alot better ones.
Comment 1 Joseph Marques 2008-06-17 11:43:18 EDT
or what if we had a full reporting subsystem, that allowed you to query and generate statistics against an arbitrary part of the domain model, not just measurement?
Comment 2 Heiko W. Rupp 2008-06-17 11:44:37 EDT
Can't you just use calltime with bob and mary being the url and 11, 10 being the time?
Comment 3 Joseph Marques 2008-06-17 12:22:31 EDT
Heiko, perhaps in this case he could have...because this is an example of tabular metrics that degenerate into one of our available measurement paradigms.  A fuller example, I think, would be for the users to have several properties to be displayed concurrently:

john : 4 3 1
bob : 6 5 2
jim : 1 1 1
Comment 4 Greg Hinkle 2008-07-30 09:35:30 EDT
Yea, there used to be another version of this (callflow) that had dynamic (plugin definable) columns (and added hierarchy). The complication in the design was that we need things to be transient and temporal to be able to store large amounts of data, but these are inherently additive. The purpose was to support tracking things like SQL statements (where the statement is tracked along with failures, successes, total rows returned, etc.) as well as lightweight profiling (all the same except add the hierarchy).

I think this would be hard to collect, hard to merge into a model, hard to maintain over time and maybe hard to render. I'd need to see more about the exact design before we can see how far out it might be.
Comment 5 John Mazzitelli 2009-02-25 09:47:09 EST
this is being discussed here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151149
Comment 6 Red Hat Bugzilla 2009-11-10 16:12:28 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-587
Comment 7 wes hayutin 2010-02-16 16:09:22 EST
Mass move to component = Monitoring
Comment 8 Corey Welton 2010-10-06 23:15:47 EDT
triaged 5-Oct

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