[Alerts] Requeriments for notifications and current work
by Lucas Ponce
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
10 years, 10 months
Repositories under github.com/rhq_project
by Heiko W.Rupp
Hello,
since we have moved a lot of the .next repositories from https://github.com/rhq_project to
https://github.com/hawkular,
there are a few leftovers that I am not sure if they belong to hawkular or what we do with them
* rhqm-charts
* rhq-audit
* rhq-msg
* rhq-next-bom
* angular-ui
* rhq-checkstyle-config
I guess -msg and -bom can just go, same for angular-ui, which is empty anyway.
What about the others?
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
10 years, 10 months
Authorization flow
by Lucas Ponce
Hi,
I have read the threads about the tenantId/integration with Keycloak, but I am still having some doubts about the ideal flow.
Please, let me know if my flow is correct:
- We will have users associated by tenants, so a tuple (tenantId, userId) should be unique i.e. (tenantA, userA), (tenantB, userA).
- A tuple (tenantId, userId) will have associated a list of roles (with hierarchy like an organization ?).
- Metrics/Definitions/Resources should be unique by tenant, so our backend should have something like (tenantId, {metricId|resourceId|definitionId}).
- In the APIs, tenantId will be explicit nor implicit.
- Keycloak would be responsible to pass a (tenantId, userId) + roles list to the component/application.
So, my main doubt is about how are we thinking to work with the authorization, I guess that component backend should define some authorization rules based on roles and permissions, right ?
I guess that this part should be more or less shared for all components.
Is there any draft about it ?
Perhaps this question is very early and it can be put on hold for later, but just curious about it, as I would like to think in possible impacts.
Thanks,
Lucas
10 years, 10 months
[Alerts] Thoughts on the notification system
by Thomas Segismont
Hi,
I've been thinking about the alert notification system lately.
What's the information needed to send a notification?
How to convert the information into text when a human is the recipient?
How to configure the system?
How to make it fit into the Hawkular suite?
1. Contextual data
A notification has contextual data. Contextual data is comprised of:
- alert definition data
- data involved in the trigger (for example metrics and availability values)
2. Notifier data
2.1 Who is the recipient?
Email: address
SMS: phone number
Sometimes the recipient is fixed (for example when sending email to a
mailing-list).
Sometimes it should be picked from user information (for example when
sending emails to a group of users)
This information depends on the alert definition, but a default should
be configurable for convenience.
2.2 How should the message be sent?
Email: SMTP address/port and credentials
SMS: Web service HTTP URL and credentials
The information depends on the tenant (in rare cases, on the alert
definition, but let's ignore the problem for now)
3. How should the message be formatted?
When a human is the recipient, information can be turned into text with
a template engine (like freemarker).
Information depends on the alert definition, but a default should be
configurable for convenience.
4. Configuration
Notifiers may expose REST endpoints (with standardized URIs)
- default config: /emailnotifier/configuration
- alert definition level config: /emailnotifier/configuration/1
Example:
{
"to": ["paul(a)foobar.com", "alfred(a)foobar.com"],
"cc": ["backoffice-mw-ops(a)foobar.com"],
"subject": "Pool soon exhausted",
"mode": "plaintext+html"
"templates":
[{
name: "plaintext",
uri: "/emailnotifier/configuration/1/templates/plaintext"
},{
name: "html",
uri: "/emailnotifier/configuration/1/templates/html"
}]
}
- template configs:
Example:
/emailnotifier/configuration/1/templates/plaintext
/emailnotifier/configuration/1/templates/html
I'm still not sure which component should be responsible of loading user
information when a user (or a group of users) is selected as the recipient.
5. Process
- Alerts sends contextual data on the bus
- Notifier picks it up
- Notifier loads configuration for this alert definition or the default one
- Notifier applies the template (optional)
- Notifier sends email or invoke sender API
6. Storage
There needs to be some shared storage where to bind configuration and
templates to alert definitions.
Comments?
Regards,
Thomas
10 years, 10 months
integration project
by John Mazzitelli
OK, good news/bad news.
I got all the pieces in the integration distribution here - its in a branch in the hawkular repo:
https://github.com/hawkular/hawkular/tree/mazz/integration-assembly
This has everything - inventory, alerts, metrics, and bus - installed in the nest.
Bad news - metrics is broken. When you start, you'll get an exception because it appears the embedded cassandra EAR initializes too late - after the metrics war tries to find C*. You'll get deployment errors due to this.
But everything else appears to deploy successfully.
Just need to find out how to get metrics deployed properly with embedded C*. Can we put some kind of optional dependency in the metrics WAR? Have it depend on the embedded EAR?
10 years, 10 months
Should Keycloak integration be optional?
by Juraci Paixão Kröhling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
As I mentioned on the previous email, one of the questions during the
demo was if it would be possible to have the Keycloak integration as
an optional part.
In the backend part, it's not hard to disable Keycloak as the
authentication mechanism, as it's just JAAS. That would require,
though, a second JAAS implementation to replace it.
In the frontend part, however, it's a bit more complicated. The setup
right now is that the web console is treated as an HTML5 single-page
app. This means that the web console is one application and the
backend is a different one, and they propagate the authentication by
using the tokens: the web console gets a token from the Keycloak
JavaScript adapter once the user logs in and sends it along with each
request to the backend. The backend (Keycloak Wildfly Adapter) reads
this token and retrieves the user data from the Keycloak server,
allowing the request to execute or not.
This means that either:
1) web console and REST API (and possibly other wars) become one, so
that the HTML5 single-page app can be served only after the user logs
in (classic Java EE application)
2) the backend JAAS adapter would need to support also some sort of
token exchange, with the frontend abstracting the Keycloak adapter to
work with one auth mechanism or another, possibly auto identifying
what is the backend's auth mechanism.
3) ??
I don't think that the first option is a real one. Having small wars,
each taking care of one concern, is a goal on the project.
So, would an effort in making Keycloak an optional part be worth it?
Should I pursue it?
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUworiAAoJECKM1e+fkPrX8oMH/jC6DSOzx5gJuQNVHsojO6jB
xHjAbhiF89mnlC9iHBKTmZnJ6O4sOs870tibxhhmNvJs+N5wvQVCWhv+5JdqONfe
ETP4O7iKYLHu317DuNW8gl3FRP9Mgj/FkpgGhanikOLZ7S1B9/86zv8qdQ1/C6Hm
EM1MOIlSqqwPk+QPj/51Uo6rMG42ObG6P+mJOu7IhuJK4LS0uZI3yCIyk42+ngit
+T05kOfYOL24nOcL4iCjb0+Qg9SjNPASklq79Kz1h9tMZkq3CAXwyPJ0ty0kKSwR
mejY48LahgwmGQF53zovQJbb7Lpek+Uu9+G/vbcaJGLgqs5qwQq+3qa3e81Q9I0=
=5KoB
-----END PGP SIGNATURE-----
10 years, 10 months
About configuration
by Thomas Segismont
Hi everyone,
Yesterday Lukas asked on IRC if there was a discussion about
configuration. AFAIK, there wasn't, hence I'm sharing how we support
configuration in metrics.
# Metrics REST server
The REST server runs on top of Wildfly.
Configuration is a set of key/value pairs (configuration properties)
defined by the following sources, in order of precedence:
* system properties (-Dkey=value)
* external java.util.Properties file, which path is defined by the
metrics.conf system property; by default, <user.home>/.metrics.conf is
used (if it exists)
* internal java.util.Properties file (META-INF/metrics.conf)
The rationale behind is that the system should be able to:
1. start with reasonable defaults
2. switch to another configuration easily
# pTrans
pTrans is different because it's a standalone application, so it's much
easier to follow the daemon configuration habits.
pTrans takes a path to a properties configuration file as a program
argument. This argument is mandatory.
# Configuration file format.
metrics started with properties file and I think it's fine.
But if we feel the need for a more structured format, we should pick
something which can be easily parsed by a variety of programming
languages, especially languages widely used for administration (Python
and Ruby).
Regards,
Thomas
10 years, 10 months
Hawkular Migration - RHQ Metrics
by Stefan Negrea
Hello Everybody,
Here is the plan migrating RHQ Metrics and related projects to Hawkular organization (timeline in chronological order):
1) Remove access to rhq-metrics-openshift, rhq-metrics, rhqm-charts, and wildfly-cassandra repositories
2) Transfer rhq-metrics-openshift, rhq-metrics, and widlfly-cassandra to the Hawkular organization
3) Replace the README.md for rhqm-charts with a link to the new Hawkular repository
4) Rename rhq-metrics-openshift and rhq-metrics repositories to reflect the new organization
5) Create new teams inside the new organization for write access to the migrated repositories
6) Update files inside the migrated repositories to reflect the new name
7) Re-organize the metrics project modules
I will start the migration tonight to have minimum impact on development. I will send updated links after all repositories get fully migrated.
Thank you,
Stefan Negrea
Software Engineer
10 years, 10 months
