6:40 p.m.
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(a)corp.org", "admin2(a)corp.org",
"cep(a)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
4:30 a.m.
On 2/11/2015 4:40 AM, Lucas Ponce wrote:
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.
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?
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?
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(a)corp.org", "admin2(a)corp.org",
"cep(a)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.
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.
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.
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.
===
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.
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?
- 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.
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.
===
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...
4:37 a.m.
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.
I agree with this. BTW: this is/was my fear that I mentioned earlier with all these REST
endpoints. We shouldn't expect every component to know all about the REST endpoints
for all the other components (just like we don't want the bus API to require someone
to supply a broker URL to point to a broker). That would just end up with a configuration
nightmare (all of our components would have to have configuration settings to point to all
the REST URLs that they want to talk to - and we'd have to expect the user to wire up
all the components together by specifying where their REST endpoints are, unless we assume
they are all on localhost). In my opinion, things like this should be done over the bus
since everyone knows where the bus is (assuming they are deployed in the nest and/or can
inject a @Resource to the connection factory) and there is no need to then have to be
configured to point to REST endpoints.
6:51 p.m.
>
> 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(a)corp.org", "admin2(a)corp.org",
"cep(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
1:20 a.m.
Le 11/02/2015 10:40, Lucas Ponce a écrit :
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@corp.org","admin2@corp.org","cep(a)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".
We can have various notifiers for a single trigger definition, right?
RHQ lets you define different notifications for the same alert
definition. Like: when server goes down:
- email admins and ceo
- send an snmp trap to space
- turn the fire sprinkler system on in the developers' openspace
1:33 a.m.
Le 11/02/2015 10:40, Lucas Ponce a écrit :
> 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@corp.org","admin2@corp.org","cep(a)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".
We can have various notifiers for a single trigger definition, right?
RHQ lets you define different notifications for the same alert
definition. Like: when server goes down:
- email admins and ceo
- send an snmp trap to space
- turn the fire sprinkler system on in the developers' openspace
Yes, the trigger definition can have a list of notifier, so that scenario is possible.
1:42 a.m.
Le 11/02/2015 10:40, Lucas Ponce a écrit :
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).
It feels more natural to me to attach a trigger definition to different
notifiers.
- Create a new notifier of a specific type.
How would the UI/engine know about the properties needed to configure a
notifier?
The UI would also need some hints to display input fields. Like: this
notifier property is a template, it needs a textarea instead of a text
input.
1:45 a.m.
Le 11/02/2015 10:40, Lucas Ponce a écrit :
> 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).
It feels more natural to me to attach a trigger definition to different
notifiers.
I was thinking more in the UI flow:
- I create a trigger definition.
- Set conditions.
- Set the notifier (from a notifier list or I can create a new one).
> - Create a new notifier of a specific type.
How would the UI/engine know about the properties needed to configure a
notifier?
The UI would also need some hints to display input fields. Like: this
notifier property is a template, it needs a textarea instead of a text
input.
+1
That's why we have the notifierType REST end point, the UI can have what are the
properties for an specific notifier Type (i.e. email, snmp, sms).
3380
days inactive
3381
days old
8 comments
4 participants
participants (4)
-
Jay Shaughnessy -
John Mazzitelli -
Lucas Ponce -
Thomas Segismont