Have you ever wondered how TBSM processes events? Have you been in a situation where you’d like to see what would happen if those events would just come in again and be processed? Did you add a new rule to a template that’s been in production for some time and now want to see how the service model would respond? Ever wonder what some of those Netcool/OMNIbus fields were used for that start with RAD_?
TBSM’s event processing is focused on a change in the severity of Netcool/OMNIbus events by default (see RAD_eventbroker.props for more detail). When an incoming event arrives, it’s assigned a specific severity as it’s inserted into Netcool/OMNIbus or by some other automated logic, correlation, etc. within Netcool/OMNIbus or Netcool/Impact. TBSM’s event reader continuously compares incoming events and identifies through comparison of the Severity field to the RAD_RawInputLastValue field that this event hasn’t been processed. TBSM updates the RAD_RawInputLastValue field with the actual Severity field contents as well as determines which rules are associated with this event updating the RAD_FilterIDList.
The key fields here are the original Severity field and the RAD_RawInputLastValue field. If these are both the same value, then things are status quo based on how the rules were configured. If the incoming event’s Severity field is updated, say from Severity 3 (Minor) to Severity 5 (Critical) then TBSM recognizes that now Severity is 5 and RAD_RawInputLastValue is still 3. This means that the TBSM will process this event and update in accordance to the specific rules in the RAD_FilterIDList and in a simple cast change the service instance from Marginal to Bad (Yellow to Red).
The recent TBSM v4.1.1 Interim Fix 11 quietly introduced (it’s in TBSM 4.2 IF1 also which is due today!) a new RADSHELL command that allows you to reprocess all Netcool/OMNIbus events. The command simply updates all events in Netcool/OMNIbus by resetting RAD_FilterIDList and RAD_RawInputLastValue. This in turn will cause TBSM to reprocess all of these events. The new RADSHELL command is: replayTBSMEvent(); .
You get a bit of control for this command by setting a property in the RAD_SLA.props file and the sla.replayradevents option. By default it’s set to RAD_RawInputLastValue = 6, RAD_FilterIDList = ” . This sets the RAD_RawInputLastValue to a value that’s not valid (Severity 0-5 are normal so you’d never get a Severity of 6) and blanks out the RAD_FilterIDList which causes TBSM to determine which rules match events.
We’ve always taught our clients and IBMers that you can just use nco_sql to manually update these fields to force TBSM to reprocess events. While the new replayTBSMEvent(); will be useful for broad based event updates, manually using nco_sql, WebTop AEL or the Desktop Client offers more fine grained ability to update specific events instead of all events.
Thanks to someone in TBSMDev for slipping that new command in!
Comments on this entry are closed.