PatrolCli - Part 1: Introduction

PatrolCli is a command-line program based on PATROL API and it runs on all PATROL agent platforms to provide access to the functions of a PATROL agent.

Unlike ProactiveNet Cli that you use to manage ProactiveNet every day, PatrolCli is not used in a standard PATROL/BPPM operation environment.  That is why many people are not even aware of its existence.  However PatrolCli is a powerful utility.  Understanding when and how to use it can save you time, lower your operations cost, and make your life a lot easier.

You can use PatrolCli to:

1. Access PATROL agents on all platforms.
2. Read PATROL objects from a PATROL agent.
3. Operate on PATROL events.
4. Execute PSL scripts.

In the next few posts, we will go through some examples on how to take advantage of PatrolCli.

PatrolCli is an executable program located at $PATROL_HOME/bin/ directory.  It is installed automatically with PATROL agent installation. You can use PatrolCli to access another PATROL agent in your network without a PATROL console.

Before you start PatrolCli, you need to set up your environment.  On Windows, you need to set up environment variable %PATROL_HOME%.  On UNIX, run '. ./patrolrc.sh' for korn shell or 'source .patrolrc' for C shell.

Here is an example on how to run PatrolCli interactively:

Myserver> PatrolCli
PCli% open RemoteServer 3181

Username: patrol

Password:

PCli% help

Here 'RemoteServer' is the host name of another server with PATROL agent running on port 3181.  When you type 'help' in PatrolCli, it will display all valid commands you can use in PatrolCli.  They include user, connect, open, list, listvars, get, getvar, event, echo, execpsl, help, source, ping, patrol, !!, exit, quit. '!!' command allows you to repeat the last command.  'exit' command will exit PatrolCli.  For each command, you can get more information by typing help followed by that command.  For example, 'help get' will give you more information on get command.

Here is an example on how you can use 'get' command in PatrolCli to display a parameter value (99.904922) and state (OK) without a PATROL console:

PCli% get /NT_CACHE/NT_CACHE/CACcachCopyReadHitsPercent
Mon Aug 25 23:42:58 2014
-1
0
99.904922
OK
3
0
0
100

PATROL Agent 9.5 - Part 7: How to configure a PATROL recovery action to run as a different user?

The information included in this post applies to all versions of PATROL agent, not just version 9.5. 

By default, if you configure a PATROL recovery action to run when a parameter is in ALARM or WARNING state, the recovery action script will be executed by PATROL default account.  What if you want to execute some commands within the recovery action script as a different account?  For example, what if you want to start SQL*Net listener within your recovery action as account 'oracle' instead of 'patrol'?

There is a PSL built-in function called execute.  Its format looks like this:

execute(type, text, [instance], [username], [password]);

For example, you can add the following PSL statement in your recovery action to start the SQL*Net listener automatically when the SQL*Net listener status parameter is in ALARM state:

execute("OS", "lsnrctl start", "", "oracle", "password");

where "password" can be either a clear text or an encrypted password.

To protect the password, you can encrypt it offline.  Then save the encrypted password in a pconfig variable.  Prior to call execute() command, you simply use command get ([variable_name]) to read the password out.

For example, if you have saved your oracle encrypted password in a pconfig variable called "/ORACLE/Encrypted_Password", you can include the following commands in your recovery action PSL script to automatically start SQL*Net when it is down.

pass = get("/ORACLE/Encrypted_Password");
execute("OS", "lsnrctl start", "", "oracle", pass); 

The reason you can use get("/ORACLE/Encrypted_Password") instead pconfig(GET,  "/ORACLE/Encrypted_Password") is because all pconfig variables are loaded into agent name space during PATROL agent start-up.

PATROL Agent 9.5 - Part 6: Do I still need PATROL Event Management KM?

You have heard from BMC for a while that PATROL Event Management KM is being phased out.  You wonder if you still need to run PATROL Event Management KM with PATROL Agent 9.5.

What does PATROL Event Management KM do?  Here are five features offered by PATROL Event Management KM:

1) Check if a server is up and if PATROL agent is up through its AS_AVAILABILITY KM;
2) Manage event generation and format through PATROL console or pconfig variable editing with or without PATROL Notification Server;
3) Set parameter thresholds through PATROL console or pconfig variable editing;
4) Turn off certain parameters through PATROL console or pconfig variable editing;
5) Add recovery actions through PATROL console or pconfig variable editing.

