Introduction

The IBM Tivoli Directory Server is a powerful enterprise directory for corporate intranets and the Internet. It is imperative that a solution is provided to monitor the server in an efficient manner. It is with this view that the TDI assembly line, a TDI-based SNMP solution has been developed.

The TDS server has the ability to monitor its own health. However, the TDI solution facilitates the monitoring of the TDS server in a more efficient and convenient manner. And, the TDI solution provides other advantages, such as the ability to monitor multiple directory servers simultaneously, monitor remote directory servers, support for secure server monitoring, and support for both IPv4 and IPv6 protocols. Before we delve into the details of the TDI-based SNMP solution, let's have quick overview of SNMP and TDI, because this solution is based on these technologies.

Simple Network Management Protocol (SNMP) is a network management protocol that is designed to monitor applications and devices such as hubs, modems, and switches. There are three parts to an SNMP setup: network management station (NMS), agent, and managed object.

• The network management station can be thought of as a client that requests various metrics from an agent. Tivoli NetView® is an example of a network management station.

• An agent is a server process. Agents monitor managed objects and send unsolicited messages, also called as traps to the NMS. It also respond to synchronous requests from the NMS

• The managed object is any device that is being managed. This can be the operating system, the directory server, or a hardware device.

Tivoli Directory Integrator (TDI) is an application that synchronizes and exchanges information between applications or directory sources. TDI can read information from multiple data sources, such as directories, databases, and data files. It can then process the information and write it back in any format that is needed. In TDI, the rules for data transformation, filtering, and communication are called assembly lines.

Prerequisites

1. This article assumes that TDS 6.1 or above is already installed and started.

2. TDI 6.1 should also be installed.

Note: The minimum requirement of TDS 6.1 or above and TDI 6.1 is required for proper functioning

TDI-based solutions

In its native form, the SNMP event handler provides some very basic functionality. To form an SNMP solution using TDI, the event handlers and connectors that are available with TDI have been enhanced. At a macro level, the SNMP agent listens to SNMP events, maps them to LDAP calls, and sends the results back to the caller. Also, the agent polls the LDAP server to monitor its health, system health, and replication health. In case of a problem, it then issues a trap to the NMS.

Note: A polling interval option is provided to the configuration file at SNMP start up. The time default value is five minutes.

To effectively monitor TDS there are two types of TDI-based solutions that are provided. The diagram above is a bird's eye view of the provided solutions. Given below is a brief overview of the TDI-based solutions.

TDI-based network management station

In order to create a TDI-based solution to work as an NMS, the TDI solution is using the ibmdi.snmp functional component. This functional component handles the workings of this NMS and it is provided by the TDI itself. The configuration of a TDI-based NMS is very simple and is similar for all operating systems unlike other network management stations, which might have a different configuration method for Windows® and UNIX®-based operating system. Another advantage is that TDI is already shipped with TDS. Hence, customers need not use third-party NMS products if they only require simple monitoring.

Configuration of TDI-based NMS

Follow the steps given below to monitor TDS through TDI.

Create a new assembly line in TDI.

Steps to create a new assembly line

Step 1: Open IBM Tivoli Directory Integrator Editor.

First, click File from the menu bar and then select the New command

You will get the following panel.

Next, specify the name of XML file that is created corresponding to the assembly line and then click the OK button to navigate to the next screen.

Step 2:Create an assembly line. Right-click and select New AssemblyLines from the left side of the panel shown above. Then, specify the name of the assemblyline in the pop-up box shown in below figure.

Next, click OK to navigate to the next panel.

Step 3:In the “Feeds” section of assembly line, select the connector ibmdi.SNMP, which is specific to SNMP. On doing this, the panel below is displayed.

Configuration

Above, the connector can be run in Client or Trap listening mode. This article concentrates on Trap listening mode.

Note: All the required fields are filled as specified in the figure.

This assembly line will run in Console mode, and on receiving a trap, display the information explained in section Received Generated Trap

TDI-based SNMP agent

