Docs » Configure detectors and alerts in SignalFx µAPM » Use default alert conditions in SignalFx µAPM » Latency - static threshold

Latency - static threshold 🔗

Note

This page explains how to use this condition when you are creating a µAPM detector. If you are creating an Infrastructure or Custom Metrics detector, see this page instead.

What this alert condition does 🔗

Alerts when latency goes above a static threshold, relative to a specified percentile, for a specified period of time.

When to use this alert condition 🔗

Use this condition when you need to be alerted based on fixed values, as opposed to trends (for which you could use the Sudden change condition) or comparisons with past behavior (for which you could use the Historical anomaly condition). For example, you have a latency signal with a “healthy” value of 300 ms, and want to be alerted when it goes above that value.

Basic settings 🔗

PARAMETER VALUES USAGE NOTES
Percentile to monitor 50, 90, 99 The percentile to monitor. For example, a value of 90 measures the current 90th percentile latency value against the static threshold.
Trigger threshold (ms) Number Trigger an alert when latency of the selected percentile is above this value for the specified trigger duration.
Trigger duration Percent: Integer between 1 and 100; Time indicator: Integer >= 1, followed by time indicator (s, m, h, d, w), e.g. 30s, 10m, 2h, 5d, 1w The number of times the signal must meet the trigger threshold, compared to the number of expected datapoints. Higher percentages and/or longer time periods result in lower sensitivity and potentially fewer alerts. For more information about this option, see Use the duration option.
Clear threshold (ms) Number Clear the alert when latency is below this value for the specified duration.
Clear duration Percent: Integer between 1 and 100; Time indicator: Integer >= 1, followed by time indicator (s, m, h, d, w), e.g. 30s, 10m, 2h, 5d, 1w The number of times the signal must meet the clear threshold, compared to the number of expected datapoints. Higher percentages and/or longer time periods result in longer times for alerts to clear (i.e. increased confidence that the alert condition is in fact no longer occurring). For more information about this option, see Use the duration option.

Advanced settings 🔗

PARAMETER VALUES USAGE NOTES
Exclude errors? Yes, No Whether to include or exclude error spans from the calculations.
Min. req/sec (absolute) Number Minimum request rate (requests/sec) required in trigger duration period; prevents alerts for sparse data.
Min. req/sec (% of history) Number between 1 and 100, inclusive Minimum request rate, as a percentage of request rate in the historical window, required to trigger or clear the alert; prevents alerts for sparse data. The historical window is five times longer than and immediately precedes the trigger duration period.

Use the duration option 🔗

The Trigger duration and Clear duration options are used to trigger or clear alerts based on how many signals met the threshold during the specified time window, compared to how many were expected.

  • Specifying 100% means that all expected datapoints arrived (there were no delayed or missing datapoints) and all met the threshold. In other words, if you specify 100% of a time range, an alert will not be triggered if any datapoints are delayed or do not arrive at all during that time range, even if all the datapoints that are received do meet the threshold. (For more information about delayed or missing datapoints, see Handling delayed or missing datapoints.)

    Tip

    To specify that an alert triggers immediately, specify 100% of 1 second for infrastructure detectors, and 100% of 10 seconds for µAPM detectors. If the signal resolution is greater than the value you enter, a message will indicate that you need to change it to at least the value of the signal resolution.

  • Specifying a percentage below 100 has a few effects:

  • For the Alert threshold, a lower percentage is more sensitive (may trigger more alerts) than using 100%, because fewer signals are needed to trigger an alert. Also, it can trigger alerts even if some datapoints are missing, as long as the required number of anomalous signals arrive.
  • For the Clear threshold, it can clear alerts more quickly than using 100%, because fewer signals are needed to trigger the clear condition. Also, it can clear an alert even if some datapoints are missing, as long as the required number of non-anomalous signals arrive.

The following examples illustrate how this option would affect triggering and clearing alerts in various situations.

Alert example 1 🔗

  • Percent of duration you specify: 100% of 10 minutes

  • Resolution of the signal: 10 seconds

  • Number of datapoints expected in 10 minutes: 6 per minute * 10 minutes (60)

  • Number of anomalous datapoints (how many times the threshold must be met) to trigger alert: 100% of 60 (60)

    Total datapoints expected Total datapoints received Anomalous datapoints required Anomalous datapoints received Alert is triggered?
    60 60 60 60 Yes
    60 60 60 59 or fewer No
    60 59 60 59 No

    Note that in the last example above, even though 100% of the datapoints that arrived were anomalous, the required number of anomalous datapoints (60) did not arrive. Therefore, the alert will not be triggered. The percent you specify represents percent of expected datapoints, not percent of received datapoints.

Alert example 2 🔗

  • Percent of duration you specify: 80% of 10 minutes

  • Resolution of the signal: 10 seconds

  • Number of datapoints expected in 10 minutes: 6 per minute * 10 minutes (60)

  • Number of anomalous datapoints (how many times the threshold must be met) to trigger alert: 80% of 60 (48)

    Total datapoints expected Total datapoints received Anomalous datapoints required Anomalous datapoints received Alert is triggered?
    60 60 48 48-60 Yes
    60 50 48 48-50 Yes
    60 50 48 47 No

    Note that in the last example above, even though 47/50 is greater than the 80% you specified, the required number of anomalous datapoints (48) did not arrive. Therefore, the alert will not be triggered. The percent you specify represents percent of expected datapoints, not percent of received datapoints.

Clear example 1 🔗

  • Percent of duration you specify: 100% of 15 minutes

  • Resolution of the signal: 30 seconds

  • Number of datapoints expected in 15 minutes: 2 per minute * 15 minutes (30)

  • Number of anomalous datapoints (how many times the threshold must be met) to clear alert: 100% of 30 (30)

    Total datapoints expected Total datapoints received Normal datapoints required Normal datapoints received Alert is cleared?
    30 30 30 30 Yes
    30 30 30 29 or fewer No
    30 25 30 25 No

    Note that in the last example above, even though 100% of the datapoints that arrived were anomalous, only 35 out of the 36 expected datapoints arrived. Therefore, the alert will not be cleared. The percent you specify represents percent of expected datapoints, not percent of received datapoints.

Clear example 2 🔗

  • Percent of duration you specify: 50% of 15 minutes

  • Resolution of the signal: 30 seconds

  • Number of datapoints expected in 15 minutes: 2 per minute * 15 minutes (30)

  • Number of anomalous datapoints (how many times the threshold must be met) to clear alert: 50% of 30 (15)

    Total datapoints expected Total datapoints received Normal datapoints required Normal datapoints received Alert is cleared?
    30 30 15 15-30 Yes
    30 20 15 15-20 Yes
    30 20 15 14 No

    Note that in the last example above, even if 14 anomalous datapoints arrive, and 14/15 is greater than the 50% you specified, the required number of anomalous datapoints (15) did not arrive. Therefore, the alert will not be triggered. The percent you specify represents percent of expected datapoints, not percent of received datapoints.