Hi Gary,
I believe currently the alerts engine does not subscribe to the bus for
events, so events need to be supplied to the alerts engine explicitly?
Today, alerts component listens from the bus for data alerts.
Also, these data is "filtered" from metrics, in the meaning that not
"all" data coming from metrics is insteresting for alerts, so in the
"glue" we have a component to filter from one topic and put the data that is
consumed for alerts.
I guess that for Events we can do a similar approach.
Do we want the alerts engine to have that capability? i.e. as part of
the
trigger definition, we offer the ability to define a bus
topic/queue/selector to feed the alert engine?
The trigger definition is more generic, it doesn't matter from alerts domain from
which "source" a data is provided.
The data model that alerts engine is expecting is here:
https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-a...
Perhaps, we can add more data types if needed for inference processes.
Or should the "event store" allow a listener to be defined
(in the glue) that
could supply events to the alert engine - but then this slightly separates
the alert definition into two parts - the bit bridging the event store and
alert engine, and the trigger definition on how the event should be
processed.
I'm +1 to separate the bus integration layer aspect from the pure alerts inference.
Today, we have the same separation and the "glue" code lives here:
https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-bus
As we identified a "filtering" preliminar tasks that is not part of inference
itself.
In the other hand, having this separation we can maintain or goal to have an scenario with
metrics+alerts and without bus dependencies.
Regards,
Lucas