Applies to NAM 2018
This alert configuration wizard is available starting in NAM 2018. For alert definition in earlier releases, see Defining an alert.
Before you begin
- NAM 2018 alerts changed. Even if you're an alert power user, try to copy and edit one of the example alerts shipped with NAM 2018 as an example which will help you understand the new alerting concepts.
- Identify a business need for the alert and the metrics that would trigger such an alert.
- If you intend to send alert notifications via email, a user with administrator privileges needs to configure the NAM server to use an existing SMTP server. See Mailer setup. Make sure that all the email recipients you intend to send alerts to are NAM users with an email address. You won't be able to add a new email recipient using alert management pages.
Applies to NAM 2019 Beta
If you have switched to NAM 2019, NAM can now take most of the work out of defining an alert. NAM 2019 enables you to open a report, click a tile or table entry (some restrictions apply), and select Create alert with most of the alert settings prefilled based on the report where you started. See Creating alerts from NAM reports for details.
Defining an alert
Defining or editing your alerts is divided into three main steps:
Choose the scope of monitoring data your alert will be based on, name your alert and optionally describe it. You can also select NAM servers (devices) that will manage and propagate your alert.
Selecting an alert type determines the scope of monitoring data used to trigger an alert and which metrics and dimensions you'll be able to use.
Real user performance (probe)
These alerts monitor traffic between a client and a server. They are based on traffic monitored by AMD, including the elements that are configured on the CAS: applications, transactions, reporting groups, tiers, regions, areas and sites.
These alerts monitor transactions and track the HTTP-based software service activity of synthetic agents and standard users. They are based on traffic monitored by DC RUM.
These alerts monitor transactions and track the HTTP-based software service activity of synthetic agents and standard users. They are based on traffic monitored by Enterprise Synthetic.
These alerts monitor the performance of Citrix servers or Windows Terminal Services (for example, the number of active or open sessions).
These alerts monitor link utilization.
These alerts monitor traffic coming in and going out of a specific site.
Application user experience
These alerts monitor application user experience for all measurement sources: probe, browser, enterprise, backbone synthetic, last mile and private last mile synthetic.
AMD driver statistics
These alerts monitor driver-specific dimensions and metrics such as drop rates and overruns.
AMD interface statistics
These alerts monitor interface interface-specific dimensions and metrics such as packet and byte counts.
AMD server statistics
These alerts monitor interface server-specific dimensions and metrics such as session statistics and errors.
Define the conditions under which your alert is triggered. Place your alert in the context using at least one dimension. For advanced configuration, if necessary change the time context of your alert and customize the propagation settings.
Dimensions segment the monitoring data. To define the scope of your alert, you must add at least one dimension.
You can choose between the two dimension types:
Dimension and filter
The metrics triggering your alert are monitored in the context of the combination of dimensions you define. If you leave the Filter field empty, NAM will monitor your alert metrics for each defined metric-dimension combination, for example tier, application, software service, etc. You can narrow this context to dimensions matching the text filter added in the Filter field. When using Dimension and filter type, you can also use the dimension value in the alert notification message. Filter syntax
When you use the Filter type, you further narrow down the applicability of the alert only to dimensions meeting specific criteria. This time, you must add a filtering expression. Filter syntax
The list shows metrics relevant to the Alert type you selected on the Basic settings tab. Select the metric, select the type, and define the filter. If all of the selected metrics match, the alert is triggered and notifications are sent. You can use the default DMI metrics or create compound metrics.
To trigger the alert, the metric values within the context of defined dimensions are compared against a value (Value type) or NAM server calculated baselines (Absolute baseline and Relative baseline types). When the result matches the criteria defined in the filter, we trigger an alert. You can choose one of the following types of monitoring the metric values:
A simple numeric value optionally qualified by a comparative operator ("
You AND these together with the
>10 && <100 (syntax)
Absolute comparison of metric value in its units (%, bytes, milliseconds, or simple counters) against the baseline.
For example, if baseline was 1000 bps,
value is at least 100 bps less than baseline would mean "trigger the alert if the value of the selected metric is less than 900 bps." Note that when you use metrics expressed in percent, it's still an absolute comparison, that is percent points. For example, if baseline was 80%,
value is at least 20 % less than baseline would mean "trigger the alert if the value of the selected metric is less than 60%", that is a simple 80%-20% subtraction, not the 20% of 80%.
Trigger the alert if the value of Metric is greater or less than defined percent share of baseline.
For example, if baseline was 80%,
value is less than 20% of baseline would mean "trigger the alert if the value of the selected metric is less than 20% of 80% (less than 16%)."
Use an auxiliary metric to add supporting (auxiliary) information to your alert notification. For example, you might create an alert that is triggered when
Application performance drops below 80% and
Number of affected users is above 10 (the two triggering metrics) and use the values of
Number of operations and
Operation time in alert's notification message (as auxiliary metrics).
Select Advanced configuration to add an output filter or to customize propagation settings.
Monitoring duration and frequency
Use these two settings to control Time range (the width of this alert’s sliding window) and Frequency (how often the conditions are checked) to change the default time context for your alert. Frequency should be smaller or equal to Time range
This is the width of the sliding window. If it’s too narrow, you may get false positives in environments where things happen infrequently.
This is the time between consecutive evaluation of the metric state. If it's too long, you may get late alerts.
Example: If we set Time range to
60 minutes, the alert's window is an hour wide, which will help you avoid the false positives such as reporting no traffic on a server that normally has no traffic for some length of time. But we don't want to wait a whole hour before checking the metrics, when an alert situation could arise in the first five minutes of that hour, so we set Frequency to something shorter such as
10 minutes, which would mean that we slide our window forward every ten minutes and check the metrics during that hour. Your alert, in this case, would never be more than ten minutes later than an event.
You can set additional conditions on metric alert output fields, so that only alerts satisfying these conditions are raised. In the empty edit box, type the filter expression for the selected element. Note that Output filter uses a more complex syntax for the expressions, that is the one used in DMI to control the visibility of selected elements. See Rules for writing expressions
These settings control when the alert is raised and add related information to the notification.
Raise after (interval)
This setting specifies the number of intervals that must occur before the alert can be raised.
Cancel after (interval) After the alert occurs, this option specifies the number of subsequent monitoring intervals for which the alert condition must not be present for the alert to cancel itself. That is, after this many monitoring intervals without an event occurring, it will be assumed that conditions are back to normal. This option has to be enabled if you want to receive notification messages after the alert state is over.
Abort after (minutes)
The number of minutes after which the alert will expire, regardless of whether the triggering conditions are fulfilled. The default value is 60 minutes.
Reissue every (interval)
Specifies the number of events that must occur following the last notification of the alert before the alert notification is re-issued.
When no traffic was observed
This option specifies how to treat the observation no qualified traffic.
The alert conditions are met
If no traffic is observed:
- The alert system assumes that the alert conditions are met and executes the actions specified in the alert definition (send raise notification).
- A cancel is sent after the number of consecutive intervals in which conditions are not met equals the Cancel after setting.
The alert conditions are not met
If no traffic is observed:
- The alert system assumes that the alert conditions are not met.
- The Cancel after setting determines how many intervals must pass with the current condition to send the cancel alert.
Perform no action and wait for traffic.
If no traffic is observed:
- The alert system ignores the missing data and waits for relevant data.
- When the relevant data is observed, the system applies its alert definition to each interval.
This is the message sent in the alert. Type or paste a text message explaining what the problem is. To insert the value of a dimension or metric, type a label such as "The value was " (so you know what the value refers to) and then press
Ctrl-Spaceto list dimensions, metrics and metric thresholds values available to your alert according to its type and your definition. Select one of them to insert the value into your message.
- Alert recipients
Use the tabs here to select recipient types (email, trap, script, or Slack) and define recipient details. Note that you must first configure Webhooks on your Slack instance and NAM Server. See Sending alert notifications to Slack. Email recipients are your NAM users with email addresses defined, you can't add them using Alert management pages.
Review the summary and click Finish to save your changes or click Previous to go back and make changes.