Product: CA Unified Infrastructure Management
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.
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.
The baseline_engine probe has the following features:
Important Note: The baseline_engine probe is designed to be deployed with minimal configuration.
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.
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:
Defines the log file name
Sets the overall root log level (from 0 (minimum) to 5(maximum))
Sets the log level for messages tracking operation of the scripts that perform the baseline calculations
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.
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.
Sets the ability to override the default baseline calculation interval for individual probes.
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.
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.
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):
Sets the log level for the messagestore sub-process
Sets the log level for the process that disassembles PDS messages from the bus
Sets the log level for the metricrunner process
Sets the log level for operation of the metricfactory (limited to whether or not the metricfactory successfully started)
Sets the logging level for the metric calculator, which executes scripts that perform the baseline calculations.
If there is no historic baseline data available in the current hour it will use the previous hour's data.
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.
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.
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.
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:
Additional help with setting up queues can be found in the section "The Queues Tab" in the Hub probe online help document.
Copyright © 2014 CA Technologies.
All rights reserved.