Hawkular Alerts preliminar architecture
Hawkular Alerts is composed of the following modules:
| hawkular-alerts-api | This is the public Java API for alerts component. Users should use only this API to interact with alerts. |
| hawkular-alerts-engine | This is the implementation of the alerts engine. It is responsible to manage the alerts definitions and the evaluation of the alerts conditions. It includes a rules engine as part of the implementation details. |
| hawkular-alerts-rest | This is a public REST API for alerts component. It is a wrapper of the main hawkular-alerts-api. |
| hawkular-alerts-bus | This component is responsible for the communication between the alerts engine and the bus. hawkular-alerts-engine is decoupled from the bus, so it can be used in other scenarios (i.e. standalone, third party alerts system). |
| hawkular-notifiers-api | Common API for notifiers plugins. A notifier plugin will be deployed as a .war artifact and it will interact with the bus via this API. |
hawkular-notifiers-email hawkular-notifiers-sms hawkular-notifiers-snmp | Project examples with the skeleton of a notifier plugin. Main responsabilities are:
|
Notification plugins interfaces
The goal of this architecture if to decouple the alerts-engine from the notifications plugins.
hawkular-alerts-engine offers an interface:
org.hawkular.alerts.api.NotificationsService
that is used by the alerts engine to send notifications requests as result of the evaluation of the alerts conditions.
These notifications can be processed using the following interface:
org.hawkular.alerts.api.NotifierListener
that will be responsible for processing the notifications request. These listeners are registered into the NotificationsService.
The hawkular-alerts-bus offers an implementation of the NotifierListener in charge to send notifications messages into the bus.
This mechanism allows to maintain hawkular-alerts-engine decoupled without dependencies with bus or other notifications specific implementations.
From the notifications plugins perspective, the flow would be the following:
- A notification plugin (i.e. hawkular-notifiers-email) registers at startup sending a
org.hawkular.notifiers.api.model.NotifierTypeRegistrationMessage
this message will be managed by the hawkular-alerts-bus that it will register it into the hawkular-alerts-engine using the DefinitionsService.
This way, allows to alerts API to query how many plugins are registered into the system and what are their properties.
- A notification plugin can listen for registration of new notifiers using the API
org.hawkular.notifiers.api.model.NotifierRegistrationMessage
A new notifier can be (id: 123, <send an email to admin@corp.org with alert msg + decoration>).
NotificationService interface should be extended to use a similar mechanism of listener described above to allow create new notifiers from the hawkular-alerts-engine in a decoupled manner.
- A notification plugin listens for notifications message using the API:
org.hawkular.notifiers.api.model.NotificationMessage
The plugin will be responsible to perform the specific task for processing (send the email with the decorations).
Comments