[Hawkular-dev] Notification messages

[Gary Brown]

Is there any plans to support an arbitrary Java type as an alert? If not, then what about a MapData type?

Regards
Gary
 
----- Original Message -----
> 
> 
> 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
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>