Previous
Contents
Index
DocHome
Next
|
| iPlanet Directory Server Configuration, Command, and File Reference |
Chapter 5 Access Log and Connection Code Reference
iPlanet Directory Server 5.1 provides you with logs to help you monitor directory activity. Monitoring allows you to quickly detect and remedy failures and where done proactively, anticipate and resolve potential problems before they result in failure or poor performance. To monitor your directory effectively, you need to understand the structure and content of your logs.
This chapter does not, and indeed cannot, set out to provide an exhaustive list of error messages. However, the information presented in this chapter will serve as a a good starting point for common problems. This chapter includes the following sections:
Access Log Content If you require further assistance in the investigation of your access log reports, please contact iPlanet Technical Support:
http://www.iplanet.com/support/support_services_10_0.html
Access Log Content
The iPlanet Directory Server 5.1 access log contains detailed information about client connections to the directory. A connection is a sequence of requests from the same client with the following structure:
connection record which gives the connection index and the IP address of the client
sequence of operation request / operation result pairs of records (or individual records in the case of connection, closed, and abandon records) Every line begins with a timestamp - [21/Apr/2001:11:39:51 -0700]- the format of which may vary depending on which platform you are using, where -0700 indicates the time difference in relation to GMT. Apart from the connection, closed, and abandon records which appear individually, all records appear in pairs, consisting of a request for service record followed by a result record. These two records frequently appear on adjacent lines but this is not always the case.
This section presents the different levels of access logging available with iPlanet Directory Server 5.1, then describes the default access logging content and ends with a description of the additional access logging level content. This section is divided into the following parts:
"Access Logging Levels"
"Default Access Logging Content"
"Access Log Content for Additional Access Logging Levels"
Access Logging Levels
Different levels of access logging exist and by changing the value of the nsslapd-accesslog-level configuration attribute, you can select the exact type of logging you require. The default level of logging is level 256 which logs access to an entry but you can choose from the following logging levels, combining more than one level to suit your needs:
4=Logging for internal access operations
256=Logging for access to an entry
512=Logging for access to an entry and referrals
131072=Precise timing of operation duration. This gives microsecond resolution for the Elapsed Time item in the access log.
For example, if you want to log internal access operations, entry access, and referrals, you would set a value of 516 (512+4) in the nsslapd-accesslog-level configuration attribute. For further information on other access log configuration attributes, see Chapter 2 "Core Server Configuration Reference".
Default Access Logging Content
This section describes the access log content in detail, based on the default access logging level extract in Code Example 5-1.
Connection Number
Every external LDAP request is listed with an incremental connection number, in this case conn=11 or conn=28, starting at conn=0 immediately after server startup. Internal LDAP requests are not recorded in the access log by default. To activate the logging of internal access operations, specify access logging level 4 on the nsslapd-accesslog-level configuration attribute.
File Descriptor
Every connection from an external LDAP client to Directory Server requires a file descriptor, or socket descriptor, from the operating system, in this case fd=608. fd=608 indicates that file descriptor number 608 was used out of the total pool of available file descriptors.
Slot Number
The slot number, in this case slot=608, is a legacy part of the access log. It has the same meaning as file descriptor. Ignore this part of the access log.
Operation Number
To process a given LDAP request, Directory Server will perform the required series of operations. For a given connection, all operation request and operation result pairs are given incremental operation numbers beginning with op=0 to identify the distinct operations being performed. In Code Example 5-1, op=0 is given for the bind operation request and result pair, then op=1 for the LDAP search request and result pair, and so on. Should you see op=-1 in the access log, it generally means that the LDAP request for this connection was not issued by an external LDAP client, but instead initiated internally.
Method Type
The method number, in this case method=128, indicates which LDAPv3 bind method was used by the client. There are three possible bind method values:
128 = simple bind with user password
sasl= SASL bind using external authentication mechanism
Version Number
The version number, in this case version=3, indicates the LDAP version number (either LDAPv2 or LDAPv3) that the LDAP client used to communicate with the LDAP server.
Error Number
The error number, in this case err=0, provides the LDAP result code returned from the LDAP operation performed. The LDAP error number 0 means that the operation was successful. For a more comprehensive list of LDAP result codes see "LDAP Result Codes".
Tag Number
The tag number, in this case tag=97, indicates the type of result returned, which is almost always a reflection of the type of operation performed. The tags used are the BER tags from the LDAP protocol. Commonly used tags include:
tag=97 for a result from a client bind operation
tag=100 indicates the actual entry for which you were searching
tag=101 for a result from a search operation
tag=103 for a result from a modify operation
tag=105 for a result from an add operation
tag=107 for a result from a delete operation
tag=109 for a result from a moddn operation
tag=111 for a result from a compare operation
tag=115 indicates a search reference when the entry you perform your search on holds a referral to the entry you require. Search references are expressed in terms of a referral.
tag=120 for a result from an extended operation
Note tag=100 and tag=115 are not result tags as such. It is unlikely that you will see them in your access log.
Number of Entries
The number of entries, in this case nentries=0, indicates the number of entries that were found matching the LDAP client's request.
Elapsed Time
Elapsed time, in this case etime=1000, indicates the amount of time (in seconds) that it took the directory server to perform the LDAP operation. An etime value of 0 means that the operation actually took milliseconds to perform. If you want to have microsecond resolution for this item in the access log, enter a value of 131328 (256+131072) in the nsslapd-accesslog-level configuration attribute.
LDAP Request Type
The LDAP request type indicates the type of LDAP request being issued by the LDAP client. Possible values are:
LDAP Response Type
The LDAP response type indicates the LDAP response being issued by the LDAP client. Possible values are:
REFERRAL=referral or search reference
Unindexed Search Indicator
The unindexed search indicator, notes=U, indicates that the search performed was unindexed, which means that the database itself had to be directly searched instead of the index file. Unindexed searches occur either when the All IDs Threshold was reached within the index file used for the search, when no index file existed or when the index file was not configured in the way required by the search.
Note An unindexed search indicator is often accompanied by a large etime value, as unindexed searches are generally more time consuming.
Extended Operation OID
An extended operation OID, in this case either EXT oid="2.16.840.1.113730.3.5.3" or EXT oid="2.16.840.1.113730.3.5.5", provides the OID of the extended operation being performed. Table 5-1 provides the list of the LDAPv3 extended operations which are supported iPlanet Directory Server 5.1, and their OIDs.
Change Sequence Number
The change sequence number, in this case csn=3b4c8cfb000000030000, is the replication change sequence number, thus indicating that replication is enabled on this particular naming context.
Abandon Message
The abandon message, in this case, [21/Apr/2001:11:39:52 -0700] conn=12 op=2 ABANDON targetop=1 msgid=2 nentries=0 etime=0, indicates that an operation has been aborted, where nentries=0 indicates the number of entries sent before the operation was aborted, etime=0 value indicates how much time (in seconds) had elapsed, and targetop=1 corresponds to an operation value from a previously initiated operation (that appears earlier in the access log).
There are two possible log ABANDON messages depending on whether the message ID succeeds in locating which operation was to be aborted or not. If the message ID succeeds in locating the operation (the targetop) then the log will read as above. However, if the message ID does not succeed in locating the operation or if the operation had already finished prior to the ABANDON request being sent, then the log will read as follows:
[21/Apr/2001:11:39:52 -0700] conn=12 op=2 ABANDON targetop=NOTFOUND msgid=2
where targetop=NOTFOUND indicates that the operation to be aborted was either an unknown operation or already complete.
Message ID
The message ID, in this case msgid=2, is the LDAP operation identifier, as generated by the LDAP SDK client. The message ID may have a different value to the iPlanet Directory Server Operation Number, but identifies the same operation. The message ID is used in the context of an ABANDON operation and tells the user which client operation is being abandoned.
SASL Multi-Stage Bind Logging
iPlanet Directory Server 5.1 logging for multi-stage binds is now more explicit. Each stage in the bind process is now logged and, where appropriate, the progress statement SASL bind in progress is included.
Access Log Content for Additional Access Logging Levels
This section presents the additional access logging levels available in the iPlanet Directory Server 5.1 access log.
In Code Example 5-2, access logging level 512, which logs access to entries and referrals, is enabled. In this extract, 6 entries and 1 referral are returned in response to the search request in bold.
In Code Example 5-3 access logging level 4, which logs internal operations, is enabled.
Access log level 4 enables logging for internal operations which log the details of the search being performed, and the search base, scope, filter, and requested search attributes.
Connection Description
The connection description, in this case conn=Internal, indicates that the connection is an internal connection. The operation number op=-1 indicates that the operation was initiated internally.
Options Description
The options description, in this case options=persistent, indicates that a persistent search is being performed. Persistent searches can be used as a form of monitoring. They can be configured to return changes to given configurations when changes occur.
Note iPlanet Directory Server 5.1 access log now distinguishes between persistent and regular searches. Previous iPlanet Directory Server releases did not make this distinction.
In Code Example 5-4, both access logging level 512 and 4 are enabled, which results in both internal access operations, as well as entry access and referrals being logged.
Common Connection Codes
A connection code is a code which is added to the closed log message to provide additional information related to the connection closure. Common connection codes include:
A1=Client aborts the connection.
B1=Corrupt BER tag encountered.
If BER tags, which encapsulate data being sent over the wire, are corrupt when they are received, a B1 connection code is logged to the access log. BER tags can be corrupted due to physical layer network problems or bad LDAP client operations, such as an LDAP client aborting before receiving all request results.
B2=BER tag is longer than the nsslapd-maxbersize attribute value. For further information about this configuration attribute, see "nsslapd-maxbersize (Maximum Message Size)".
B3=Corrupt BER tag encountered
B4=Server failed to flush data response back to client
P2=Closed or corrupt connection has been detected.
T1=Client does not receive a result within the specified idletimeout period
T2=Server closed connection after ioblocktimeout period was exceeded
U1= Connection closed by server after client sends an UNBIND request. The server will always close the connection when it sees an UNBIND request. LDAP has a set of result codes that it is useful to be familiar with.
Previous Contents Index DocHome Next
Copyright © 2002 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.
Last Updated February 26, 2002