All modern enterprise LDAP servers have a cn=monitor branch which can be used to fetch server statistics. Many of the statistics presented under cn=monitor are very useful for diagnosing server problems and better yet for predicting problems before they happen.

The “cn=monitor” branch can be accessed using the LDAP protocol. Search under “cn=monitor” including operational attributes with your search. For example, this command should show you your entire cn=monitor branch, assuming your ~/.ldaprc is configured with a proper BINDDN and URI and the passsword credential is in an ~/.ldappw file:

ldapsearch -x -y ~/.ldappw  -b “cn=Monitor” -s sub +|more

Note that sometimes the attributes listed under cn=monitor are operational attributes and therefore must be search for explicitly or by designating that the search return all operational attributes (for example, OpenLDAP). Because these counter instruments are available via the LDAP protocol, it is easy to script the collection of them over time at precise intervals. This data can be used for real-time or post-incident server information mining, as well as plotting visual representation of traffic shapes. Highly recommended is the tool on sourceforge.net named “cn=monitor”.

Some of the key entries with the OpenLDAP server’s cn=montor to pay attention to are:

cn=connections, cn=monitor: This branch has information about active connections. You can see all sorts of information about each current LDAP connection using the following attributes: “monitorConnectionStartTime”, “monitorConnectionActivityTime”, “monitorConnectionLocalAddress” (the IP address of the client). A “monitorConnectionMask=r” means it is a read connection. The attribute “monitorConnectionOpsReceived” reports how many operations the server has received on this connection; to see completed operations, search for “monitorConnectionOpsCompleted”. The difference between “monitorConnectionOpsReceived”and “monitorConnectionOpsCompleted” should be in “monitorConnectionOpsExecuting” and in “monitorConnectionOpsPending”. By checking “monitorConnectionAuthzDN”, you can see what DN is bound to the connection. And by checking the monitorConnectionNumber, you can correlate the cn=connections,cn=monitor info with your access log entries.

cn=databases,cn=monitor: This branch contains basic information about your database backends. Most, or all, of this information can also be found in the configuration. There isn’t much realtime instrumentation here, just server configuration information.

cn=listeners,cn=monitor: This branch shows which listeners (SSL, TLS, localhost, or IP-bound) are active. Most of this information can also be found in the configuration or startup script (or by checking the running process), but it’s nice to have it here for quick reference and verification for running processes.

cn=operations,cn=monitor: This branch is very useful. It contains some “monitorOpInitiated” and “monitorOpCompleted” total server operation counters at its base level. Sublevel to cn=operations,cn=monitor are subbranches for each type of LDAP operation, and monitorOpInitiated and monitorOpCompleted for each. For example, to see how many successful binds have occurred since the server startup, check the cn=Bind,cn=Operations,cn=Monitor entry’s monitorOpCompleted attribute.

cn=overlays,cn=monitor: This just shows the overlays available at run-time.

cn=statistics,cn=monitor: There are four important subentries here: cn=bytes, cn=entries, cn=PDU, and cn=referrals. Each has a “monitorCounter” attribute so you can check the number of bytes total traffic for the server since startup. Similarily, “cn=entries” shows total server entries operated on since startup. The entry “cn=PDU” is for ASN.1 “protocol data units” which won’t generally be as practically useful to an operations team as the entries and bytes count. The “cn=referrals” is obviously the count of the referrals since startup.

One more TIP: By the way, sometimes you might want to know the branches (or, “namingcontexts” available) on your LDAP server. In this case you can search the RootDSE entry, by setting your base to “” (null) and your scope to base, like this:

ldapsearch -H ldap://localhost:3892 -x -y ~/.ldappw2  -b “” -s base namingcontexts

© Copyright 2020 Rex Consulting, Inc. – All rights reserved