Bug 536212 (RHQ-587)

Summary: RFE: tabular data measurement type
Product: [Other] RHQ Project Reporter: John Mazzitelli <mazz>
Component: MonitoringAssignee: RHQ Project Maintainer <rhq-maint>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0.1CC: cwelton, jshaughn
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-587
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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