baseline_engine Configuration

This article describes how to configure baselines or thresholds for probes. The article also describes how to configure the amount of time, in weeks, to retain the baseline data. This article is for baseline_engine versions 2.71 and later.
uimpga-ga
baseline_engine_AC
This article describes how to configure baselines or thresholds for probes. The article also describes how to configure the amount of time, in weeks, to retain the baseline data. 
This article is for baseline_engine versions 2.71 and later
.
 
Content
 
 
 
Create Baselines and Thresholds for Probes Using a Command Line
You can set up baselines and thresholds for probes using a command line instead of the web-based GUI. From <baseline_engine_dir>, use one of the following commands to set baselines or thresholds for probes:
Set up Baselines
To set up a baseline, use the following command:
java -cp ".;lib/*" com.nimsoft.threshold.cmd.BaselineSetter -user <user> -pwd <password> -probe <path> -o <add | delete> [-f <file name>| -id <merticId>] [-native] [-queue]
 For Linux or Unix, the path is ".:lib/*".
The options are:
  • user (required): The user name
  • pwd (required): The password
  • probe (required): The path to the baseline_engine probe
    For example: /domain/hub/robot/baseline_engine
  • o (required): The operation add or delete
  • f: The name of file containing the baseline definitions to load
    : Format this file so that it is in the same format as the metricset.txt file. The metricset.txt file is available in the baseline_engine folder after you configure a baseline.
  • id (required): The metric ID of the QoS to baseline
  • native: Use the native sample frequency of the probe to baseline the QoS.
  • queue: Send configurations over the BASELINE_CONFIG queue instead of using callbacks.
Set up Thresholds
To set up a threshold, use the following command:
java -cp ".;lib/*" com.nimsoft.threshold.cmd.ThresholdSetter -user <user> -pwd <password> -probe <probepath> -id <metric id> -threshType <static | dynamic> -type <percent | scalar | stddev> -o <operator> [-operator1 <operator> | -operator2 <operator> | -operator3 <operator> | -operator4 <operator> | -operator5 <operator>] [-level1 <value> | -level2 <value> | -level3 <value> | -level4 <value> | -level5 <value>] -subsysId <subsysId> [-customAlarmMessage <message>] [-customClearAlarmMessage <message>] [-queue]
 For Linux or Unix, the path is ".:lib/*".
The options are:
  • user (required): The user name
  • pwd (required): The password
  • probe (required): The path to the baseline_engine probe
    For example: /domain/hub/robot/baseline_engine
  • threshType (required): The type of threshold, which is either static or dynamic
    • Static: No alarms are sent until sufficient alarms meeting the time requirements have exceeded the threshold.
    • Dynamic: A dynamic threshold is calculated on variance from the calculated static baseline with no averaging. Variances can be set to one of the following algorithms
  • id: The metric ID of the QoS for which thresholds are being defined
  • type (required): The algorithm that is used to calculate the variance from the calculated baseline
    Options are:
    • Scalar: A set value past the calculated baseline
    • Percentage: A set percentage past the baseline
    • Stddev: A set standard deviation past the baseline
  • o: One of the following operators:
    • L: less than
    • LE: less than or equal to
    • G: greater than
    • GE: greater than or equal to
    • EQ: is equal
    • NE: is not equal
  • operator1 <operator>: operator1 takes precedence over <operator>, information alarm threshold operator
  • operator2 <operator>: operator2 takes precedence over <operator>, warning alarm threshold operator
  • operator3 <operator>: operator3 takes precedence over <operator>, minor alarm threshold operator
  • operator4 <operator>: operator4 takes precedence over <operator>, major alarm threshold operator
  • operator5 <operator>: operator5 takes precedence over <operator>, critical alarm threshold operator
     If you specify one operator, you must specify all operators.
  • level1: Information alarm threshold value
  • level2: Warning alarm threshold value
  • level3: Minor alarm threshold value
  • level4: Major alarm threshold value
  • level5: Critical alarm threshold value
     The alarm threshold values are generated in the format 50.0 (for 50 percent). To generate an alarm, you must specify at least one level alarm threshold value.
  • subsysId (required): The subsystem ID of the QoS for which the thresholds are being defined
    Only one subsystem ID can be specified using the subsysId option.
  • threshID (Optional): A unique ID that distinguishes between multiple thresholds of the same threshType and id (metric ID)
  • delete: Remove the threshold that the id (metric ID), threshType, and threshID identify
  • customAlarmMessage: A custom alarm message that is generated when a threshold is breached
    Variables include:
    ${baseline} - The baseline that is calculated for a QoS metric, when you select the Compute Baseline and Dynamic Alarm options
    Baselines are not calculated for static messages, so this value is always zero for static alarms.
    ${level} - The numerical critical level of the alarm
    Valid values are: 1 (critical), 2 (major), 3 (minor), 4 (warning), or 5 (information)
    ${operator} - The operator (>, ≥, <, ≤, =, or !=) for the critical level of the alarm
    ${qos_name} - The name of the QoS metric
    ${source} - The source of the QoS metric that generated an alarm
    ${target} - The target of the QoS metric that generated an alarm
    ${threshold} - The threshold upon which an alarm is generated
    ${value} - The value that is contained in the generated QoS metric
    EXAMPLE:   -customAlarmMessage “${qos_name} is at ${value}”
  • customClearAlarmMessage: A custom alarm message that is generated when the alarm and its source return to a normal state
    Variables include:
    ${qos_name} - The name of the QoS metric
    ${value} - The value that is contained in the generated QoS metric
    ${source} - The source of the QoS metric that generated an alarm
  • queue: Send configurations over the BASELINE_CONFIG queue instead of using callbacks
Set up Thresholds Using a File
To set up thresholds for probes by using a file, use the following command:
java -cp ".;lib/*" com.nimsoft.threshold.cmd.ThresholdSetter -user <user> -pwd <password> -probe <probepath> -file <filename> [-queue]
 
 
 For Linux or Unix, the path is ".:lib/*".
The options are:
  • user: The user name
  • pwd: The password
  • probe: The path to the baseline_engine probe
    For example: /domain/hub/robot/baseline_engine
  • file: The name of file containing the threshold definitions to load
    Note
    : Format this file so that it is in the same format as the thresholds.cache file.
  • queue: Send configurations over the BASELINE_CONFIG queue instead of using callbacks
Change the Baseline Retention Period
The default baseline retention period is four weeks. You can adjust the length of the retention period to suit the use patterns for your environment.
 The baseline retention period can be set to a minimum of three weeks, or a maximum of 12 weeks. If you set the retention period to an unsupported value, the baseline_engine probe uses the nearest supported value. For example, if you set the retention period to 15 weeks, the probe sets the retention period to 12 weeks.
 
Follow these steps:
 
  1. In the Raw Configure menu of baseline_engine, click on the 
    Setup
     folder.
  2. Select the retentionPeriod key and then click the 
    Edit
     Key.
  3. On the Edit Key menu, change the value to the desired number of weeks (3 through 12). The key is updated with the new value.
  4. Click 
    Apply
    .
 
More Information: