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
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
Basic PATROL KM task flow - Add features to build a basic PATROL KM
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
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% |
UNIX ® | $ PATROL_HOME | ||
User | User-owned error logs, session information, and custom PSL scripts stored for each PATROL Console user account | Windows | %HOMEDRIVE%%HOMEPATH% |
UNIX | $HOME/patrol | ||
Event Manager locks | Event Manager lock files for all PATROL products running on a host | Windows | % PATROL_HOME%\log |
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.