Monitor Policy

  • General Information
  • Monitor Policy Details
  • Conditions
  • Monitor Types
  • Supported Variables
  • Monitor Policy for SNMP walk/get
  • Pre-Execution


    • General Information

    The Monitor Policy configures all necessary aspects of threshold type monitors.

    Note: Use CTRL+Space in the policy fields to pop-up the variable list.



    Monitor Policy Details

    monitor policy


    Field Description

    Policy Version: This shows the current version of the Policy. The field will be automatically updated when changes are saved on the boom Server. The drop-down menu at the right side displays all previous versions of this Policy. The Compare button allows you to review the history of changes that have been made to the the Policy.
    Compare: With the compare function you can compare the current Policy with an older version. More details about the compare function see the chapter Policy Management.
    Monitor Name: This is the unique name of the Policy (unique across all kind of Policies).
    Global Variable: The policy is only activated if the specified Global Variable matches the specified value. For more information on setting Global variables see chapter Supported Variables and Functions.
    Plugin Name: The Plugin Name is a non editable field. The name comes from 3d party plug-ins.
    Deactivation Schedule: Deactivation Schedule
    Interval: The Interval specifies a polling interval for the Monitor. Format of interval field:

    Regular:  <n>T
    n – number of units,
    T – type of units(m – minutes, h-hours, d-days).

    i.e.    
    5m – 5 minutes
    10h – 10 hours
    7d – 7 days

    Cron-like:  T<n1:n2:n3:n4>
    n1 – days from Monday,
    n2 – hours,
    n1 – minutes,
    n1 – seconds,
    T – type of units(h-hours, d-days, w-weeks).

    h0:00:20:10 - every hour on 20 min 10 sec
    d0:18:11:05 - every day at 18:11:05
    w5:23:10:00 - every week Friday on 23:10
    Description: A description of the Policy.
    Type: Possible types are: MAXTHRESHOLD or MINTHRESHOLD. The type of the Monitor defines the main meaning of expected values:

    MINTHRESHOLD: The Monitor delivers an Indication when the submitted value is equal or less one of the specified threshold. One example can be the "Free Disk Space Monitor".

    MAXTHRESHOLD: The Monitor delivers an Indication when the submitted value is bigger or equal one of the specified threshold. One example can be the "System CPU Load".
    Set Application: Default application that will be assigned to the generated indication if no condition specific value is set.
    Set Group: Default indication group that will be assigned to the generated indication if no condition specific value is set.
    Policy with Reset: YES|NO flag. If this flag is set to "NO" all delivered values from this Monitor will be delivered to the server without suppression. In other words "NO" flag defines "continuous" Monitor.
    Monitor Type: Possible types are JAVA | EXEC | EXTERNAL | OPM. They define the type of the Monitor trigger.

    JAVA expects a Java Monitor deployed to the boom Agent.
    EXEC will trigger binary or script available on the boom Agent.
    EXTERNAL just waits for the Monitor value from any external process.
    OPM: Output Parser Monitor
    For more detailed information see the paragraph Monitor Types or Chapter OPM Java Monitors.
    Call: In this field you specify the java class name or an executable/script with parameters that must be executed on the specified interval.
    1. JAVA monitor expects a fully qualified java class name in the first line.
    2. EXEC monitor expects a binary or a script name relative to the Agent's plug-in directory ($BOOM_ROOT/spi/).
    3. IF EXEC binary is a system tool and available in global PATH use the '#' character at the first position: #<exec_name>...
    i.e.: #CScript scriptname [params] or #df -kl
    Indication Key:
    (on Policy level)    		 A key template identifies the Monitor value.

    The Indication Key contains a list of supported variables that will be resolved during the processing of the incoming value. the result string is used for the correlation with the following Indication for the auto acknowledgment and the duplicate suppression.

    Conditions

     This Section takes care of the Monitor threshold lists. The order of the conditions depends on the type of the monitor. For MAXTHRESHOLD Monitors the biggest threshold value must be on top of the list. The MINTHRESHOLD type expects the lowest value on top. the incoming values will be compared with the thresholds, resets and the object filters specified in the condition list in a order that is specified in the Policy. The first condition that matches with the submitted value will be used as the source to generate a new Indication. All following conditions will be skipped.


    Field Description

    Condition List: custom attributes dialog
    Name: Label of the Condition.
    ID: Auto generated ID of the Condition.
    Advice: An advice message that will be shown in the Indication Browser
    Instruction URL: Define the URL of an external knowledge base e.g. http://myInstruction.server.net.
    Agent and indication variables can be used in the Instruction URL.
    Availability Metric: Defines if the submitted value that matched with this Condition has an impact on the availability of the monitored system.
    KPI Metric: This flag defines if the submitted value must be treated as a Key Performance Indicator.
    Add as Closed: This will add the message already as a 'closed message' to the Indication Browser.
    Detect Duplicates: This flag notifies the boom Server to recognize duplicates. By receiving duplicate Indications the boom Server increases the "duplicate count" and updates the "last duplicate time" of the first received Indication. No new entry will be created in the database.
    The following message attributes are used for recognizing duplicates:
    AGENT_HOST,HOST,APPLICATION,GROUP,OBJECT,SEVERITY,INDICATION KEY, MESSAGE TEXT
    De-Duplicate KeyOnly: This flag notifies the boom Server to recognize duplicates based on the defined Indication Key. By receiving duplicate Indications the boom Server increases the "duplicate count" and updates the "last duplicate time" of the first received Indication. No new entry will be created in the database.
    The Indication Key attributes are used for recognizing duplicates hence an Indication Key has to be defined.
    Custom Attributes: User defined attributes which can be either just a text or a variable value. CA's are forwarded to the boom server as specified , they aren't subject to match on the agent. Up to 15 Custom Attributes can be defined in the Custom Attributes Dialog.
    Names of the Custom Attribute should not contain '=' sign.
    Attribute Values can use supported variables.

    custom attributes dialog
     
    Indication Key:
    (on Condition level)    		 A key template identifies the Monitor value.

    The Indication Key contains a list of supported variables that will be res olved during the processing of the incoming value. the result string is used for the correlation with the following Indication for the auto acknowledgment and the duplicate suppression.
    Close Mask: Pattern that is used to search and close previously submitted Indications.
    Threshold: A double value defines the threshold level.
    Reset: A double value defines the reset value of the previously specified threshold. This value allows to keep the severity unchanged in case of a small deviation of following submitted values.
    Ignore Reset: YES | NO . 'YES' - tells to the boom Agent that this condition must be processed as continuous. All incoming values will be forwarded as new indications to the server. This has no effect if the policy has "Policy with reset" flag set to "NO"
    Silence Count: A count of values since the first match of the threshold that must be suppressed and not delivered to the server. Used when it is necessary to ignore short and not important peaks.
    Severity: Defines the severity of the Indication that sends on current threshold level.
    Condition Type: STOP | SEND

    STOP – means that a incoming message that matched with the current condition must be ignored and all following conditions must not be checked. This helps to increase the performance of the boom Agent by using a STOP condition at the beginning of the Policy. As result the Correlation engine doesn't need to check all following condition and drops all text messages that have no interest.

    SEND value indicates that the matched text must be send as an Indication. The rest of the conditions inside the current Policy will be automatically ignored.
    Object: Object mask pattern. If the submitted object doesn’t match with the specified pattern, the condition will be skipped. It allows to create a combined threshold list (multiple overlapping threshold Conditions) for multiple objects in one Policy.
    Overwrite Attributes: This section allows to overwrite incoming values with user specified values.
    Set Host: Overwrites the hostname of the submitted Monitor value. Default value is an Agent hostname. All supported and optional variables can be used in this field as well. In case the monitor submits the hostname as optional variable you can use this variable in the "Set Host" field.
    Set Application: Overwrites the application name of the submitted Monitor value.
    Set Object: Overwrites the object of the submitted Monitor value.
    Set Group: Overwrites the group of the submitted Monitor value.
    Auto Action: Specifies automatic action that must be executed on the incoming Monitor value. An automatic action will be triggered from the boom Server. The result of this action will be stored in the Annotation Field of the Indication. All supported and optional variables that are specified in the field will be resolved by the boom Agent.
    AA Host: The target Agent hostname for the remote automatic action. If nothing is specified, the action will be triggered on the agent where the Indication was created. All indication variables are supported and will be resolved.
    AA Timeout: Timeout in seconds for the remote automatic action.
    Operator Action: Recommended operator action. All supported and optional variables that are specified in the field will be resolved by the boom agent.
    Text: Indication text template. All supported and optional variables will be replaced with the submitted values.

    Monitor Types

    The Monitor Type defines the type of the Monitor Trigger. For more information see Chapter OPM Java Monitors.

    The following Monitor Types are possible:
    EXEC: EXEC will trigger binary or script available on the boom Agent.

    monitor policy
    JAVA: JAVA expects a Java Monitor deployed to the boom Agent.

    monitor policy
    EXTERNAL: EXTERNAL This type just waits for the Monitor value from any external process.
    OPM: LineByLine

    monitor policy


    TableSummary

    monitor policy

    Supported Variables


    <$AGENT_ID>
    <$AGENT_IP>
    <$AGENT_HOST>
    <$HOST> || <$MSG_NODE_NAME> || <$MSG_NODE>
    <$APPLICATION> || <$MSG_APPL>
    <$GROUP> || <$MSG_GRP>
    <$OBJECT> || <$MSG_OBJECT>
    <$SEVERITY> || <$MSG_SEV> - one of "unknown","normal","minor","major","critical"
    <$NAME> - monitor name
    <$VALUE> - monitor value
    <$THRESHOLD> - threshold value
    <$OPTIONS> - prints all available optional variables in the following form: varname=value, ...
    Optional variables can be used as: <$varname>

    For more information see Chapter Supported Variables and Functions

    Monitor Policy for SNMP walk/get

    A monitor policy is used for fetching values with SNMP get or walk.

    The OID can be a field or table.

    The Monitor Type is "JAVA", the Monitor Name is "com.blixx.boom.snmp.SNMPWalkPrinter".

    SNMPWalkMonitor supports following parameters in the Monitor Call field:
    -h <hostIP>
    -o <oid of target table or field>
    -c <community>
    -v <SNMP version[1,2]>
    -p <port>
    -t <timeout in seconds>
    -r <retries>
    A line $n = $m is mandatory, $n is the field with the object and $m the field with the value.

    Pre-Execution

    In many cases the input parameters for the Monitors are different from system to system. It is possible to include in the parameter block following special triggers:


    1.  <$BOOMMON_ONINIT(<exec string>)>
    2.  <$BOOMMON_ONSTART(<exec string>)>

    The "ONINIT trigger" will be resolved during the deployment of the Policy or the restart of the Agent.

    The "ONSTART trigger" triggers the execution on every start of the Monitor.


    The result of the ONINIT and ONSTART triggers will replace the own declaration.

    Example: "Call" attribute in a Policy defined as:
    HTTPMonitor.exe http://<$BOOMMON_ONINIT(hostname)>:<$BOOMMON_ONINIT(get_port.sh)>/

    After initialization and execution the 'hostname' command and the 'get_port.sh' script the call string will be resolved as:
    HTTPMonitor.exe http://hostname.domain.net:1234/

    ONINIT  is supported by JavaMonitors as well, but not ONSTART!