Configuring thresholds 165 - IBM Tivoli Netcool Performance Manager Wireline Component Document

Explains how to use the resmgr command to configure thresholds.

This chapter explains how to use resmgr to configure thresholds. Thresholds are Tivoli Netcool Performance Manager object types that belong to the design category.

Before using the commands in this chapter, review the information in Chapter 4,

“Managing Tivoli Netcool Performance Manager objects,” on page 15. Additional resmgr commands for managing thresholds can be found in “Working with thresholds” on page 173 of Chapter 7, “Managing design objects,” on page 111.

Thresholds

This section defines thresholds and the threshold options. There are two types of thresholds in Tivoli Netcool Performance Manager:

v Default threshold: is deployed against a metric, for any group or resource.

v Resource threshold: is deployed against a metric or resource, for any group.

v Group threshold: is deployed against a metric or group, for any resource.

v Group/resource threshold: is deployed against a specific metric, group or resource combination.

Threshold options

The following table lists threshold options:

Name Definition

idxMetric|fgp.nName Metric Id. Prop: Not Null, not 0 idxGroup|segp.name Sub-Element Group Id.Prop: Not null,

defaults to 0

idxResource|se.name Sub-Element Resource Id. Prop: Not null, defaults to 0

dteDate The date and time the action (STR_ACTION)

takes effect. Actions cannot be applied in the past and only take effect on the hour. The value is in seconds since January 1, 1970 GMT.Prop: Not null

mode Mode of the threshold: 1 = Under, 2 = Over,

3 = BandProp: Not null thrStat

Define which statistic will be used by the CME to calculate the threshold information:

0=raw(default), 1=min, 2=max, 3=avg, 4=sum, 5=countProp: Not null

Name Definition thrCalc

The calculation to be used to determine the value of DBL_BRST_MAX_PCT_OVER and DBL_PRD_MAX_PCT_OVER.

Values for this field include:

0=standard=abs(Value-Level)/abs(Level), 1=normalized=abs(Value-Level)/

(critical_level-warning_level), 2=scaled=abs(Value-Level)/scale where scale = DBL_TRH_CALC_VALUE

thrCalcValue The value used for calculating the

percentage over/under threshold.

brstCrtclLevel Level of the critical threshold for burst thresholds. Null implies that the threshold is not defined.

brstWrnngLevel Level of the warning threshold for burst thresholds. Null implies that the threshold is not defined.

brstCrtclTime Time limit for the critical period threshold in seconds. 0 indicates that the threshold is violated when the metric exceeds the threshold.

brstWrnngTime Time limit for the warning period threshold in seconds

brstGenEvent Indicates if Tivoli Netcool Performance

Manager has to generate events for the burst threshold. 0=no, 1=yes

prdCrtclLevel Level of the critical threshold for period thresholds. Null implies that the threshold is not defined.

PrdWrnngLevel Level of the warning threshold for period

thresholds. Null implies that the threshold is not defined.

PrdCrtclTime Time limit for the critical period threshold in seconds

PrdWrnngTime Time limit for the warning period threshold

in seconds PrdPeriod

Define the period for burst and period thresholds:

1 = Day / 2 =Week / 3 = Month / 4 = All

"All" period means that the CME will use the period of the aggregation tables

PrdGenEvent Indicates if Tivoli Netcool Performance

Manager has to generate events for the period threshold. 0=no, 1=yes

Deploying thresholds

This section explains the different threshold deployment scenarios.

Threshold deployment against groups and resources

Thresholds can be deployed by Class of Service (CoS), before any other criteria.

This means that for the same metric, resources in CoS=Platinum will have one threshold value X, and resources in CoS=Gold will have one threshold value X.

This figure illustrates that deploying a latency threshold of 100 ms for Platinum and 150 ms for Gold is not possible by group

Two different values are required for the same metric (latency), based on one grouping structure (CoS), and that it is required to have also a view of threshold violation following another grouping structure (Location).

Figure 1. Grouping Structure and Threshold Configuration

Deploying "Non-differentiated" thresholds

Non-differentiated thresholds is the preferred deployment method to follow because it does not involve resources (only metrics;) therefore, it is less CPU and memory intensive for the Tivoli Netcool Performance Manager Data Channel and is easier to provision.

