This section addresses common questions about using the BMC PATROL Knowledge Module (KM) for UNIX and Linux to perform remote monitoring.
PATROL KM for UNIX and Linux started supporting remote monitoring from version 9.8.00 onwards.
Remote monitoring uses the PATROL Scripting Language (PSL) data collection method to discover instances and to get data through the remote External PSL Call (XPC).
PATROL KM for UNIX and Linux uses an XPC-based collection mechanism to support monitoring of the remote hosts. The pukremotexec.xpc stand-alone executable communicates with PATROL Agent through standard input (stdin) and output (stdout) channels connected with pipes. The communication between PATROL Agent and the XPC server is handled by the SDK libraries through PSL function calls.
pukremotexec.xpc is an XPC-based SSH2 client that opens sessions with remote hosts, runs commands on those hosts, and returns the output to the PSL collectors. For the PSL collectors, the command execution is transparent and the same PSL collectors work well with the local host and the remote host.
The XPC-based SSH2 client has following advantages:
The XPC-based client is responsible for collecting information from the remote host for the application classes.
The following table lists the hardware requirements for a single PATROL Agent running on a dedicated computer and monitoring 175 remote hosts.
Hardware requirements for remote monitoring on multiple UNIX computers
|Server memory||2 GB||4 GB|
|Disk space||600 MB||600 MB|
The following operating systems that are supported by PATROL Agent and PATROL KM for UNIX and Linux can be monitored remotely:
The PATROL Agent computer should be a dedicated server for remote monitoring. The SSH client should be installed on the PATROL Agent computer to communicate with the remote host on which the SSH server is installed. The SSH server should be available and running on port 22 on the remote host before adding it into a PATROL Agent.
It is not mandatory to install the SSH client on the PATROL Agent computer; the pukremotexec.xpc process performs the role of an SSH client.
Configuration requirements for host computers (PATROL Agent)
You must restart the SSH2 server after making configuration changes.
The following figure illustrates a configuration with multiple remote hosts.
Monitoring configuration with multiple remote hosts
PATROL KM for UNIX and Linux supports the following types of user authentication mechanisms.
When you configure a remote host for monitoring, you must provide a user name and a password to access the remote host. PATROL KM for UNIX and Linux stores these login credentials in a secure key store. The SSH2 client submits the credentials to the remote host in order to initiate a remote connection. If the credentials are validated successfully, the SSH2 client starts collecting data for the remote host.
To configure the remote host for password-based authentication, add the following entry to the SSH2 server configuration (sshd_config) file, if it is not already present:
When you configure a remote host for monitoring, you must provide the public and private key file paths, and the passphrase (if applicable). The key file paths must be absolute paths (for example, /home/user/id_rsa.pub), and the PATROL user must have read permissions to access the key files. PATROL KM for UNIX and Linux stores the key file paths in a secure key store.
To configure the remote host for key-based authentication, add the following entry to the SSH2 server configuration (sshd_config) file, if it is not already present:
The KM stores the file name information and not the public or private key. BMC recommends that you set a passphrase for the private key.
User profiles provide a way share credentials among multiple hosts. The hosts that have the same credentials can be grouped into a user profile. You can then assign that profile to all hosts.
Host A, Host B, and Host C have the same credentials (patqa1/patAdm1n). You can create a profile named Test with credentials, patqa1/patAdm1n.
All hosts that are added to the Test profile automatically refer to these profile credentials for authentication; you do not have to enter credentials every time.
The remote monitoring functionality in version 9.8.00 and later of PATROL KM for UNIX and Linux, supports the following application classes:
The following application class limitations apply for remote monitoring on UNIX and Linux computers:
The PROCESS_PRESENCE application class discovers and creates all default instances for the respective remote host.
The Synchronization functionality does not work for remote hosts.
Solaris non-global zone processes cannot be monitored if you are monitoring a Solaris global zone computer as a remote host. This functionality works only for local monitoring.
The SMP application class will not be discovered if a single processor is running on the remote host.
The FILESYSTEM application class is discovered 5 minutes after the discovery of the remote host.
The filesystems on which the PATROL user does not have read and execute permissions are not monitored. The parameters for these filesystems remain offline unless the required permissions are granted to the PATROL user.
The menu commands that require root credentials are not supported.
The following table lists the application classes and the system commands that they use.
System commands used by PATROL KM for UNIX and Linux application classes
|Application class||System commands|
|vmstat, sar, uptime|
|SWAP||swap / swapon|
|zpool / zfs|
There is no maximum limit to the number of remote hosts that one PATROL Agent can monitor. However, in the PATROL Performance, Scalability and Reliability (PSR) lab, the largest configuration tested was 175 hosts.
Yes. You can use any one of the earlier PATROL Agent versions supported. BMC recommends you to use the latest version of the PATROL Agent for better performance.
No, you cannot monitor UNIX or Linux systems from a Microsoft Windows computer.
The REMOTE_HOST and REMOTE_CONT application classes are supported to monitor remote hosts.
Load UNIX3.kml and Remote.kml.
By default, all the application classes in the DCM collection method are discovered.
To switch to the PSL collection method, right-click UNIX OS and choose KM Commands > Knowledge Module Admin > Toggle PSL/DCM Collection.
After full discovery, right-click the Remote Monitoring container and choose KM Commands > Manage List of Monitored Hosts.
When the Manage List of Monitored Hosts dialog box appears, the Add New Host option is selected by default.
Click OK, and in the Add New Host dialog box, provide the host name, user name, and password of the remote host to be monitored.
The host can also be added by using a profile, and public and private keys.
No, you cannot use the DCM method for local monitoring and the PSL method for remote monitoring, simultaneously. You must switch from DCM collection to PSL collection to enable remote monitoring on UNIX computers.
Do not run multiple PATROL Agents for DCM and PSL collection, as this could result in duplicate monitoring on the local host.
No, all of the collectors for a remote host use the same SSH session.
Yes, a persistent SSH connection is maintained for each remote host being monitored.
Yes, you can specify a different polling cycle for each application class.
The default polling cycles that are applied for each application class in remote monitoring are the same as those used in local monitoring, except the FILESYSTEM application class.
You can configure threshold values for a specific remote host using the BMC PATROL KM for Event Management.
The instance hierarchy that is displayed for a remote host is the same as that of a local host.
BMC ProactiveNet discovers remote host instances as devices.
The following table lists the metrics based on 2 processors and 2 GB of RAM for 175 remote hosts monitored for 120 hours.
Performance and Scalability metrics for remote monitoring with PATROK KM for UNIX and Linux
|Operating system||Average CPU (in %)||Average Memory (in MB)||Network|
|PATROL Agent||pukremotexec. xpc||PATROL Agent||pukremotexec. xpc||In (Kilo Bytes per second)||Out (Kilo Bytes per second)|
|Oracle Solaris 10||20.43||6.37||329.41||12.30||55.6||10.3|
|Red Hat Enterprise Linux 5.4 x86-64||23.45||7.0||407.09||12.73||65.4||11.9|
|IBM AIX 6.1 Power6||21.04||6.25||392.30||13.44||83.0||23.4|
|HP-UX 11.23 PARISC||36||9.45||422.70||14.43||56.1||10.7|
You can add remote hosts in the PATROL Agent by creating the following rulesets in PCM:
To add a remote host in the PATROL Agent, create:
To add a remote host in the PATROL Agent with public and private key, create:
To add a remote host in the PATROL Agent using profiles, create:
The following table gives a description of the items to be entered in the preceding rulesets:
|remoteHost||Name of the remote host|
|UserName||User name that you will use to configure remote hosts|
|ProfileName||Profile name that you will use to share credentials|
Encrypted password that you will enter in a secure key store.
You can encrypt the password in the following ways:
Public key that you will use for authentication for remote monitoring
Private key that you will use for authentication for remote monitoring
Ctrl+B is a key combination that you will use to insert a separator character
For information on configuring remote hosts in the PATROL console, see Configuring PATROL KM for UNIX for remote monitoring.
Yes, you can monitor more than 175 remote hosts on a single computer. To do this, you have to run another PATROL Agent on a port different from the one you are already using and add upto 175 remote hosts. In the PATROL PSR lab, a maximum of two PATROL Agents have been tested to function simultaneously. To monitor more than 175 hosts at the same time, ensure that you have enough hardware resources to support this configuration in your environment. For more information, see the recommended hardware configurations.
The following information addresses common questions about SSH, and issues that you might face while configuring remote monitoring.
You can enable and disable debugging at the XPC and SSH library levels for the remote XPC for a remote host.
You can store the debug information for the remote XPC in an external file.
The sshd_config file resides in /etc/ssh/, but the location might vary depending upon the operating system or distribution:
By default, a root user has permissions to modify this file. However, the environment can be configured to allow a standard user to modify this file.
You can use the following commands to start and stop the sshd service:
You can use the following commands to verify and debug the ssh connection with a remote host. The debug log appears only on that same session of system.
You must execute these commands on monitoring servers (PATORL Agent computer).
An RSA key pair must be generated on the client system. The public portion of this key pair must reside on the servers that the client will access, and the private portion must reside on a secure local area of the client system (by default in the ~/.ssh/id_rsa directory).
The following figure shows the RSA key pair on client and server systems.
RSA key pair on client and server systems
You can generate the keys by using the ssh-keygen utility.
The file permissions should be locked to prevent other users from being able to read the key pair data. OpenSSH might also refuse to support public key authentication if the file permissions are too open. These fixes should be done on all systems involved.
The following figure represents the workflow for remote monitoring: