Alerts can be divided into different categories based on the underlying detector mechanism and on their function. Alert detectors are the actual mechanisms responsible for analyzing the monitored traffic and for recognizing alert triggering events. The detector mechanism determines such things as the types and number of parameters that a given alert takes (or can be modified to take), the speed of processing, and user access to the actual detector code.
In most cases, you will be working with user-defined metric alerts, which provide a simple and fast mechanism for performing complex queries on a set of predefined metrics; or on expressions combined of such metrics. They are easy to create, modify, and use. They execute quickly: up to 1,000 alert definitions can be processed in one reporting cycle. We recommend that metric alerts be used whenever possible because of their speed of execution and ease of modification.
The following types of metric alerts can be configured:
Dynatrace Synthetic Monitoring backbone
These alerts report problems related to Dynatrace Synthetic Monitoring transactional traffic.
Real user performance
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.
Synthetic and sequence
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 NAM or 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.
Although we recommend that metric alerts be used whenever possible, not every possible alert condition can be expressed as a metric alert. This is why a set of pre-defined SQL-based alerts is provided. These alerts perform SQL queries on the traffic monitoring database. The benefit of using them is that there are no constraints to the complexity of the queries: any event that can be expressed in SQL can be detected. However, the SQL queries take a considerable amount of time to execute, so performance problems can result.
You cannot create new SQL-based alert definitions or duplicate the existing ones in the RUM Console. You can, however, modify some of the detector settings—for example, change the threshold values—or delete the alert definitions.
Among predefined alert definitions, there are also a few non-SQL alerts that were designed for specific purposes and that can be modified in only limited ways. Most of them monitor and report on resources of a report server and cannot be deleted from the system.
The predefined alerts are grouped based on the type of event on which they report:
Alerts sent when an abnormal situation is detected (for example, when there are too many services detected for a single user).
Alerts that are related to the resources of a report server (for example, free space on the server hard drives or free space for the server database).
Alerts that are sent when a user, server, or service registers for the first time in the monitored network.
Alerts that report mainly errors that occur during the execution of operations and abnormal time metric values for the operations. They also notify recipients about application availability problems.