Skip navigation
Share This:

BMC PATROL uses variables in the BMC PATROL configuration database to store information about exclusion and inclusion lists. The two variables are

 

>> /PatrolAgentSetup/application.filterList - contains the list of instances to include or exclude depending upon the value of application.filterType

 

The format is a comma-separated list of instances or regular expressions. The variable has a limit of 1024 characters. Regular Expressions can be used to alleviate this limitation. The belo error is generated when a filter exceeds the maximum size allowed for an PatrolAgent configuration variable.:

------------

Exclusion list too long. Please use regular expression exclusion.

------------

 

>> /PatrolAgentSetup/application.filterType - determines whether the list is an exclusion or inclusion If application.filterType does not exist, the list defaults to exclude. Valid values are:

 

- exclude

- include

 

The exclusion list feature is designed for ignoring a small number of instances. If you want BMC PATROL to ignore a majority of instances, you can create an inclusion list, which forces BMC PATROL to ignore all but the instances that you specify. However, monitoring by inclusion has a few limitations.

 

Benefits of Creating Exclusion Lists Using Menu Commands:

BMC Software recommends that you use the menu options Stop Monitoring and Edit <application> Exclusion List to exclude application instances. These menu options are accessed from the pop-up menu of the instances.

 

The menu commands add two entries into the /PatrolAgentSetup/application.filterList for each instance excluded.

 

To accomplish monitoring of all application classes in local monitoring and selected application classes in remote monitoring, let's first understand the way Unix KM creates instances of each application class.

 

For local monitoring, in case of single instance application classes like CPU, MEMORY, KERNEL, km creates instances with those names.

 

Eg. PatrolAgent with only local monitoring would create CPU instance with name CPU.

 

When remote monitoring is configured, KM creates CPU instance for remotely monitored host as CPU@<remote host name>, similarly for KERNEL it would create KERNEL instance with name KERNEL@<remote host name>

 

 

PATROL PatrolAgent provides instance filtering functionality which can be configured by adding pconfig variable with key

/PatrolAgentSetup/<APPLICATION_CLASS>.filterList and  instance name as value.

 

Thus, to enable CPU monitoring in local and exclude the same in remote, add variable

Key - /PatrolAgentSetup/CPU.filterList

Value - CPU@.*

 

For unix, it is CPU@.*

For Windows it is *.@CPU

 

In case of application class which has multiple instances like NETWORK/DISK/SWAP, km creates instances under corresponding containers with <Instance Name>@<remote host name>

 

Eg. For host pl-pun-pat-qa01, eth0 instance of NETWORK application class will get created as eth0@ pl-pun-pat-qa01

 

To avoid instance creation, appropriate regex should be used or comma separated list of instances can be added in /PatrolAgentSetup/NETWORK.filterList

 

Also, you can suspend a application class from event management KM. I would like to inform you that EM KM is a default KM and you just need to load it. If possible reload it and follow the steps given below:

 

To deactivate the application class permanently, you can use EM km.

 

>> Right Click on Agent

>> KM Commands

>> Event Management

>> Instance Filtering

>> Select application class

>> Select the proper Application Class (Remot_cont in case of remote monitoring)

 

The first check box needs to be unchecked in case you do not want the parameter to be active.

 

There is no GUI option from CMA to create a filtering policy for REMOT KM to filter out remote application classes. We can create below ruleset to filter CPU application class remote machine.

 

Ruleset:

"/AgentSetup/CPU.filterList" = { REPLACE = "CPU@137\\.72\\.245\\.223" }

 

The default filter type is exclude and here, the host ip is: 137.72.245.223

 

If we want to exclude CPU monitoring for all remote systems, we can apply below:

 

"/AgentSetup/CPU.filterList" = { REPLACE = "CPU@*" }

 

Similar way, we can do for rest of the application classes.

 

Apart from disabling some application classes using filterList,  as a best practice, all the related collectors must be disabled.

 

To disable collector parameters in remote monitoring, add following rules in agent configuration (Event Management KM must be loaded )

 

Eg. To disable SMPColl

Key - /AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/COLLECTORS/COLLECTORS@{re:*}/SMPColl

Value - 0,0 0 0 0 0 0,0 0 0 0 0 0,0 0 0 0 0 0

 

Key - /AS/EVENTSPRING/processWildcards

Value - 1

 

We can disable Service monitoring for all services on PatrolAgent machine using below variable:

 

"/PSX__P4WinSrvs/PWK__PKMforMSWinOS_config/ServiceMonitoring/DisableServiceMonitoring" = { REPLACE = "1" },

 

where, 1 = do not monitor; 0 = monitor all services

 

And then we can enable monitoring of selected services using below variables:

