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

Lucas Ponce lponce at redhat.com
Wed Feb 11 04:40:08 EST 2015


Hello,

We have had several threads and discussion about notifications architecture, and we have also a small draft of the API in the current work.
So, to unify all this conversations I am going to describe in the ML the current approach to summary all discussion around it.

The conceptual requeriments are the following:

Req1: Notifications will follow a plugin-based architecture
-----------------------------------------------------------

So, we can add/remove plugins into the system, without impact of rest of the components.


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

A plugin can have properties that are shared for all plugin.
(i.e. the server/gateway used for email/snmp/sms).

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.


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.

===

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.

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.
- Main use case of the plugin is to listen for notifications messages to process its specific sent.


TechReq3: Predefined notifiers
------------------------------

Notifiers can be pre-created from an initialization configuration.


===

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.

Lucas








More information about the hawkular-dev mailing list