IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Administrator's Guide > Agent Management Services

IBM Tivoli Monitoring, Version 6.3 Fix Pack 2

Tivoli Agent Management Services installation and configuration

The Agent Management Services is installed automatically with the Linux OS agent, UNIX OS agent, or Windows OS agent, depending on the host platform. Application support files for these agents are also installed on the Tivoli Enterprise Monitoring Server and Tivoli Enterprise Portal Server.

With IBM Tivoli Monitoring V6.2.3 Fix Pack 1 or later OS agents are now monitored through sockets in addition to the process status and cinfo check. The socket monitored is a PIPE internally used by the Proxy Agent Services for external requests. You can choose to restart the OS agent if it does not respond to the socket in the consecutive number of tries specified by KCA_MAX_RETRIES_ON_PIPE environment variable. Once the variable has been changed in the agent ENV file, you must restart the agent for the changes to be implemented. By default the variable is not defined, meaning that the OS agent is never restarted. You must use a value for this variable that is greater than 5.


Common agent package file

The monitoring behavior of the Agent Management Services towards a particular agent is governed by settings in an XML-based policy file, referred to as a common agent package (CAP) file. Every agent that can be managed by the Agent Management Services installs a CAP file named, where pc is the product code, kpc_default.xml into a directory defined by the KCA_CAP_DIR environment variable in the OS monitoring agent configuration file for the relevant platform. Agents that run natively on 64-bit Windows put their CAP files in the 64-bit Tivoli Monitoring Agent directory; all others go in the 32-bit directory:
install_dir\TMAITM6[_x64]\CAP
install_dir/config/CAP.

On the zLinux platform, Agent Management Services has the following behaviors:

To enable the Agent Management Services after an upgrade, set the KCA_CAP_DIR environment variable to an existing directory containing the CAP files.

On Intel Linux and other supported platforms, the Agent Management Services is enabled by default.


CAP file customizable elements

The CAP file installed by the agent is configured to be read-only and should not be directly modified. To customize the policy settings of this file, create a copy of the file and name it with the convention kpc.xml. Watchdog automatically detects when a new CAP file is added or a CAP file is removed from the directory. Changes to an existing CAP file require the OS agent to be restarted in order to pick up the changes. An update to a non-OS agent CAP file can be done without needing to restart the OS agent. To complete this action remove the CAP file from the directory and then after Watchdog has discovered the file has been removed, copy the updated file back into the directory. An update to the OS agent CAP file requires the OS Agent to be restarted. You can have one CAP file govern multi-instance monitoring agents or create a separate CAP file for each instance.

The elements defined in the CAP file can be viewed in the Tivoli Enterprise Portal "Agent's Management definitions" view of the Agent Management Services workspace. Note: Attributes not defined in the CAP file are not displayed in "Agent's Management definitions" view.

The order of the elements is important. Review kwgcap.xsd for a formal definition of the CAP file schema.

<checkFrequency>

The length of time between availability checks by Agent Management Services of the managed agent. If system load is heavy, consider increasing the checkFrequency interval along with the KCA_CMD_TIMEOUT agent environment variable setting.

Enter the frequency value in multiples of 5 seconds, up to a maximum of 3600 seconds (1 hour). Default: 120.

<cpuThreshold>

The maximum average percent of CPU time that the agent process can consume over a time interval equal to "checkFrequency" seconds before being deemed unhealthy and then restarted by Agent Management Services.

Enter the threshold percentage as a positive integer from 1 to 100.

<memoryThreshold>

Maximum average amount of working set memory that the agent process can consume over a time interval equal to "checkFrequency" seconds before being deemed unhealthy and then restarted by Agent Management Services.

Enter the threshold value followed by the unit of measurement: KB, MB, or GB. Example: 50 MB.

<managerType>

The entity that performs availability monitoring of the agent.

Enter an enumerated value: NotManaged or ProxyAgentServices. Default: NotManaged.

<maxRestarts>

The number of times per day an abnormally stopped or unhealthy agent should be restarted. Agents that do not need to be kept running can have a value of 0.

Enter a positive integer. Default: 4.

<subagent id>

Edit this value only if you are creating an instance-specific CAP file for a particular agent. For example, if you want to create a CAP file specifically for a set of DB2 agent instances where the kud_default.xml file has a subagent id="kudagent", set it to something like <subagent id="kud_instance">. The <agentName> value for both the agent's original CAP file and its instance-specific CAP files should match.

Enter a string value for the ID.

<instance>

Use this element to provide specific instance names that the target CAP file policies apply to. It must follow the <agentName> element in the CAP file. For example, to specify that an instance of a CAP file should apply to two specific instances of the Tivoli Monitoring DB2 agent, named test1 and test2, enter this information: 

    <subagent id="kud_instance">
<agentName>ITCAM Agent for DB2</agentName>
<instance>
   <name>test1</name>
   <name>test2</name>
</instance>

Enter a string value for the instance name within a <name> </name> tagging pair.


Database and messaging monitoring agents on Linux and UNIX

The database and messaging agents are typically started as non-root users. For the Agent Management Services to support this behavior, you can specify that an agent start as a particular user in the start script of the CAP file.

The Agent Management Services rely on the same file that the autoscript files rely on, kcirunas.cfg, to get configuration information about which user an agent should RunAs. This information is used when the Agent Management Services starts the agent to ensure that it runs as the correct user. In an environment where agents are remotely deployed, use the hostname_kdyrunas.cfg file. The file is also checked for RunAs information.

If you want to enable this support in an older CAP file, update the CAP file as illustrated in the following example of the Tivoli Log File Agent (lo) on Linux (lz):

To enable this support in an older CAP file, update the stop script:

For single instance agents, such as the Linux OS Agent on Linux, use the following syntax:

For single instance agents such as the UNIX Agent, use this syntax. It is identical to the syntax on Linux except that - ##USER## is placed after su rather than at the end:


Parent topic:

Agent Management Services

Related reference:

Linux or UNIX installation considerations: Autostart scripts

+

Search Tips   |   Advanced Search