"/PSX__P4WinSrvs/PWK__PKMforMSWinOS_config/ServiceMonitoring/ServiceList/CryptSvc/OverrideGlobalServiceMonitoring" = { REPLACE = "1" },

"/PSX__P4WinSrvs/PWK__PKMforMSWinOS_config/ServiceMonitoring/ServiceList/CryptSvc/SvcConfigVars" = { REPLACE = "0,0,1,0,1,1,0,0,0" },

 

The information is available at below URL:

 

https://docs.bmc.com/docs/display/public/mswindows47/PATROL+KM+for+Microsoft+Windows+OS+configuration+variables

 

We can disable Service monitoring for all services on PatrolAgent machine using below variable:

 

"/PSX__P4WinSrvs/PWK__PKMforMSWinOS_config/ServiceMonitoring/DisableServiceMonitoring" = { REPLACE = "1" },

 

where, 1 = do not monitor; 0 = monitor all services

 

And then we can enable monitoring of selected services using below variables:

"/PSX__P4WinSrvs/PWK__PKMforMSWinOS_config/ServiceMonitoring/ServiceList/<service-name>/OverrideGlobalServiceMonitoring" = { REPLACE = "1" },

"/PSX__P4WinSrvs/PWK__PKMforMSWinOS_config/ServiceMonitoring/ServiceList/<service-name>/SvcConfigVars" = { REPLACE = "0,0,1,0,1,1,0,0,0" },

 

We can disable Service monitoring for all services on remote machine using below variable:

"/REMOTE/HOSTS/<ReplaceThisWithRemoteHostname>/PSX/PSX__P4WinSrvs/PWK__PKMforMSWinOS_config/ServiceMonitoring/DisableServiceMonitoring" = { REPLACE = "1" },

 

And then we can enable monitoring of selected services using below variables:

"/REMOTE/HOSTS/<ReplaceThisWithHostname>/PSX/PSX__P4WinSrvs/PWK__PKMforMSWinOS_config/ServiceMonitoring/ServiceList/OverrideGlobalServiceMonitoring" = { REPLACE = "1" },

"/REMOTE/HOSTS/<ReplaceThisWithHostname>/PSX/PSX__P4WinSrvs/PWK__PKMforMSWinOS_config/ServiceMonitoring/ServiceList/<service-name>/SvcConfigVars" = { REPLACE = "0,0,1,0,1,1,0,0,0" },

Share This:
  • The PATROL Agent (version 3.2 and higher) will run as the "patrol" account as opposed to the "root" account as it did with PATROL version 3.1.9.  The PATROL Agent binary has "setuid" on it so that it will switch to the "root" account as necessary during execution of instructions, which require the ability to "su" to other accounts for processing commands or instructions. 

 

  • This applies to most all of the platforms supported by PATROL. There are a few exceptions where the PATROL Agent process is owned by the "root" account exclusively. 

 

  • The PatrolAgent binary will allow someone to start it if they belong to the group of the executable.

 

  • Once the PatrolAgent process is started it assumes the user of the setuid value. In this case it is root. The process runs as root, but inside the agent is running as the default account.

 

  • Information from AIX man pages describing inheritance of process id 1 and changing from originating process id to actual root:

 

  • The setuid system call sets the real user ID, effective user ID, and saved user ID of the calling process.  The setgid system call sets the real group ID, effective group ID, and saved group ID of the calling process.

 

  • At login time, the real user ID, effective user ID, and saved user ID of the login process are set to the login ID of the user responsible for the creation of the process.  The same is true for the real, effective, and saved group IDs; they are set to the group ID of the user responsible for the creation of the process.

 

  • When a process calls exec(2) to execute a file (program), the user and/or group identifiers associated with the process can change.  If the file executed is a set-user-ID file, the effective and saved user IDs of the process are set to the owner of the file executed.  If the file executed is a set-group-ID file, the effective and saved group IDs of the process are set to the group of the file executed. If the file executed is not a set-user-ID or set-group-ID file, the effective user ID, saved user ID, effective group ID, and saved group ID are not changed.

 

  • One of the reasons why the Patrol Agent runs as root on a Unix/Linux server is because it is set to run at a lower priority than other processes on the system. This is called the "nice" value in Unix.

 

"nice" sets the priority of a process on the system.

 

  • The average nice value of a process on a Unix / Linux system is 20. The Patrol Agent process starts running at this value and and then adds "10" to this value.  The Patrol Agent default configuration has a rule:

 

/AgentSetup/AgentTuning/agentPriority = { REPLACE="10" },

 

  • This rule sets the default  priority of "10" over the average nice value. Hence the patrolagent runs with the nice value of "30". Now if  the Patrol Agent is competing against many applications that run lower than / equal to a nice value of 20, the agent may never get a chance over the other processes to execute. So the Patrol Agent is unable to switch from the "root" account to the Patrol default account and it continues running as "root"

 

To resolve this problem make the value of "AgentSetup/AgentTuning/agentPriority" as 0.

 

" /AgentSetup/AgentTuning/agentPriority = { REPLACE="0" },"

 

  • When we do this the agent will run at the nice value of 20 and can get the priority to execute normally.

 

There will not be any performance impact on the server as "20" is considered as a acceptable nice value for the processes on the UNIX/Linux systems.

 

  • The PatrolAgent binary from $PATROL_HOME/bin should be owned by root but the PatrolAgent file from Patrol3 directory should not be owned by root user.
Share This:

We can use event_trigger() and event_trigger2() to trigger events specific to your application, events specific to your KM, or user events.

 

  • event_trigger()
  • event_trigger2()

 

Explaination:

In the custom event catalog "MY_KM", event class "MyClass" defines a description template as:

 

"On host HOSTNAME}%, at time %{TIME}%, alert on '%s' from %s parameter '%s' cancelled; exception no longer exists.".

 

In this example, 3 formal string arguments are

 

“alert on '%s' from %s parameter '%s' cancelled; exception no longer exists."

 

And the two Agent-macros are

 

“%{HOSTNAME}%” and “%{TIME}%”.

 

You must specify the 3 actual arguments for publishing time as:

event_trigger("MY_KM","MyClass","ALARM","3","arg1","arg2", "arg3");

 

# actual argument to the event

 

The resulting event description will be

 

"On host maxpc, at time 18:48:30, alert on '%s' from %s parameter '%s' cancelled; exception no longer exists."

 

Note that the event trigger does not pass an actual argument to expand the Agent macros. The Agent does it automatically.

 

%{EVENT_CATALOG}%           Event catalog name of originating event (example, 0)

%{EVENT_CLASS}%              Event class name of originating event (example, 11)

%{EVENT_ID}%                   Event Manager's Event Id for the alert (example, 8765)

%{EVENT_SEVERITY}%          Event severity of originating event (example, 4)

%{EVENT_STATUS}%             Event status of originating event (example, OPEN)

%{EVENT_TYPE}%               Event type of originating event (example, ALARM)

 

Do not use the event_trigger function for event messages:

The KM must not use the event_trigger or event_trigger2 functions to generate events that are implicitly generated by PATROL. The KM must rely on the PATROL Agent to generate events when alarm ranges are exceeded.

 

How PATROL events are triggered:

PATROL events are triggered automatically whenever an state change occurs. PATROL events also can be triggered explicitly by the PSL event_trigger() and event_trigger2() functions. These functions allow you to trigger an event of a specific event class, assign a severity to it, and perform event-driven processing through the event Notification command.

 

Triggering an Event:

Any event that has been defined and stored in an event catalog can be triggered by one of the following methods.

  1. 1. Using the PSL event_trigger function
  2. 2. Manually from the PEM Console
  3. 3. From the PEM Application Programming Interface (API)

 

 

Event severity:

Although severity is not an event class property, an event instance can have a severity value to indicate how serious the event is. Event severity can be assigned to an event through the PSL event_trigger() and event_trigger2() functions. Event severity can be an integer value between 1 and 5, with a value of 5 indicating the most serious events. Event severity is used as a filter to limit the events that display in an event management console to only those of equal or greater severity than the specified filter.

 

event_trigger() Creates a PATROL event of the specified event class. The implicit origin of the event instance is the PSL context under which the event_trigger()function executed. The event will appear in the PEM. Use this function to develop event reporting within a PATROL KM.

 

event_trigger2() Creates a PATROL event of the specified event class. The origin of the event instance is explicitly set by the origin parameter which can be a specific application class or application instance.

 

Type defines the default event type as

  • ANY
  • Information
  • State_Change
  • Error
  • Warning
  • Alarm
  • RESPONSE

 

Description:

specifies the summary description (including runtime arguments) that is displayed in the PEM window when an event occurs The event description can contain as many as 20 dynamic arguments written as %S. The actual value of these arguments is determined when the event is triggered.

 

Example:

in Event Catalog: “Configuration error in application %s”

 

Line of script that triggers the event from PSL:

-------------

event_trigger (PemDemo, everr, ERROR, 4, my_app);

-------------

 

Resulting message displayed in the PEM window:

-------------

Configuration error in application my_app

