Unsolved
This post is more than 5 years old
3 Posts
0
1626
March 16th, 2015 14:00
How to probe MBIM (Maintenance and Business Impact Manager) Service
Am researching how to probe the MBIM (Maintenance and Business Impact Manager) service to gather and evaluate metrics that would be helpful in determining performance impact of the automated process we're using to tag devices as InMaint.
Would like to understand in a bit of depth on what's taking place underneath the hood with MBIM each time an object is tagged InMaint. For example does each submission of a new/updated InMaint tag notification for an object or list of objects cause MBIM to evaluate a full notification list; when/how are notifications evaluated for maintenance correlation, what notification queue(s) are evaluated, etc.
Would like to know how to interrogate MBIM for the following and any other useful data:
-List of objects MBIM is tracking which are tagged as InMaint
-Start/End maintenance window times for objects tagged as InMaint
Appreciate any help with how to probe MBIM for metrics that might be indicative to performance as described above or related, and more depth with understanding how the service works behind the scenes so that we might understand the implications in the way objects are tagged InMaint. Thanks!
AlanG2
17 Posts
1
March 18th, 2015 10:00
We don't use the InMaint function at our site - we ended up implementing our own. But I've poked around in the code a bit. The best way to familiarise yourself with it is to review the code in rules/bim/ics-maintenance.asl and rules/ics/ics-nl-processing.asl - this is where the bulk of the work is performed.
My understanding is that each invocation of the InMaint tool creates a notification which encapsulates the device name and the end time period, also an auto-expiry timer is set to clear the event at the start of the maint window. When the maint event clears this signifies the start of the window and triggers moving all active events on that device to InMaint. In addition another notification is created with an auto-expiry timer linked to the end of the maint window and an internal lookup table is populated with the name of the device.
For every event ingressing SAM the internal lookup table is inspected and the event tagged InMaint if there is a match on the device name. At the end of the window the special InMaint notification expires and this triggers MBIM to remove the the InMaint tag from any active events on that device and finally remove the device name from the internal lookup table.
Alan
PaulORourke
170 Posts
1
March 19th, 2015 00:00
Hi,
As AlanG mentioned, best option would be to review the scripts mentioned and his summary is pretty accurate.
To get the list of current InMaint devices, use the following dmctl command to get the contents of the internal lookup table:
./dmctl -s get ICS_InMaint::ICS-InMaint::InMaintTable
As regards the start/end time for maintenance windows, this is tracked in notifications as mentioned by AlanG.
The two main types of notifications are SchedMaint and InMaint notifications.
SchedMaint notifications are placeholder notifications that track upcoming maintenance windows.
When a SchedMaint notification clears that signals the beginning of a maintenance window.
This rule takes the context data from the SchedMaint notification and creates an InMaint notification.
The pre-computed duration from the UserDefined1 field is used for the duration of the InMaint notification and the end time is used from UserDefined2 field.
Please let me know if you have any additional questions.
Kind Regards,
Paul O'Rourke