$('a[name]').remove(); $('#ic-homepage__footer').before('

'); $("#tabs").tabs({ selected: 1 }); $("#ic-homepage__ic-tips").append( quickTipHTML() ); unhideOneProductTip(); $("#ic-homepage__product-tips").wrapInner('

'); $("#ic-homepage__feed-tips").wrapInner('

'); });

IBM Tivoli Monitoring > Version 6.3 > User's Guides > Log File Agent User's Guide > Requirements and agent installation and configuration > Agent-specific installation and configuration IBM Tivoli Monitoring, Version 6.3


Remote log file monitoring

You can use Remote log file monitoring to monitor log files on remote systems.

Log File agent can monitor text log files on remote systems using the Secure Shell (SSH) File Transfer Protocol. SSH File Transfer Protocol is also known as Secure FTP, or SFTP. Remote log file monitoring requires that the remote systems have a working SSH daemon that supports the SFTP protocol. For each Log File agent monitoring profile, you can specify a list of remote hosts to monitor. You specify the list of remote hosts by using a configuration (.conf) file setting, SshHostList in the configuration file of the monitoring profile. For more information about monitoring profiles, see Subnodes. The log files to be monitored are configured by using either the LogSources or RegexLogSources configuration settings as they are normally used for non-remote files. When you specify a list of remote hosts using the SshHostList setting, all configured log files are monitored on each of the listed remote hosts.

Authentication information for the remote hosts must also be provided. The information consists of a user name, which is valid on all the remote systems, and a password or a private key-public key pair for certificate-based authentication. All remote systems within a single configuration must use the same authentication data.

It is important to note that regular expression processing can be processor-intensive. If a single agent is being used to monitor log files on multiple remote systems, that agent runs all regular-expression processing. It runs this processing on the data that arrives from all of the remote hosts. This process centralizes the workload rather than distributing it. This centralization means that as the number of remote systems that are being monitored increases, the workload on the system on which the agent runs can become substantial. In most cases, it is wise to dedicate a server to the task of running the monitoring agent. This architecture also has the advantage that the systems that are being monitored are spared the processor load of regular expression processing. In this way, regular expression processing does not interfere with the business purpose of those systems.

When an event is generated and sent to Tivoli Monitoring, it contains an attribute, RemoteHost, which is an identifier of the system on which the event originated. If the event originated on the local system, this attribute is empty. If the event originated on a remote system, it contains a string of the form user@host:port, which indicates the remote host name on which the event occurred, and the user and port on that host that are used to connect.

When an event is generated and sent to Tivoli Netcool/OMNIbus using the Event Integration Facility (EIF), a slot that is named RemoteHost is used to convey information about the remote host. Before you send events to Tivoli Netcool/OMNIbus, you must define this slot in the format (.fmt) file. You name the slot RemoteHost, and give it the value DEFAULT. The Log File agent fills the value with information about the remote origin of the event. If the event originated on the local system, this attribute is empty. If the event originated on a remote system, it contains a string of the form user@host:port, which indicates the remote host name on which the event occurred, and the user and port on that host that are used to connect. For more information about the DEFAULT keyword, see Keywords.

The Monitored File Status attribute group for Tivoli Self-Monitoring now contains a similar attribute. When you use this attribute, for each monitored file you see which remote system the file is being monitored on. The other information in this attribute group is not affected when the file is remote. For more information about configuration settings for remote log file monitoring, see Options for remote log file monitoring by using SSH.


Example

Monitor three remote hosts, called host1, host2, and host3, and send events using the Event Integration Facility (EIF), including the remote origin of the event in the event. Authenticate on the remote host as a user called loguser, by using that user's password.

Add the following to the configuration (.conf) file (in addition to other options as usual):

In the format file, add the required remote slot to our base event, and allow other events to inherit it:


Supported SSH capabilities and features

The following are the SSH capabilities and features that are supported by the Log File agent. The remote system must support one of the Key Exchange Methods, Hostkey Types, Ciphers, Compression, and MAC hashes for the local / remote system communications. For example, if the remote system SSH daemon does not support one of the Key Exchange Methods, the Log File Status object shows a status of NO SUPPORTED DESC. :

Key Exchange Methods

diffie-hellman-group1-sha1, diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1

Hostkey Types

ssh-rsa, ssh-dss

Ciphers

aes256-cbc (rijndael-cbc@lysator.liu.se), aes192-cbc, aes128-cbc, arcfour, 3des-cbc

Compression

None

MAC hashes

hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96

As Windows does not provide SSH support natively, if you want to use a Windows system as the remote server, install and configure SSH software on it.


Parent topic:

Agent-specific installation and configuration

+

Search Tips   |   Advanced Search