Developing a PATROL Knowledge Module

This section provides an overview of PATROL Knowledge Module development and describes a general approach to building a PATROL KM.

You can build a PATROL KM in several stages. This section describes how to develop a PATROL KM progressively in the following stages:

Building a prototype PATROL KM

For a prototype PATROL KM that proves the KM design, create the following PATROL KM components:

PATROL KM Prototype Components

Component name	Description	Purpose	Refer to
Application class	The framework and logic required to monitor and manage instances of the application class.	To define the methods by which instances of the application class are detected, monitored, and managed.	Defining application classes
Discovery (Pre-Discovery)	The logic that determines whether any application instances exist on the monitored machine and instantiates them.	To determine whether any application instances exist on the monitored machine and to instantiate them. If pre-discovery fails, the rest of the PATROL KM is not loaded, saving memory and CPU resources.	Setting up application discovery
Parameters	A scheduled procedure that obtains data about a monitored object.	To indicate the current status of various attributes of an application instance. Without defined alarm ranges, a parameter cannot indicate problems. You can define both warning and alarm ranges.	Creating parameters

Prototype PATROL KM task flow

Building a basic PATROL KM

To create a basic PATROL KM that provides monitoring and limited management, add the following PATROL KM components to the prototype KM:

Additional basic PATROL KM components

Component name	Description	Purpose	Refer to
Menu Items	Menus to execute OS and PSL commands.	To enable users to perform actions on monitored application instances.	Creating Menus
InfoBox Items	Attributes of a monitored application.	To provide information about the monitored application. There are basic built-in InfoBox items for each defined application. However, you can add information such as version information.	Creating InfoBoxes

Basic PATROL KM task flow

Building an Advanced PATROL KM

To create an advanced PATROL KM, add the following PATROL KM components to the basic PATROL KM:

Additional advanced PATROL KM components

Component name	Description	Purpose	Refer to
Type of Command	A definition of the command interpreter that you want to use in KM development	To provide alternative interpreted programming languages to use in coding PATROL KM logic.	See the Advanced PATROL Knowledge Module Development Online documentation.
Recovery Actions	Corrective actions to be taken when a parameter's value indicates an abnormal condition.	To correct the underlying problem indicated by the parameter's value. The simplest form of a recovery action is to execute a task that produces a textual report about the problem.	Recovery Actions
Event Classes	Custom event catalog for the PATROL KM	To generate specific events that the KM can trigger.	Defining PATROL KM event classes
Environment Variables	External environment variables for use by PATROL KM child processes (for example, PATH or ORACLE_SID)	To set up external variables in the PATROL KM framework.	Parameter environment variable properties
Icons	Customized BMP and XPM format icons	To provide users quick visual clues to the PATROL KM's monitored applications.	Requirements and guidelines for creating PATROL KM icons
Help	Online information about the product its features	To provide the user with valuable information on how to use the product and how the product works.	Advanced PATROL Knowledge Module Development Online documentation.

Advanced PATROL KM task flow

PATROL product file structure and physical layout

The PATROL product uses three main directories to store information.

PATROL product directories

Directory	Content	Operating system	Directory name
Installation	Binaries, knowledge, sounds, images, application defaults, help, utilities, and parameter histories	Windows	*% PATROL_HOME%*
Installation		UNIX ^®	$ PATROL_HOME
User	User-owned error logs, session information, and custom PSL scripts stored for each PATROL Console user account	Windows	%HOMEDRIVE%%HOMEPATH%
User		UNIX	$HOME/patrol
Event Manager locks	Event Manager lock files for all PATROL products running on a host	Windows	*% PATROL_HOME%\log*
Event Manager locks		UNIX	*$ PATROL_HOME/log*

PATROL KM system load considerations

In developing PATROL KMs, consider the following to minimize the load that your PATROL KM places on system resources.

PATROL Agent load

Consider using the following strategy to minimize the load that your PATROL KM places on the PATROL Agent resources:
The resource consumption of the PATROL Agent is directly related to the number of parameters and their scheduling interval.
In general, parameter scheduling should be as infrequent as is practical to provide valid information for given parameter or collector. In general, PATROL KMs should balance the overhead of obtaining the parameter data against the benefits the data can provide.

Measuring PATROL Agent resource consumption

Consider using PATROL profiling to determine the overhead the KM generates on the system. For information about PATROL profiling, see the Advanced PATROL Knowledge Module Development Reference Manual. Also, observe the number of short-lived child processes that the KM launches. Using various development techniques, you can limit the number of child processes that are launched.

Page tree