Enable_Auto_Threshold: set threshold parameters

The baselining process supplies statistical information about request response times. Cloud Pak System Software interprets this information to set automatic thresholds. Several parameters control this interpretation.

The default values for these parameters are sufficient for most cases. However, if the thresholds are not adequate and the baselining process was run recently, you might have to change these parameters. If there are many false alarms or warnings, you must raise the bad or fair threshold; if alarms or warnings are not triggered when needed, you must lower the bad or fair threshold.

Although you can change the parameters for the entire application or for all requests of a given type, most likely you do this only for an individual request.

• To set threshold parameters for all requests in the application, select this application in the Application Health workspace or Application Registry workspace, and select the Enable_Auto_Threshold take action command.
• To set threshold parameters for all requests of a given type in the application, select this request type in the Application Request Configuration table of the Application Configuration workspace, and select the Enable_Auto_Threshold take action command.
• To set threshold parameters for an individual request, select this request in the Request Baseline workspace, and select the Enable_Auto_Threshold take action command.

In the Request Baseline workspace, when you select a line representing a request, you can see the bar charts representing statistical data for this request. This data was gathered during the baselining process. Colors on the bar charts show the way in which the parameters are applied. You can change the parameters using the Enable_Auto_Threshold take action command, and immediately see the effects on the bar charts.

The Response Times Distribution chart shows the statistical distribution of response times for this request. The height of every bar shows the percentage of requests that had the indicated response time during the baselining period.

Some bars represent bigger time intervals than others; more bars are devoted to most common response times. For example, if the maximum encountered time is 1000 ms but most response times are 300 - 500 ms, then the first bar can be 0 - 50 ms, but there can also be bars of 305 - 310 ms and 400 - 402 ms.

The bars colored blue show the zone into which the "typical" response times for this application fall. The green bars show response times that are not "typical", but are below the fair threshold. Response times above the fair threshold but below the bad threshold are shown as yellow bars; for those above the bad threshold, the bars are red.

Use the Enable_Auto_Threshold take action command to set the parameters that affect both the position of the "typical" zone and the way the thresholds are derived from this zone.

For more information about how the bar chart and parameters work, see Threshold calculation detail.

The Level2 Delays Distribution chart shows the distribution of time spent in "nested requests" within the requests that had this response time range. Each bar represents a response time of the top-level request . Within this bar, colored sections show how much time is spent within nested requests of different types; the color legend is shown on the bar. ITCAM uses this distribution within the selection zone (that is for typical overall request types) to work out the average share of time that each nested request type takes. When an error or warning arises, ITCAM checks which of the request types takes more than its usual share of time; based on this, it displays whether the likely cause is the application, backend, or server.