System Monitoring | The ABCs of LDAP: How to Install, Run, and Administer LDAP Services

< Day Day Up >

Why Monitoring

Server administrators normally want to know how their servers are performing and what they are doing. As more and more clients and applications begin to use the directory server, the availability of the directory server becomes crucial to many other services within the enterprise. Thus, it becomes increasingly important to maintain the service level of the directory server. With the help of monitoring tools, you can detect service interruptions as soon as they occur. With timely notice of a service interruption, you may even be able to solve the problem before any user or application experiences a failure of the directory service.

It is quite probable that you have a monitoring tool installed in your intranet environment. Not only large and medium intranets, but even smaller environments, have a great number of servers and services installed, and their numbers keep growing. For this reason, even smaller enterprises need a monitoring tool. Most of the commercial system-monitoring tools allow you to expand them to monitor nearly every process you need to manage. When certain events occur (for example, the process is not responding anymore, the process not running at all, or similar events), the tool reacts with an alert on a system console, an e-mail, or whatever other communication method you have configured. Most commercially available directory servers can easily be integrated into an existing monitoring tool.

SNMP

Monitoring tools frequently use SNMP (Simple Network Management Protocol) to manage or monitor services. SNMP was first implemented in 1988, but it quickly became a de facto standard. The first implementations, however, did not include security issues. These were integrated with version 3.

SNMP is based upon three concepts: managers, agents, and the so-called MIB, the management information base. The MIB is local to the managed service and contains information about it. The agent is installed on the managed service and provides access to the MIB. The agent responds to requests from the manager to get resource values from the MIB or to set them. For example, the agent could request to send to the manager the number of search requests the directory server had to handle. Finally, the manager runs the management software.

SNMP (v3) is defined in a set of RFCs. The application of SNMP tailored specifically for directory services is defined in the RFC 2605, "Directory Server Monitoring MIB." This RFC substitutes and obsoletes RFC 1567, "X.500 Directory Monitoring MIB." If you are interested in the underlying technology, see the following RFCs.

RFC 2271, "An Architecture for Describing SNMP Management Frameworks"
RFC 2272, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)"
RFC 2273, "SNMPv3 Applications"
RFC 2274, "User-Based Security Model for SNMPv3"
RFC 2275, "View-Based Access Control Model (VACM) for SNMP"

As mentioned previously, you can find commercial software implementing SNMP. Because SNMP is a standard protocol such as LDAP, it is not hard to get it to work with software from different vendors. You could use a Sun One LDAP server that supports SNMP and install as SNMP manager OpenView from HP, NetView from IBM, or Tivoli, just to mention some names. Or you could develop your own home-grown implementation of SNMP.

Home-Grown Solutions

If you prefer to develop an in-house solution, you have some advantages over a commercial solution, but it comes at the cost of development maintenance for a proprietary solution. The advantages are:

Greater flexibility
Exact fit with your requirements

Once you have decided to develop your own solution, you can choose one of two different approaches:

You can use SNMP
You can use the LDAP protocol itself

Use of SNMP

If you use SNMP, you should first take your favorite search engine and have a look at the Internet. You are not the only one facing the problem of monitoring an LDAP server, and you will find that there are many tools available. Again, you will find commercial solutions, but also open-source solutions, some of them produced by vendors such as Sun Microsystems.

You can get a robust Java framework from Sun Microsystems from the following Web site: http://java.sun.com/products.

