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:
For a prototype PATROL KM that proves the KM design, create the following PATROL KM components:
PATROL KM Prototype Components
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.
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.
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.
Prototype PATROL KM task flow
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
Menus to execute OS and PSL commands.
To enable users to perform actions on monitored application instances.
Attributes of a monitored application.
To provide information about the monitored application. There are basic built-in InfoBox items for each
Basic PATROL KM task flow
To create an advanced PATROL KM, add the following PATROL KM components to the basic PATROL KM:
Additional advanced PATROL KM components
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.
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.
Custom event catalog for the PATROL KM
To generate specific events that the KM can trigger.
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.
Customized BMP and XPM format icons
To provide users quick visual clues to the PATROL KM's monitored applications.
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
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%|
|UNIX ®||$ PATROL_HOME|
|User||User-owned error logs, session information, and custom PSL scripts stored for each PATROL Console user account||Windows||%HOMEDRIVE%%HOMEPATH%|
|Event Manager locks||Event Manager lock files for all PATROL products running on a host||Windows||% PATROL_HOME%\log|
In developing PATROL KMs, consider the following to minimize the load that your PATROL KM places on system resources.
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.
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.