Smarts SDI Adapter: There is a time delay between events created in SAM and writing to tables like notification_occurrences in the SDI adapter

Products

• VMware Smart Assurance

Issue/Introduction

Symptoms:


Seeing 1-2 hour delays between events created in SAM and the corresponding data being inserted into the SDI adapter table.

Environment

VMware Smart Assurance - SMARTS

Cause

The SDI adapter is single threaded, it processes topology updates, summary updates and Report updates every day.

During the process of these updates, the notification sync thread will not process any new notifications which can lead to delays.

During these updates the sdi adapter will queue the notification messages and process it once after the updating is complete.

The file which controls this is sdi.conf where you define deviceUpdateInterval and SummaryUpdateInterval.

Resolution

Summary Update and Device Update interval;

There are a set of classes defined in SDI_Summary_Policy which is present in sdi.conf,

By default the list is 

DI_Summary_Policy::SDI-Summary-Policy{
EventTypes += "Unresponsive"
useDeviceTable = TRUE
ClassEventMap += 
{ "Host", "" }
ClassEventMap += { "Switch", "" }
ClassEventMap += { "Router", "" }
ClassEventMap += { "Cable", "" }
ClassEventMap += { "NetworkConnection", "" }
ClassEventMap += { "ServiceOffering", "Impacted" }
ClassEventMap += { "ServiceSubscriber", "Impacted" }
ClassEventMap += { "BusinessProcess", "Impacted" }
ClassEventMap += { "LOB", "Impacted" }
ClassEventMap += { "BusinessUnit", "Impacted" }
ClassEventMap += { "Department", "Impacted" }
ClassEventMap += { "Customer", "Impacted" }
ClassEventMap += { "Organization", "Impacted" }
}

Class names like Host, Router, Switch are defined here. The instances of these classes are synchronised from SAM server with the SDI database. This is done once during the startup and later the deviceUpdateInterval defines the sync period.  By default the period is 86400 which is in seconds which defaults to 24 hours 

In summary, once everyday, for the classes mentioned in SDI_SummaryPolicy, the topology will be synced from SAM to SDI database.

The summary feature is about getting a device summary, for example a Router Unresponsive notification may get notified to SDI database from SAM server and at some point of time, this notification gets cleared. The device summary which actually executes as per the SummaryUpdateInterval - tries to get a summary of Unresponsive notifications for a device - which is like, the summary of a device would be the Router was unresponsive for a duration (the duration will be caluculated as notification->cleartime - notification->notifyTime).

The summary update - would provide the summary of device based on the notifications of the device. Again summary update runs everyday after a device update is complete.

There is one another feature enableNewRMData, this flag can be set to FALSE; the purpose of this is to generate reports for a  product Report Manager, now that the Report Manager product is no longer supported, this enableNewRMData can be set to FALSE;

If the issue is synchronization of the notifications from SAM to SDI database, then these deviceUpdate and summaryUpdate can be disabled. 

To disable summary updates - (changes in sdi.conf)
change the 

enableSummary = TRUE 

to 
enableSummary = FALSE

to disable device updates - change the section sdi.conf

SDI_Summary_Policy::SDI-Summary-Policy{
EventTypes += "Unresponsive"
useDeviceTable = TRUE

ClassEventMap += { "Host", "" } 
ClassEventMap += 
{ "Switch", "" } 
ClassEventMap += 
{ "Router", "" } 
ClassEventMap += 
{ "Cable", "" } 
ClassEventMap += 
{ "NetworkConnection", "" } 
ClassEventMap += 
{ "ServiceOffering", "Impacted" } 
ClassEventMap += 
{ "ServiceSubscriber", "Impacted" } 
ClassEventMap += 
{ "BusinessProcess", "Impacted" } 
ClassEventMap += 
{ "LOB", "Impacted" } 
ClassEventMap += 
{ "BusinessUnit", "Impacted" } 
ClassEventMap += 
{ "Department", "Impacted" } 
ClassEventMap += 
{ "Customer", "Impacted" } 
ClassEventMap += 
{ "Organization", "Impacted" } 
}

to

SDI_Summary_Policy::SDI-Summary-Policy{
}

after this is done, SDI adapter needs to be restarted