Enable_Auto_Threshold: set threshold parameters

The baselining process supplies statistical information about request response times. monitoring agent 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 may need to change these parameters. If there are a lot of false alarms or warnings, you need to raise the bad or fair threshold; if alarms or warnings are not triggered when needed, you need to lower the bad or fair threshold.

While you may change the parameters for the entire application or for all requests of a given type, most likely you will only do this 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.
• 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.
• To set threshold parameters for an individual request, select this request in the Request Baseline workspace , and select the Enable_Auto_Threshold take action.

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, and immediately see the effects on the bar charts.

The Response Times Distribution chart shows the statistical distribution of response times for this request. To the left are smaller (faster) response times; to the right, larger (slower) ones. 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 between 300 and 500 ms, then the first bar may be 0 to 50 ms, but there may also be bars like 305 to 310 ms and 400 to 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 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 (the same as on the top chart). 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. The monitoring agent will use 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, the monitoring agent will check which of the request types takes more than its usual share of time; based on this, it will display whether the likely cause is the application, backend, or server.