[Hawkular-dev] Notification messages

[Jay Shaughnessy]

On 3/2/2015 6:13 AM, Lucas Ponce wrote:
>
> ----- Original Message -----
>> From: "Gary Brown" <gbrown at redhat.com>
>> To: "Lucas Ponce" <lponce at redhat.com>
>> Cc: hawkular-dev at lists.jboss.org
>> Sent: Monday, March 2, 2015 12:06:55 PM
>> Subject: Re: [Hawkular-dev] Notification messages
>>
>> Hi
>>
>> Maybe your suggestion is the way to go - RTGov still generates 'situations'
>> which are made available to the alerts engine to determine if a notification
>> should be raised. So looks like there are two possibilities:
>>
>> (a) RTGov somehow creates alerts directly, so alerts engine, RTGov, other
>> components, etc could independently raise alerts that are then used to
>> create notifications.
>>
>> or
>>
>> (b) RTGov and other components create their own event to represent a
>> 'situation of interest', and the alerts engine interprets these to determine
>> if an alert should be create resulting in notifications.
>>
>>
>> I'm open to either approach, although (b) has the benefit of allowing the
>> source component (e.g. RTGov) to simple raises the 'situations' while not
>> worrying about issues such as dampening, which can be defined with the
>> alerts engine.
>>
> Exactly, 'situations' are data that can be used to create a trigger definition, that can be attached with a notification list.
>
> This data can be really simple, for example, it can be just a String with a value, and a condition can be just to detect if you have a new situation into the alerts engine.
>   

We definitely want to be able to incorporate external alerts into the 
engine.  I think perhaps we will want to support both approaches above, 
but if it  were just one then I think (b) would be the preference, 
because as you said, it opens up dampening, safety logic and anything 
else that comes into play at the condition-matching phase.

I'm not sure there is anything today preventing RTGov or anyone from 
using a registered Action, or registering their own Action, and then 
using the bus infrastructure to send it a message.  As long as the 
message had the correct payload it should just work.

But it should also be fairly easy to hook into the Alerting as a whole.  
I think you could create a Trigger looking for a StringCondition 
operator, send in a Situation in some String format, and have it fire an 
alert for each.  We could maybe do a little better by creating a more 
robust Data element for external systems to hook into.  Something that 
perhaps could extend StringData and also provide a secondary String 
(maybe json), as data that just gets passed along to the notifiers/actions.

Moreover, we have yet to talk about incorporating Alerts themselves into 
Triggers, such that we start to allow for higher-level Alerting that 
correlates Alerts.  This may lead to a true AlertCondition.  It may be a 
built-in Action that generates an AlertCondition for the alert generated 
by the trigger. Or something like that.



Actions are tied to the triggers and when the trigger fires an Alert we 
explicitly send a message to the relevant actions' topics on the bus.


How to handle external alert generation is a great topic.
This is a good topic.  I think it could be useful to have external 
Alert-generators just feed fully-fledged Alerts into the system