A very interesting Java framework, ModularSNMP (SNMPv3 toolkit), is available from the University of Quebec (l'Université du Quéec à Montrél, Canada).

If you prefer Perl, there is a Perl module available from CPAN. An excellent example is MRTG, developed by Tobias Oetiker <oetiker@ee.ethz.ch>. The multirouter traffic grapher (MRTG) creates HTML-containing images that monitor the actual situation of SNMP-agent-controlled components. You can learn more about it at http://www.stat.ee.ethz.ch/mrtg.

Another interesting approach is SMB_SNMP, which permits you to monitor SNMP agents, treating them as shared Windows resources. You can download it from a number of universities, for example, the TU Wien (university at Vienna, Austria) using the URL http://gd.tuwien.ac.at/opsys/linux/ibiblio/system/network/management.

Other languages that offer libraries include TK/TCL, Python, and many others. Again, just browse the Internet to see what is available.

Use the LDAP Protocol

If you do not want to learn another protocol, you could use the LDAP protocol itself to understand the actual situation of your directory server. This is a simple approach that is easy to implement. Furthermore, you will see the LDAP server exactly the way your clients see it.

Log-File Analysis

Another tool for system monitoring is to analyze the log files the directory server is writing. However, it is important to understand exactly what kind of information a log file can provide. The log file informs you about the actions the directory server has undertaken in response to user requests. This includes the type of request, the time spent upon the request, the details of the request (for example, the query filter in a search), and the traffic load on the directory server. If you need to monitor problems arising from the network, the log file will not help you. In this case, you should use an SNMP tool or write a custom tool that continues to access the directory at regular intervals. You can write it in your favorite language using one of the libraries available. This tool can test several functions that the directory provides.

Again, you have the choice of using a commercial product or developing your own solution. Commercial directory servers offer built-in tools, and there are also commercial tools that elaborate the log files of your directory server. Should you choose to develop your own solution, you can use the ubiquitous Perl (developed by Larry Wall), an ingeniously flexible language. Perl offers a powerful toolbox of pattern-matching utilities that allow you to read the log files and load the activities of your directory server in data structures. Perl also allows you to quickly and easily generate graphs of this data and send an e-mail alert if there is a problem. Perl is available on a myriad of platforms.

Exhibit 16 shows an example of output from the OpenLDAP directory server. Other directory servers will produce analogous output. Most products allow you to configure the log format and the degree of informational detail you wish to obtain. All commercial products have a utility to monitor activity on your directory server. However, it is not difficult to write your own. Exhibit 17 shows the skeleton of a script written in Perl that parses a log file from the OpenLDAP server and produces statistics. The statistics this script produces are not very sophisticated, but the example should be enough to point you in the right direction for producing your own useful statistics.

click to expand
Exhibit 16: Example of LDAP Server Log File

 01 #!/usr/bin/perl -w 02 03 $LogFile = "Ldap.log" ; 04 05 # Contains connections per hour 06 my %ConnectionsPerHour ; 07  # Initialize ConnectionsPerHour: 08   for ($Hour=0 ; $Hour < 24 ; $Hour++) { 09        $ConnectionsPerHour{$Hour} = 0 ; 10   } 11 12 open(LOG,"<$LogFile") || die "Could not open LDAP Logfile : $LogFile" ; 13 14 # Format of the Log File is: 15 # Month Day Hour:Minute:Second ServerName Process: Action 16 17 while(<LOG>) { 18   s/(\w+)\s+(\w+)\s+(\d+):(\d+):(\d+)\s+([^\s]+)\s[^:]+:// ; 19 20   if (! registerEvent(Month         => $1, 21                       Day           => $2, 22                       Hour          => $3, 23                       Minute        => $4, 24                       Second        => $5, 25                       Machine       => $6, 26                       Process       => $7, 27                       Event         => $_)) { 28      printf("Error registering Event at %s %s %s:%s:%s\n", 29                $2,$1,$3,$4,$5); 30    } 31 } 32 close(LOG) ; 33 34 # Once registered the Events we can produce the statistics: 35 36 if (!produceStatistics() )  { 37   printf("Failed in building access statistics\n"); 38     exit(-1); 39 }

Exhibit 17: Example Perl Script of Log File Analysis

Let us review what this script is actually doing. First, it parses the log file. Recall that the format of the log file is:

 Month Day Hour:Minute:Second ServerName Process: Action

In Perl, this is:

 (\w+)\s+(\w+)\s+(\d+):(\d+):(\d+)\s+([^\s]+)\s[^:]+:

where

\w+ means one or more alphanumeric characters
\d+ means one or more digits
\s+ means one or more space characters

Putting brackets around \w+ or \d+ makes characters they match available in the parameters $1 for the first bracket, $2 for the second, and so on. Have a look at the Perl manual pages or the Perl manual for more information.

Line 18 in the "while" loop parses the entire file and calls a procedure that registers the action, thus preparing the statistics. Exhibit 18 shows a straightforward example that simply adds a connection if one occurs. It assumes that a connection has occurred when it encounters the "accepted" keyword in the "action" field. It puts the connection in an associative array that holds the number of accesses for each hour. The function produceStatistics then produces the statistics. In our case, it simply prints out the connections per hour. Alternatively, you could also produce a graph here or print the data out as an Excel file.

 01 sub registerEvent { 02   my (%Fields) = @_ ; 03   # Here in fields now we have all the data sent from 04   # the parse process before, therefore we can make 05   # all statistics we whatever want to make. 06   if ($Fields{'Event'} =~ m/accepted/) { 07     printf("Connection opened at : %s:%s\n", 08       $Fields{'Hour'} , 09       $Fields{'Minute'}); 10     $ConnectionsPerHour{$Fields{'Hour'}}++ ; 11   } 12   return(1); 13 } 14 15 sub produceStatistics { 16 17   for ($Hour=0 ; $Hour < 24 ; $Hour++) { 18    printf("%2d : %4d\n",$Hour,$ConnectionsPerHour{$Hour}); 19   } 20   return(1); 21 }

Exhibit 18: Examples of Function to Prepare and Produce Statistics

As stated previously, this is a simplistic example, but it does clearly demonstrate how you can start producing your own statistics. If you have some idea of programming, you will have no problem in extending it.

< Day Day Up >