If this method cannot be applied, you can apply the alternative method described in section “Deploying differentiated thresholds” on page 171. This method is more CPU and RAM intensive for Data Channel and requires usage of the CLI because of the number of thresholds to position.

You can have a uniform or non-differentiated threshold. For example, latency is differentiated by CoS (see “Threshold deployment against groups and resources”

on page 167) but Inbound Loss threshold is not: 1% for every resource in the system.

IBM recommends deploying thresholds at the metric level only, with no link to any resource. This means attaching thresholds to database metric identifier (mid) without any attachment to resource identifier (rid) or group identifier (gid).

Figure 2. Non-Differentiated Threshold Deployment

Note: You can also use the Tivoli Netcool Performance Manager DataMart Resource Editor to deploy non-differentiated thresholds. See Using Resource Editor in the IBM Tivoli Netcool Performance Manager: DataMart Configuration and Operation Guide for details.

Enter the following command:

resmgr -import thrdv -colNames "idxMetric(2201) mode(1) thrStat(0) thrCalc(0) thrCalcValue(0) brstCrtclLevel(1) brstWrnngLevel(0.5) brstCrtclTime(900) brstWrnngTime(1800) brstGenEvent(0)

prdCrtclLevel(1) prdWrnngLevel(0.5) prdCrtclTime(7200) prdWrnngTime(3600) prdPeriod(1) prdGenEvent(0)"

Each time a new resource is provisioned by Resource Manager or an SNMP or Bulk inventory, there is nothing to process because, as soon as the formula (for example, Inbound Loss, percent) is collected/imported against that subelement, that threshold is attached to the formula. This configuration can be considered as a default configuration for the "Inbound Loss" threshold.

In the Figure 2 on page 170 figure, R1 is moving from Boston to New York. Its Inbound Loss threshold is not supposed to change.

You can change the value of the threshold for only one resource. For example, R3 becomes an exception to the rule/default value (to reflect a specific customer commitment) and Inbound Loss threshold is changed from 1 to percent.

In this case, IBM recommends to use the Resource Editor module (or Resource Manager) for creating a new threshold attached to the metric and the resource.

Threshold attached to metric identifier: "Inbound Loss" Thr = 1 percent (no

resource attachment used) and threshold attached to (mid, rid): "Inbound Loss" Thr

= 1 percent for R3, (no resource attachment used). The (mid, rid) setting overwrites the default metric identifier setting.

Deploying differentiated thresholds

If you cannot apply the non-differentiated threshold deployment, then you can apply the differentiated threshold deployment. This method is more CPU and RAM intensive for Tivoli Netcool Performance Manager Data Channel and requires usage of the CLI because of the number of thresholds to position.

IBM recommends deploying threshold at the resource level vs. at the group level.

This mean attaching thresholds to couples (mid and rid) without any attachment to gid.

The Resource Editor module is not usable for deployment, but more for testing and prototyping, before deployment. This is due to the number of lines that are Figure 3. Differentiated Threshold Deployment

required in this interface. Each resource (network interface) x metric (latency) generates one line in the GUI, which can be unmanageable.

Enter the following command:

resmgr -import thrdv -colNames "idxResource idxMetric(2201) mode(1) thrStat(0) thrCalc(0) thrCalcValue(0) brstCrtclLevel(1)

brstWrnngLevel(0.5) brstCrtclTime(900) brstWrnngTime(1800) brstGenEvent(0) prdCrtclLevel(1) prdWrnngLevel(0.5)

prdCrtclTime(7200) prdWrnngTime(3600) prdPeriod(1) prdGenEvent(0)"

-file "./temp"

In the case of feeding resources in Tivoli Netcool Performance Manager with Resource Manager (from a provisioning system): every time a new resource is provisioned by Resource Manager, this command line should be launched, so that threshold is configured when the resource is provisioned.

Every time a threshold is attached or updated at a resource level, IBM recommends to duplicate it as a property, storing the same value for the property. This

overcomes any Tivoli Netcool Performance Manager DataView issues such as it being impossible to display a threshold value in RST/RTT/TOP N (as a

property=column in the table) and it being impossible follow the history of the threshold value within the Property History tables. It could also be impossible to display a threshold value as simple text (in PVRcLabels). Populating a shadow property replicating this threshold and its changes helps solve these issues.

