Child pages
    • Developing a PATROL Knowledge Module
    Skip to end of metadata
    Go to start of metadata

    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



    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


    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



    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



    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


    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


    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

    DirectoryContentOperating systemDirectory name
    InstallationBinaries, knowledge, sounds, images, application defaults, help, utilities, and parameter historiesWindows% PATROL_HOME%
    UserUser-owned error logs, session information, and custom PSL scripts stored for each PATROL Console user accountWindows%HOMEDRIVE%%HOMEPATH%
    Event Manager locksEvent Manager lock files for all PATROL products running on a hostWindows% 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.

    • No labels