Smart Alerts
Smart Alerts provide you with automatically generated alerting configurations, so you can receive alerts based on blueprints such as Throughput (based on sessions and views), HTTP status codes, and Custom Events.
If you select a blueprint that you would like to be alerted for, and choose an arbitrary scope (for example, by geolocation, browser, OS, and other options), Instana automatically creates a tailored alert for you.
- Adding an alert
- Simple mode
- Advanced mode
Adding an alert
- From the Instana user interface (UI), click Websites & Mobile Apps on the sidebar.
- Select the Mobile Apps tab,
- Click the name of your mobile app and then click Add Smart Alert.
Simple mode
By default, you create an alert in simple mode, which involves the following steps:
- Select an alert.
- Confirm your scope.
- Select the alert channels to be alerted on.
In Simple mode you can select alerts with zero configuration so that you don't need to create queries or define thresholds.
To create an alert in advanced mode, which you can use to investigate and modify any automatically configured alert setting, click Switch to Advanced Mode.
Select an alert
Select one of the following predefined blueprints that you want to create an alert for.
| Blueprint | Description |
|---|---|
| HTTP Status Codes | Select a specific HTTP Status Code that you would like to be alerted for when they occur more often than usual. |
| Throughput | Select Unexpectedly Low Number of Views / Sessions to receive alerts when the expected number of page views or sessions of your Mobile App significantly differs compared to the available historical data. |
| Custom Events | Select a specific Custom Event to receive an alert when it occurs more or less often than it should be. |
| Crash | Receive an alert when the selected crash metric is higher or lower than expected. |
Confirm your scope
The scope, your current open mobile app, is automatically selected. By applying the Unbounded Analytics queries, you can further scope the alert to a specific subset of mobile app traffic; for example, by geolocation, view name, or platform.
Each query filter connects with the AND logic operator by default, so a mobile app beacon needs to match all the filters applied:
- Specific pages.
- Operating systems.
- Countries.
- Meta: specify more metadata that you can use to annotate page views and sessions. Select one of the available keys, a predefined value, and then select an operator.
Add alert channels
Click Select Alert Channel, then from the list of preconfigured channels select the channels to receive the alerts. For more information about creating channels, see Alert Channels.
Advanced mode
To have a full understanding and control over your alerts, advanced mode helps you to inspect the configuration of each alert and modify the configuration, if needed. In addition to the selections available in simple mode, the advanced mode offers the following.
Trigger
Select one of the following predefined blueprints that you want to be alerted for.
HTTP status codes
The same configuration options are available as in simple mode. For more information, see Select an alert.
Additionally, in the Threshold section, you can select which metric is used for alert evaluation; status code count or status code rate. Whichever metric you select, use a threshold value based on historical data
that you can modify.
Throughput
In advanced mode you can define a generic Smart Alert based on any page view related metric. By contrast, in simple mode, you select from predefined blueprints for use-case specific options described in Select an alert.
In addition, you can select which metric is used for alert evaluation, such as Page Views or Sessions.
In the following image, the example configuration the Threshold section defines Views greater than (>) Static Daily Seasonality with a mid-range sensitivity. For this configuration, an alert is triggered when the number of page views is higher than usual. Depending on the amount of available historical data, Instana suggests a static threshold. Additionally, you can choose between a daily or weekly seasonality baseline when sufficient data is available.
You can modify the static threshold value. You can tune the daily or weekly seasonality by using the sensitivity parameter, which defines how far outliers can deviate from the expected value before it is considered a violation.
Custom Events
The same configuration options are available as in simple mode. For more information, see Select an alert.
Crash
In the Threshold section, you can select which metric is used for alert evaluation. The following 8 metrics are supported:
- Crash Affected Session Rate
- Crash Affected User Rate
- Crash Affected Session Count
- Crash Affected User Count
- Crash Free Session Rate
- Crash Free User Rate
- Crash Free Session Count
- Crash Free User Count
The same metric selection is also available in simple mode.
Type of Threshold
When you set up a Smart Alert, you can choose to use static or adaptive thresholds.
Static
Static thresholds do not change after the Smart Alert is created. The threshold itself can be either a simple constant value, or can account for seasonal variations that occurred in the past at the time of creation of the Smart Alert configuration. You can imagine the second case as a lookup table for every point in time of the day or week with values that were computed based on historic data.
The threshold might stop being relevant after the underlying metric is changed significantly. In response, the threshold can be manually adjusted or recalculated at any point in time.
When to use static threshold
Static thresholds work best in the following situations:
- Irrespective of any seasonality of the underlying metric. It is undesirable for the metric to go larger than or lower than a constant value.
- The underlying metric is seasonal, and therefore different thresholds exist depending on the point in time of the day or week. The thresholds themselves don't change over time, and gradual changes to these thresholds over long periods of time is undesirable.
Adaptive (public preview)
Adaptive thresholds continuously evolve and adjust themselves with new data that is observed by Instana. The threshold continuously accounts for seasonal changes to the underlying metric without any human intervention.
Adaptive baselines are classified as a public preview feature.
When to use adaptive threshold
Adaptive thresholds work best for blueprints such as Throughput or generally for the following situations:
- The underlying metric is not seasonal. The threshold is expected to gradually change over time, but any sudden deviation from this trend is undesirable.
- The underlying metric is seasonal and different thresholds exist for different times of the day or week. The thresholds themselves are expected to gradually change over time, but any sudden deviation from this trend is undesirable.
Scope
The same configuration options are available as in simple mode. For more information, see Confirm your scope.
Alert threshold
You can configure the alert threshold of the Smart Alert. The underlying metric is an aggregation of beacons that relate to the mobile app. When the alert threshold of the Smart Alert has been configured, the alert preview of the dialog shows the metric, threshold, and the violations on historic data for the last 24 hours or 7 days.
Choose a metric
Select a metric from the available blueprints.
Select Metric
The metric is calculated for mobile app beacons with a timestamp within the evaluation granularity, which is chosen as part of the time threshold.
Choose threshold operator
Based on the chosen blueprint, you have the option between <, <=, >, >=.
Choose threshold type
Here you can choose among the following static threshold types:
- Static Threshold: Takes a constant value as threshold.
- Static Daily Seasonality: Uses a threshold that captures the daily repeating patterns of the metric where every day behaves roughly the same, but is different throughout the day. As an example, a mobile app that has more traffic during the day compared to during the evening.
- Static Weekly Seasonality: Uses a threshold that captures the weekly repeating patterns of the metric where every day of a week behaves roughly the same, but is different throughout the week. As an example, a mobile app that has more traffic on workdays compared to the weekend.
For Static Daily Seasonality, at least 5 days of continuous metric data is required, but 7 days of data is recommended. For Static Weekly Seasonality, at least 2 weeks of continuous historic metric data is required. The Smart Alert cannot be created when these requirements are not met.
For Adaptive Threshold, at least 5 days of continuous metric data is required. If this requirement is not fulfilled, the Smart Alert can still be created. Issue detection and alerting starts working when the data requirement is met to initialize the used model.
Choose threshold value or sensitivity
If you choose Static Threshold, you can either use the suggested threshold value or define the value manually.
Increase the sensitivity to narrow the upper and lower anomaly detection boundaries. As a consequence, you receive more alerts. However, if you want to receive fewer alert notifications, you can decrease the sensitivity. If you decrease the sensitivity, you extend the detection boundaries that define the expected value range of the metric. Depending on the used threshold operator, a metric that exceeds either the upper or lower detection boundary is considered a violation that might cause an alert.
Time threshold
So that the alert is triggered, you can use a time threshold to impose more conditions on how the defined threshold on the metric are violated.
The following typical conditions, often used in practice, are offered:
-
Persistence of time: Select a time window. When the metric violates a defined threshold over the defined time window, you are alerted.
-
The number of violations over time: Select a time window and the number of violations. When the metric violates the threshold a specified number of times during the time window, you are alerted.
-
User impact:
Besides the threshold condition on the selected metric, you can define a secondary criterion on the minimum number or ratio required for users impacted by a problem. With such a secondary criterion, you receive alerts only in case a significant number or ratio of users are impacted by the defined problem.
- User Impact Evaluation method: Defines how the user impact is measured when the primary metric is violated for the amount of evaluation windows. You can select one of the following methods:
- Aggregate across all evaluation windows, which measures the user impact as a single aggregate across the defined time window. To receive an alert, this value needs to be exceeded.
- Calculate for each evaluation window, which measures user impact for each evaluation window individually, like any other metric. To receive an alert, the defined number of evaluation windows need to be violated in sequence for both the primary metric and the user impact.
- Number of impacted users or percentage of impacted users: Specify either the absolute number of users impacted, the percentage of users impacted, or both. In the latter case, you get alerted only when both limits are reached during the defined time window.
The user impact metric requires the Instana Users API to identify authenticated users and Session API to approximate other users based on their session. Depending on the integration of these APIs, the user ID is used if provided, otherwise the session ID as a fallback.
- User Impact Evaluation method: Defines how the user impact is measured when the primary metric is violated for the amount of evaluation windows. You can select one of the following methods:
In the presence of gaps for a metric that is not SUM aggregated, such as latency or error-rates, Instana preserves the current alert state until the next metric value is seen. For example, this is helpful in case a Smart Alert
is defined for a mobile app that receives only infrequent traffic, but suffers from a persistent problem. Therefore, these periods without any mobile app traffic do not cause repetitive alerts. However, the absence of a single mobile app
beacon for more than 24 hours causes any active alert to be closed.
The following image depicts an example of a configuration for a time threshold based on user impact. Using a metric evaluation granularity of 10 minutes, an alert is triggered when at least 20% of the users are impacted within the last 10 minutes.
Alert channels
Click Select Alert Channel, and from the list of preconfigured channels, select the channels to receive the alerts. For more information, see Alert Channels.
Alert properties
Adding more alert properties is optional, but provides you with the additional configuration that best suits your needs. Besides editing the current title and description of the alert, you can define the alert level (warning or critical), and select whether the alert triggers an incident. For more information, see Alerting.
Custom payloads
To include an extra payload that is relevant to you in alert notifications for specific alert configuration that is sent by Instana, click Add Row in the Custom Payloads section.
For more information about custom payloads, see Configure Custom Payload Globally.
Both global custom payload and alert-specific custom payload are included in alert notifications if applicable, but the alert-specific configuration has priority over the global configuration. As a result, if using the same key, the value of the global custom payload field is overridden by the alert-specific one.
The following image shows globally defined custom payloads that are used in the alert configuration:
Dynamic custom payload fields in alert-specific configuration are also supported.
The following image shows commonly used options that you can select for Dynamic Tag, including Mobile App Label, View Name, Platform, Country, and Meta:
You can use the suggestions to select the right key for the selected dynamic tag or add it manually.