Working with thresholds

This section explains how to work with thresholds. It contains information about exporting, importing, and deleting thresholds.

Exporting thresholds

The following are examples of exporting thresholds.

Example 1

Output appears. For example:

# type = thrdv

# col = fgp.nName segp.npath se.name mode thrStat

# filter =

# order =

# sep = |_|

# sepRec =

FORMULA|_|~NOC Reporting~Network Management~BasicInterface & ExtendedInterface|_|

192.168.3.252_<NULL>|_|1|_|0|_|

Example 2

Export of the idxGroup and idxResource fields. The thrsh_desc.idx_resource and thrsh_desc .idx_group columns have a value of 0.

Output appears. For example:

# type = thrdv

# col = fgp.nName idxGroup idxResource mode thrStat

# filter =

# order =

# sep = |_|

# sepRec =

~FORMULA|_|0|_|0|_|1|_|0|_|

Example 3

Export of the segp.npath and se.name fields. The thrsh_desc.idx_resource and thrsh_desc .idx_group columns have a value of 0.

Output appears. For example:

# type = thrdv

# col = fgp.nName segp.npath se.name mode thrStat

# filter =

# order =

# sep = |_|

# sepRec =

~FORMULA|_||_||_|1|_|0|_|

Deleting thresholds

To delete a line of the threshold table, you need to provide the value of the columns in the table.

Deleting by indices

Output appears. For example:

# type = thrdv

# col = idxMetric idxResource idxGroup mode thrStat

# filter =

# order =

# sep = |_|

# sepRec =

4065|_|0|_|0|_|1|_|0|_|

1000401|_|0|_|0|_|1|_|0|_|

1000401|_|1000193|_|1000292|_|1|_|0|_|

1000403|_|0|_|0|_|1|_|0|_|

1000403|_|1000347|_|1000292|_|1|_|0|_|

1000405|_|1000347|_|0|_|1|_|0|_|

Deleting a line from the index

Output appears. For example:

Info : === delete : DELETE ON Threshold ( 1140 1000196 ) (exists)

Verifying the deletion

Output appears. For example:

# type = thrdv

# col = idxMetric idxResource idxGroup mode thrStat

# filter =

# order =

# sep = |_|

# sepRec =

4065|_|0|_|0|_|1|_|0|_|

1000401|_|0|_|0|_|1|_|0|_|

1000401|_|1000193|_|1000292|_|1|_|0|_|

1000403|_|0|_|0|_|1|_|0|_|

1000405|_|1000347|_|0|_|1|_|0|_|

Importing thresholds

The following are examples of importing thresholds.

Example 1

Output appears. For example:

Info : === insert : INSERT ON Threshold (1000401 1000196 ) (does not exist)

Verifying the import

Output appears. For example:

# type = thrdv

# col = fgp.nName segp.npath se.name mode thrStat

# filter =

# order =

# sep = |_|

# sepRec =

~FORMULA|_|~NOC Reporting~Network Management~BasicInterface & ExtendedInterface|_|

192.168.3.62_<NULL>|_|1|_|0|_

Example 2

Import without specifying resource or group:

Output appears. For example:

Info : === insert : INSERT ON Threshold (1000401 1 ) (does not exist)

Verifying the import in index form

Export of the resource and group in index form.

Output appears. For example:

# type = thrdv

# col = idxMetric idxGroup idxResource mode thrStat

# filter =

# order =

# sep = |_|

# sepRec =

1000401|_|0|_|0|_|1|_|0|_|

Verifying the import in name form

Export of the resource and group in name form.

Output appears. For example:

# type = thrdv

# col = fgp.nName segp.npath se.name mode thrStat

# filter =

# order =

# sep = |_|

# sepRec =

~FORMULA |_||_||_|1|_|0|_|

Import by specifying an empty resource and group value

Output appears. For example:

Info : === insert : INSERT ON Threshold (1000402 0 ) (does not exist)

Verifying the import

Export of the resource and group in index form.

Output appears. For example:

# type = thrdv

# col = idxMetric idxGroup idxResource mode thrStat

# filter =

# order =

# sep = |_|

# sepRec =

1000402|_|0|_|0|_|1|_|0|_|

Verifying the import