In PATROL agent version 9.5, the above feature 1) is replaced by automatically generated  MC_CELL_HEARTBEAT_FAILURE and MC_CELL_HEARTBEAT_ON events in BPPM cell.  When a server or PATROL agent goes down, you will automatically receive a MC_CELL_HEARTBEAT_FAILURE event.  You no longer need AS_AVAILABILITY KM.

In PATROL agent version 9.5, the above feature 2) is replaced by a set of pconfig variables starting with /EventSetup and /EventRules.  These pconfig variables provide many different ways to control and format the events from PATROL agents.  You no longer need PATROL Notification Server or use PATROL Event Management KM to control and format your events.

In PATROL agent version 9.5, the above feature 3) is replace by "Agent Threshold Configuration" section of CMA (Central Monitoring Administration).  You no longer need to use PATROL Event Management KM to set parameter thresholds.

In PATROL agent version 9.5, the above feature 4) is partially replaced by "Monitoring Configuration" of CMA when you want to turn off the data collection for the entire monitoring type (application class).  However if you only want to turn off certain parameters in an application class, you still need to use PATROL Event Management KM.

In PATROL agent version 9.5, the above feature 5) still cannot be replaced by anything else.  If you want to add a recovery action in PATROL agent without modifying the KM source code, you still need to use PATROL Event Management KM.

In summary, whether or not you can drop PATROL Event Management KM from your PATROL agent 9.5 configuration depends on if you need to turn off individual parameters and if you need to add your own recovery actions.

PATROL Agent 9.5 - Part 5: Data and event filtering

In BPPM 9.5, you can add 'Filtering Configuration' in a monitoring policy using CMA (Central Monitoring Administration).  Would this feature replace the old way you used to configure data and event filtering?

The short answer is no though you can use CMA to enhance the old way as described at the end of this post.  The 'Filtering Configuration' section in a CMA policy controls if data and events will be streamed to BPPM server or not. There are four options:

• No Filtering - the default (send all data and events)
• Filter out data (send no data, send all events)
• Filter out events (send no events, send all data)
• Filter out data and events (send no data, send no events) 

Even you select 'Filter out data and events', all data and events will still be sent to BPPM server on demand. They are just not sent as streamed.

Then how to stop sending data and events to BPPM server?  Let's take a closer look.

1) Filtering on parameter data

For data you don't need, you don't want the data being collected by PATROL KM at the first place so that you can reduce PATROL agent footprint and resource consumption.  Since CMA only allows you to control at monitoring type (application class) level, you still need to use Event Management KM to control at parameter level.  For example, if you don't want to see parameter CACcachCopyReadsPerSec, your pconfig variable settings would look like this:

"/AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/NT_CACHC/NT_CACHE/CACcachCopyReadsPerSec" = { REPLACE = "0,0 0 0 0 0 0,0 0 0 0 0 0,0 0 0 0 0 0" }

2) Filtering on event forwarding

For events you are not interested such as information and login events, you don't want those events being forwarded to a BPPM integration service or cell. You need to create some pconfig variable settings to activate and deactivate event types.  For example, if you only want to forward type 11 events (value of parameter is in alarm zone) and Notify Events, your pconfig variable settings would look like this:

/EventSetup/Format/BiiP3/catalogs/0/active = { REPLACE = "0"},
/EventSetup/Format/BiiP3/catalogs/0/types/11/active = { REPLACE = "1"},
/EventSetup/Format/BiiP3/catalogs/0/types/11/KM/AS_EVENTSPRING/active = { REPLACE = "0"},
/EventSetup/Format/BiiP3/catalogs/AS_EVENTSPRING/types/NOTIFY_EVENT/active = { REPLACE = "1"}

In the old way, you would save the pconfig settings for the above two cases in PCM (PATROL Configuration Manager) and push them manually to each PATROL agent they apply.  With CMA of BPPM 9.5, you can continue using PCM, or you can save them in 'Configuration Variables' section of a CMA policy so that they will automatically apply to all PATROL agents with matching tags.