Events timestamp field mapping
search cancel

Events timestamp field mapping

book

Article ID: 333425

calendar_today

Updated On:

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:

(/opt/APG/Custom/WebApps-Resources/Default/property-mapping/FLOW-RPE2.xml)
FirstNotifiedAt ---- ----
LastChangedAt LastChangedAt lastModifiedAsDate
LastClearedAt  ClosedAt clearedAsDate
    clearedTimestamp
LastNotifiedAt  OpenedAt lastNotifiedAsDate
    createdTimestamp
    notifiedTimestamp
    lastNotifiedPerDay
    lastNotifiedGraphable


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_rtr9876_Unresponsive | grep edAt
                      FirstNotifiedAt = 1403603907
                        LastChangedAt = 1403603907
                        LastClearedAt = 0
                       LastNotifiedAt = 1403603907
 
 
mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="rtr9876";
+------------+---------------+----------+------------------------------------------+
| OpenedAt   | LastChangedAt | ClosedAt | Name                                     |
+------------+---------------+----------+------------------------------------------+
| 1403603907 |    1403603907 |     NULL | NOTIFICATION-Router_rtr9876_Unresponsive |
+------------+---------------+----------+------------------------------------------+
 
 
 
2. Another occurrence is raised:
 
./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_rtr9876_Unresponsive | grep edAt
                      FirstNotifiedAt = 1403603907
                        LastChangedAt = 1403604161
                        LastClearedAt = 0
                       LastNotifiedAt = 1403603907
 
                                          
mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="rtr9876";
+------------+---------------+----------+------------------------------------------+
| OpenedAt   | LastChangedAt | ClosedAt | Name                                     |
+------------+---------------+----------+------------------------------------------+
| 1403603907 |    1403604161 |     NULL | NOTIFICATION-Router_rtr9876_Unresponsive |
+------------+---------------+----------+------------------------------------------+
 
3 The notification is CLEARED:
 
./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_rtr9876_Unresponsive | grep edAt
                      FirstNotifiedAt = 1403603907
                        LastChangedAt = 1403604315
                        LastClearedAt = 1403604315
                       LastNotifiedAt = 1403603907
 
mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="rtr9876";
+------------+---------------+------------+------------------------------------------+
| OpenedAt   | LastChangedAt | ClosedAt   | Name                                     |
+------------+---------------+------------+------------------------------------------+
| 1403603907 |    1403604315 | 1403604315 | NOTIFICATION-Router_rtr9876_Unresponsive |
+------------+---------------+------------+------------------------------------------+
 
 
4. Another occurrence of the notification is raised after it is CLEARED (Re-NOTIFY):
 
./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_rtr9876_Unresponsive | grep edAt
                      FirstNotifiedAt = 1403603907
                        LastChangedAt = 1403604412
                        LastClearedAt = 1403604315
                       LastNotifiedAt = 1403604412
                                          
mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="rtr9876";
+------------+---------------+------------+------------------------------------------+
| OpenedAt   | LastChangedAt | ClosedAt   | Name                                     |
+------------+---------------+------------+------------------------------------------+
| 1403603907 |    1403604315 | 1403604315 | NOTIFICATION-Router_rtr9876_Unresponsive |
| 1403604412 |    1403604412 |       NULL | NOTIFICATION-Router_rtr9876_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_rtr6789_ColdStart | grep edAt
                      FirstNotifiedAt = 1403604556
                        LastChangedAt = 1403604556
                        LastClearedAt = 0
                       LastNotifiedAt = 1403604556
 
mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="rtr6789";
+------------+---------------+------------+---------------------------------------+
| OpenedAt   | LastChangedAt | ClosedAt   | Name                                  |
+------------+---------------+------------+---------------------------------------+
| 1403604556 |    1403604556 | 1403604556 | NOTIFICATION-Router_rtr6789_ColdStart |
+------------+---------------+------------+---------------------------------------+
 
 
2. Another occurrence of the notification is raised:
 
./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_rtr6789_ColdStart | grep edAt
                      FirstNotifiedAt = 1403604556
                        LastChangedAt = 1403604998
                        LastClearedAt = 0
                       LastNotifiedAt = 1403604998
 
mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="rtr6789";
+------------+---------------+------------+---------------------------------------+
| OpenedAt   | LastChangedAt | ClosedAt   | Name                                  |
+------------+---------------+------------+---------------------------------------+
| 1403604556 |    1403604556 | 1403604556 | NOTIFICATION-Router_rtr6789_ColdStart |
| 1403604998 |    1403604998 | 1403604998 | NOTIFICATION-Router_rtr6789_ColdStart |
+------------+---------------+------------+---------------------------------------+
 
 
3. The notification is CLEARED
 
./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_rtr6789_ColdStart | grep edAt
                      FirstNotifiedAt = 1403604556
                        LastChangedAt = 1403605165
                        LastClearedAt = 1403605165
                       LastNotifiedAt = 1403604998
 
mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="rtr6789";
+------------+---------------+------------+---------------------------------------+
| OpenedAt   | LastChangedAt | ClosedAt   | Name                                  |
+------------+---------------+------------+---------------------------------------+
| 1403604556 |    1403604556 | 1403604556 | NOTIFICATION-Router_rtr6789_ColdStart |
| 1403604998 |    1403605165 | 1403604998 | NOTIFICATION-Router_rtr6789_ColdStart |
+------------+---------------+------------+---------------------------------------+
 
4. Another occurrence of the notification is raised after it is CLEARED (Re-NOTIFY):
 
./dmctl -s INCHARGE-SA get ICS_Notification::NOTIFICATION-Router_rtr6789_ColdStart | grep edAt
                      FirstNotifiedAt = 1403604556
                        LastChangedAt = 1403605214
                        LastClearedAt = 1403605165
                       LastNotifiedAt = 1403605214
 
mysql> select OpenedAt,LastChangedAt,ClosedAt,Name from events_live where InstanceName="rtr6789";
+------------+---------------+------------+---------------------------------------+
| OpenedAt   | LastChangedAt | ClosedAt   | Name                                  |
+------------+---------------+------------+---------------------------------------+
| 1403604556 |    1403604556 | 1403604556 | NOTIFICATION-Router_rtr6789_ColdStart |
| 1403604998 |    1403605165 | 1403604998 | NOTIFICATION-Router_rtr6789_ColdStart |
| 1403605214 |    1403605214 | 1403605214 | NOTIFICATION-Router_rtr6789_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:


Powered by Wolken Software