The TDI-based agent first reads the configuration file to determine the server instances that are to be monitored and the polling interval for finding out the health of the server. To ensure that the agent polls the LDAP server after the specified time intervals, a timer is also configured at start up. The agent then connects to the monitored LDAP instances using an LDAP connector. In the event of out of the ordinary scenarios, such as server down, start up, replication down, replication pending queue becoming very large, system memory utilization being very high, or CPU utilization being very high, the SNMP agent sends a trap to the NMS specified to receive the traps.

Note: The agent can monitor multiple instances simultaneously.

The SNMP agent is able to generate trap alerts for the following conditions

Configuration of TDI-based SNMP agent

1. In the configuration file of the SNMP agent, mention the address of the TDS server along with the port number in the following way.

				
Port                 <port on which the SNMP Agent listens>
Server               <Server IP Address> <Server Port>
Community           <community string> <ip address of the NMS> <sample view if required>
View                 <oid for the view>   
Trap                 <ip address of the NMS> <port of the NMS> 
Poll                 <time interval for Agent to poll the Server instance>

2. Configure a user on the TDS server with minimal rights. In addition, add an entry of objectclass person.

				

#ldapadd -D <AdminDn> -w <AdminPwd> 
dn : cn=snmpuser,o=ibm,c=us
userPassword : user
objectclass : person
sn : snmp user

#ldapmodify -D <AdminDn> -w <AdminPwd> 
dn:  <replication context> 
changetype: modify
add: aclEntry
aclEntry: access-id:cn=snmpuser,o=ibm,c=us:at.ibm-replicationPendingChangeCount:
          rs:at.ibm-replicaURL:rs:at.ibm-replicationState:rs

To retrieve system information from remote machines, a system user needs to be created across all systems monitored by the TDI solution. This user should have minimum privileges. Also, this user should be updated in the idssnmp.properties file.

3. Update the idssnmp.properties file.

• Specify the userDn and password of a TDS user (as created in Step2). If the TDS server is supporting anonymous search, there is no need to specify userDn and password. Except for replication information, other information can be accessed by anonymous search.

• Specify the user and password of the system where TDS is running.

• Specify the threshold and activate the trap conditions for which the user wants this agent to generate a trap.

Note: In our case we have activated a trap condition for memory utilization of systems where TDS is running.

4. Run the SNMP agent to start monitoring the TDS. In order to run the SNMP agent, you need to run idssnmp.xml solution through TDI.

Received generated trap

Once the TDI-based SNMP agent and the TDI-based NMS are configured, the TDS will be monitored for its performance and availability. If a trap is generated, NMS displays the following information.

				
	  
Entry attributes

1.  Snmp.agentIP (replace):      9.182.186.80    
2.  Snmp.specificID (replace):   8
3.  1.3.6.1.4.1.2.6.199.1.1.4.1.4.9.182.191.63.5389 (replace):  6.1
4.  snmp.timestamp (replace):    4656
5.  snmp.community (replace):    public
6.  1.3.6.1.4.1.2.6.199.1.1.5.1.4.9.182.191.63.5389 (replace):   ltoyota.in.ibm.com
7.  snmp.genericID (replace):    6
8.  1.3.6.1.4.1.2.6.199.1.1.6.1.4.9.182.191.63.5389 (replace):   IBM Directory Full
    (Backend Server)
9.  snmp.notify.enterprise  (replace):   1.3.6.1.4.1.2

Looking at the trap above, we can determine the following

Line 1 Specifies the IP address of the machine where the SNMP agent is running.

Line 2 snmp.specificID 8 specifies that CPU utilization of the system where TDS is running has crossed the threshold limit. For different conditions, different ID traps will be generated. Possible trap conditions are specified in Table 1.

Line 3, Line 6 and Line 8 specify the TDS version, Machine name and Server type respectively. See the Referencessection.

SNMP Solution in Post 61 TDS Releases

If the customer is using the post 61 releases, following changes can be observed with the tool.

1. TDS will now also send SNMP traps when an error condition or server failure occurs, so that systems monitoring tools are alerted. The new SNMP solution will comply to per instance basis approach.