-------------

 

 

  • event_trigger("MyApp","MyAlarmEvent","ALARM","5","Warning situation generating alarm condition");

 

  • event_trigger("STD", "41", "INFORMATION", "3", "testing add diary");

 

  • event_trigger("0", "41", "INFORMATION", 9, "Attempt to set preloadedKMs by ".from);

 

 

event_trigger() - Create an event instance for the PATROL Event Manager

 

Format:

event_trigger(catalog,class,type,severity,[argument1,...,argument20])

 

Parameters:

 

  1. 1) catalog - character string name of the PATROL catalog to which the event belongs

To specify the PATROL standard event catalog, use one of following values:

  • STANDARD
  • STD
  • 0

 

  1. 2) class character string name of the event in the class to which the event belongs

 

  1. 3) type event type as displayed in the PATROL Event Manager

Valid Values

  • ALARM
  • WARNING
  • ERROR
  • CHANGE_STATUS
  • INFORMATION

 

  1. 4) severity integer value indicating the severity of the event

Valid Values

  • 0–5 (5 is most severe)

 

A severity of 0 will send an event to the PATROL Agent, but the event will not appear in the PATROL Event Manager.

 

 

  1. 5) argumentn arguments passed to the PATROL Event Manager and displayed in the event detailed report. This function permits a maximum of 20 arguments.

 

Note: Avoid using the \" characters in this argument. In some cases, using these characters in this argument can cause a command to fail if the command also uses the EV_DESC and EV_ARGS macros.

 

Description:

 

The event_trigger() function creates an event instance that appears in the PATROL Event Manager. The origin of the event instance is the PSL context under which the event_trigger() function executes. The event_trigger() function assumes that the event catalog and class are already defined. The event_trigger() and event_trigger2() functions are identical except how they identify the event origin:

 

  • The event_trigger() function always sets the origin to the context in which it
  1. executes.
    • The event_trigger2() function allows you to specify an origin.

 

The event_trigger() function can be used to develop event reporting within PATROL Knowledge Modules. The return value of this function is the event ID of the event that was created, followed by a vertical bar (|), followed by the timestamp expressed as seconds since 00:00:00 GMT January 1, 1970. The event ID appears in the PATROL Event Manager.

 

Example:

The following is an example of the event_trigger() function:

 

event_trigger(

"STD",            # event catalog : STANDARD

"41",             # event class: 41

"INFORMATION",    # event type: INFORMATION

"3",              # severity: 3

"myarg"           # one dynamic argument

);

 

When entered at the System Output window, this statement displays the event ID of the event that is created by this function. The event ID appears in the PATROL Event Manager.

 

%PSL print(event_trigger("STD","41","INFORMATION","3", "myarg");

 

event_trigger2():

Create an event instance with a specific origin for the PATROL Event Manager

 

Format:

event_trigger2(origin,catalog,class,type,severity, [argument1,...,argument20])

 

 

 

 

Parameters:

 

  1. 1) origin character string indicating the application instance or class that originated the event

 

  1. 2) catalog character string name of the PATROL catalog to which the event belongs

To specify the PATROL standard event catalog, use one of following values:

  • STANDARD
  • STD
  • 0

 

  1. 3) class character string name of the event in the class to which the event belongs

 

  1. 4) type event type as displayed in the PATROL Event Manager

Valid Values

  • ALARM
  • WARNING
  • ERROR
  • CHANGE_STATUS
  • INFORMATION

 

  1. 5) severity integer value indicating the severity of the event Valid Values
  • 0–5 (5 is most severe)

A severity of 0 will send an event to the PATROL Agent, but the event will not appear in the PATROL Event Manager.

 

  1. 6) argumentn arguments passed to the PATROL Event Manager and displayed in the event detailed report. This function permits a maximum of 20 arguments.

 

Note: Avoid using the \" characters in this argument. In some cases, using these characters in this argument can cause a command to fail if the command also uses the EV_DESC and EV_ARGS macros.

 

Description

The event_trigger2() function creates an event instance that appears in the PATROL

Event Manager. The origin of the event instance is origin. The event_trigger2() function assumes that the event catalog and class are already defined. The event_trigger2() and event_trigger() functions are identical except how they identify the event origin:

 

  • The event_trigger2()
  • The event_trigger()
  1. executes.

 

The event_trigger2() function can be used to develop event reporting within PATROL

Knowledge Modules. The return value of this function is the event ID of the event that was created, followed by a vertical bar (|), followed by the timestamp expressed as seconds since 00:00:00 GMT January 1, 1970. The event ID appears in the PATROL Event Manager.

 

Example:

The following is an example of the event_trigger2() function:

 

event_trigger2(

"myorigin",       # origin: myorigin

"ORACLEx",        # event catalog: ORACLEx

"ResetCounters", # event class: ResetCounters

"ALARM",          # event type: ALARM

"3",              # severity: 3

"myarg1",         # dynamic argument 1

"myarg2"          # dynamic argument 2

);

