This page shows an overview about future enhancements in the processing of alerts.
Those may be

• Pluggable alert senders (in RHQ 3)

• Ability to acknowledge alerts (can be done via UI in RHQ 3)

• Disabling of alerts / alert sending during maintenance

• Escalation of non-acknowledged alerts

• Groupwise conditions (e.g. if 2 of x nodes are down... or if > 75% of nodes have condition true)

The next image shows the overview that is explained below

1) Conditions happening - resources deliver events like metrics, availability, operation status etc.. Those are fed into the alert condition handling. If conditions match, the alert is ready to fire
2) Alert fires
3) Maintenance check is done (future) - for the target resource it is checked if this resource or one of its platforms is in maintenance state (may be a boolean on the resource or its inventory state). If in maintenance mode, alert is not sent. (One can argue if the next step is hit nevertheless, but the maintenance condition is forwarded into the sender selection process
4) Alert is fired
5) Senders are selected from the AlertDefinition and processed in the defined order
6) If escalation is implemented, the sender selection picks up operator schedules and escalation rules to pick up the correct email / sms / .. receipients. Those will be passed to the senders.
7) In case of alert acknowledgement, senders may set the acknowledged flag on alerts
8) A periodic job checks for non-acknowledged alerts and re-injects them into the sender selection. This job can also pick up alerts where the ack time is to far in the past - escalation processing picks the next person in the escalation table to escalate to.

Note that the colored parts will not be in the first implementation.

The operation schedules table will contain data who is on duty for what time of a day - with appropriate filling of the table it is possible to implement follow the sun escalation.
Actually while this schedule table and the list of escalations look like just database tables, this "red block" should be seen as a service that delivers this data to the alert processing (and probably other subsystems within RHQ). The service itself can get the data from e.g. LDAP or CSV-files.

When notifying roles and users notification schemes for the users can be honored. This means that we need to allow users to give their preferred ways of being alerted within the users preferences. This choice may be limited depending on what we support. Email is default, but with Mobicents installed, one could e.g. also allow voice calls and Short messages (SMS).

About maintenance mode: this is a "bit" on a resource which will put the resource into maintenance mode - along with all its children. This could be combined into groups (mixed allowed) to put a whole bunch of resources into maintenance mode at at time. It should be possible to schedule the maintenance mode (for the next 2 hours) or at recurring times (e.g. each saturday between 2 and 4 am). - Thanks to Maurice Zeijen