Document ID: 25041
This document answers some frequently asked questions about CEMF Performance Management.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Q. Why does a dialog box appear sometimes when the Performance Manager window is opened stating that the object has no monitored objects? (Products affected : CEMF 3.0.1, 3.0.2, 3.0.3)
A. A. This can be due to any of the following reasons. In each case, running the following command from within CEMF shell helps diagnose the problem:/bin historyAdmin
This command displays the history criteria that are currently loaded into CEMF. These criteria are loaded in from history criteria files at startup.
For each object, Performance Manager displays the attributes that are defined in history criteria files. History criteria files are based on Object Groups. The Controller puts an object into an Object Group and it is commissioned and polled. This means that if the object has never been polled it won't be in the Object Group, and so the Performance Manager reports that none of its attributes are being monitored.
Note: If the object is no longer polled, it remains in the Object Group and so its attributes can still be viewed in the Performance Manager.
Running the historyAdmin list command in this case shows the criteria that specifies this object has been successfully loaded.
To determine if this scenario is causing the problem, ensure the criteria is loaded, and that the object is commissioned and being polled. If the criteria is not loaded, the problem is due to something else.
The solution is to start polling the object.
The history criteria specification within a history criteria file may be incorrect or invalid. The following cases should be checked.
If a criteria includes one or more SUMMARYRULE entries, each rule must be valid for each ATTRIBUTE within the specification. All SUMMARYRULEs are valid only for ATTRIBUTEs of the following types:
For example, totalling IP addresses is not a valid operation. If any rule is invalid for any attribute within a criteria, that criteria is not loaded. The format of an ATTRIBUTE entry in a criteria specification is:ATTRIBUTE <module>.<name> <section>
For controller mapped attributes, the section should be the controller section, not, for example, SNMP.
To determine if this scenario is causing the problem, ensure the criteria is not loaded. A criteria may fail to load for a different reason (see below).
The solution is to correct the criteria specification. The criteria can then be loaded by running the following command within a CEMF shell:<CEMF_Root>/bin/historyAdmin add <criteria filename>
Subsequent installations of the EM with a corrected history criteria file results in the criteria being automatically loaded.
Only those attributes that are in the object's class are displayed. Consider a history criteria that specifies some attributes, and each of those attributes are components of a table that is in the object's class. Although the table is an attribute of the object, its component attributes aren't. This means the Performance Manager won't display it.
This will be changed in a future CEMF patch/release, so attributes can be specified in criteria and subsequently visible in the Performance Manager.
The solution for current CEMF releases is to change the class model so that the object's class explicitly contains those attributes.
There is an intermittent bug affecting CEMF versions up to and including 3.0.3 that can result in valid criteria files not being loaded. A workaround is to explicitly load the criteria by running the following command in a CEMF shell:bin/historyAdmin add <criteria filename>
This bug will be fixed in a future patch/release.
Q. How do I clean out a full attribute history file or increase the size of the database? (Products affected : CEMF 2.1.x)
A. There are two possible changes you can make, both are changes to the CEMFROOT/config/init/attributehistorymgr.ini file.
An alarm is raised when the size of the database that stores data for the Performance Manager exceeds a predefined level. The warnDatabaseSize and purgeDatabaseSize variables within the above .ini files control this process. Increasing their values means the alarm are raised when the database is larger.
Alternatively, you can lower the autoPurgeToAge variable within the .ini file. This results in younger data being purged, and so the database will not grow as quickly.autoPurgeToAge variable within the .ini file. This results in younger data being purged, and so the database will not grow as quickly.
|Updated: Jan 31, 2006||Document ID: 25041|