[Hawkular-dev] [Alerts] Requeriments for notifications and current work

Thu Feb 12 04:51:50 EST 2015

> >
> > Req1: Notifications will follow a plugin-based architecture
> > -----------------------------------------------------------
> >
> > So, we can add/remove plugins into the system, without impact of rest of
> > the components.
> 
> Is it correct to assume that for Hawkular a NotifierType Plugin will be
> an MDB listening on the Bus for published Alerts?  And that
> Hawkular-Alerts will supply some default NotifierType MDBs?
> 

Yes, but I would put a comment:

- From alerts-engine perspective I would like to maintain an abstract separation, so a notifierType plugin and a notifier can / can't depend of MDB.
- MDB is the implementation used in a bus-architecture for the whole hawkular suite.
- For example, in an embedded scenario, we would like to maintain the concept of plugin/notifier but without the bus dependencies.
(i.e. I am thinking in a case where a third party wants to create a "console-plugin" or similar without dealing with MDBs).

That is my main motivation for this abstraction layer.

> If that is true, then I think the NotifierType MDBs could self-register
> by sending a message to the Alerts Queue.  This would be as an
> alternative to using the Rest API to register, and then avoiding the
> need for a plugin to know any endpoint information.  It also avoids any
> disconnect that could happen if registration and deployment are done
> separately.  Did you have a different idea?
> 

No, that's the current idea drafted in the API.
In the hawkular "suite" implementation the examples plugins send an init message for registering.
In these case, plugins interacts with the bus only.

> > Req2: There are two concepts: plugin (notifier type) and notifier
> > -----------------------------------------------------------------
> >
> > A plugin will be responsible of a type of notifications
> > (i.e. email-plugin, sms-plugin, snmp-plugin, etc...).
> >
> > A notifier is a representation of a destination with status about how it
> > has to process the notification.
> > A notifier can be reused in several triggers definitions.
> > (i.e. in json pseudo-format
> >        { notifierId: "email-admins-and-ceo",
> >          properties: {
> >                NotifierType: "email",
> >                to: ["admin1 at corp.org", "admin2 at corp.org", "cep at corp.org"]
> >                template: "Incident in %MSG% at %TIME%. Alert description:
> >                %ALERT_DETAILS% ..."
> >                }
> >        }
> > )
> >
> > So, we can have several triggers definitions that will use the notifier
> > "email-admins-and-ceo".
> 
> I don't think it should be required that a Trigger use a pre-defined
> Notifier.   I think it's OK that we could have pre-defined Notifiers,
> although it may be necessary then to ensure only a
> proper subset are displayed, not just by Type but possibly tenant/user,
> etc.  So, the Trigger definer could select an existing Notifier, or
> supply an ad-hoc property-set.
> 

+1 

Exactly, I was referring to pre-defined triggers "available" in the persistence/repository, but not prefilled in the Trigger definition.

I was thinking more like an UI role, that when I'm in the UI create-new-trigger page, I would like to see at least a couple of pre-defined notifiers.
(i.e. console, or something like that, I don't know, it's an open point).

> I expect a NotifierType could have optional and required properties.
> Above, "to" would be required and "template" would likely be optional,
> with some default text.
> 

+1

> > A plugin can have properties that are shared for all plugin.
> > (i.e. the server/gateway used for email/snmp/sms).
> 
> I'm not sure I understand, but I'm not sure we need to have
> shared/global properties for the NotifierType plugins.  It seems a
> self-contained plugin may be best.
> 

My use case is the following: we have a new plugin to send info through a mobile gateway, and that gateway can be changed, let's say by and admin.
Instead of change that property in a configuration file of the plugin at deployment phase, I was thinking that option can be available for UI.

Of course, this can have sense in some scenarios, for example, an email plugin that needs a email server configured in an standalone.xml can't use this scenario, as it could not change this info.

But as the API was generic, I was considering to introduce this feature in an optional way.