Since the tool comply to be per instance basis, and all the properties related to an instance are stored in the properties file, for this feature. The tags, Server and SecureServer are removed from idssnmp.conf file. The file will look like following :

Port 161
Community     public 127.0.0.1    readOnly 1.3.6.1.4.1.2.6.199
View 1.3.6.1.4.1.2.6.199
Trap 127.0.0.1 162 public
Poll 60

Following are the changes required to the existing idssnmp.properties file.

server: 192.168.0.1
port: 389
isSSL: false
ldapbindDN:
bindDNpwd:
systemuser:
systemuserpwd:
filterCacheActive:false
filterCacheThreshold:
pendingRequestsActive:false
pendingRequestsThreshold:
pendingRequestsSinceLastIntervalActive:false
pendingRequestsSinceLastIntervalThreshold:
activeConnectionActive:false
activeConnectionThreshold:
memoryUtilizationActive:false
memoryUtilizationThreshold:
cpuUtilizatinActive:false
cpuUtilizationThreshold:
diskSpaceUtilizationActive:false
diskSpaceUtilizationThreshold:
replicationPendingChangeCountActive:false
replicationPendingChangeCountThreshold:
replicationStatusActive:false
trapForMessageId-slapd: TRAP_MID
trapForMessageId-audit: TRAP_MAX
trapForMessageId-ibmdiradm: TRAP_MID

server: 192.168.0.2
port: 636
isSSL: true
ldapbindDN:
bindDNpwd:
systemuser:
systemuserpwd:
filterCacheActive:false
filterCacheThreshold:
pendingRequestsActive:false
pendingRequestsThreshold:
pendingRequestsSinceLastIntervalActive:false
pendingRequestsSinceLastIntervalThreshold:
activeConnectionActive:false
activeConnectionThreshold:
memoryUtilizationActive:false
memoryUtilizationThreshold:
cpuUtilizatinActive:false
cpuUtilizationThreshold:
diskSpaceUtilizationActive:false
diskSpaceUtilizationThreshold:
replicationPendingChangeCountActive:false
replicationPendingChangeCountThreshold:
replicationStatusActive:false
trapForMessageId-slapd: TRAP_MID
trapForMessageId-audit: TRAP_MAX
trapForMessageId-ibmdiradm: TRAP_MID

The property server: in idssnmp.properties file is to specify the ip address of the server running the instance to be monitored.

TrapForMessageId- <log type> <.GLP...> will be a list of message identifiers. The list will be a "," separated list of message identifiers. A SNMP trap will be generated in the event of a matchingmessage identifier in the server log requested through the ldap extended operation. The log type describes the type of log required by the ldap extended operation. Each log type has to be mentioned separately.

If the user doesn't wish to specify individual log codes but would like to send traps for all the messages generated in the log file, he can specify one of the following.

• TRAP_MAX – This will send traps for all (Information, Warning and Error) messages seen in the log files.

• TRAP_MID – This will send traps only for all Warning and Error messages seen in the log files.

• TRAP_MIN – This will send traps only for all Error messages seen in the log files.

The user can specify only one of the above OR a set of messages for which he wishes to receive traps. Following are invalid combinations for the tool.

• Multiple TRAP_XXX values in the TrapForMessageId-log_name property.

• A combination of TRAP_XXX and GLPXXXXXXX as value for TrapForMessageId-log_name property.

Example of a valid value.

trapForMessageId-slapd: TRAP_MAX

Incase the tool encounters an invalid combination of trap ids, it will skip the values found and continue its normal execution.

2. The new TDI based idssnmp solution can co-exist and work with multiple TDI based tools without affecting each other.

The idssnmp tool will now have its own solution directory, which will be the install directory, i.e LDAP_HOME/idstools/snmp . The idssnmp tool cannot have the solutions directory within the instance home directory since the idssnmp tool is not instance specific. This will ensure that all TDI related files are local to the tool and other TDI based tools running on the system are not affected by the configuration details and various files created/used by idssnmp tool during its run.

Note: The tool will continue to generate all the logs as it did with TDS 6.1. With the introduction of solution directory, the ibmdi.log and idssnmpinit.log will be created at LDAP_HOME/idstools/snmp/logs folder. The idssnmp.log will be created at /var/idsldap/V6.2/ folder if TDS62 is in working.

Security: The values in idssnmp.properties file will be encrypted using encryption algorithm routine provided by TDI. There is no customizable encryption key for the properties file. This key is internal to TDI. The following property values of the idssnmp.properties file will get encrypted when the idssnmp tool is launched.

• ldapbindDN

• bindDNpwd

• systemuser

• systemuserpwd

The encrypted value will be prefixed with {encr} for the tool to understand that the value is already encrypted during its subsequent runs.

Probable Problems and there corrective actions

This section discusses the possible problems and corrective actions that can be tried before contacting IBM® Software Support.

1. It is observed that LDAP_HOME/idstools/snmp/logs/ibmdi.log grows huge with time when idssnmp is running. If the user is not interested in older logs, he can modify the LDAP_HOME/idstools/snmp/etc/log4j.properties file to use a different appender. Customers can refer to Tivoli Directory Integrator 6.1.1 Administration guide for a list of appenders. " http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.doc_6.1/referenceguide07.htm"

2. The logs are read sequentially and this will cause all the lines from a particular log (e.g slapd) to appear at once. We maintain the timestamp as found in the log in the trap message. The user will then have to compare these timestamps and workout the order the logs were generated.

3. If the customer wishes to run idssnmp over SSL, he needs to edit the solution.properties found at LDAP_HOME/idstools/snmp and specify the certificate information. Refer " http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.doc_6.1/adminguide20.htm" for SSL setup.

4. If the customer wishes to have idssnmp run over SSL and solution.properties files is not present, he needs to execute the following

LDAP_HOME/tdi/ibmdisrv -s LDAP_HOME/idstools/snmp –v

This command will create the solution files required by idssnmp. The customer can then edit required files to setup idssnmp.

Limitations

The proposed solution can monitor multiple servers but this monitoring is sequential instead of parallel. The solution can be enhanced to monitor multiple servers in parallel.

Conclusion

The purpose of this solution is to improve the monitoring of the Directory server for performance and availability using a TDI solution as an SNMP agent as well as a network management station. Here we focus on the TDI solution that will work as an SNMP agent and collect performance and wellness information, such as monitor search, root DSE search, and system information of the IBM Tivoli Directory Servers it is monitoring. This eliminates the need to use third party network management stations to monitor a trap. Here, TDI itself is used as an NMS that will catch the trap that has been generated by a TDI-based agent.

Even though IBM Tivoli Directory Server has the ability to determine the status of replication, users cannot easily determine how caught up (or behind) replication is to a given server. Nor can users easily determine whether replication is operating properly. Hence, TDI-based SNMP solutions provide an efficient way to monitor the IBM Tivoli Directory Server.

References

For TDI information

• IBM Tivoli Directory Integrator Version 6.1, Installation and Configuration Guide.
• "TDI Documentation"

For more details about SNMP

• "SNMP tutorials."

Back to top

Downloads

Information about download methods

Resources

• Participate in the discussion forum.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  
• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

About the authors

Vinay Arya is a Software Engineer at IBM Software Labs, India. He is working as a member of the IBM Tivoli Directory Server Developer team.

Gaurav Khanna is a Software Engineer at IBM Software Labs, India. He is working as a part of the IBM Tivoli Directory Server team.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Prerequisites
• TDI-based solutions
• TDI-based network management station
• Configuration of TDI-based NMS
• TDI-based SNMP agent
• Configuration of TDI-based SNMP agent
• Received generated trap
• SNMP Solution in Post 61 TDS Releases
• Probable Problems and there corrective actions
• Limitations
• Conclusion
• References
• Downloads
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Tivoli Directory Integrator
• Webcast: Achieve an Agile Organization through Enterprise Architecture
• Briefing: Introduction to Tivoli service management environment
• Buy: Tivoli Directory Integrator

My developerWorks community

Dig deeper into Tivoli on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers