NetApp Filers KM for PATROL

Release Notes for v2.2.00

Home  Previous  Next

What's New

Full support for instance-to-device mapping in version 8.6.02 of BMC ProactiveNet Performance Management: Integrating the KM in BPPM dynamically creates devices that correspond to the remotely monitored systems.
With the implementation as a separate component of a collection hub shared by several modules, it is now possible to configure several aspects of this collection hub separately. Separate options for the debug mode, for example, are now available.
The KM now fully supports version 9.0.00 of the PATROL Agent.

Changes and improvements

Optimized Performance: NetApp Filers KM for PATROL leverages Java 1.5 or greater to optimize the performance of its discovery process. You need to install a Java Runtime Environment (JRE) on the same system that runs the PATROL Agent and NetApp Filers KM for PATROL to benefit from this optimization. Java not installed on the system or if the KM not being able to detect it, does not prevent the KM from performing properly, but may slow down the monitoring of large systems. In any case, the Java Settings wizard lets you define the path of the Java environment to be used by the KM.

Thresholds Management

In order to optimize the discovery process and improve the scalability of the solution, several important changes have been implemented in the way alert thresholds are managed by the KM.

Default thresholds are set in the agent’s configuration, only once, the first time the KM runs. In previous versions, the KM would set default alert thresholds during each discovery (every hour by default) according to its internal policy, thus overwriting any changes that were made manually by the administrators. Administrators can now customize the default thresholds using the Event Management KM or PCM (PATROL Configuration Manager) and do not need to use the KM’s interface to make sure these customization are overwritten by the discovery of the KM.
Thresholds are set globally at the class level (or at least for a group of instances). In previous versions, the KM would set alert thresholds for each and every instance of each class, leading to extremely large configuration files (which could cause PCM to crash in some occasions). A limited set of parameters still require alert thresholds to be set at the instance level. This results in a much smaller agent configuration file and vastly improved performance.
The “Modify Thresholds” KM Commands has been removed from most classes, as the thresholds can now be managed by PATROL administrators in a standard way through the Event Management KM and PCM (or any other method used in their environment).
The “Alert After N Times” KM Command has been removed, as this setting can now be managed by PATROL administrators in a standard way through the Event Management KM and PCM.
To reset the alert thresholds to their default values (as when the KM first runs), the administrator can either use the “Reinitialize KM” KM Command with the “Reset alert thresholds” option enabled or use the Event Management KM or PCM to delete the corresponding configuration variables. The KM resets the threshold configuration variables to their default values when such variables do not exist.
The “Thresholds Mechanism Selection” KM Command configures the location of the default alert thresholds configuration variables that are set during the first initialization of the KM: either in the /AS or in the /___tuning___ configuration tree. It is recommended to leave this setting to “Automatic” to make sure the thresholds configuration variables are stored in the proper location and avoid instability in the threshold settings.

noteDuring the upgrade from an earlier version, the KM will remove all of the instance-specific thresholds configuration variables. These numerous identical instance-specific thresholds are replaced with global thresholds at the class level. Thresholds that had been manually customized through the KM interface remain in place.

Java Settings

The product can now be installed with an optional embedded Java Runtime Environment, thus preventing failures of the KM when a compatible version of Java could not be found.
The KM now properly avoids Java Runtime Environment instances that predates version 1.5.00
The automatic detection of a suitable JRE has been modified to optimize its utilization throughout the KM.
A username and a password can now be specified to execute java instead of using the PATROL default account.

Fixed Issues

Alert could not be acknowledged on the FailureCount and DefermentCount parameters of the SnapMirror and SnapVault classes.
The %{FILER_LABEL}, %{FILER_ID}, %{PARENT_LABEL}, and %{PARENT_ID} macros were not functioning in Alert Actions.
The FreeSpace parameter sometimes returned negative values when monitoring aggregates and volumes
Traffic Reports were not generated if at least one of the selected parameters was offline.
The formula used to calculate the value of the Lag parameter was erroneous.
Some application classes require a NetApp active license to be properly activated in the KM. The KM would not identify these licenses during the discovery process of the filers and thus would not activate license-specific classes such as snapvault, snapmirror, etc.
On version 9.0.00 of the PATROL Agent on Windows systems with the default account configured with a domain account, "Invalid username/password" error messages were displayed in the System Output Windows of the PATROL Console.

Known Issue

During its first discovery after an upgrade, the KM may take a long time to migrate the thresholds in the agent configuration.