When I configure an alert's template on Datasource resource, it seems to be inpossible to fire the alert when active connections represents 50% of the max-pool-size. I've tried to do it with "active Connections > 50.0% of Max Value" but Max Value, here, is not the max-pool-size. The only solution I see for the moment is to make an alert on absolute value but, as the value max-pool-size is not the same on every datasource, it could be a heavy work to configure this alert on each datasource manually (and we loose the great advantage of templates to have automatic alerting for coming new datasource)
This is going to be hard(ish). AFAIK, the alert subsystem condition cache assumes that a value to compare a metric with is stored in the condition itself. What is required here is that both values to be compared come from the measurement report. Today the conditions are checked in a very "simple" manner by merely iterating over a set of measurements and checking conditions for each by comparing the measured value with the value stored in the condition. We'd need a new type of alert condition that would not hold a value but would provide a matches() method that would take in two values. We'd also need a lookup mechanism to obtain the two values to match. The trouble is that there is no guarantee that the two values that should participate in the condition are going to be in the set of the processed measurements (the agent plugins are free to not provide a metric value when asked for it). Therefore we'd need another DB/cache lookup of the value before we could pass it to the condition "processor". Note that because of the nature of the measurement collection there would be no difference between comparing values coming from the same resource and values from different resources.
Please note that this RFE is for all metrics and the datasource metric provided in the description is only an example.
worked with lukas directly
Moving to JBoss ON BZ as this is from downstream.
Larry, I think we agreed to deferred that one ?
From PRODMGT-31 this was accepted and would be considered as part of the 4.0 payload.
JBoss ON is coming to the end of its product life cycle. For more information regarding this transition, see https://access.redhat.com/articles/3827121. This bug report/request is being closed. If you feel this issue should not be closed or requires further review, please create a new bug report against the latest supported JBoss ON 3.3 version.