Export of the resource and group in name form

Output appears. For example:

# type = thrdv

# col = fgp.nName segp.npath se.name mode thrStat

# filter =

# order =

# sep = |_|

# sepRec =

~FORMULA1|_||_||_|1|_|0|_|

Setting thresholds

This section explains how to set and verify thresholds against groups and resources.

Identifying formula indexes

About this task

You need to identify the index of the formula to be used as follows:

Procedure

1. Enter the following command to export the list of formulas and indexes:

resmgr -export frm -colNames "name dbIndex"

2. Choose the Generic formula for the metric to which you want to apply the threshold. Thresholds need to be applied to generic formulas because this is the proper database index under which the data will be stored.

3. Identify the index of the group or resource to be used in thresholding.

4. Enter the following command to export the list of subelement groups and indexes (use the -filter option to filter the results of the export).

resmgr -export segp -colNames "npath dbIndex se.dbIndex se.name"

5. Choose a group index that meets the following criteria:

a. A calendar and time zone have been applied at or above the group, to the specific subelement, or to the group that a subelement is in.

b. The group, resource, or group the specific subelement is in, is one under the reporting tree, or on a branch where reporting is performed.

Setting a threshold against a group (dbIndex)

To set a threshold against a group, enter the following command:

resmgr -import thrdv -colNames "idxMetric idxGroup mode thrStat thrCalc thrCalcValue brstCrtclLevel brstWrnngLevel brstCrtclTime brstWrnngTime brstGenEvent prdCrtclLevel prdWrnngLevel prdCrtclTime prdWrnngTime prdPeriod prdGenEvent" -line

"2210|_|1001033|_|2|_|0|_|0|_|1000000|_|2000000|_|1000000|_|0|_|0|_|0|_|

2000|_|1000|_|900|_|900|_|1|_|0"

Output appears. For example, if the threshold does not exist in the database:

Info : === insert : INSERT ON Threshold ( 2210 0 ) (does not exist) If the threshold does exist in the database:

Info : === insert : UPDATE ON Threshold ( 2210 0 ) (exists)

Note: prdPeriod is mandatory for both burst and period thresholds.

Verifying the threshold

To verify the threshold you need to export the threshold as follows:

resmgr -export thrdv -colNames "idxMetric idxGroup mode thrStat thrCalc thrCalcValue brstCrtclLevel brstWrnngLevel brstCrtclTime brstWrnngTime brstGenEvent prdCrtclLevel prdWrnngLevel prdCrtclTime prdWrnngTime prdPeriod prdGenEvent" -filter "idxMetric(2210)"

Output appears telling you that the threshold is in the database properly. For example:

2210|_|1001033|_|2|_|0|_|0|_|1000000|_|2000000|_|1000000|_|0|_|0|_|0|_|2000|_|

1000|_|900|_|900|_|1|_|0|_|

Setting a threshold against a group (name)

Enter the following command:

resmgr -import thrdv -colNames "idxMetric segp.npath mode thrStat thrCalc thrCalcValue brstCrtclLevel brstWrnngLevel brstCrtclTime brstWrnngTime brstGenEvent prdCrtclLevel prdWrnngLevel prdCrtclTime prdWrnngTime prdPeriod prdGenEvent" -line "2210|_|~NOC

Reporting~Network Management~Unknown_Area~All

Techs|_|2|_|0|_|0|_|1000000|_|2000000|_|1000000|_|0|_|0|_|0|_|2000|_|1000|_|

900|_|900|_|1|_|0"

Output appears. For example, if the threshold does not exist in the database, Info : === insert : INSERT ON Threshold ( 2210 0 ) (does not exist)

If the threshold does exist in the database:

Info : === insert : UPDATE ON Threshold ( 2210 0 ) (exists)

Note: prdPeriod is mandatory for both burst and period thresholds.

Verifying the threshold

To verify the threshold you need to export the threshold:

resmgr -export thrdv -colNames "idxMetric segp.npath mode thrStat thrCalc thrCalcValue brstCrtclLevel brstWrnngLevel brstCrtclTime brstWrnngTime brstGenEvent prdCrtclLevel prdWrnngLevel prdCrtclTime prdWrnngTime prdPeriod prdGenEvent" -filter "idxMetric(2210)"

