Events timestamp field mapping

Products

• VMware Smart Assurance

Issue/Introduction

• Unable to apply filter on timestamp fields FirstNotifiedAt, LastChangedAt, LastClearedAt and LastNotifiedAt in Smarts Notification in frontend reports for Smarts Events.
• How are the timestamp fields from Smarts(FirstNotifiedAt, LastChangedAt, LastClearedAt and LastNotifiedAt) represented in EMC M&R?
• Why are lastNotifiedAsDate, createdTimestamp, notifiedTimestamp ,lastNotifiedPerDay, lastNotifiedGraphable all mapped to OpenedAt/LastNotifiedAt?
• Why is FirstNotifiedAt not used?

Environment

Watch4Net/M&R - 7.x

Cause

• The behaviour is due to the way Watch4net handles Smarts events.
• In Smarts, each event has its own instance of the ICS_Notification class until it is archived, regardless of how many times it is cleared and re-notified.
• In Watch4net, each time a Smarts notification is cleared and re-notified, a new instance   i.e. new line in the events_live table is created.
  
  

Resolution

The following table shows the relationship between the timestamp fields in Smarts and the Watch4net Database and Frontend:

Smarts Notification: (ICS_Notification class)	Watch4net Database: (events_live / events_archive tables)	Watch4net Frontend: (APG_HOME/Custom/WebApps-Resources/Default/property-mapping/FLOW-RPE2.xml)
FirstNotifiedAt	----	----
LastChangedAt	LastChangedAt	lastModifiedAsDate
LastClearedAt	ClosedAt	clearedAsDate
		clearedTimestamp
LastNotifiedAt	OpenedAt	lastNotifiedAsDate
		createdTimestamp
		notifiedTimestamp
		lastNotifiedPerDay
		lastNotifiedGraphable

1). Why are lastNotifiedAsDate, createdTimestamp, notifiedTimestamp ,lastNotifiedPerDay, lastNotifiedGraphable all mapped to OpenedAt/LastNotifiedAt? Why is FirstNotifiedAt not used?

• The reason for this is due to the way Watch4net handles Smarts events. It treats them slightly differently to the way Smarts does.
• In Smarts, each event has its own instance of the ICS_Notification class until it is archived, regardless of how many times it is cleared and re-notified.
• In Watch4net, each time a Smarts notification is cleared and re-notified, a new instance i.e. new line in the events_live table is created.
• The following two examples illustrate this for both DURABLE and MOMENTARY notifications. 
  
  Example 1 : DURABLE Notifications:
   
  1. A new DURABLE notification is raised (NOTIFY):
   
  dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_router_Unresponsive | grep edAt
                        FirstNotifiedAt = 1403603907
                          LastChangedAt = 1403603907
                          LastClearedAt = 0
                         LastNotifiedAt = 1403603907
   
   
  mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="router";
  +------------+---------------+----------+------------------------------------------+
  | OpenedAt   | LastChangedAt | ClosedAt | Name                                     |
  +------------+---------------+----------+------------------------------------------+
  | 1403603907 |    1403603907 |     NULL | NOTIFICATION-Router_router_Unresponsive |
  +------------+---------------+----------+------------------------------------------+
   
   
   
  2. Another occurrence is raised:
   
  ./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_router_Unresponsive | grep edAt
                        FirstNotifiedAt = 1403603907
                          LastChangedAt = 1403604161
                          LastClearedAt = 0
                         LastNotifiedAt = 1403603907
   
                                            
  mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="router";
  +------------+---------------+----------+------------------------------------------+
  | OpenedAt   | LastChangedAt | ClosedAt | Name                                     |
  +------------+---------------+----------+------------------------------------------+
  | 1403603907 |    1403604161 |     NULL | NOTIFICATION-Router_router_Unresponsive |
  +------------+---------------+----------+------------------------------------------+
   
  3 The notification is CLEARED:
   
  ./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_router_Unresponsive | grep edAt
                        FirstNotifiedAt = 1403603907
                          LastChangedAt = 1403604315
                          LastClearedAt = 1403604315
                         LastNotifiedAt = 1403603907
   
  mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="router";
  +------------+---------------+------------+------------------------------------------+
  | OpenedAt   | LastChangedAt | ClosedAt   | Name                                     |
  +------------+---------------+------------+------------------------------------------+
  | 1403603907 |    1403604315 | 1403604315 | NOTIFICATION-Router_router_Unresponsive |
  +------------+---------------+------------+------------------------------------------+
   
   
  4. Another occurrence of the notification is raised after it is CLEARED (Re-NOTIFY):
   
  ./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_router_Unresponsive | grep edAt
                        FirstNotifiedAt = 1403603907
                          LastChangedAt = 1403604412
                          LastClearedAt = 1403604315
                         LastNotifiedAt = 1403604412
                                            
  mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="router";
  +------------+---------------+------------+------------------------------------------+
  | OpenedAt   | LastChangedAt | ClosedAt   | Name                                     |
  +------------+---------------+------------+------------------------------------------+
  | 1403603907 |    1403604315 | 1403604315 | NOTIFICATION-Router_router_Unresponsive |
  | 1403604412 |    1403604412 |       NULL | NOTIFICATION-Router_router_Unresponsive |
  +------------+---------------+------------+------------------------------------------+
   
   
  From this we can see that for DURABLE notifications:
• In Smarts, before the CLEAR and re-NOTIFY, LastNotifiedAt = FirstNotifiedAt (highlighted in green)
• LastNotifiedAt is only updated after a CLEAR and re-NOTIFY. At this point a new line in the Watch4net events_live table has been created and the OpenedAt field for the new line is equal to the LastNotifiedAt field in Smarts (highlighted in yellow).
• This is why OpenedAt is mapped to lastNotifiedAsDate etc in the frontend.

 
 
       Example 2 : MOMENTARY notifications:
 
     1. A new MOMENTARY notification is raised (NOTIFY)
 
     ./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_rtr_ColdStart | grep edAt
                      FirstNotifiedAt = 1403604556
                        LastChangedAt = 1403604556
                        LastClearedAt = 0
                       LastNotifiedAt = 1403604556
 
      mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="rtr";
+------------+---------------+------------+---------------------------------------+
| OpenedAt   | LastChangedAt | ClosedAt   | Name                                  |
+------------+---------------+------------+---------------------------------------+
| 1403604556 |    1403604556 | 1403604556 | NOTIFICATION-Router_rtr_ColdStart |
+------------+---------------+------------+---------------------------------------+
 
 
     2. Another occurrence of the notification is raised:
 
     ./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_rtr_ColdStart | grep edAt
                      FirstNotifiedAt = 1403604556
                        LastChangedAt = 1403604998
                        LastClearedAt = 0
                       LastNotifiedAt = 1403604998
 
mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="rtr";
+------------+---------------+------------+---------------------------------------+
| OpenedAt   | LastChangedAt | ClosedAt   | Name                                  |
+------------+---------------+------------+---------------------------------------+
| 1403604556 |    1403604556 | 1403604556 | NOTIFICATION-Router_rtr_ColdStart |
| 1403604998 |    1403604998 | 1403604998 | NOTIFICATION-Router_rtr_ColdStart |
+------------+---------------+------------+---------------------------------------+
 
 
    3. The notification is CLEARED
 
    ./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_rtr_ColdStart | grep edAt
                      FirstNotifiedAt = 1403604556
                        LastChangedAt = 1403605165
                        LastClearedAt = 1403605165
                       LastNotifiedAt = 1403604998
 
mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="rtr";
+------------+---------------+------------+---------------------------------------+
| OpenedAt   | LastChangedAt | ClosedAt   | Name                                  |
+------------+---------------+------------+---------------------------------------+
| 1403604556 |    1403604556 | 1403604556 | NOTIFICATION-Router_rtr_ColdStart |
| 1403604998 |    1403605165 | 1403604998 | NOTIFICATION-Router_rtr_ColdStart |
+------------+---------------+------------+---------------------------------------+
 
    4. Another occurrence of the notification is raised after it is CLEARED (Re-NOTIFY):
 
    ./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_rtr_ColdStart | grep edAt
                      FirstNotifiedAt = 1403604556
                        LastChangedAt = 1403605214
                        LastClearedAt = 1403605165
                       LastNotifiedAt = 1403605214
 
mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="rtr";
+------------+---------------+------------+---------------------------------------+
| OpenedAt   | LastChangedAt | ClosedAt   | Name                                  |
+------------+---------------+------------+---------------------------------------+
| 1403604556 |    1403604556 | 1403604556 | NOTIFICATION-Router_rtr_ColdStart |
| 1403604998 |    1403605165 | 1403604998 | NOTIFICATION-Router_rtr_ColdStart |
| 1403605214 |    1403605214 | 1403605214 | NOTIFICATION-Router_rtr_ColdStart |
+------------+---------------+------------+---------------------------------------+
 
From this we can see that for MOMENTARY notifications

• In Smarts, LastNotifiedAt is updated for every NOTIFY, regardless of whether it is cleared.
• Watch4net treats MOMENTARY notifications as standalone one-off events and hence always has OpenedAt=ClosedAt.
• For EVERY occurrence, a new line is created in events_live.
• LastNotifiedAt = OpenedAt. Again, this is why OpenedAt is mapped to lastNotifiedAsDate in the frontend.

The following shows how these timestamp fields appear in a table report: