Operational requirements

This section presents the following topics: 

Create one application class per KM file

A KM file must contain only one application class.

Do not require a Developer Console

The KM must not require a Developer Console connection for configuration. For more information about best practices for KM configuration, see Packaging KMs for PATROL Agents.

Support multiple application instances

The KM must support multiple instances or state in the product documentation that it does not support multiple instances of an application.

With multiple instances of an application, the KM maintains a different session for each instance of an application. For more information about multiple application classes, see Managing multiple application instances.

Limit the number of discovered instances

When it is realistic that the KM discovers a large number of instances of an application it is monitoring, the KM must provide a method for limiting the number of instance icons that are displayed.

For more information about ways to limit the number of instances, see Reducing the number of discovered instances.

Limit cumulative data

If the KM generates more than 20 MB of cumulative data files per week, the KM must either include an automated clean-up mechanism (unless implemented as a circular file) or document this information in the product documentation.

The PATROL history and event repository are implemented as circular files; these files are exempt from this requirement. This requirement only applies if you are storing data somewhere else.

Clean-up and close channels

If the KM supports multiple channels, it must clean up and close channels properly.

Store configuration data in the Agent database

The KM must store KM configuration settings and information in the PATROL Agent configuration database, usually done with pconfig(). For more information about storing KM information in the PATROL Agent configuration database, see Storing KM configuration information.

Store KM configuration in unique pconfig branch

The KM must create its configuration variables in the PATROL Agent configuration database under a unique pconfig branch.

Create unique configuration variables

The KM must create its configuration variables in the PATROL Agent configuration database using a unique name.

For more information about storing KM information in the PATROL Agent configuration database, see Storing KM configuration information.

Notify the user of Agent reinitialization

The KM must notify the user if the KM must reinitialized the agent.

Enable KM with metadata

KM metadata represents the set of characteristics of a KM and its parameters. With version 9.0.00 of PATROL Agent, you can specify the metadata for a KM by using version 3.5.92 of the PATROL Developer console. Version 3.5.92 of the PATROL Developer console now supports writing an XML file for your KM that contains metadata for application classes, parameters, as well as configuration information, if any. For more information about defining the metadata, see the Building a PATROL Knowledge Module Developers Guide.

With BMC ProactiveNet version 8.5.00 or later, a KM must be enabled with metadata which provides valuable information to BMC ProactiveNet for probable cause analysis.

For example, for a KM, the MetaKMCategory metadata attribute denotes the category of monitor type (such as SYSTEM, DATABASE, and NETWORK). A KM that provides its category information through metadata enables BMC ProactiveNet to determine a suitable heuristic methodology based on its category. Similarly, for a parameter, the metadata attributes (such as Key Performance Indicator and Availability) enable the analytics engine to determine the nature and type of the parameter and adopt the appropriate probable cause analysis methods.

If a KM is not enabled with metadata, KM is imported into BMC ProactiveNet and adapter defaults are used to fetch the metadata for the probable cause analysis. If the adapter defaults are not available for the KM, BMC ProactiveNet generates the default metadata for the KM for the probable cause analysis. However, in these cases, the analysis is not as efficient as when a KM is enabled with metadata.

Enabling KMs with metadata has the following advantages:

• When a later version of KMs is available, the PATROL adapter and Integration Service combination provides the latest metadata for the later version of the KM to have the new KM definition available in BMC ProactiveNet. All the baselines and historical data for the old monitor type are retained while new data is getting imported after the upgrade.
• For updated KMs, you do not need to install the new adapter defaults on the BMC ProactiveNet.
• For customized KMs, you do not need to construct the adapter defaults files manually and keep them in sync with the KM by updating the BMC ProactiveNet server.

For information about metadata specifications, see the Building a PATROL Knowledge Module Developers Guide.

Use a common JRE for your KM

With version 9.0.00 of PATROL Agent, a common JRE (Java Runtime Environment) package is shipped, to be used by all the PATROL KMs.

If you want to use a JRE package other than the one shipped with the PATROL Agent, you must set up the JAVA_HOME pconfig variable at the KM level and define the correct Java path.

For more information on creating a rule for setting the pconfig variable, see the PATROL Configuration Manager User Guide.

Specify KM configuration metadata

With version 9.0.00 of PATROL Agent and version 9.0.00 of BMC ProactiveNet, you have the capability of configuring KMs by using the BMC ProactiveNet Central Monitoring Administration console. To be able to configure KMs using this console, you must specify the input metadata which is used for generating the user interface for KM configuration. You can specify the input metadata by creating the KM specific XML file and deploying it in the Central Monitoring repository.

For more information about specifying the meta data, see the Building a PATROL Knowledge Module Developers Guide.