> > A notifier can have specific properties.
> > (i.e. list of destination, decoration of the message, other).
> >
> >
> > Req3: There should be a central way where plugins are notifier are
> > available
> > ----------------------------------------------------------------------------
> >
> > New triggers definitions will be create through UI, so in the API we need
> > to perform:
> > - Get the list of notifiers created in the system (for an specific plugin
> > or all plugins).
> > - Link a notifier with a specific trigger(s) definition(s).
> > - Create a new notifier of a specific type.
> 
> Right, we only need the first thing is we persist Notifiers.  We
> definitely need the ability to define an ad-hoc Notifier for a Trigger.
> 
> 
> > Req4: Alerts engine sends alerts in a decoupled way
> > ---------------------------------------------------
> >
> > Alerts engine is responsible to process data and to infer which alerts have
> > to be sent.
> > The alert engine should provide a decoupled way to send a notification
> > through the notifier attached.
> 
> I agree.  The engine should be responsible for generating Alerts. For
> Hawkular the Alerts should be "tagged" with (perhaps JMS Headers for
> filtering) and likely be publish to a TriggeredAlerts topic for
> consumption by NotifierType plugins, and possibly anything else
> interested in generated alerts.
> 

+1

That's the current design.
Just a detail comment, the communication to/from the bus is done under the hawkular-alerts-bus project, to maintain the scheme that the engine should be decoupled from any explicit bus dependency.

> > ===
> >
> > There are also some technical requeriments that we are following in the
> > current approach:
> >
> > TechReq1: Alerts engine should work in a decoupled way from other
> > components
> > ----------------------------------------------------------------------------
> >
> > The alerts engine implementation should not have a strong dependency with
> > the bus component
> > or any specific plugin implementation.
> > So, the engine should be able to run in the whole hawkular architecture or
> > it can be reusable
> > for third party scenarios where other developers can create their own
> > notifications architecture.
> 
> I think this is fine.  It means that some of the Hawkular-Alerts
> artifacts are independent of Hawkular "Kettle", although I don't think
> we need to split up the project repo.
> 
> 

+1

Yeap,  as I commented, the idea is that a possible third party user can use metrics/alerts/other just picking the engine, using the API and adding their own notifications mechanism without have to deal with JMS semantic or add extra dependencies.

> > More details of the architecture proposed are under this article:
> > https://developer.jboss.org/wiki/NotificationsPlugins-NotesAboutArchitecture
> >
> >
> > TechReq2: Notifications plugins flow
> > ------------------------------------
> >
> > A preliminar flow for the notifications plugins can be the following:
> >
> > - When a plugin is deployed, it should be registered, then it is
> > available/visible for the API.
> > - When a notifier is created through the UI using the API, a plugin should
> > be notified.
> 
> Why is this?  Why does the plugin need to know about the defined Notifiers?
> 

The idea is that UI can create a new notifier, so it uses the central API, so a new notifier is persisted.

In my first draft I was thinking that in an alert/notification message only is saved the notifierId, but not the full properties.

So, when a notifierId is created a plugin should receive this info (for example to cache this data, instead to query per each message what are the properties).

Another option is to add al notifier properties in the notification message, my first thought is that could be a lot of info.
(i.e. If we have a long template for a notifierId, in each notification message I don't need to send full template, but the plugin needs to know - and possible cache - this template).

> > - Main use case of the plugin is to listen for notifications messages to
> > process its specific sent.
> 
> I'm not sure it should be listening for notification messages but rather
> published Alerts, which would contain/include the Notifier
> configuration/properties.
> 

I guess that we are talking about the same, I understand a Notification message as a consequence of an Alert.

Perhaps, an Alert can create multiple notifications messages, for example, if a trigger definition has more than 1 notifier attached.

Of course, each notification message has its own header in the message to filter the specific plugin responsible for its processing.

> > TechReq3: Predefined notifiers
> > ------------------------------
> >
> > Notifiers can be pre-created from an initialization configuration.
> 
> Like other definitions, it should be possible to import/export
> Notifiers, if we persist them.
> 

+1

> > ===
> >
> > These are the requeriments used for the current draft of this area.
> > The idea of this thread is to discuss about it to clarify/explain/modify
> > it.
> >
> > After that I will try to collect all comments in a new article.
> >
> > Thanks in advance for your comments.
> >
> 
> One last comment.  I wonder if we should maybe avoid RHQ's "Notifier"
> terminology.  It is OK, but it became sort of clunky when you would say
> that performing an operation on a resource was a Notification.   Perhaps
> "Action" may be a better term?  So we have Trigger Actions and Trigger
> Action Plugins.   Just a thought...
> 
> 

+1

I'm using "notifier"/"notifier type"/"notification" wording just as a continuation of rhq terminology, but whatever that is more clear, the best.

> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 