2 Replies Latest reply on Feb 25, 2009 2:33 PM by ips

    Extending measurement data

    ccrouch

      I'm posting this to start a discussion on requirements and designs for extending our measurement data system to support better analysis/alerting on data such as call times. One use case would be wanting to collect method invocation timings on all the methods on an EJB, graph how those timings change over time and let you create alerts if timings breach a particular value.

      Arguably instead of the single metric value data type we have now this would require a more tabular approach, e.g. one axis for timing values, another for the methods themselves. Potentially related jira:

      http://jira.rhq-project.org/browse/RHQ-587

      Please add your thoughts on
      a) more use cases
      b) design considerations

      Thanks

        • 1. Re: Extending measurement data
          mazz

          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

            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)