-
1. Re: Extending measurement data
mazz Feb 25, 2009 9:44 AM (in response to ccrouch)The main use case we are talking about here is EJB method call times along with invocation times. But similar use cases are hibernate statistics and SQL executions (we can be considered analogous - SQL statements executed, average execution time, successes, failures). Also, web activity (which users hit an app and how many times they hit it - that's the use case in the jira).
Tabular results are like this (example is for EJB method data):
METHOD NAME | # TIMES CALLED
getProperty | 5
execute | 10
setTime | 7
Or for SQL results:
SQL | # TIMES EXECUTED | AVG ROWS RETURNED
select * from table1 | 5 | 50
select id from person | 7 | 1
Each table of results would be time-stamped so we would know when the data was collected.
Looking at those examples, the problem with trying to view these as dynamic measurement data becomes apparent - how do you render this in a graph whose X-axis is time? Think how the dynamic measurement data is rendered today - each measurement data point is a "double" - just a number. Its easy to graph that - Y-axis is the value of that measurement data and X-axis is time.
But with tabular data, its not a 2-D graph. X-axis might still be time, but how do you graph N-columns of data? If you can guarantee the tabular data is two-columns wide, then perhaps we can say, "the first column represents a single dataset (thus a line on the graph - so you would overlay several lines representing each dataset) with the second column being the value (this would assume the second column of data is numeric). But how do you handle this if the table has more than two columns? And how do you handle this if the data is not numeric but simple strings (say, boolean values for example).
These are the kinds of issues the design must address in order to implement a solution. -
2. Re: Extending measurement data
ips Feb 25, 2009 2:33 PM (in response to ccrouch)We could also provide the ability to alert on call-time metrics without adding support for tabular data. Here's a couple examples of new condition types we could add:
Call time metric [EJB Method Call Time] is [greater than] [5 seconds] for any method.
Call time metric [EJB Method Call Time] is [greater than] [500 milliseconds] for method [getCurrentAvailability].
(these two would check reported MAX values)