SAM domain log has messages such as:
INCHARGE-AM-PM_Event-Driver
ASL_MSG-*-ASLP-ics/ics-event-processing.asl: DISCARDED EVENT:Interface::IF-10.10.10.10/1::Down- Reason: event object is null
--
INCHARGE-AM-PM_Event-Driver
ASL_MSG-*-ASLP-ics/ics-event-processing.asl: DISCARDED EVENT:Interface_Fault_MIB2::I-Interface_Fault_MIB2-IF-10.10.10.10/2::ExceededMaximumUptime- Reason: event object is null
--
INCHARGE-AM-PM_Event-Driver
ASL_MSG-*-ASLP-ics/ics-event-processing.asl: DISCARDED EVENT:Interface_Fault_MIB2::I-Interface_Fault_MIB2-IF-10.10.10.10/2::BackupActivated- Reason: event object is null
--
INCHARGE-AM-PM_Event-Driver
ASL_MSG-*-ASLP-ics/ics-event-processing.asl: DISCARDED EVENT:Interface::IF-10.10.10.10/2::LogicalConnectionDown- Reason: event object is null
--
INCHARGE-AM-PM_Event-Driver
ASL_MSG-*-ASLP-ics/ics-event-processing.asl: DISCARDED EVENT:Interface::IF-10.10.10.10/2::Disabled- Reason: event object is null
Why does SAM domain log have "Event Object is null" messages?
Are these messages benign?
Smarts 10.X / 2.X
These log entries are created when SAM receives a CLEAR event and the original event object (created by NOTIFY event) is no longer in the topology.
When the Smarts IP domain has a topology change, it will trigger a Topology Sync between SAM and Smarts IP. After the topology sync completes, SAM will purge event objects from systems that are no longer in the topology.
If this purging is followed by a CLEAR event this may create the above log messages.
Delayed CLEAR events can be generated by any layers such as Aggregrate SAM layer (due to congestion) or OI (due to delayed traps) or by hook scripts, etc.
There is no easy way to prevent these messages from occurring.
One possible workaround is to modify the ics-event-processing.asl script and comment out this log print line, then it will not occur:
if (eventObj->isNull()) {
if (detailDebug) { print(eventObj." is null"); }
// print("DISCARDED EVENT:".eventClass."::".instance."::".event."- Reason: event object is null");
return;
}