A component's notifications can be:

  • Included in a watchlist that users can subscribe to.
  • Configured to be sent to an individual user or an email address
  • Caught by the default notification settings.

The options listed above are in descending order of flexibility.

The recommended method for managing notifications, is to create watchlists for logical groupings of components and then add recipients to their required watchlists. It is perfectly valid to have watchlists that overlap which can make management even easier.

Watchlists

Watchlists provide a method for logically grouping components together and providing a visual indicator of any alerts occurring on one of the components. They also provide a scheduling mechanism that allows the redirection of notifications to different users based on their defined shifts. The status of all watchlists is displayed on the Engine Monitor page.

Watchlists have the added flexibility of allowing Scheduling. A schedule allows for the specification of shifts; blocks of time during the day; for example, a 24 hour day would commonly be split into three 8-hour shifts. When a user subscribes to a watchlist that has shifts configured, the user can be set up to only receive notifications during particular shifts and/or on particular days and/or including public holidays. This allows you to configure the notifications to follow your shift roster.

Watchlists also support the scheduling of leave for a user. This allows a user to schedule their leave in the system and have their notifications redirected to another user.

Individuals/Email Addresses

Configuring a component to send notifications to an email address or individual is the most granular option but has the following drawbacks:

  • There is no shift support.
  • There is no leave support.
  • It is more difficult to see who is getting what notifications for each component since there is no grouping.

Default Notifications

The system can be configured with Default Notification Settings for all new components that are being added and do not have notifications set up or in case the notification schedule has gaps. The purpose is to handle components that do not have any User, SNMP or an Email Address set up to receive notifications and where watchlists have gaps in the schedule.

This is the catch-all method for notifications. The major drawback of having this configured, is that all components and the engine will log to this meaning test routes etc that you may not be interested in receiving notifications from are included.

The recommended method for managing notifications, is to create watchlists and then add recipients to their required watchlists. It is perfectly valid to have watchlists that overlap which can make management even easier.

Notification Destinations

Notifications can be sent to the following:

  • Person (24/7) - Enables you to specify a user that these notifications will be sent to 24/7. Each user has their own Email Address, SMS and Pager number.
  • Watchlist - Enables you to specify a watchlist that these notifications should be sent to.
  • Email - Enables you to configure a specific email address to send notifications to 24/7.
  • Windows Event Log - Enables you to send these notifications to the Windows Event Log (only applies to installations on Windows).
  • SNMP - Enables you to send these notifications via SNMP.

Notification Thresholds

System-level notifications are designed to provide you with the status of your overall system, whereas component-level notifications provide the status of individual components. When configuring notifications via the Management Console, there are three types of interrelated thresholds that you set:

  • System-level threshold - can be set for system-level notifications from the System Monitor page. It overrides any corresponding component-level or default threshold settings, but only if it is lower than them.
  • Component-level thresholds - can be set for component-level notifications for a specific component from the component's details page. It overrides the corresponding default threshold setting for that specific component.
  • Default thresholds - can be set for component types from the Default Settings page. It sets the default threshold for component-level notifications on a per component type basis unless overridden for a specific component by the corresponding component-level threshold.

For example:

  1. Set the default alarm threshold for communication points' Large Queue to 100. All communication points will trigger an alarm when the number of messages in their queue reaches 100.
  2. Set a Directory communication point's alarm threshold for Large Queue to 50. This specific Directory communication point will now trigger an alarm when the number of messages in its queue reaches 50.
  3. Set the system-level alarm threshold for Large Communication Point Queue to 25. All communication points and routes set to the default settings as well as the Directory communication point with a custom setting will now trigger an alarm when the number of messages in their queue reaches 25. In this case, the system-level threshold should probably be set to value much larger than 100 if it is to be of any value to users.

Notification Logging

As of Rhapsody 6.4, three separate Log4j loggers are provided for notifications, which are categorized according to purpose:

  • Notification.User - for user actions applied to specific alert notifications (such as dismiss, suspend, or comment).
  • Notification.System - for system operations.
  • Notification.Delivery - for notification delivery-related logs.

Users have the ability to configure the log level for each logger category independently.