What are ways of making a good Alert Profile?
Alert Profiles should be tailored for the customer's own Network. While it’s possible to use the pre-defined Alert Profiles, you may find that they have too frequent of alerts (noisy) or not enough alerting for important network events.
A good Alert Profile can be customized to a path to receive alerts when an issue arises that needs to be investigated, but it’s also important to ensure the use of Diagnostic Tests. When an alert condition is violated for the specified time, the Diagnostics can be used to pinpoint the failure, so without having strategic Alert Profiles, you could see too many or not enough diagnostics triggered during various network events.
It's recommended that a customer gather a baseline of performance of the Network Paths they wish to apply it to and adjust the thresholds based on that baseline. Allow for enough flexibility that if the path fluctuates by a few ms that we don’t needlessly trigger Diagnostic Tests but do trigger them when a significant issue arises.
Alert Profiles for these modules contain different threshold settings. They are also applied in different ways.
Delivery Alert Profile Thresholds are set against the entire Network Path from source through to destination. If performance degrades in an intermediary hop along it will be considered within these measurements. Here's a list for the various conditions that can be monitored:
Experience Alert Profile Thresholds are set against a Web Path measuring for various experience specific items such as HTTP Status Codes, Script Completion or Errors. They can be applied on a per-Milestone basis or the entire Web Path workflow. Here's a list for the various conditions that can be monitored in Experience:
Usage Alert Profiles thresholds can be set against total traffic volume/rates for a specific Application or Categorization for a Monitoring Point Usage Interface. They will notify when the threshold violates the configured criteria’s, note that as Usage has roughly a 5-10 minute delay from real-time these alerts would not be considered real-time. Here's a list for the various conditions that can be monitored with Usage:
Using settings such as 0% Voice/Data Loss is not recommended on WAN paths, especially when they cross multiple intermediary hops. While it’s always great to aim for no loss what-so-ever this is often not realistic on WAN paths and can result in a very noisy path.
Jitter/Latency/RTT usually remain quite low in a properly configured LAN path/environment. Stricter settings make more sense in a LAN path as you are more likely staying within the same physical LAN network.