Table of Contents |
---|
DOCUMENT DEPRECATED, see opCharts Dynamic Baseline and Threshold Tool
Why we need a Dynamic Baseline and Thresholding Tool
Forewarned is forearmed the poverb goes, a quick google tells me "prior knowledge of possible dangers or problems gives one a tactical advantage". The reason we want to baseline and threshold our data is so that we can receive alerts forewarning us of issues in our environment, so that we can act to resolve smaller issues before they become bigger. Being proactive increases our Mean Time Between Failure.
...
The delta baseline is only concerned with the amount of change in the baseline, for example
Working with the Dynamic Baseline and Thresholding Tool
The Dynamic Baseline and Threshold Tool includes various configuration options so that you can tune the algorithm to learn differently depending on the metric being used. The tool comes with several metrics already configured. It is a requirement of the system that the stats modelling is completed for the metric you require to be baseline, this is how the NMIS API extracts statistical information from the performance database.
Dynamic Baseline Configuration Options
Configuration of the baseline tool is done in the file /usr/local/omk/conf/Baseline.nmis the default configuration should be installed when the tool is installed.
...
Same-Day Dynamic Baseline Configuration Example
Here is what the configuration file would look like, this example is a Same-Day Baseline:
...
from a sample of data from the last 4 hours we would see that the average of a metric is 100, we then take the current value, for example, the spike of 145 below, and we calculate the change as a percentage, which would be a change of 45% resulting in a Critical event level.
The delta baseline configuration then allows for defining the level of the event based on the percentage of change, for the defaults, this would result in a Major, you can see the configuration in the example below, this table is how to visualize the configuration.
Change % | Resulting Event Level |
---|---|
10 | Warning |
20 | Minor |
30 | Major |
40 | Critical |
50 | Fatal |
If the change is below 10% the level will be normal, between 10% and 20% Minor, and so up to over 50% it will be considered fatal.
In practicality this spike was brief and using the 15 minute threshold period (current is the average of the last 15 minutes) the value for calculating change would be 136 and the resulting change would be 36% so a Major event. The threshold period is dampening the spikes to remove brief changes and allow you to see changes which last longer.
Installing the Baseline Tool
Copy the file to the server and do the following, upgrading will be the same process.
Code Block |
---|
tar xvf Baseline-X.Y.tgz
cd Baseline/
sudo ./install_baseline.sh |
Working with the Dynamic Baseline and Thresholding Tool
The Dynamic Baseline and Threshold Tool includes various configuration options so that you can tune the algorithm to learn differently depending on the metric being used. The tool comes with several metrics already configured. It is a requirement of the system that the stats modeling is completed for the metric you require to be baseline, this is how the NMIS API extracts statistical information from the performance database.
Dynamic Baseline Configuration Options
Configuration of the baseline tool is done in the file /usr/local/omk/conf/Baseline.nmis the default configuration should be installed when the tool is installed.
Configuration Option | Description | Example |
---|---|---|
baseline | Which type of baseline are we using, "dynamic" or "delta", the default is dynamic, if undefined, dynamic will be used. | delta |
active | Is baselining this metric active or not, values are true or false | true |
metric | Which NMIS data point or variable, equates to an RRD DS | RouteNumber |
type | Which NMIS model section or metric | RouteNumber |
use_index | For using with certain types where the type is not how the index is stored, e.g. the index for pkts_hc is interface, so when type=pkts_hc then use_index=interface. A rarely used option. | interface (where applicable) |
section | What is the section name in the node info, just run it, otherwise the section must exist. | |
nodeModel | This is a regex which defines which NMIS models should be matched | CiscoRouter |
event | The name of the event to use, will default to Proactive Baseline type metric if none provided. | Proactive Route Number Change |
indexed | Is this variable indexed or not | false |
threshold_exceeds | Ignored if undef otherwise the value must ALSO exceed this threshold to raise an event | undef |
threshold_period | How many minutes should the value to be baselined be averaged, e.g. -5 minutes is the last poll, -15 minutes would be the average of the last 15 minutes, -1 hour would be the last 60 minutes. | -5 minutes |
multiplier | How many standard deviations to vary the baseline by. | 1 |
weeks | The number of weeks to look back | 0 |
hours | The number of hours to include in the baseline metrics | 8 |
levels | The levels section is used by the delta baseline method to define when an amount of change will trigger an event and what level that event will be. |
Same-Day Dynamic Baseline Configuration Example
Here is what the configuration file would look like, this example is a Same-Day Baseline:
Code Block |
---|
'RouteNumber' => {
'active' => 'true',
'metric' => 'RouteNumber',
'type' => 'RouteNumber',
'nodeModel' => 'CiscoRouter',
'event' => 'Proactive Route Number Change',
'indexed' => 'false',
'threshold_exceeds' => undef,
'threshold_period' => "-5 minutes",
'multiplier' => 1,
'weeks' => 0,
'hours' => 8,
}, |
Multi-Day Dynamic Baseline Configuration Example
Another configuration option using the BGP Prefixes being exchanged with BGP peers, is from systemHealth modelling and this is a multi-day baseline:
Code Block |
---|
'cbgpAcceptedPrefix' => { 'active' => 'true', 'metric' => 'RouteNumbercbgpAcceptedPrefix', 'type' => 'bgpPrefix', 'section' => 'RouteNumberbgpPrefix', 'nodeModel' => 'CircuitMonitor|CiscoRouter', 'event' => 'Proactive Route Number Change BGP Peer Prefix Change', 'indexed' => 'true', 'indexedmultiplier' => 'false'1, 'threshold_exceedsweeks' => undef4, 'threshold_periodhours' => "-5 minutes"1, }, |
Delta Baseline Configuration Example
Currently delta baselines do not support multi-day, but the hours value can be very large if required.
Code Block |
---|
'multiplierhrSystemProcesses' => 1,{ 'weeksbaseline' => 0'delta', 'hoursactive' => 8, }, |
Multi-Day Dynamic Baseline Configuration Example
Another configuration option using the BGP Prefixes being exchanged with BGP peers, is from systemHealth modelling and this is a multi-day baseline:
Code Block |
---|
'cbgpAcceptedPrefix'true', 'metric' => {'hrSystemProcesses', 'activetype' => 'trueHost_Health', 'metricnodeModel' => 'cbgpAcceptedPrefixnet-snmp', 'typeindexed' => 'bgpPrefixfalse', 'sectionhours' => 4, 'bgpPrefix'threshold_period' => "-15 minutes", 'nodeModellevels' => 'CircuitMonitor|CiscoRouter', { 'eventWarning' => 'Proactive BGP Peer Prefix Change',10, 'indexedMinor' => 'true'20, 'multiplierMajor' => 130, 'weeksCritical' => 440, 'hoursFatal' => 1, 50 } }, |
Delta
...
Baseline for Output Packets Discarded Configuration Example
Currently delta baselines do not support multi-day, but the hours value can be very large if required.
Code Block |
---|
'hrSystemProcessesifOutDiscards' => { 'baseline' => 'delta', 'active' => 'true', 'metric' => 'ifOutDiscards', 'type' => 'pkts_hc', 'active'use_index' => 'trueinterface', 'metricnodeModel' => 'hrSystemProcessesCiscoRouter', 'typeevent' => 'Host_HealthProactive Output Discards (Delta)', 'nodeModelindexed' => 'net-snmptrue', 'indexedhours' => 'false'1, 'hoursthreshold_period' => 4 "-15 minutes", 'levels' => { 'Warning' => 101, 'Minor' => 202, 'Major' => 303, 'Critical' => 404, 'Fatal' => 507 } }, |
Running the Baseline Tool
...