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": 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.
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?
Can't you just use calltime with bob and mary being the url and 11, 10 being the time?
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: USER : TOTAL_HITS UNIQUE_HITS NUM_SESSIONS john : 4 3 1 bob : 6 5 2 jim : 1 1 1
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.
this is being discussed here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151149
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-587
Mass move to component = Monitoring
triaged 5-Oct