[Hawkular-dev] Notification messages

Lucas Ponce lponce at redhat.com
Mon Mar 2 05:30:57 EST 2015


Hi Gary,

Thx for your questions, some answers in-line:

> 
> Hi Lucas
> 
> Thanks again for the info - a couple more points related to potential use for
> 'situations' in RTGov:
> 
> 1) RTGov maintains a list of 'situations' that have occurred, which can be
> used to access other information about the business transaction, historic
> analysis, etc. Wondering whether maintaining a historic view of
> notifications that have occurred is something you have thought about?
> 

Yes, the concept of record will be handled via the "Alert" entity, as a result of an alert a set of notifications messages will be sent.

Additionally the plugin itself can also store/save their notifications (i.e. audit purposes), but I guess that specific task should be part of the ActionPlugin logic.

> Possibly this could be another plugin - may be not explicitly defined as an
> action, but implicitly just records any notifications sent.
> 

Right, the idea is to have a plugable architecture that allow to add these kind of features without impacting into the main alerts engine.

> 2) From the description in the doc, it gives an example of an email notifier
> with an email address - so in this context the email address is statically
> defined. Is it also possible for the component raising the
> 'action'/'notification' to provide the email address?
> 

Yes, it is.

The idea is that the ActionPlugin at registration time, should provide which properties need for an action.
These properties can be to set up a list of destionation emails, or even to have a default one, or other combination.
Plugin will be responsible to implement the notification itself.

The engine, will trigger the alert, and when an alert happen, it will signal their actions attached.

These actions are de-couple and the engine doesn't have any detail of what is behind, the bus component will get the info of the notifiers/actions id and it will send the notification/action messages through the bus, where the plugins are listening and they will perform the actions once they receive the messages.

> 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).

Lucas


> 
> ----- Original Message -----
> > Hi Gary,
> > 
> > answers in line:
> > 
> > ----- Original Message -----
> > > From: "Gary Brown" <gbrown at redhat.com>
> > > To: hawkular-dev at lists.jboss.org
> > > Sent: Friday, February 27, 2015 4:58:49 PM
> > > Subject: [Hawkular-dev] Notification messages
> > > 
> > > Hi
> > > 
> > > Started looking at Hawkular alerts with an eye on RTGov eventually using
> > > the
> > > notification mechanism to represent what we currently store/display as
> > > 'situations'. Had a couple of questions:
> > > 
> > > 1) The notification message currently has a notifierId - so does this
> > > mean
> > > an
> > > alert trigger will only have a single notifer? Or could a single alert
> > > (notification message) potentially be sent to multiple notifiers (e.g.
> > > twitter, email, etc.) - and if so require a notifierId list?
> > > 
> > 
> > No, a trigger definition can be linked with a list of "notifiers" (this
> > term
> > will be called "action" in our next api review).
> > 
> > Also this actions can be shared, i.e. an action can be "email to admins and
> > CTO" and this action has an ID that can be re-used in several triggers
> > definitions.
> > 
> > 
> > > 2) Only other field is currently a description, which is fine for targets
> > > such as email, twitter etc, but in RTGov 'situations' are also used to
> > > hold
> > > other information that can be used to understand the source of the
> > > problem,
> > > and tie it back to the originating business transaction. Will it be
> > > possible
> > > to add such fields to the notification message, even though they may not
> > > be
> > > relevant for the email/sms/twitter type notifiers?
> > > 
> > 
> > Yes, sure, the UI of the MVP was very simple due time constrainst we
> > couldn't
> > add a rich functionality on that component.
> > 
> > The idea is the following:
> > 
> > - We will have plugable ActionsPlugins that are responsible of the perform
> > (i.e. an action plugin for emailing, other for mobile, other smp, etc).
> > - So this ActionPlugin is registered at deployment type, and it specifies
> > which info can a plugin get, so in the UI you will see that depending of
> > the
> > plugin selected you will be able to select some properties or others.
> > 
> > - Also, not business requeriments, but technical requeriment, we want the
> > alerts engine and the action plugins work decoupled, so, i.e. the alerts
> > engine can be reused for a paas cloud provider to use the engine but add
> > their own notifications mechanism.
> > 
> > Some notes of this architecture can be reviewed here:
> > 
> > https://developer.jboss.org/wiki/NotificationsPlugins-NotesAboutArchitecture
> > 
> > 
> > Cheers,
> > Lucas
> > 
> > > Regards
> > > Gary
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > 
> > 
> 


More information about the hawkular-dev mailing list