]> git.ipfire.org Git - thirdparty/openldap.git/commitdiff
(ITS#4770) monitoringslapd.sdf patch from Gavin Henry
authorKurt Zeilenga <kurt@openldap.org>
Fri, 8 Dec 2006 17:18:37 +0000 (17:18 +0000)
committerKurt Zeilenga <kurt@openldap.org>
Fri, 8 Dec 2006 17:18:37 +0000 (17:18 +0000)
doc/guide/admin/master.sdf
doc/guide/admin/monitoringslapd.sdf

index cb29bd28a222daa773ad30b580d4794a23bf3755..9095fced09b5412dc281ae9d3b1a1da3cdc14ca9 100644 (file)
@@ -60,8 +60,8 @@ PB:
 !include "tls.sdf"; chapter
 PB:
 
-#!include "monitoringslapd.sdf"; chapter
-#PB:
+!include "monitoringslapd.sdf"; chapter
+PB:
 
 #!include "tuning.sdf"; chapter
 #PB:
index d34204191472f17c764084f3f359a319a202c667..299cb1f68dd76368d3c30a6ab291ac219bf61ea2 100644 (file)
 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
 H1: Monitoring Slapd
 
-Slapd supports a monitoring interface you can use to find out
-many useful bits of information about what slapd is currently
+{{slapd}} supports a monitoring interface you can use to find out
+many useful bits of information about what {{slapd}} is currently
 doing, how many connections it has, how many threads are
-working, etc. You can access the monitor feature by doing a
-base object search of the SLAPD_MONITOR_DN from
-include/ldapconfig.h with any kind of valid filter (e.g.,
-"(objectclass=*)"). By default, this DN is set to "cn=monitor".
-You will get one entry returned to you, with the following
-attributes:
+working, etc. 
+The monitor backend to {{slapd}} is not an actual database; if enabled, it is 
+automatically generated and dynamically maintained by {{slapd}} with information 
+about the running status of the daemon.
 
-E: version: slapd <version> (<date>)
+To inspect all monitor information, issue a subtree search with base 
+{{EX:cn=Monitor}}, requesting  that  attributes  {{EX:+}} and  {{EX:*}} are 
+returned. The monitor backend produces mostly operational attributes, and LDAP 
+only returns operational attributes that are explicitly requested.  Requesting 
+attribute "+" is  an  extension  which  requests  all operational attributes.
 
-This attribute identifies the slapd server software by name,
-version, and build date, e.g., {{EX: slapd 3.3 (Thu May 21 14:19:03
-EDT 1996)}}
+H2: Configuration
 
-E: threads: <integer>
+These {{slapd.conf}}(5) options apply to the monitor backend database.  That is, 
+they must follow a {{EX:database monitor}} line and come before any subsequent 
+{{backend}} or {{database}} lines.
 
-This attribute indicates the number of threads (operations)
-currently outstanding in slapd.
+As opposed to most databases, the monitor database can be instantiated only 
+once, i.e. only  one  occurrence  of {{EX:database monitor}} can occur in 
+the {{slapd.conf}}(5) file. Moreover, the suffix of the database cannot be 
+explicitly set by means of the suffix directive.  The suffix is automatically 
+set to {{EX:cn=Monitor}}
 
-E: connection: <fd> : <opentime> : <opsinitiated> :
-E:     <opscompleted> : <binddn> : [ <rw> ]
+The monitor backend honors access control semantics as indicated in 
+{{slapd.access}}(5), including the disclose access privilege, on all currently 
+implemented operations.
 
-This multi-valued attribute summarizes information for each
-open connection. The information given is {{EX: <fd>}}, the file
-descriptor; {{EX: <opentime>}}, the time the connection was opened
-in UTC format; {{EX: <opsinitiated>}}, the number of operations
-initiated over the connection; {{EX: <opscompleted>}}, the number
-of operations completed over the connection; {{EX: <binddn>}}, the
-DN currently bound to the connection; and optionally {{EX: <rw>}},
-indicating whether the connection is currently blocked for
-read or write..
+For understanding how to do the following with dynamic configuration, 
+see {{SECT:Configuring slapd}}
 
-E: currentconnections: <integer>
+H3: Enabling the monitor backend
 
-The current number of connections.
+Enable at configure:
 
-E: totalconnections: <integer>
+>   configure --enable-monitor
 
-The total number of connections handled by slapd since it
-started.
+Or if you have enabled modules, put in {{slapd.conf}}(5):
 
-E: dtablesize: <integer>
+>   # Load dynamic backend modules:
+>   modulepath  /usr/local/libexec/openldap
+>   moduleload  back_monitor.la
 
-The size of slapd's file descriptor table.
+Also ensure that the {{core.schema}} file is loaded. The monitor backend 
+relies on some standard track {{attributeTypes}} that must be already defined 
+when the backend is started.
 
-E: writewaiters: <integer>
+H3: Activate the monitor database
 
-The number of threads blocked waiting to write data to a
-client.
+Put this in your {{slapd.conf}}(5) or via the {{config}} backend
 
-E: readwaiters: <integer>
+>   database monitor
 
-The number of threads blocked waiting to read data from a
-client.
+You may also specify a {{rootpw}} below this
 
-E: opsinitiated: <integer>
+H3: Add ACLs
 
-The total number of operations initiated by slapd since it
-started.
+Here's an example you might use:
 
-E: opscompleted: <integer>
+>   access to dn.subtree="cn=Monitor"
+>       by dn.exact="uid=Admin,dc=my,dc=org" write
+>       by users read
+>       by * none
 
-The total number of operations completed by slapd since it
-started.
+More information is detailed in {{slapd.access}}(5)
 
-E: entriessent: <integer>
+H2: Available Subsystems
 
-The total number of entries sent to clients by slapd since it
-started.
+There are various subsytems you can explicitly query for, with most information
+being held in the {{monitoredInfo}} attribute.
 
-E: bytessent: <integer>
+H3: Backends
 
-The total number of bytes sent to clients by slapd since it
-started.
+The main entry contains the type of backends enabled at compile time;
+the subentries, for each backend, contain the type of the backend.
+It should also contain the modules that have been loaded if dynamic 
+backends are enabled.
 
-E: currenttime: <UTC time>
+For example:
 
-Slapd's idea of the current time.
+Backend 1:
 
-E: starttime: <integer>
+>   dn: cn=Backend 1,cn=Backends,cn=Monitor
+>   structuralObjectClass: monitoredObject
+>   monitoredInfo: ldif
+>   monitorRuntimeConfig: TRUE
+>   supportedControl: 2.16.840.1.113730.3.4.2
+>   entryDN: cn=Backend 1,cn=Backends,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
 
-The time slapd was started.
+Backend 2:
 
-E: nbackends: <integer>
+>   dn: cn=Backend 2,cn=Backends,cn=Monitor
+>   structuralObjectClass: monitoredObject
+>   monitoredInfo: hdb
+>   monitorRuntimeConfig: TRUE
+>   supportedControl: 1.3.6.1.1.12
+>   supportedControl: 2.16.840.1.113730.3.4.2
+>   supportedControl: 1.3.6.1.4.1.4203.666.5.2
+>   supportedControl: 1.2.840.113556.1.4.319
+>   supportedControl: 1.3.6.1.1.13.1
+>   supportedControl: 1.3.6.1.1.13.2
+>   supportedControl: 1.3.6.1.4.1.4203.1.10.1
+>   supportedControl: 1.2.840.113556.1.4.1413
+>   entryDN: cn=Backend 2,cn=Backends,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
 
-The number of backends currently being served by slapd.
+Backend 3:
 
-E: concurrency: <integer>
+>   # Backend 3, Backends, Monitor
+>   dn: cn=Backend 3,cn=Backends,cn=Monitor
+>   structuralObjectClass: monitoredObject
+>   monitoredInfo: monitor
+>   monitorRuntimeConfig: TRUE
+>   supportedControl: 2.16.840.1.113730.3.4.2
+>   entryDN: cn=Backend 3,cn=Backends,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
 
-Under Solaris 2.x only, an indication of the current level of
-thread concurrency.
+H3: Connections
 
-Note that slapd takes a snapshot of this information and
-returns it to you. No attempt is made to ensure that the
-information is consistent (i.e., if an operation thread is
-modifying one of these things when the monitor thread is
-reading it, strange results could be returned).
+The main entry is empty; it should contain some statistics on the number 
+of connections.
+
+Dynamic subentries are created for each open connection, with stats on
+the activity on that connection (the format will be detailed later).
+There are two special subentries that show the number of total and
+current connections respectively.
+
+For example:
+
+Total Connections:
+
+>   dn: cn=Total,cn=Connections,cn=Monitor
+>   structuralObjectClass: monitorCounterObject
+>   monitorCounter: 4
+>   entryDN: cn=Total,cn=Connections,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
+
+Current Connections:
+
+>   dn: cn=Current,cn=Connections,cn=Monitor
+>   structuralObjectClass: monitorCounterObject
+>   monitorCounter: 2
+>   entryDN: cn=Current,cn=Connections,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
+
+
+H3: Databases
+
+The main entry contains the naming context of each configured database; 
+the subentries contain, for each database, the type and the naming
+context.
+
+For example:
+
+>   # Database 2, Databases, Monitor
+>   dn: cn=Database 2,cn=Databases,cn=Monitor
+>   structuralObjectClass: monitoredObject
+>   monitoredInfo: monitor
+>   monitorIsShadow: FALSE
+>   monitorContext: cn=Monitor
+>   readOnly: FALSE
+>   entryDN: cn=Database 2,cn=Databases,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
+
+H3: Listener
+
+It contains the description of the devices the server is currently 
+listening on:
+
+>   # Listener 0, Listeners, Monitor
+>   dn: cn=Listener 0,cn=Listeners,cn=Monitor
+>   structuralObjectClass: monitoredObject
+>   monitorConnectionLocalAddress: IP=0.0.0.0:389
+>   entryDN: cn=Listener 0,cn=Listeners,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
+
+
+H3: Log
+
+It contains the currently active log items.  The {{Log}} subsystem allows 
+user modify operations on the {{description}} attribute, whose values {{MUST}} 
+be in the list of admittable log switches:
+
+>   Trace
+>   Packets
+>   Args
+>   Conns
+>   BER
+>   Filter
+>   Config             (useless)
+>   ACL
+>   Stats
+>   Stats2
+>   Shell
+>   Parse
+>   Cache              (deprecated)
+>   Index
+
+These values can be added, replaced or deleted; they affect what 
+messages are sent to the syslog device.
+
+H3: Operations
+
+It shows some statistics on the operations performed by the server:
+
+>   Initiated
+>   Completed
+
+and for each operation type, i.e.:
+
+>   Bind
+>   Unbind
+>   Add
+>   Delete
+>   Modrdn
+>   Modify
+>   Compare
+>   Search
+>   Abandon
+>   Extended
+
+There are too many types to list example here, so please try for yourself 
+using {{SECT: Monitor search example}}
+
+H3: Overlays
+
+The main entry contains the type of overlays available at run-time;
+the subentries, for each overlay, contain the type of the overlay.
+
+It should also contain the modules that have been loaded if dynamic 
+overlays are enabled:
+
+>   # Overlays, Monitor
+>   dn: cn=Overlays,cn=Monitor
+>   structuralObjectClass: monitorContainer
+>   monitoredInfo: syncprov
+>   monitoredInfo: accesslog
+>   monitoredInfo: glue
+>   entryDN: cn=Overlays,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: TRUE
+
+H3: SASL
+
+Currently empty.
+
+H3: Statistics
+
+It shows some statistics on the data sent by the server:
+
+>   Bytes
+>   PDU
+>   Entries
+>   Referrals
+
+e.g.
+
+>   # Entries, Statistics, Monitor
+>   dn: cn=Entries,cn=Statistics,cn=Monitor
+>   structuralObjectClass: monitorCounterObject
+>   monitorCounter: 612248
+>   entryDN: cn=Entries,cn=Statistics,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
+
+H3: Threads
+
+It contains the maximum number of threads enabled at startup and the 
+current backload.
+
+e.g.
+
+>   # Max, Threads, Monitor
+>   dn: cn=Max,cn=Threads,cn=Monitor
+>   structuralObjectClass: monitoredObject
+>   monitoredInfo: 16
+>   entryDN: cn=Max,cn=Threads,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
+
+
+H3: Time
+
+It contains two subentries with the start time and the current time 
+of the server.
+
+e.g.
+
+Start time:
+
+>   dn: cn=Start,cn=Time,cn=Monitor
+>   structuralObjectClass: monitoredObject
+>   monitorTimestamp: 20061205124040Z
+>   entryDN: cn=Start,cn=Time,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
+
+Current time:
+
+>   dn: cn=Current,cn=Time,cn=Monitor
+>   structuralObjectClass: monitoredObject
+>   monitorTimestamp: 20061207120624Z
+>   entryDN: cn=Current,cn=Time,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
+
+H3: TLS
+
+Currently empty.
+
+H3: Waiters
+
+It contains the number of current read waiters.
+
+e.g.
+
+Read waiters:
+
+>   dn: cn=Read,cn=Waiters,cn=Monitor
+>   structuralObjectClass: monitorCounterObject
+>   monitorCounter: 7
+>   entryDN: cn=Read,cn=Waiters,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
+
+Write waiters:
+
+>   dn: cn=Write,cn=Waiters,cn=Monitor
+>   structuralObjectClass: monitorCounterObject
+>   monitorCounter: 0
+>   entryDN: cn=Write,cn=Waiters,cn=Monitor
+>   subschemaSubentry: cn=Subschema
+>   hasSubordinates: FALSE
+
+H2: Monitor search example
 
 You should be able to use any LDAP client to retrieve this
 information. Here's how you might do it using the
 {{I: ldapsearch}}(1) client:
 
-E: ldapsearch -x -s base -b cn=monitor 'objectclass=*'
-
+>   ldapsearch -x -s base -b cn=monitor 'objectclass=*' +