Share This:

By default PATROL Agent Service starts as Local System Account and is the recommended one.

 

You can use the “PATROL Agent Configuration utility to configure a PATROL Agent to use a specified user account. This utility verifies that the specified user account has all the required rights as mentioned below:

 

PATROL Agent requires the following rights to operate and perform certain functions after installation. The installation automatically grants these rights to the PATROL Agent default account.

 

  • Act as part of the operating system

This user right allows a process to impersonate any user without authentication. The process can therefore gain access to the same local resources as that user.  E.g.: You need this right to access HKEY_PERFORMANCE_DATA (this is related to reading of Performance counter data).

 

This is required when process use LogonUser and ImpersonateLoggedOnUser API's. Windows OS KM uses these calls typically to execute recovery actions on automatic services that are stopped so as to restart these services. If this right is not present it will fail to impersonate the user.

 

  • Adjust memory quotas for a process

This privilege determines who can change the maximum memory that can be consumed by a process.

 

  • Log on as a service

To run a PATROL Agent as a service. Log on as a service (SeServiceLogonRight) right is required whenever a service is running as user other than Local System, Local Service and Network service account.

 

  • Replace a process level token

This security setting determines which user accounts can call the CreateProcessAsUser API so that one service can start another. New shell is spawn with this API in agent code.


"Replace a process level token" along with "Debug Programs" is use to get command line arguments for a process in case of Process KM.


Right click on Processes->KM Commands->Configure Manual Process Monitoring->Add Process

 

  • Allow log on locally

Missing this right will not allow connecting with console. Allow logon on locally (SeInteractiveLogonRight) right is required so as to discover Windows Services (NT_SERVICES) and Processes (NT_PROCESS) KM. Services KM uses OpenSCManager, OpenService etc. windows API’s to get data. We are not able to fetch data without this right.

 

  • Profile system performance

This security setting determines which users can use performance monitoring tools to monitor the performance of system processes. PATROLPerf will not work if this right is not set.

 

Profile system performance (SeSystemProfilePrivilege) is required to collect performance data using WMI. WMI wizard uses Windows Management Instrumentation to get the performance data also Process KM uses WMI to get Process list, owner and command line arguments.

 

  • Debug program

This user right determines which users can attach a debugger to any process.

 
Rights required for default PATROL account for Windows KM and the description/effect of the rights:

PATROL requires a dedicated user account, known as the PATROL Agent default account, in the windows environment. The PATROL Agent default account must exist in the Windows environment before you install PATROL. The PATROL Agent default account can be either a local or a domain account:

 

    • Stand-alone workgroup servers must use a local user account as a PATROL Agent default account.
    • Servers that are trusted members of a domain can use either a local or a domain account.
    • Domain controllers must use a PATROL Agent default account that is also a domain account.

 

  • Manage auditing and security log

This user right is required to monitor the ‘Security’ event log and must be assigned to the PATROL Agent default account. If this right is not assigned, then the NT_EVENTLOG application displays a message in the _DiscoveryStatus parameter and sends a discovery failed event to PEM at initial discovery.

Backup Event Log and Clear Event Log recovery action does not work. (Backup files and directories right is required)

 

  • Debug programs

The Terminate Process and Restart Process recovery actions do not work if the PATROL Agent default account lacks the Debug Programs right, cannot monitor the status of processes.

 

  • If the account is not present in Local/Domain Administrators group:
    • Restart Service recovery action does not execute.
    • Logical disk quotas and mount points do not work.
    • Blue Screen KM unable to detect a blue screen condition.

 

  • Read/write permissions on the temp directory

The Clean Temporary Directories recovery action does not execute.

 

  • Read /write access to %PATROL_HOME%\log and %PATROL_HOME%\tmp

It is required to read/write trace data.  Without the required access, trace information will not be available.

 

Additional rights required for Active Directory, Microsoft Cluster and Domain Services KM:

 

  • Logon as a Batch Job

This user right must be assigned to the impersonation account that is supplied by a user.  Without this user right, the product will be unable to logon as the user-supplied account and the following operation will fail with a descriptive message.

    • When used as Internal CLA in Microsoft Cluster Server KM.

Requires Admin group privileges for External CLA in Microsoft Cluster Server KM.

 

  • Allow log on locally

DFSRootReplica does not work when checking alternate domain controller for Domain Services KM.

 

  • List Folder Contents/Read Data

DSA Working Directory and its subdirectories and access to the registry key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS is required for Microsoft Active Directory KM.

 

  • Account Operators, Print Operators, or Server Operators built-in Group

