Concept:
Alerting is a useful feature in RHQ. However, RHQ is so far not able to raise alerts on the basis of call-time data. Call-time data pre-aggregates data into max, min, and avg (total/count) in map indexed by call destinations.

I propose to implement alerting for call-time data. Alerting should have two features: comparison to absolute values and change detection (i.e. comparison to old values).

General issues: Alerts for call-time data will always work on one of the seperate values included in the pre-aggregated structure, i.e. max, min, avg, and count. Moreover, only those call-time data map entries will be checked to match a (optional) regular expression.

Comparison to absolute values: Alerts when a choosen value of this call-time metric (i.e. max, min, avg, count) is smaller, equal or greater than some actual value.

Change detection: Alerts when the current value of this call-time metric (i.e. max, min, avg, count) is within a certain percentage band of the previous value. The current value is only compared to a previous value if the previous value had the same call destination. Change detection knows three operators: shrinks, change, grows. 
Let "p" be the previous value and "c" be the current value. Both belong to the same call destination. Moreover, let "x%" be a percent value specified by the user. Then, an alert will be then when:
Shrinks: c < p - (x% * p)
Grows: c > p + (X% * p)
Changes: (c < p - (x% * p)) || (c > p+ (x% *p))

I supply an implementation as a (subversion) patch based on RHQ revision 5155. I donate the code on behalf of Orga Systems GmbH. We publish the code subject to the LGPL.

Implementation notes:
- Change detection compares previous and current value. We cache the previous value in the specific CacheElement. This means that the cache is flushed when the CacheElement is reinstantiated (i.e. when the cache is reloaded). In this period we might miss data constellations which might cause an alert otherwise.
- Change detection relies on the CallTimeDataValue objects to be processed in chronological order. We implement this by sorting the CallTimeDataValue objects of one data chunk in advance to processing the data. It is possible, but very unlikely that call-time data *for same resource and metric* are processed concurrently. Then our implementation will not work correctly, i.e. deliver alert when it shouldn't or deliver no alerts when it should, because the chronological ordering is broken by interleaving checks for two data sets.