Using correlation triggers

The previous section discusses how to correlate messages as they arrive at the BMC Defender Server system. Because error messages, by their nature, do not usually need any special context to be understood, the prior sections have ignored message context, but have described a wide range of useful correlation functions.

A log message, by itself, is typically a stand-alone communication; hence it is not usually necessary to worry about the nature of any earlier message. However, it is notable that many times, the full meaning of some message depends upon a different message that has been previously received.

For instance, an error message that has been preceded within the last several minutes by a reboot message signifies something slightly atypical (that is, a startup error, as opposed to some other type of error).

The purpose of the BMC Defender Server triggers function is to provide the additional functionality needed to place a message within a specific context. As discussed in this section, BMC Defender Server triggers furnish a special type of time correlation that takes into account not only the current message but also the previous messages that have been received.

Human communications are highly dependent on the context to derive meaning. Chatbot programs recognize this and construct state machines to handle the context. Similarly, BMC Defender Server provides triggers to establish a state machine and a high degree of semantic correlation, as discussed herein.

Section summary and additional notes about correlation triggers

  • Triggers provide the ability to add context to correlation and operate as both gates for messages and latches to store message information.
  • Each trigger accepts a set pattern, an expiration time, and an optional clear pattern. 
  • When a message matches the set pattern, the trigger is set and an expiration timer starts. 
  • When the timer expires, or if a message matches the optional clear pattern, the counter gets cleared.
  • The Trigger Expiration severity value can be used to log a message should a trigger expire. This can be used to detect the non-occurrence of some event, such as waiting for a valid login within one minute of an invalid login. The trigger now expired message is logged as any other message (at your specified severity) and can be correlated like any other message.
  • Triggers can gate on the collection of messages by threads and the execution of programs by Actions.
  • Triggers support a special type of global variables that permits threads and actions to work with multiple triggers, and for triggers to be cascaded to add deep context.
  • Using global variables, triggers can be cascaded, so that one trigger is set only if some other trigger is set. This can establish deep context in messages, where multiple messages must occur (perhaps in a specific order) before a trigger is actually set.

This section provides information about the following topics:

 

 

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