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

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


Was this page helpful? Yes No Submitting... Thank you
  • No labels
© Copyright 2013 - 2014 BMC Software, Inc.
Legal notices