Version 1

    Hawkular Alerts preliminar architecture

    Hawkular Alerts is composed of the following modules:


    This is the public Java API for alerts component.

    Users should use only this API to interact with alerts.


    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.


    This is a public REST API for alerts component.

    It is a wrapper of the main hawkular-alerts-api.


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


    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.




    Project examples with the skeleton of a notifier plugin.

    Main responsabilities are:

    • Register at deployment time into the alerts-engine.
    • Process registration of new notifiers.
    • Process notifications messages.

    Notification plugins interfaces


    The goal of this architecture if to decouple the alerts-engine from the notifications plugins.

    hawkular-alerts-engine offers an interface:




    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:




    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




         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




         A new notifier can be (id: 123, <send an email to 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:




         The plugin will be responsible to perform the specific task for processing (send the email with the decorations).