IBM Tivoli Monitoring > Version 6.3 > User's Guides > Agentless OS Monitor User's Guides > Agentless Monitoring for Linux User's Guide > Troubleshooting > Problems and workarounds IBM Tivoli Monitoring, Version 6.3


Installation and configuration troubleshooting

Problems can occur during installation, configuration, and uninstallation of the agent.

The problems and solutions in Table 1 can occur during installation, configuration, and uninstallation of the agent.


Problems and solutions for installation and configuration

Problem Solution
(UNIX only) During a command-line installation, you choose to install a component that is currently installed, and you see the following warning: WARNING - you are about to install the SAME version of "component_name" where component_name is the name of the component that you are attempting to install.

This problem affects UNIX command-line installations. If you monitor only Windows environments, you see this problem if you choose to install a product component (for example, a monitoring server) on a UNIX system.

You must exit and restart the installation process. You cannot return to the list where you selected components to install. When you run the installer again, do not attempt to install any component that is currently installed.
Diagnosing problems with product browse settings (Windows systems only). When you have problems with browse settings, complete the following steps:

  1. Click Start > Programs > IBM Tivoli Monitoring > Manage Tivoli Enterprise Monitoring Services. The Manage Tivoli Enterprise Monitoring Services window is displayed.

  2. Right-click the Windows agent and select Browse Settings. A text window is displayed.

  3. Click Save As and save the information in the text file.

If requested, you can forward this file to IBM Software Support for analysis.

A message similar to "Unable to find running CMS on CT_CMSLIST" in the log file is displayed. If a message similar to "Unable to find running CMS on CT_CMSLIST" is displayed in the log file, the agent cannot connect to the monitoring server. Confirm the following points:

  • Do multiple network interface cards (NICs) exist on the system?

  • If multiple NICs exist on the system, find out which one is configured for the monitoring server. Ensure that you specify the correct host name and port settings for communication in the IBM Tivoli Monitoring environment.

The system is experiencing high CPU usage. Agent process: View the memory usage of the KR4CMA process. If CPU usage seems to be excessive, restart the monitoring agent.

As the number of remote systems is increased, the CPU, memory, and network utilization on the agent server also increases. A dedicated agent server might be added to the environment to handle a large agentless monitoring environment.

Network cards: The network card configurations can decrease the performance of a system. Each stream of packets that a network card receives (assuming that it is a broadcast or destined for the under-performing system) must generate a CPU interrupt and transfer the data through the I/O bus. If the network card in question is a bus-mastering card, work can be offloaded and a data transfer between memory and the network card can continue without using CPU processing power. Bus-mastering cards are 32-bit and are based on PCI or EISA bus architectures.

The configuration panel is blank on 64-bit Windows systems where the Tivoli Enterprise Monitoring Agent Framework (component GL) is version 06.23.00.00 or 06.23.01.00. Check the GL component version by running kincinfo -t GL from a Windows command line. Example:

    %CANDLE_HOME%\InstallITM\kincinfo -t GL

If the GL component version is 06.23.00.00 or 06.23.01.00, take one of the following actions:

  • Preferred action: Upgrade the Windows OS Agent to Version 6.2.3 Fix Pack 2.
  • Alternate action: Install the Agent Compatibility (AC) component from the IBM Tivoli Monitoring V6.2.3 Fix Pack 1 media. See Install the Agent Compatibility (AC) component (http://pic.dhe.ibm.com/infocenter/tivihelp/v15r1/topic/com.ibm.itm.doc_6.2.3fp1/itm623FP1_install199.html#acpinstall).


General problems and solutions for uninstallation

Problem Solution
On Windows systems, uninstallation of IBM Tivoli Monitoring fails to uninstall the entire environment. Be sure that you follow the general uninstallation process described in the IBM Tivoli Monitoring Installation and Setup Guide:

  1. Remove Tivoli Enterprise Monitoring Server Application support by completing the following steps:

    1. Use Manage Tivoli Enterprise Monitoring Services.

    2. Select Tivoli Enterprise Monitoring Server.

    3. Right-click and select Advanced.

    4. Select Remove TEMS application support.

    5. Select the agent to remove its application support.

  2. Uninstall the monitoring agents first, as in the following examples:

    • Uninstall a single monitoring agent for a specific database.

      -OR-

    • Uninstall all instances of a monitoring product, such as IBM Tivoli Monitoring for Databases.

  3. Uninstall IBM Tivoli Monitoring.

The way to remove inactive managed systems (systems whose status is OFFLINE) from the Navigator tree in the portal is not obvious. Use the following steps to remove, but not uninstall, an offline managed system from the Navigator tree:

  1. Click the Enterprise icon in the Navigator tree.

  2. Right-click, and then click Workspace > Managed System Status.

  3. Right-click the offline managed system, and select Clear offline entry.

To uninstall the monitoring agent, use the procedure described in the IBM Tivoli Monitoring Installation and Setup Guide.

IBM Tivoli Monitoring might not be able to generate a unique name for monitoring components because of the truncation of names that the product automatically generates. If the agent supports multiple instances, IBM Tivoli Monitoring automatically creates a name for each monitoring component by concatenating the subsystem name, host name, and product code separated by colons (subsystem_name:hostname:KR4).

When you monitor a multinode system, such as a database, IBM Tivoli Monitoring adds a subsystem name to the concatenated name, typically a database instance name.

The length of the name that IBM Tivoli Monitoring generates is limited to 32 characters. Truncation can result in multiple components having the same 32-character name. If this problem happens, shorten the hostname portion of the name as follows:

  1. Open the configuration file for the monitoring agent, which is located in the following path:

    • On Windows: install_dir\tmaitm6\Kproduct_codeCMA.INI. For example, the product code for the Monitoring Agent for Windows OS is NT. The file name is KNTCMA.INI.
    • On UNIX and Linux: itm_home/config/product_code.ini and product_code.config. For example, the file names for the Monitoring Agent for UNIX OS is ux.ini and ux.config.

  2. Find the line that begins with CTIRA_HOSTNAME=.

  3. Type a new name for host name that is a unique, shorter name for the host computer. The final concatenated name including the subsystem name, new host name, and KR4, cannot be longer than 32 characters.

    You must ensure that the resulting name is unique with respect to any existing monitoring component that was previously registered with the Tivoli Enterprise Monitoring Server.

  4. Save the file.

  5. Restart the agent.

The software inventory tag for the agent on UNIX and Linux systems is not removed during uninstallation of the agent. After uninstalling the agent, manually remove the file named full name of agent.cmptag from the $CANDLEHOME/properties/version/ directory.
When the agent is installed using group deployment, deploygroup was run multiple times. The group deployment starts and completes successfully, but there were multiple entries in the Deploy Status Summary workspace on the Tivoli Enterprise Portal. When the command tried to install multiple times, the additional installations were queued and then were in failed state though the agent was deployed successfully.

  • When the bundle group contains a single bundle and the deployment group contains more than one member (managed system of the same type as AIX or Linux), the deployment is successful on both systems.

  • When the bundle group contains more than one bundle and the deploy group contains single or multiple members, the deployment will be executed on each group member (managed system) depending on the members present in the bundle group and deploy group.

  • The command creates a transaction for each XX bundle for each target system; the bundle matching the operating system for the deployment member is processed successfully; and remaining transactions were in a queued or failed state.

There is no solution at this time.


Parent topic:

Problems and workarounds

+

Search Tips   |   Advanced Search