[Hawkular-dev] Notification messages

Lucas Ponce lponce at redhat.com
Mon Mar 2 06:13:14 EST 2015



----- 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.
 
> Regards
> Gary
> 
> ----- Original Message -----
> > 
> > > 
> > > ----- Original Message -----
> > > > > 3) Would you expect any component generating notifications to use a
> > > > > 'client
> > > > > api' or is direct publishing of the NotificationMessage a valid use
> > > > > case?
> > > > > 
> > > > > 
> > > > 
> > > > Not sure if I get the "client api" use case, if you can add an example
> > > > I
> > > > can
> > > > check if the current architecture supports that use case.
> > > > 
> > > > At the moment, the idea is that the plugin should listen from the bus,
> > > > but
> > > > you can create an alternative notifications implementation without
> > > > having
> > > > that dependency from the bus (i.e. some thirdparty likes metrics and
> > > > alerts
> > > > components and they want to hard integrate them into other code, so
> > > > they
> > > > won't use the bus but the API defined for the notifications can be
> > > > overrided
> > > > it with additional/alternative implementations).
> > > > 
> > > 
> > > The question was more about how the alerts/notification messages are
> > > raised
> > > -
> > > so instead of the alert engine, it may be rtgov policies identifying a
> > > 'situation' an needing to create an 'alert'. In this case, would rtgov
> > > use
> > > some form of client API to report the alert, or simply create the alert
> > > and
> > > publish it on the bus?
> > > 
> > 
> > In our present design the hawkular-alerts-engine should be responsible to
> > generate the Alerts from Events/Data.
> > 
> > The alerts engine is also responsible to manage the persistence layer of
> > alerts and rules definitions.
> > 
> > If I am understanding your scenario, it is like if we can "decouple" the
> > alerts engine, because we have a third party element that can raise alerts
> > (i.e. RTGov policies) and it can be interesting to create an Alert that can
> > have attached a list of actions/notifications.
> > 
> > It sounds not clear for me (at a first thought) I guess you can accomplish
> > same feature just letting RTGov to generate a simple data and attaching a
> > definition from the alerts engine, that sounds more natural.
> > 
> > But anyway it is interesting to understand this use case to see what is the
> > best way to implement it.
> > 
> > Thx,
> > Lucas
> > 
> > > Regards
> > > Gary
> > > 
> > 
> 


More information about the hawkular-dev mailing list