Re: [Hawkular-dev] Event Store - triggering alerts

Hi Gary, Probably restating much of the below... Alerts does integrate with the bus and listens on three topics. Two of which are specific to integrating with Hawkular Metrics, and one is relevant only to bus integration. Hawkular feeds will supply numeric and availability metrics and those will be published to the HawkularMetricData and HawkularAvailabilityData topics. H Alerts subscribes to them both. Because only a small subset of data persisted in metrics will be relevant to alerting (only those involved in defined trigger conditions), alerts filters out the irrelevant data in the listener code. It then translates the filtered metric data into the format suitable to alerts and forwards it for alert evaluation (via the Java API). Additionally, data can be published to the bus HawkularAlertData topic, and that data goes straight into alert processing, currently without filtering, although that may change. So, Events data could be published and picked up via the bus today by sending to the HawkularAlertData topic. Of course there is also a rest endpoint for sending in data. Alerting currently supports 3 types of "primitive" data: numeric, availability and string, which are used in the various condition types. But more likely we'd want something like you suggest, something analogous to the listener we have on HawkularMetricData, add a listener for published events, filter them as needed, and forward relevant events for evaluation. One question, I guess, is whether alerting on events requires a dedicated type, and dedicated condition types in alerting, or whether the current "primitives" are sufficient. For example, in RHQ, alerting on logging events could involve match on log level, the logfile path, and/or the actual log entry text. We don't have support for that kind of condition evaluation today in alerting. We'd rather have to distill it down to a single string datum and a regex test, for example. of the trigger definition, we offer the ability to define a bus topic/queue/selector to feed the alert engine? So, I don't think we want to incorporate data sources/streams into our trigger definitions but rather, as Lucas says, insulate the engine and keep it cleanly separated from the bus. Keeping the reception/filtering/translating of event data in the hawkular (i.e. glue) code. Regards, Jay On 5/12/2015 11:50 AM, Gary Brown wrote: