'); $("#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
Subnodes
Use subnodes to implement monitoring profiles that monitor multiple applications from a single agent instance.
You can accomplish the following tasks with a single agent instance by using subnodes:
- Monitor each instance of an application that is running on a system.
- Monitor different applications from a single agent instance, with different patterns applied to different logs. This type of monitoring means that logs for one application are not searched for the patterns from a different application. This type of monitoring improves efficiency.
- Monitor logs that need different duplicate detection settings (Tivoli Monitoring only) from a single agent instance.
- Organize logically separate groups of patterns, maintained by different administrators, in separate files with different write permissions without creating separate agent instances.
Create subnodes and monitoring profiles
On the system you are monitoring, you might have multiple applications you want to monitor. To monitor all these applications from a single agent instance, you associate a profile with each application. A profile represents a single configuration and format file pairing and is implemented by using a subnode. This separation of profiles means that the logs for one application are not searched for the patterns from a different application, which improves efficiency.
To create the subnodes, you create a configuration (.conf file), and format (.fmt file) pair for each application, and place them in a specific directory location. You specify the directory location to the agent using the Configuration file autodiscovery directory value in the configuration panel. For more information about setting configuration panel values, see Configure from the configuration panel.
To organize your profiles, you can store the configuration and format file pairs in a directory tree structure under the Configuration file autodiscovery directory. Individual configuration and format file pairs must be stored in the same directory. Different configuration and format file pairs can be stored in different directories. The Log File agent checks the Configuration file autodiscovery directory location periodically, running a recursive search of the directory structure for new configuration files. The agent expects to find a format file with the same base-name as the configuration file in the same directory. For each configuration and format file pair, it finds, the agent creates a subnode using the configuration file base-name as the profile (subnode) name. The number of subnodes is determined by the number of configuration and format file pairs. When the subnodes are created, the Log File agent begins monitoring for each configuration without further intervention.
You set configuration settings that apply globally to all subnodes when you install the agent. You set these global configuration settings using the configuration panel or command line. You can override two of these global installation time configuration settings to use configuration file settings. The global settings that can be overridden with configuration file settings are:
- Automatically initialize UNIX syslog: You can set this value at installation time to use a configuration file value, AutoInitSyslog, that applies per subnode. To use the configuration file value you set Automatically initialize UNIX syslog to USE_CONF_FILE_VALUE. This value is the default.
- Process Priority Class: You can set this value at installation time to use a configuration file setting, ProcessPriorityClass. To use the configuration file value you set Process Priority Class to USE_CONF_FILE_VALUE. This configuration file value does not apply per subnode as it cannot have different values in different configuration files. The limitation of not having different values is to support compatibility with earlier versions with existing configuration files. This limitation is because before the introduction of monitoring profiles that use subnodes, this value was set in the configuration file.
Defining monitoring for a number of application instances by using subnodes instead of agent instances can significantly increase the scale and performance of the Tivoli Monitoring environment.
Configuration and format files can be hosted in a central location. See Centralized Configuration.
Example
You have a group of WebSphere servers to monitor the same or similar types of log files. Some servers are running a Linux operating system and others are running the AIX operating system. Each server has either a DB2 or Oracle database. Each of the operating systems and data bases has a set of log files to be monitored and patterns to be searched for in these log files.
For the purposes of the example, you want to monitor three WebSphere servers with the following log files:
WS_server_1: AIX_logfile DB2_logfile WS_server_2: Linux_logfile Oracle_logfile WS_server_3: Linux_logfile DB2_logfile
To create the required subnodes for one agent instance to monitor all log files, create four pairs of configuration and format files:
translog_aix.conf translog_aix.fmt translog_db2.conf translog_db2.fmt translog_linux.conf translog_linux.fmt translog_oracle.conf translog_oracle.fmt
When the file pairs are completed, you place them in the directory set in the Configuration file autodiscovery directory. The next time the Log File agent checks the directory, it creates a subnode for each file pair and begin monitoring for each configuration.
The configuration files in this example are deployed to servers as shown in Table 1
Allocation of configuration files to servers
Server Configuration files WS_server_1 translog_aix.conf
translog_aix.fmt
translog_db2.conf
translog_db2.fmt
WS_server_2 translog_linux.conf
translog_linux.fmt
translog_oracle.conf
translog_oracle.fmt
WS_server_3 translog_linux.conf
translog_linux.fmt
translog_db2.conf
translog_db2.fmt
This configuration means for example that WS_server_1 does not waste resources by searching for Linux or Oracle messages that never occur on this server.
Parent topic:
Agent-specific installation and configurationRelated tasks:
Configure from the configuration panelRelated reference:
Configuration Files