Shares are not monitored. Parameters are not discovered in Domain Services KM.

 

  • DHCP Users group

On Windows 2003, the NT_DHCP application class does not work in Domain Services KM.

 

Some information available at http://documents.bmc.com/supportu/documents/33/78/443378/443378.pdf pg. no. 42

Share This:

Starting PatrolAgent version 9.0.00 onwards, we can have direct event integration with BPPM. We just need to configure PatrolAgent with below three rulesets and the moment we configured PatrolAgent with these rulesets, BPPM will start fetching events from PatrolAgent.

 

With the integration of PATROL Agent with BMC ProactiveNet Event Manager, the events generated by PATROL Agent can be propagated to BMC ProactiveNet Event Manager directly.  the PATROL Agent runs as a client for BMC ProactiveNet Event Manager and thus opens a persistent TCP connection with BMC ProactiveNet Event Manager. Specify the primary and  secondary cells to connect the PATROL Agent to the high-availability set up of BMC ProactiveNet Event Manager.

 

NOTE: It is recommended that you send PATROL Agent events to a remote cell for processing, and then propagate only select events to the BPPM Server cell.

 

--------------

"/EventSetup/Configuration/EventCells" = { REPLACE = "" },

"/EventSetup/Configuration/Format" = { REPLACE = "BiiP3" },

"/EventSetup/Configuration/Key" = { REPLACE = "" },

--------------

 

Example:

"/EventSetup/Configuration/EventCells" = { REPLACE = "clm-pun-001364.bmc.com/1828" },

>>> Here we need to specify the hostname/ip of integration service node and the port number for which ISN node configured.

"/EventSetup/Configuration/Key" = { REPLACE = "mc" },

>> key for event integratin

"/EventSetup/Configuration/Format" = { REPLACE = "BiiP3" },

>> The default event format is BiiP3.

 

You can find the information about direct event integration in BMC PATROL Agent Reference Manualon on Page 144 available at below URL:

http://documents.bmc.com/supportu/documents/31/93/443193/443193.pdf

 

and

 

http://docs.bmc.com/docs/display/public/PN90/Benefits%2Bof%2Badopting%2Bthe%2BBMC%2BPATROL%2BAgent%2Bevent%2Bintegration

 

There won’t be as such any impact on migrating to direct Integration feature apart from the fact that the BEM will have many inbound TCP connection (one for each Patrol Agent). And migration has its advantages –

  • Removed maintenance of a middleware (bii4p) adapter component
  • Bii4p (adapter base) integrations are not fault tolerant, there’s an event loss if the adapter goes down.
  • With direct integration PatrolAgent guarantees the delivery of every Event set to pass to BEM.
  • Easy setting on filtering and enrichment configuration.
  • BMC is also moving towards the limited support mode for Bii4P/mcxp adapter based integrations thus promoting customers to migration more manageable and simplified direct integration approach.
Share This:

We can apply below rule-sets to disable monitoring of required filesystems:

---------------------

"/FILESYSTEM.excludeTypes" = { REPLACE = "1111" },

"/UNIX/FILESYSTEM/NFSTokens" = { REPLACE = "NFS CACHEFS NFS3 NFSV3" },

"/UNIX/FILESYSTEM/CDFSTokens" = { REPLACE = "CDFS HSFS ISO9660 CDRFS" },

"/UNIX/FILESYSTEM/PROCTokens" = { REPLACE = "PROC USBDEVFS DEVPTS PROCFS" },

"/UNIX/FILESYSTEM/CUSTTokens" = { REPLACE = "BINFMT_MISC RPC_PIPEFS DEVPTS TMPFS" },

"/PUK/FILESYSTEM/moniList" = { DELETE = "" }

---------------------

 

We would need to restart the PatrolAgent to get the changes in effect.

 

Some more information about how it works:

 

The FILESYSTEM KM uses a 4 binary-digit flag to determine what types of filesystems to monitor. The variable /FILESYSTEM.excludeTypes is used to store this 4 binary-digit flag:-

------------------------------

1st bit controls NFS 

2nd bit controls CDROM

3rd bit controls PROC

4th bit controls custom file types

------------------------------

 

 

