Each notification has a unique name. A notification’s name consists of the class name and instance name where the event occurred, and the event name. The notification naming convention is:
NOTIFICATION-ClassName_InstanceName_EventName
For example, the notification NOTIFICATION-Router_R1_Down identifies the event Down, which occurred in instance R1 of the Router class.
The Notification Log Console will not list more than one notification with this name. If the event clears and occurs again before it is archived, the Count field is increased accordingly.
The following notification attributes are related to a notification’s state:
-
First Notify — Is the first time a notification occurs.
-
Last Notify — Is the last time a notification occurs.
-
Last Clear — Is the last time a notification cleared.
-
Last Change — Is the last time a notification changed.
-
Count — Is the number of occurrences of an event starting from First Notify until Last Notify.
For the First Notify and Last Notify attributes, the timestamp value is provided by the underlying domain that diagnosed the event.
“Notification Log columns� on page 59 includes additional notification attributes information.
States of NOTIFICATION-Router_R1_Down illustrates the states of the notification NOTIFICATION-Router_R1_Down. For the First Notify and Last Notify attributes, the timestamp value is provided by the underlying domain that diagnosed the event. Values for Last Change, Count, and Last Clear (not shown) are provided by the Global Manager.
Note:When a Global Manager disconnects from an underlying Domain Manager, all notifications identified as ACTIVE are marked as WAS_ACTIVE. When the Global Manager reconnects to the underlying Domain Manager, the Global Manager refreshes its subscriptions and starts receiving currently active events from the Domain Manager. Existing WAS_ACTIVE notifications are interpreted as resubscription messages, not as re-occurrences of notifications. The notification is updated to a state of ACTIVE, the Last Change attribute is assigned the current time, and the Last Notify attribute value remains unchanged.
| Time |
User/system actions |
Notification status |
Time of first notify |
Time of last notify |
Time of last change |
Count |
|---|---|---|---|---|---|---|
| 2:00 |
Notify |
1:00 |
1:00 |
2:00 |
1 |
|
| 2:15 |
Clear |
1:00 |
1:00 |
2:15 |
1 |
|
| 2:25 |
Notify |
1:00 |
2:25 |
2:25 |
2 |
|
| 2:35 |
Clear |
1:00 |
2:25 |
2:35 |
2 |
|
| 3:00 |
Acknowledge |
1:00 |
2:25 |
3:00 |
2 |
|
| 3:05 |
Archived |
1:00 |
2:25 |
3:00 |
2 |
|
| 3:55 |
Notify |
3:55 |
3:55 |
3:55 |
1 |
|
| 4:00 |
Disconnect |
3:55 |
3:55 |
4:00 |
1 |
|
| 4:05 |
Notify |
3:55 |
3:55 |
4:05 |
1 |
In this example, an Availability Manager generated a Down event at 1:00.
At 2:00, the Global Manager connected to the Availability Manager and the Global Manager created the notification NOTIFICATION-Router_R1_Down for the Down event. The Global Manager retains the original timestamp of the event and stores it in the notification—First Notify and Last Notify are assigned the values of 1:00. The notification’s EventState is ACTIVE.
At 2:15, the notification is cleared.
At 2:25, the Availability Manager generated the same Down event again, the Availability Manager was already connected to the Global Manager, and the Global Manager reactivates the notification. The First Notify remains 1:00 and the Last Notify reads 2:25. The notification’s EventState changes to ACTIVE.
At 2:35, the notification is cleared. The notification’s EventState changes to INACTIVE.
At 3:00, the operator acknowledged the notification. The notification’s EventState changes to INACTIVE.
Notice at 3:05, the notification is archived and the archive action records the most recent values for First Notify, Last Notify, and Last Change. A notification cannot be archived until it has been acknowledged. Acknowledgement does not change a notification’s state unless the notification attribute ClearOnAcknowledge is set to True for a specific notification. The notification is removed from the notification view.
At 3:55, the Availability Manager generated a Down event again and the Global Manager created the notification again. After a notification is archived, the Global Manager treats a recurrence of that notification as though it were a first occurrence. The notification’s EventState is ACTIVE. The value of notification attributes start all over again: new First Notify time, Count starts at 1, and so on.
At 4:00, the Availability Manager disconnects from the Global Manager. The Global Manager marks the notification as WAS_ACTIVE. Last Change value is updated as whenever a change is applied to a notification.
At 4:05, the Availability Manager is restarted and reconnects to the Global Manager. Since a reconnection causes a client to re-subscribe to remote server’s events, all currently active alarms in the Availability Manager that the Global Manager subscribed are re-sent to the Global Manager. The Global Manager uses these event messages to update the event state of existing notifications. Notifications that did not previously exist or were INACTIVE before the disconnect, are notified with their Last Notify and Last Change times initialized or updated appropriately, and the notifications’ EventState is ACTIVE. For existing WAS_ACTIVE notifications, the event message is interpreted as a re-subscription message, in other words not as a re-occurrence of the notification. The notification’s Last Notify does not change. Its EventState is updated to ACTIVE and Last Change time is assigned the current time since changes were applied to it. In short, Last Notify attribute value is not updated when a notification transitions from WAS_ACTIVE to ACTIVE.