Output appears if the threshold is in the database properly. For example:

2210|_|~NOC Reporting~Network Management~Unknown_Area~All Techs |_|2|_|0|_|0|_|

1000000|_|2000000|_|1000000|_|0|_|0|_|0|_|2000|_|1000|_|900|_|900|_|1|_|0|_|

Setting a threshold against a resource (dbIndex)

Enter the following command:

resmgr -import thrdv -colNames "idxMetric idxResource mode thrStat thrCalc thrCalcValue brstCrtclLevel brstWrnngLevel brstCrtclTime brstWrnngTime brstGenEvent prdCrtclLevel prdWrnngLevel prdCrtclTime prdWrnngTime prdPeriod prdGenEvent" -line

"2210|_|1000660|_|2|_|0|_|0|_|1000000|_|2000000|_|1000000|_|0|_|0|_|0|_|

2000|_|1000|_|900|_|900|_|1|_|0"

Output appears. For example, if the threshold does not exist in the database Info : === insert : INSERT ON Threshold ( 2210 0 ) (does not exist)

If the threshold does exist in the database:

Info : === insert : UPDATE ON Threshold ( 2210 0 ) (exists)

Note: prdPeriod is mandatory for both burst and period thresholds.

Verifying the Threshold

To verify the threshold you need to export the threshold:

resmgr -export thrdv -colNames "idxMetric idxResource mode thrStat thrCalc thrCalcValue brstCrtclLevel brstWrnngLevel brstCrtclTime brstWrnngTime brstGenEvent prdCrtclLevel prdWrnngLevel prdCrtclTime prdWrnngTime prdPeriod prdGenEvent" -filter "idxMetric(2210)"

Output appears. For example:

2210|_|1000660|_|2|_|0|_|0|_|1000000|_|2000000|_|1000000|_|0|_|0|_|0|_|

2000|_|1000|_|900|_|900|_|1|_|0|_|

Setting a threshold against a resource (name)

Enter the following command:

resmgr -import thrdv -colNames "idxMetric se.name mode thrStat thrCalc thrCalcValue brstCrtclLevel brstWrnngLevel brstCrtclTime brstWrnngTime brstGenEvent prdCrtclLevel prdWrnngLevel prdCrtclTime prdWrnngTime prdPeriod prdGenEvent" -line

"2210|_|zelkona.quallaby.com_Interface<1>|_|2|_|0|_|0|_|1000000|_|2000000|_|

1000000|_|0|_|0|_|0|_|2000|_|1000|_|900|_|900|_|1|_|0"

Output appears. For example, if the threshold does not exist in the database.

Info : === insert : INSERT ON Threshold ( 2210 0 ) (does not exist) If the threshold does exist in the database:

Info : === insert : UPDATE ON Threshold ( 2210 0 ) (exists)

Note: prdPeriod is mandatory for both burst and period thresholds.

Verifying the threshold

Enter the following command:

resmgr -export thrdv -colNames "idxMetric se.name mode thrStat thrCalc thrCalcValue brstCrtclLevel brstWrnngLevel brstCrtclTime brstWrnngTime brstGenEvent prdCrtclLevel prdWrnngLevel prdCrtclTime prdWrnngTime prdPeriod prdGenEvent" -filter "idxMetric(2210)"Either

"su" to the oracle user, or use the $ORACLE_HOME/sqlplus utility.

$ORACLEHOME/sqlplus pv_admin/<password>@PV(or other instance name)SQLPLUS> select * from thrsh_desc where idx_metric = ’2210’

and idx_resource = ’1000245’;

Output appears to tell you that the threshold is in the database properly. For example:

2210|_|zelkona.quallaby.com_Interface<1>|_|2|_|0|_|0|_|1000000|_|2000000|_|

1000000|_|0|_|0|_|0|_|2000|_|1000|_|900|_|900|_|1|_|0|_|

Setting a future threshold

This section explains how to set a future threshold.

1. Follow steps 1 to 5 as detailed in the section “Setting thresholds” on page 177.

2. Specify a future date. For example, if today's date is 7/10/01, then choose 7/11/01 at 12:00 a.m. Convert this date to Epoch numerical time: 994867200.

Epoch time is an exact specification of the date and time at which the Keplerian element set is valid.