For example,

  1. 1000 monitors all other Filesystem Tokens but specified in NFSTokens filesystems.
  2. 1100 monitors all other Filesystem Tokens but NFSTokens and CDFSTokens filesystems.

 

 

  • The agent configuration variable "/UNIX/FILESYSTEM/NFSTokens" is used to store the "tokens" that identify NFS filesystems. By default, this variable is set to:  NFS CACHEFS NFS3 NFSV3

 

  • The agent configuration variable "/UNIX/FILESYSTEM/CDFSTokens" is used to store the "tokens" that identify CDROM filesystems. By default, this variable is set to: CDFS HSFS ISO9660 CDRFS

 

  • The agent configuration variable "/UNIX/FILESYSTEM/PROCTokens" is used to store the "tokens" that identify PROC filesystems. By default, this variable is set to: PROC USBDEVFS DEVPTS PROCFS

 

  • The agent configuration variable "/UNIX/FILESYSTEM/CUSTTokens" is used to store the "tokens" that identify "custom" filesystems defined by the user. By default, this variable is not created by default but is created when excluding custom filesystems.

 

By editing the appropriate "Token" agent configuration variable, the we can add, delete, or modify filesystem types for any of these classes. 

 

For example,

We can add "AUTOFS" to the variable defining NFS filesystem types:  "/UNIX/FILESYSTEM/NFSTokens".


This would cause the FILESYSTEM.km to treat filesystems with type=AUTOFS as an NFS filesystem, which would result in inclusion/exclusion based on NFS filesystem exclusion rule.

 

When the FILESYSTEM KM encounters filesystems that it is supposed to monitor, it creates the appropriate instances and adds the filesystem to a variable "/PUK/FILESYSTEM/moniList" which it uses for persistence between PatrolAgent startups.

 

Some more information is available in the knowledge article#KA286642 in the knowledge-base.

 

  • How we can exclude /mnt and /tmp filesystems for monitoring?

"/AgentSetup/FILESYSTEM.filterList" = { REPLACE = "mnt.*,tmp.*" },

"/AgentSetup/FILESYSTEM.filterType" = { REPLACE = "exclude" }

 

BMC PATROL uses variables in the BMC PATROL configuration database to store information about exclusion and inclusion lists. The two variables are

 

>> /AgentSetup/application.filterList—contains the list of instances to include or exclude depending upon the value of application.filterType

 

 

The format is a comma-separated list of instances or regular expressions. The variable has a limit of 1024 characters. Regular Expressions can be used to alleviate this limitation. The error:

------------

Exclusion list too long. Please use regular expressionexclusion.

------------

 

is generated when a filter exceeds the maximum size allowed for an Agent configuration variable.

 

>> /AgentSetup/application.filterType—determines whether the list is an exclusion or inclusion If application.filterType does not exist, the list defaults to exclude. Valid values are:

 

exclude

include

 

The exclusion list feature is designed for ignoring a small number of instances. If you want BMC PATROL to ignore a majority of instances, you can create an inclusion list, which forces BMC PATROL to ignore all but the instances that you specify. However, monitoring by inclusion has a few limitations.

 

  • Benefits of Creating Exclusion Lists Using Menu Commands:

BMC Software recommends that you use the menu options Stop Monitoring and Edit <application> Exclusion List to exclude application instances. These menu options are accessed from the pop-up menu of the instances.

 

The menu commands add two entries into the /AgentSetup/application.filterList for each instance excluded.

 

The first entry is in the form "pathname-instance", where slashes are replaced by dashes and the initial slash is omitted.

 

NOTE: When using xpconfig or wpconfig to create an exclusion list, add both entries (pathname-instance and /pathname/instance) for each instance that you intend to exclude.

 

For example,

-------------

mnt-hpserv-users indicates the filesystem /mnt/hpserv/users.

-------------

 

 

This entry is used by the collector in setting the consumer variables. The second entry is in the form "/pathname/instance".

 

For example,

-------------

/mnt/hpserv/users indicates the filesystem /mnt/hpser/users.

-------------

 

This entry is used to display the instance in the <application> Exclusions dialog box. If you omit this entry, the instance will not appear in the dialog box.

 

Monitoring application instances by using an inclusion list disables some of the instance’s features and requires the user to perform additional tasks.

 

Such as:

> PATROL will not automatically monitor any new instances.

 

NOTE: The user assumes full responsibility for maintaining this list.

 

The Stop Monitoring menu command on an application will not work. Initially, the instance will disappear from the list of monitored instances. However, the instance reappears during the next discovery cycle.

 

Sample rulesets:

-------------

"/AgentSetup/FILESYSTEM.filterType" = { REPLACE = "include" },

"/AgentSetup/FILESYSTEM.filterList" = { REPLACE = "root,/,boot,/boot,dev,/dev,dev-pts,/dev/pts" }

-------------

 

If we specify above rulesets, Patrol for UNIX KM will monitor only the filesystems specified in the above rulesets.

 

Sample rulesets:

-------------

"/AgentSetup/FILESYSTEM.filterType" = { REPLACE = "exclude" },

"/AgentSetup/FILESYSTEM.filterList" = { REPLACE = "root,/,boot,/boot,dev,/dev,dev-pts,/dev/pts" }

-------------

 

If we specify above rulesets, Patrol for UNIX KM will monitor all the filesystems except the filesystems specified in the above rulesets.

 

Preventing filesystems from being monitored: "/UNIX/FILESYSTEM/nonPersistCUSTTokens" = { REPLACE = "" }

 

The PATROL KM for UNIX automatically discovers the presence of mounted filesystems and also issues an alert on the FSMountStatus parameter if a discovered filesystem is later unmounted. This feature is not optional and cannot be turned off.

 

In some situations, however, you may want to unmount a discovered filesystem and cancel any alerts that the PATROL KM for UNIX would subsequently issue, or you may want to exclude a filesystem from being monitored in the first place. In such cases, you can use one of the following options to prevent a filesystem from being monitored.

 

  • Use the Stop Monitoring command to add the name of the filesystem to the FILESYSTEM exclusion list. This command will prevent monitoring of the filesystem without regard to whether the filesystem is mounted.

 

  • Edit the /PUK/FILESYSTEM/moniList variable to remove the filesystem name from the variable. This option only applies to previously discovered filesystems that are no longer available. The variable moniList maintains a list of persistently monitored instances based on the filesystem category and the custom filesystem tokens. The variable fsCategory provides the category of the filesystem instance and the variable /UNIX/FILESYSTEM/nonPersistCUSTToken provides the custom filesystem tokens for which the persistence monitoring should be denied.

 

You can get some more information in article#KA341503 at our BMC improved KnowledgeBase https://kb.bmc.com.

 

The pconfig variable "/UNIX/FILESYSTEM/discovery" is a private KM variable not meant to be consumed or documented - this is true of many other types of pconfig variables

 

The value is set to TRUE when the File System discovery is started, later when discovery is completed the value is set to FALSE.

 

Part 1) What will be the impact of applying below rule sets?

-----------------

"/AgentSetup/FILESYSTEM.filterList" = { REPLACE = "mnt.*,tmp.*" },

"/AgentSetup/FILESYSTEM.filterType" = { REPLACE = "exclude" }

-----------------

 

Above rulesets will stop monitoring filesystem /mnt and /tmp. It will exclude these filesystems for monitoring by name. The value for ruleset 'FILESYSTEM.filterType' can be 'include' or 'exclude'. Above two rulesets will work according to the filesystem names and below rulesets will work according to the filesystem types.

 

 

Part 2) How many filesystems we can specify in the CUSTTokens FILESYSTEM.filterList?

We can specify all the filesystems that we want to exclude for monitoring int the CUSTTokens ruleset.

-----------------

"/FILESYSTEM.excludeTypes" = { REPLACE = "1111" },

"/UNIX/FILESYSTEM/CUSTTokens" = { REPLACE = "MNTFS LOFS FD OBJFS CTFS TMPFS DEVFS SHAREFS ODM NFS IPATHFS NFSD SYSFS" },

"/UNIX/FILESYSTEM/CDFSTokens" = { REPLACE = "CDFS HSFS ISO9660 CDRFS" },

"/UNIX/FILESYSTEM/NFSTokens" = { REPLACE = "NFS CACHEFS NFS3 NFSV3" },

"/UNIX/FILESYSTEM/PROCTokens" = { REPLACE = "PROC USBDEVFS DEVPTS PROCFS" }

-----------------


There is no ruleset available like "/FILESYSTEM.includeTypes". By using above four ruleset's the filesystems types specified in those rulesets will be excluded for monitoring.

 

You can have both the rulesets at the same time. Above mentioned part 1 and part 2 are two different things.

 

Part 3) What is the meaning of below rulesets:

-----------------

"/FILESYSTEM.persistentTypes" = { REPLACE = "1111" },

"/UNIX/FILESYSTEM/nonPersistCUSTTokens" = { REPLACE = "" },

-----------------

 

Persistent Types are to do with FILESYSTEM persistence. By default once a FILESYSTEM is discovered, it will always be monitored, event if the FILESYSTEM is unmounted/deleted. You can specify which FILESYSTEM types you want to apply persistence to or not.

 

Exclude Types are the FILESYSTEM types you want to exclude from monitoring completely. If you look at the FILESYSTEM Exclusion GUI you will see a section on Exclusion and a section on Persistence.

 

There is a variable called moniList. What is included in that is determined by persistence. If you tell the FILESYSTEM KM to not apply persistence to NFS, then no NFS filesystems discovered will get written to moniList.

 

Chapter 7 of below document will has all the information about Monitoring and managing filesystems:

http://documents.bmc.com/supportu/documents/22/60/412260/412260.pdf