Previous Topic: Configure Linux Free Memory Calculation

Next Topic: Monitoring Configuration

CA SystemEDGE User Guide › Agent Configuration › File-Based Configuration › Configure Monitor Aggregation in a Multi-tier Hierarchy

Configure Monitor Aggregation in a Multi-tier Hierarchy

SystemEDGE can aggregate self monitor and process monitor entries to correlate multiple monitors for the same attribute to display only the greatest severity. Monitors that are aggregated have the same object class, instance, and attribute. By default, when managing aggregate monitor entries, the agent only sends traps and executes actions for the entry with the worst aggregated state. You can change this default setting in the sysedge.cf file.

To send traps and execute actions for all connected monitors, not just the worst severity, add the following lines to sysedge.cf:

aggregate_monitor_traps
aggregate_monitor_actions

You can also configure the level of monitor aggregation. By default, the agent aggregates all self monitors and process monitors with the same object class, instance and attribute into standard aggregates. All monitors belonging to an aggregate are called connected monitors. You can configure higher levels of aggregation in the sysedge.cf file. The higher level of aggregates are called super aggregates (use an asterisk '*' as a placeholder). For example, you can create monitor aggregations like the following in the object Aggregate table:

Aggregates for virtual object instances support more than two tiers. The supported instances are structured as follows: 

//<any1>/<any2>/.../<anyN>/<instance>

Example

Object instances on an LPAR :

//hmc1/hyper1/lpar1/disk1

Super aggregates are only provided for two tiers (the two rightmost ones) but not for all tiers. For this example the following super aggregates are created:

//hmc1/hyper1/lpar1/*

//hmc1/hyper1/*/disk1

//hmc1/hyper1/*/*

The special super aggregate //* is created to aggregate all instances

Note: For the object instance '//' and '/' are used as delimiters to relate an instance to its hosted hierarchy: '//hierarchy/instance'. The hierarchy can be multi-tier. For local system instances '//./' is prepended.

Examples

//VM-Host/VM-Guest/Disk1
//Host/Disk1
//./Disk1

Super aggregates can be enabled for one or both of the rightmost two tiers. The special super aggregate //* is created to aggregate all instances.

Examples for level 0002

//VM-Host/VM-Guest/*
//Host/*
//./*

Examples for level 0004

//VM-Host/*/Disk1
//*/Disk1           (excluding //./Disk1)

Examples for level 0008

//VM-Host/*/*
//*/*               (excluding //./Disk1)
//*

To configure monitor entry aggregation levels, add the following line to the sysedge.cf file:

aggregate_level <level>
level

Specifies a bit field allowing the aggregation levels of the following table:

Class

Instance

Attribute

Level

class

//hierarchy/instance

attribute

(standard aggregate)

class

//hierarchy/*

attribute

0002

class

//hierarchy-1/*/instance

attribute

0004

class

//hierarchy-1/*/*

attribute

0008

class

//hierarchy/instance

*

0010

class

//hierarchy/*

*

0020

class

//hierarchy-1/*/instance

*

0040

class

//hierarchy-1/*/*

*

0080

*

//hierarchy/instance

attribute

0100

*

//hierarchy/*

attribute

0200

*

//hierarchy-1/*/instance

attribute

0400

*

//hierarchy-1/*/*

attribute

0800

*

//hierarchy/instance

*

1000

*

//hierarchy/*

*

2000

*

//hierarchy-1/*/instance

*

4000

*

//hierarchy-1/*/*

*

8000

For example, add the following line to the sysedge.cf file to apply all aggregation rules, causing aggregations up to an overall agent state:

aggregate_level 0xffff

For more information about monitor aggregation and the object class, instance, and attribute Self Monitor table columns, see the chapters "Concepts" and "Self Monitoring."