Indication

The second major concept of the boom Infrastructure is an Indication. An Indication is an incoming message that describes an event which occurred on the monitored node but has additional attributes like severity, message group, application, object, etc...

In a general picture the Monitor value also produces an Indication on the boom Server. This Indication states that the threshold level for the monitored metric has been changed.

Any monitoring probe or external application can submit a message to the boom Agent. The boom Agent uses Indication Policies to filter the submitted messages in order to prevent the server from a "message storm". Indication Policies contain all necessary information to suppress unimportant or useless messages and allow parsing and constructing new Indications in a form that can be used by the administrator or operator.

The results of flexibility inside Indication Policies are:

  • reducing the number of messages that are displayed in the boom GUI
  • the possibility to extract useful parts of the Indication text for remote actions or
  • adjusting the Indication itself.

    • The Indication Correlation Engine is the main component which is responsible for processing the incoming messages based on a set of loaded policies. All incoming Indications shall be compared against all Policies. If multiple Policies have matched conditions for one incoming Indication, the agent will produce multiple result Indications. An exception is a Policy that matches all messages (in other words "forwards all messages"). In case one of the other Policies has generated an Indication the "forwards all messages" Policy will be ignored.

    All Hybrid Policies which will be explained in the next chapter, are excluded from general correlations. The Hybrid Policies are only working with Indications that are submitted by triggers. The triggers must be defined inside the Hybrid Policy.

    The "Application" and "Indication Group" attributes of an Indication Policy are used as main pre-filtering condition. If these attributes are specified in the Policy and the submitted Indication contains non empty values, than the Agent is able to process a reduced set of Policies and increase the speed of the processing.

    Conditions

    The process of matching incoming indications to an Indication Policy is based on the filter conditions that are defined inside the Policy. The first condition that has been matched stops the processing of all following conditions.

    There are two major types of conditions: Conditions that create an Indication and conditions that "STOP" the processing.

    Such STOP Conditions allow cutting off Indications that are of no interest. For example: A logfile usually contains a big number of informative messages with normal severity. For problem detection and monitoring only warnings and errors should be delivered to an operator. To cut off unnecessary messages and processing, you can use the STOP Condition as the top condition (first condition in the list) in the Indication Policy.

    Patterns and Usage

    One of the most powerful and most complicated concepts of Indication Policies is the pattern concept. Pattern are used for filtering incoming indications to identify the matching Policy conditions. By default the 'Simplified Patterns' are used for filtering attributes.

    Note: In addition the "Search Text" filter can have a fully featured java pattern, because the syntax of 'Simplified Pattern' does sometimes not allow handling complex situations. The Java format of a pattern requires the prefix "java=". I.e java=Error:.*

    As described later, the UI includes a powerful Pattern Editor that makes the generation and validation of patterns very easy.

    Any Indications have the following attributes:

    • Application (required)
    • Indication Group
    • Object
    • Host
    • Severity
    • Text (required)
    These values are all used by the filtering process.

    An Indication must provide at least the Application and Text attributes. All other attribute values are optional. The default value for all filtering fields in a new Indication Policy is the "MATCH_ALL" condition: <*>



    This means that a new created Policy will process all incoming messages. It is necessary to specify patterns that match only messages that should be processed by this Policy.


    ApplicationGroupObjectHostSeverityTextMatches
    <*><*><*><*><*><*>all (MATCH_ALL condition)
    APPL1<*><*><*><*><*>indications with
    Application="APPL1"
    APPL1|APPL2<*><*><*><*><*>indications with
    Application "APPL1" OR "APPL2"
    <*>GRP1|G2|G3OBJECT_<*><*><*><*>Group ("GRP1" OR "G2" OR "G3") AND
    Object starts with "OBJECT_"
    APACHE|TomcatWEBMEMORY<*>critical|major<*>Application ("Apache" OR "Tomcat") AND
    Group="WEB" AND
    Object="MEMORY" AND
    Severity (major OR critical)

    For the Application, Indication Group, Object and Host fields it is allowed to have simple "OR" notation like: APPL1|APPL2|APPL3 instead of [APPL1|APPL2|APPL3]

    Note: It is recommended to have only one condition across all Policies that match all Indications.

    Note: It is recommended to have Application & Indication Group Filters specified with the exact value or list of the expected values by using OR notation. This will reduce time of the processing and increase performance.