Alert types and functions

BMC Defender Server alerting functions complement the Thread functions discussed previously and can be considered a type of correlation. Specifically, whereas the threads group together messages that match common criteria, alerts correlate the counts of these messages with respect to time, and generate new alerts when the number of messages during a time window exceeds.

Related topic

Correlating-messages-into-groups-and-patterns

Alerts-tab

All alerting functions exist in the Alerts tab of the system. All alerting functions open tickets on the system, and further feed syslog messages back to the main event log. All alerting functions include a Suggest option (to suggest an alert message to be sent, that is also the same text used in tickets).

Given the preceding common features, the types of alerting is somewhat diverse, and is used for different alerting applications as follows:

  • Counter alerts—The Alerts > Counters tab provides general utility in keeping track of the number of incoming messages associated with a particular thread counter. These are the most commonly used types of alerts; they work with all types of threads and messages, and they furnish a great overview of anomalous activity, building on the organization of correlation threads. Counter alerts work with the auto-learn function of the system. Counter alerts permit GT (Greater Than), or LT (Less Than) compare functions.
    For more information, see Adding-or-editing-counter-alerts and Out-of-the-box-counter-alerts.

  • Device alerts—The Alerts > Devices tab provides a more specialized type of alerting, where a single match pattern is applied across a range of devices. For instance, if you want to be alerted if, any device receives more than X number of errors in Z seconds, this is the type of alert to use. 

    Important

    This is different from counter alerts because device alerts are maintained for each active device instance, and these instances refer to an alert condition specific to a particular device.

    For more information, see Setting-device-alerts and Out-of-the-box-device-alerts.

  • User alerts—The Alerts > Users tab provides functionality similar to device alerts, but is specific and maintained for each active user instance. For example, use this type of alert if the operator wants to be alerted when any user receives more than a specified number of errors in a specified number of seconds.
    For more information, see Setting-user-alerts.
  • Pattern alerts—The Alerts > Patterns tab supports a highly specialized type of alerting that works with Trigger elements of the system. The alert condition exists when a certain combination of correlation triggers get detected during an overlapping time window. For instance, if the administrator has configured a trigger which is active for 200 seconds when a printer is active and has configured another trigger that is active for 300 seconds when a file is accessed, then the Pattern Alert detects the condition of both of these triggers being set (indicating that a file might have been printed out.) Patterns are configured for All Messages, or in a context of Same Device or Same User. This gives the operator considerable control in detecting anomalous system, hardware, or user activity.
    For more information, see Setting-pattern-alerts.
  • Custom alerts—The Alerts > Custom tab provides a highly specialized type of extensible alert, based on the execution of batch files (whose output is scanned for match patterns) and based on the execution of a parse function across a range of thread messages. This type of alert offers a wide integration area to cover any esoteric type of alerting.
    For more information, see Setting-custom-alerts.
  • Automated Response alerts—The Alerts > Automated Response tab provides Automated Response alerts based on any message criteria. When triggered, they can initiate actions on a z/OS system.
    For more information, see Initiating-actions-with-Automated-Response-alerts and Out-of-the-box-Automated-Response-alerts.

Each of the preceding types of alerts, while somewhat different, behave similarly: The count of some value is compared to a threshold during a specified time interval. If the threshold is violated, then a syslog message is sent back to the main event log (possibly for further correlation), and a ticket is opened in the Tickets tab. The ticket can trigger notifications, such as by email. The ticket documents the alert condition, including the messages that caused the alert to be triggered.

This section presents the following topics:

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*