IBM Tivoli Monitoring DLA problems

Two DLA programs are present in IBM Tivoli Monitoring installation

Problem

The following two DLA programs exist in the IBM Tivoli Monitoring installation:

• KfwTmsDla
• Tmsdla

Solution

KfwTmsDla is an earlier version of the DLA that is compatible with IBM Tivoli Monitoring 6.1.

Tmsdla is the DLA program to use if you are using IBM Tivoli Monitoring 6.2.1 IF2 or later and you want to publish data to TADDM.

DLA data sometimes does not reconcile with data that is discovered by the IBM Tivoli Monitoring Scope sensor

DLA data sometimes does not reconcile with data that is discovered by the IBM Tivoli Monitoring Scope sensor due to any of the following problems:

Problem 1

The problem might be due to mismatches in signature. When populating computer systems after a discovery, TADDM uniquely identifies each system based on the IP address and MAC address of the network interface. When multiple network interfaces are present, TADDM selects the interface with the IP address that is lowest based on a string evaluation of its representation. In contrast, the IBM Tivoli Monitoring DLA selects the interface with the MAC address that is lowest based on numerical evaluation. This mismatch introduces duplicate computer systems in TADDM when native discovery is combined with IBM Tivoli Monitoring data.

Solution for problem 1

Upgrade to IBM Tivoli Monitoring 6.2.2 Fix Pack 2 or later.

Problem 2

The problem might be due to mismatches in serial number. Sometimes, the IBM Tivoli Monitoring DLA populates the serialNumber attribute of computer systems with the value UNKNOWN, which causes erroneous merges between different computer systems when the DLA data is loaded into TADDM.

Solution for problem 2

Upgrade to IBM Tivoli Monitoring 6.2.2 Fix Pack 2 or later.

Problem 3

The problem might be due to filtering of private networks. The IBM Tivoli Monitoring DLA does not populate computer systems with data from private network interfaces that are configured according to Internet Engineering Task Force (IETF) RFC 1918 and IETF RFC 4193 (for details about RFCs, see http://tools.ietf.org/rfc/index). This behavior prevents the incorrect merging of computer systems when multiple private networks use overlapping address ranges. However, in environments where private network addresses are not duplicated, you can change this behavior so that the DLA populates these computer systems.

Solution for problem 3

Edit the IP address filters in the XML template files that control the DLA behavior. Back up the template files before editing.

On Linux® and UNIX systems, the template files are stored in $ITM_HOME/arch/cq/tmsdla on the Tivoli Enterprise Portal Server. On Windows systems, the template files are stored in %ITM_HOME%\CNPS\tmsdla on the Tivoli Enterprise Portal Server. The stored templates are platform-specific to the systems that are managed by IBM Tivoli Monitoring in the environment. The file names are:

• knt_tmsdla.xml for Windows computers
• kux_tmsdla.xml for UNIX computers
• klz_tmsdla.xml for Linux computers

Ensure that each of the multiple filter sections in each of the template files contains only the filters for loopback addresses (127.0.0.1 for IPv4 and ::1 for IPv6), as shown in the following example:

<tmsdla:filters>
    <tmsdla:filter name="IF_IP_ADDR" exclude="127\.0\.0\.1"/>
    <tmsdla:filter name="IF_IP_ADDR" exclude="::1"/>
</tmsdla:filters>

Problem 4

The problem might be due to mismatches in operating system name. The IBM Tivoli Monitoring DLA inconsistently populates the operating system name attribute, which causes multiple operating system objects to be on a single computer system when the DLA data is loaded into TADDM.

Solution for problem 4

Add an OSId attribute to the XML template files that control the DLA behavior. Back up the template files before editing.

On Linux and UNIX systems, the template files are stored in $ITM_HOME/arch/cq/tmsdla on the Tivoli Enterprise Portal Server. On Windows systems, the template files are stored in %ITM_HOME%\CNPS\tmsdla on the Tivoli Enterprise Portal Server. The stored templates are platform-specific to the systems that are managed by IBM Tivoli Monitoring in the environment. The file names are:

• knt_tmsdla.xml for Windows computers. Add the OSId attribute as shown in the following example:

  <cdm:sys.windows.WindowsOperatingSystem 
  id="%{IPADDR}-WindowsOperatingSystem" 
  sourceToken="managed_system_name=%{MSYSN}&amp;object_id=p@%{MSYSN}" 
  outputonce="true">
       ...
       <cdm:OSId>1</cdm:OSId>
  </cdm:sys.windows.WindowsOperatingSystem>

• kux_tmsdla.xml for UNIX computers. Add the OSId attribute as shown in the following example (this change must be made in two places in the template file for UNIX computers):

  <cdm:sys.unix.Unix id="%{IPADDR}-UNIX" 
  sourceToken="managed_system_name=%{MSYSN}&amp;object_id=p@%{MSYSN}">
      <cdm:ManagedSystemName>%{MSYSN}</cdm:ManagedSystemName>
      ...
      <cdm:OSId>1</cdm:OSId>
  </cdm:sys.unix.Unix>

• klz_tmsdla.xml for Linux computers. Add the OSId attribute as shown in the following example:

  <cdm:sys.linux.Linux id="%{IPADDR}-Linux" 
  sourceToken="managed_system_name=%{MSYSN}&amp;object_id=p@%{MSYSN}">
      ...
      <cdm:OSId>1</cdm:OSId>
  	</cdm:sys.linux.Linux>

Running of the DLA results in OutOfMemoryError message

Problem

The Tmsdla program abnormally ends with a message similar to the following message:

JVMDUMP006I Processing dump event "systhrow", 
detail "java/lang/OutOfMemoryError" - please wait.

Either or both of the following situations can cause the Java™ heap to be exhausted, which results in the OutOfMemoryError message and the creation of heapdump and javacore files:

• The system on which the Tmsdla program is running is low on memory.
• The monitored enterprise is extremely large.

Solution

If you observe symptoms of heap memory exhaustion using the default maximum Java heap size of 256 MB, update the value for the maximum Java heap size in the respective Tmsdla startup script (using increments of 64 MB) until the problem is resolved.

Startup script on Windows systems

Update the %ITM_HOME%\CNPS\tmsdla.bat file.

Startup script on non-Windows systems

Update the $ITM_HOME/arch/cq/bin/tmsdla.sh file.

To update the value in the startup script, complete the following steps:

1. Search for the following parameters (near the end of the file):

   java -Xms64m -Xmx256m

   The Xms64m parameter specifies the starting size of the Java heap (64 MB), and the Xmx256m parameter specifies the maximum size of the Java heap (256 MB).

2. Increment the Xmx256m parameter by 64 MB (for example, change it to Xmx320m), and save the file.
   Note: Ensure that the system on which the Tmsdla program runs has enough memory to process the maximum heap size that is defined in the Tmsdla startup script.
3. Run the Tmsdla program.
4. If the OutOfMemoryError message reoccurs, repeat this process of incrementing the maximum heap size by 64 MB (examples of additional values to try include 384 MB and 448 MB).