Hi Gary, answers in line: ----- Original Message ----- > From: "Gary Brown" <gbrown(a)redhat.com&gt; > To: hawkular-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev >

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?

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

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?

3) Would you expect any component generating notifications to use a 'client api' or is direct publishing of the NotificationMessage a valid use case?

----- Original Message ----- > Hi Gary, > > answers in line: > > ----- Original Message ----- > > From: "Gary Brown" <gbrown(a)redhat.com&gt; > > To: hawkular-dev(a)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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > >

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

Regards Gary

From: "Gary Brown" <gbrown(a)redhat.com&gt; To: "Lucas Ponce" <lponce(a)redhat.com&gt; Cc: hawkular-dev(a)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.

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

On 3/2/2015 6:13 AM, Lucas Ponce wrote: > > ----- Original Message ----- >> From: "Gary Brown" <gbrown(a)redhat.com&gt; >> To: "Lucas Ponce" <lponce(a)redhat.com&gt; >> Cc: hawkular-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev