[Hawkular-dev] Event Store - triggering alerts

[Lucas Ponce]

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-api/src/main/java/org/hawkular/alerts/api/model/data  

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