There are conditions where SLM escalations are either inconsistent or incomplete execution of the expected workflow. Some examples are
1) update to the SLM Status field on the incident record does not reflect update to the MeasurementStatus field on the service target SLM:Measurement record
2) milestone notifications are either sporadic in being sent or not being sent
Typically, these conditions occur in a high production environment with extensive escalation workflow related to the SLM:EventSchedule:TAD_PollingEscalation escalation. |
This knowledge article may contain information that does not apply to version 21.05 or later which runs in a container environment. Please refer to Article Number 000385088 for more information about troubleshooting BMC products in containers. When SLM escalation workflow executed by SLM:EventSchedule:TAD_PollingEscalation escalation is not executing as expected, there has been great success simply by moving this escalation to run in its own escalation pool. The option to configure separate escalation pools is available with v7.1 and later releases of ARSystem server. Following is exceprt from the v7.5 Workflow and Objects Guide:
Following are directions to configure SLM:EventSchedule:TAD_PollingEscalation escalation to run in its own escalation pool:
1) determine how many escalation pools are currently configured
- open Admin tool or Dev Studio
- list escalations in descending order by escalation pool
- the highest escalation pool number is the number of escalation pools that are configured
2) identify whether SLM:EventSchedule:TAD_PollingEscalation escalation is
- running in an escalation pool
- if so, whether any other escalations are configured to run in that same pool
3) make whatever changes are necessary to escalations currently configured to run in escalation pools to ensure that identify whether SLM:EventSchedule:TAD_PollingEscalation escalation is running in a pool by itself and that no other escalations are configured to run in this escalation pool
- move any escalations running in the same escalation pool to a different pool
OR
- configure SLM:EventSchedule:TAD_PollingEscalation escalation to run in a pool in which no other escalation is running; this can be done by configuring this escalation to run in a pool that is higher than the highest escalation pool number already in use
4) determine whether there are enough escalation threads configured to support the number of escalation pools configured
- through the Admin console, confirm the minimum and maximum threads configured for the escalation queue
- configure maximum threads to be equal to the highest escalation pool number configured for any escalation
NOTE:
The minimum number of threads for escalation queue is different that minimum number of threads for fast, list, or private queues. There will be as many escalations threads started at startup of ARServer as there are number of maximum threads configured. With fast, list and private queues, there will be as many fast, list and private threads for each queue starts as there are number of minimum threads configured with ARServer starting a new thread at anytime that the load on that queue warrants. The maximum number of threads for the escalation queue should reflect how many escalation pools are configured. Because all escalations will be evaluated at startup of the escalation queue, all escalation pools (maximum number of threads for escalation queue) will be required immediately. As noted in the excerpt above, if an escalation is assigned to a pool for which no thread is configured, it will run be run by the default or first escalation pool (thread).
5) restart ARServer to implement configuration of escalation pools
NOTE:
An alternative to restart of ARServer is to temporarily disable any escalation which has a change to escalation pool configuration and then enabling it once more. Turn on escalation logging before disabling an escalation and the logging output when it is enabled once more will verify which escalations are running in which pools.
It is also recommended that the SLM:ConfigReviewPeriod:Check escalation be configured to run in a separate escalation pool. This escalation has potential for being a long running escalation and, as such, can impact timely execution of other escalations running on the same thread (pool). If the version, patch or hotfix version of SLM includes existence of the SLM:EventSchedule:TAD_PollingEscalation_Compliance escalation, it is imperative that this escalation be configured to run in the same escalation pool as the SLM:ConfigReviewPeriod:Check escalation. Failure to do will will result in duplicate SLM:SLACompliance records which is deemed to be data corruption. The corrective action will require delete of the duplicate compliance records and their child compliance history records. The SLM:EventSchedule:TAD_PollingEscalation_InvalidateMeasurement escalation should also run in this same escalation pool.
Related Products:
|