[Hawkular-dev] [Alerts] Thoughts on the notification system

[Jay Shaughnessy]

This is a good overall topic for discussion, how far we want to go with 
Alert management in H-Alerts.   At the moment we haven't entered this 
arena at all.  We are just firing Triggers, generating Alerts, and 
presumably handing them off to Notifiers to do what they wish.   We 
currently don't even persist the Alerts but that will likely come next, 
along with whatever post-notification handling we want to provide.   
Lifecycle, ack, duration, etc is all pending.  As is any kind of 
auto-disable/enable of Triggers, a la recovery alerting in RHQ.

On 2/6/2015 9:31 AM, Thomas Heute wrote:
> Does it need possibility and template for end of alert notification
> (back to normal) ?
>
> In general we need to think about alert lifecycle.
>
> alert is raised at 9am -> situation is back to normal by itself at 10am
> or
> alert is raised at 9am -> alert is acked at 9:30am (still an issue
> though) and mute the alert for "some time" someone change the alert
> definition, delete it or fix the actual issue -> situation is back to
> normal at 10am
>
> For the 1 case there would be 2 notifications I guess. For the case 2,
> we may want to let others know if it's a distribution list ("bob as
> acked the alert, you can ignore")
>
> In both cases this should likely create an "event" from 9am to 10am that
> is displayed in the UI console (which is another kind of notification).
>
>
> Thomas
>
> On 02/06/2015 01:17 PM, Thomas Segismont wrote:
>> 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 at foobar.com", "alfred at foobar.com"],
>>        "cc": ["backoffice-mw-ops at 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
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>