Setting a threshold against a group (dbIndex)

Enter the following command to import a threshold for a group:

Resmgr -import thrdv -colNames "idxMetric idxGroup dteDate mode thrStat thrCalc thrCalcValue brstCrtclLevel brstWrnngLevel brstCrtclTime brstWrnngTime brstGenEvent prdCrtclLevel

prdWrnngLevel prdCrtclTime prdWrnngTime prdPeriod prdGenEvent"

-line

"2210|_|1001033|_|994867200|_|2|_|0|_|0|_|1000000|_|2000000|_|1000000|_|0|_|0|_|

0|_|2000|_|1000|_|900|_|900|_|1|_|0"

Output appears. For example (if the threshold does not exist in the database):

Info : === insert : INSERT ON Threshold ( 2210 0 ) (does not exist) If the threshold does exist:

Info : === insert : UPDATE ON Threshold ( 2210 0 ) (exists)If the threshold does exist in the database.

Note: prdPeriod is mandatory for both burst and period thresholds.

Verifying the threshold

Verify the threshold by exporting the threshold:

Resmgr -export thrdv -colNames "idxMetric dteDate idxGroup mode thrStat thrCalc thrCalcValue brstCrtclLevel brstWrnngLevel brstCrtclTime brstWrnngTime brstGenEvent prdCrtclLevel

prdWrnngLevel prdCrtclTime prdWrnngTime prdPeriod prdGenEvent"

-filter "idxMetric(2210)"

Output appears. For example:

2210|_|1001033|_|994867200|_|2|_|0|_|0|_|1000000|_|2000000|_|1000000|_|

0|_|0|_|0|_|2000|_|1000|_|900|_|900|_|1|_|0|_|

This means the threshold is in the database properly.

You can verify if a future threshold has taken place properly as follows:

1. Set the date of the threshold to a date in the future.

2. Wait for the system time on the CME machine to reach that date for the threshold to be activated.

After the date has been reached, a threshold appears in DataView reports. Time is in Epoch time.

Tip: Consider installing an Epoch time converter on your system.

CAUTION:

Do not set the system time ahead as it can cause CME conflicts.

3. Check the subelement group or specific sub-elements in the reports after the time has passed to verify that the threshold has taken effect.

Setting traps

This section explains how to set burst and period traps.

Setting burst traps

Enter the following command to set a threshold for a metric:

"2210|_|1001033|_|2|_|0|_|0|_|1000000|_|2000000|_|1000000|_|0|_|0|_|1|_|2000|_|

1000|_|900|_|900|_|1|_|0"

In this example, a threshold is set for metric 2210 against the group with the ID of 1001033. The Burst Generate Event flag has also been set.

Note: prdPeriod is mandatory for both burst and period thresholds.

Verifying the burst trap

To verify the burst trap:

1. Log in as root on the server where the Topology Editor is installed.

2. Set and export your DISPLAY variable.

3. Change your working directory to the directory where the Topology Editor is installed. For example:

# cd /opt/IBM/proviso/topologyEditor

4. Start the Topology Editor using the following command:

# ./topologyEditor

5. In the Topology Editor, select Topology > Open existing topology. The Open Topology window is displayed.

6. For the topology source, select From database (v. 443) and click Next.

7. Verify that all of the fields for the database connection are filled in with the correct values:

v Database hostname-- The name of the database host. The default value is localhost.

v Port-- The port number used for communication with the database. The default value is 1521.

v Database user-- The username used to access the database. The default value is pv_admin.

v Database Password-- The password for the database user account. For example, pv.

v SID-- The SID for the database. The default value is PV.

8. Click Finish.

9. In the Logical View, click the DataChannels folder.

10. Click the DataChanneln component, where n is the appropriate DataChannel number.

11. Click the Complex Metric Engine n.m component, where n.m is the appropriate DataChannel and sub-channel number.

12. In the Properties tab, search for the following parameter:

Trap destination=value

13. Verify that the value is set to the IP address and port for your snmptrap daemon (for example, Trap destination=192.168.69.30:162).

14. When you are satisfied with your settings, select Topology > Save topology to save the topology.

In document IBM Tivoli Netcool Performance Manager Wireline Component Document Revision R2E1. Command Line Interface Guide (Page 173-195)