Introduction

Product: CA Unified Infrastructure Management

Release: 8.0

A baseline expresses normalized QoS levels on an hour-of-day and day-of-the week basis. The baseline_engine probe follows QoS messages on the bus and samples this data up to 30 times during each one-hour interval. This sampling rate provides a statistically accurate baseline while minimizing system resource use.

At the top of each hour, a baseline data point is calculated for each QoS monitor and sent to the qos_processor probe, which, after processing, writes this data to the UIM database. This first baseline approximation for the hour interval is available after the hour has concluded, and is improved with succeeding baseline data points from corresponding intervals gathered over a four-week period.

Baselines are displayed with their associated QoS monitor data in dashboards and reports in UMP.

This Knowledge Base Article constitutes a portion of the official CA product documentation for this CA product. This Knowledge Base Article is subject to the following notices, terms and conditions.

Prerequisites

The baseline_engine probe depends on the qos_processor probe for data storage. The baseline_engine probe is distributed as part of your CA Unified Infrastructure Management (UIM)--it requires the version of qos_processor included with UIM (qos_processor saves the baseline data), and will not install or operate on versions of NMS earlier than 6.5.

By default, the baseline_engine probe stores four weeks of historical QoS metric and baseline data on the local disk of the system that hosts it.

Features

The baseline_engine probe has the following features:

Important Note: The baseline_engine probe is designed to be deployed with minimal configuration.

baseline_engine Probe Deployment

The baseline_engine probe package is deployed on the primary hub in a standard UIM installation. It starts automatically. The baseline_engine probe also enables dynamic thresholds within your UIM environment.

If you want to calculate baselines for your QoS metrics you must configure the calculate baseline setting in the individual monitoring probe configuration.

If you upgrade your NMS from version 7.1, the baseline_engine will inherit the metric set list and calculate baselines after the upgrade is complete.

Configuration

The baseline_engine probe is configured using the Raw Configure option in the probe.

The Raw Configure GUI provides these configurable key-value pairs in the setup folder:

logfile

Defines the log file name

loglevel

Sets the overall root log level (from 0 (minimum) to 5(maximum))

scriptloglevel

Sets the log level for messages tracking operation of the scripts that perform the baseline calculations

performance

Switches a lightweight performance monitor process on (true) or off (false). The performance monitor checks every minute on the rate of execution of queuing and calculation, etc. and logs this information to performance.log.

The following keys can be added to the setup folder.

messagelimitlog

Sets the log level for messages that show if the maxmetrics limit is exceeded or not. This is essentially a binary setting, with level=1 denoting "off" and level=>2 equivalent to "on." If level=2, then an error message is logged to the main log when maxmetrics is exceeded. To see the metrics that are not processed/baselined, view the skipped_message.log file.

isNative

Sets the ability to override the default baseline calculation interval for individual probes.

projection

By default, this key-value is set to True and baselines are projected one week in the future to ensure that dynamic threshold alarms are consistent with the baseline. When this setting is True, the baseline_engine adjusts the timestamps of the baselines to one week in the future and sends duplicate baselines with unadjusted timestamps. This allows dynamic threshold configurations to be evaluated immediately without having to wait one week. The duplicate baselines are only generated for one week. If you do not want to use this projection behavior, change this setting to False before the baseline_engine calculates any baselines.

Important! If projectBaselines is set to True and you have already configured baselines, do not change this setting back to False. This causes the system to have two baselines for a period of one week in the future.

Important! Do not delete the projectionEnabled file stored in the root baseline_engine directory. Otherwise, your baseline timestamps will be affected.

retentionPeriod

Sets the amount of time (in weeks) for the baseline to retain monitoring data. The range is between 3 and 12 weeks. The default is 4 weeks.

predictiveAlarmSubject

Sets the alarm subject for a Time To Threshold alarm. The baseline_engine probe uses this subject setting to assist in routing predictive alarms. If this setting is alarm, the baseline_engine probe sends predictive alarms properly. If this parameter is set to a value other than alarm, the baseline_engine will be unable to properly route predictive alarms to an administrator.

For all the following keys, the default level is set to 1 (levels 1 through 5 allowed):

messagestorelog

Sets the log level for the messagestore sub-process

demartialpdslog

Sets the log level for the process that disassembles PDS messages from the bus

metricrunner

Sets the log level for the metricrunner process

metricfactory

Sets the log level for operation of the metricfactory (limited to whether or not the metricfactory successfully started)

metriccalculator

Sets the logging level for the metric calculator, which executes scripts that perform the baseline calculations.

useprevioushour

If there is no historic baseline data available in the current hour it will use the previous hour's data.

Sample Configuration

The settings listed below are the typical values for the keys:

<startup>
	<opt>
	java_mem_init = -xms64m
	java_mem_max = -xmx2048m
	java_opts - -XX:+UseConcMarkSweepGC -XX:+ScavengeBeforeFullGC -XX:+UseParNewGC
	</opt>
</startup>

<setup>
	logfile = baseline_engine.log
	loglevel = 1
	scriptloglevel = 3
	messagelimitlog = 2
	performance = true
</setup>

<threshold>
	useprevioushour = true
	alarmcheckers = 4
</threshold>

The alarmcheckers value can be increased to 16 if needed. If the alarmcheckers option is equal to 0 then the dynamic thresholds feature is not enabled.

Dynamic Alarm Thresholds

In order to create dynamic alarm thresholds you must have the baseline_engine probe version 2.00 installed on the robot and configured. Dynamic thresholds are configured at the QoS metric level in each probe that publishes an alarm for a QoS metric.

For each QoS metric you must select the Publish Data and Compute Baseline options in order to view the Dynamic Alarm Thresholds section of the configuration.

Example:

There are three algorithms allowed for dynamic alarm thresholds:

Note: You must indicate the direction for each algorithm, either increasing or decreasing.

If you are using baseline_engine 2.1, you can also change the Subsystem ID using the Subsystem (override) field. This is only required if the Subsystem ID shown in the Subsystem (default) field is not correct for your configuration.

BASELINE--Subsystem_ID

Recommended Multiple Hub (tiered) Probe Deployment

The baseline_engine has been designed to be horizontally scalable. The recommended deployment approach is to install it on secondary or sub-hub(s) to distribute the processing. You can distribute the probe using drag and drop with Admin Console or Infrastructure Manager.

Note: The qos_processor probe must be running on the primary Hub to store the QOS_BASELINE messages in the UIM database.

QOS_BASELINE messages (where subject ID is QOS_BASELINE) must be forwarded from the baseline_engine probe on the secondary hub(s) to the qos_processor probe running on the primary Hub. To enable this message forwarding, create a new hub queue or amend existing hub queues to forward the new QOS_BASELINE messages to the primary hub--just as is done for QOS_MESSAGE and QOS_DEFINITION messages.

To amend or augment existing hub queues, edit your existing post (or attach) queues and add the "QOS_BASELINE" subject. Alternatively, create a new post (or attach) queue with just the "QOS_BASELINE" subject.

Example: Configure an Existing Queue

This example shows how to configure and existing hub queue in Infrastructure Manager.

Follow These Steps:

  1. In Infrastructure Manager, double-click the hub probe to open its GUI.
  2. In the Hub configuration GUI, under the Queues tab, select the queue that forwards messages with QOS_MESSAGE and QOS_DEFINITION subjects:

  3. Edit this queue by appending the additional subject ",QOS_BASELINE":

  4. Click OK and then Yes when prompted to enable changes. The hub will refresh its configuration (perform a soft restart).

Additional help with setting up queues can be found in the section "The Queues Tab" in the Hub probe online help document.