[Hawkular-dev] Event Store - triggering alerts

[Jay Shaughnessy]

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.

 >  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?

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:
> Hi Lucas
>
> I'd just started looking at hawkular-alerts-bus :)
>
> Just wondering how complex the configuration may become in the glue, if it is used to wire up the components but also potentially has to apply filters - but we can see what is possible.
>
> Regards
> Gary
>
> ----- Original Message -----
>> 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
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>