Oracle Unified Directory provides an extensible monitoring framework. This chapter provides an overview of the monitoring functionality, and describes how to configure monitoring. When the monitoring framework has been configured, you can view the statistics on a server instance, or replicated topology.
This chapter covers the following topics:
Section 29.4, "Configuring Alerts and Account Status Notification Handlers"
Section 29.8, "General Purpose Enterprise Monitoring Solutions"
Monitoring information and performance data can be found in:
logs
For information about configuring logs, see Section 29.3, "Configuring Logs".
alerts
For information about configuring alerts, see Section 29.4, "Configuring Alerts and Account Status Notification Handlers".
cn=monitor
For information about cn=monitor
, see Section 29.5, "Monitoring the Server With LDAP".
DIRECTORY_SERVER_MIB, defined by RFC 2605
For information about monitoring the server with SNMP, see Section 29.6, "Monitoring the Server With SNMP".
To access the monitoring information, ensure that you have the required protocol:
For logs you need a file system.
For alerts you need JMX:RMI or SMTP.
For cn=monitor
you need LDAP or JMX:RMI (for example jconsole).
For DIRECTORY_SERVER_MIB you need SNMP.
Monitor providers are enabled by default and provide information about the server that can be useful for monitoring or troubleshooting purposes. The cn=monitor
entry contains the monitoring information that is published by the monitor providers. When the monitor provider is disabled, the provided information is no longer available under cn=monitor
.
Monitor providers can be configured by using the dsconfig
command. For more information, see Section 14.1, "Managing the Server Configuration With dsconfig
".
Run the dsconfig
command with the list-monitor-providers
subcommand, as follows:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ list-monitor-providers Monitor Provider : Type : enabled -------------------:-------------------:-------- Client Connections : client-connection : true Entry Caches : entry-cache : true JVM Memory Usage : memory-usage : true JVM Stack Trace : stack-trace : true System Info : system-info : true Version : version : true
Run the dsconfig
command with set-monitor-provider-prop
as follows:
For example, to set the JVM Stack Trace monitor provider to false, use the following command:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-monitor-provider-prop --provider-name "JVM Stack Trace" \ --set enabled:false
Running the dsconfig
command with the list-monitor-providers
subcommand now shows the JVM Stack Trace monitor provider as false:
Monitor Provider : Type : enabled -------------------:-------------------:-------- Client Connections : client-connection : true Entry Caches : entry-cache : true JVM Memory Usage : memory-usage : true JVM Stack Trace : stack-trace : false System Info : system-info : true Version : version : true
Oracle Unified Directory provides several types of logs: access logs, audit logs, error logs, debug logs, and a replication repair log. The replication repair log is read-only and its use is restricted to enabling replication conflict resolution. The following sections describe how to configure access, audit, error, and debug logs by using the dsconfig
command-line interface or Oracle Directory Services Manager. In addition, the section describes how to log admin operations.
For a breakdown of the result codes found in the logs, see Section D.17.11, "result code."
This section contains the following topics:
The easiest way to configure logging with dsconfig
is to use the command in interactive mode, which walks you through the configuration. This section provides the required commands in non-interactive mode, so that you can see the specific parameters that are set. For more information about dsconfig
, see Section 14.1, "Managing the Server Configuration With dsconfig
".
Log configuration includes the definition of three configuration objects:
Log publisher. A log publisher is defined for each logger. The log publisher type corresponds to the type of log. For more information about log publishers, see Section 29.3.1.1, "Configuring Log Publishers".
Log retention policy. The retention policy determines how long archived log files are stored. For more information about log retention policies, see Section 29.3.1.2, "Configuring Log Retention Policies".
Log rotation policy. The rotation policy determines how often log files are rotated. For more information on log rotation policies, see Section 29.3.1.3, "Configuring Log Rotation Policies".
Oracle Unified Directory provides several log publishers by default.
Any number of log publishers of any type can be defined and active at any time. This means that you can log to different locations or different types of repositories and that you can specify various sets of criteria for what to include in the logs.
For more information about the configuration properties associated with log publishers, see the Oracle Unified Directory Configuration Reference.
This section covers the following topics:
To view the existing log publishers run the following dsconfig
command:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ list-log-publishers
The default output will be similar to the following:
Log Publisher : Type : enabled -------------------------------:-------------------:-------- File-Based Access Logger : file-based-access : true File-Based Admin Access Logger : file-based-access : true File-Based Audit Logger : file-based-access : false File-Based Debug Logger : file-based-debug : false File-Based Error Logger : file-based-error : true Oracle Access Logger : file-based-access : false Oracle Error Logger : file-based-error : false Replication Repair Logger : file-based-error : true
To display the properties of a log publisher run the following dsconfig
command:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ get-log-publisher-prop --publisher-name "File-Based Error Logger"
Not all of the log publishers are enabled by default. If a log publisher is disabled, messages of that type are not logged.
To enable a log publisher, set its enabled property to true. For example, to enable the audit logger, run the following command:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-log-publisher-prop --publisher-name "File-Based Audit Logger" \ --set enabled:true
When a log publisher is enabled, the server immediately starts logging messages to the appropriate publisher. You do not need to restart the server for this change to take effect.
Oracle Unified Directory also writes diagnostic log files in the Oracle Diagnostic Logging (ODL) format.
ODL is disabled by default. To enable ODL, set the enabled
property of the ODL Access Log publisher or the ODL Error Log publisher to true
. The following example enables the access logger:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-log-publisher-prop --publisher-name "Oracle Access Logger" \ --set enabled:true
To enable the error logger, use --publisher-name "Oracle Error Logger"
.
ODL access logs are stored in the following file:
instance_dir/OUD/logs/access.log
ODL error logs are stored in the following directory:
instance_dir/OUD/logs/errors.log
Note that the standard access and error loggers are not disabled when you enable the ODL loggers. You should therefore disable the standard access and error logs after you enable the ODL loggers, unless you specifically want to maintain logs in both formats.
For more information about ODL, including an explanation of the log file format, see "Managing Log Files and Diagnostic Data" in the Oracle Fusion Middleware Administrator's Guide.
By default, the suppress-internal-logging
property for log publishers is set to true
. If you need to log internal operations (such as operations performed by the LDIF connection handler and certain plug-ins), set suppress-internal-logging
to false
. The following example sets suppress-internal-logging
to false
for the file-based access logger:
dsconfig set-log-publisher-prop \ --publisher-name File-Based\ Access\ Logger \ --add operations-to-log:internal \ --hostname localhost \ --port 4444 \ -X \ --bindDN cn=directory\ manager \ --bindPasswordFile /tmp/password \ --no-prompt
By default, Oracle Unified Directory automatically renames (rotates) its local server log file using date stamp in GMT format.
You can change these default settings for log file rotation. You can configure a server instance to include a local time stamp in the file name of rotated log files.
To configure the log file names using local time stamp, you must set the log-file-use-local-time
property of the appropriate log publisher to true
. The following example describes how to set up the local time stamp in the the file name of access rotated log files:
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-log-publisher-prop --publisher-name "Oracle Access Logger" \ --set log-file-use-local-time:true
Note:
The rotated log file name using local time stamp follows the format used by Oracle Directory Server Enterprise Edition to ensure compatibility.
Log retention policies dictate size and space limits for log files. Oracle Unified Directory provides the following three log retention policies:
File count retention (file-count
). By default, this policy sets the maximum number of log files to 10, for a specified type of log file.
Free disk space retention (free-disk-space
). By default, this policy sets a minimum remaining free disk space limit to 500 Mb, for a specified type of log file.
Size limit retention (size-limit
). By default, this policy sets the disk spaced used to a maximum of 500 Mb, for a specified type of log file.
By default, the log retention policy that is enabled is File count retention.
You can also create your own custom log retention policies.
To view a list of the existing log retention policies run the following dsconfig
command:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ list-log-retention-policies
The default output will be similar to the following:
Log Retention Policy : Type : disk-space-used : free-disk-space : number-of-files ---------------------------------:-----------------:-----------------:-----------------:---------------- File Count Retention Policy : file-count : - : - : 10 Free Disk Space Retention Policy : free-disk-space : - : 500 mb : - Size Limit Retention Policy : size-limit : 500 mb : - : -
To list the log retention policy properties run the following dsconfig
command
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
get-log-retention-policy-prop --policy-name "Free Disk Space Retention Policy"
To create a log retention policy, and to set it as enabled, type:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -w pwd-file -X -n
create-log-retention-policy --policy-name MyMaxDiskSpace \
--type size-limit --set disk-space-used:100mb
To modify the properties of an existing log retention policy run the following dsconfig
command:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -w pwd-file -X -n \
set-log-retention-policy-prop --policy-name "File Count Retention Policy" \
--set number-of-files:20
Instead of setting a property value, you can add, reset or remove a property value, using the --add
, --reset
, or --remove
subcommands instead of the --set
subcommand. For details, see Section A.2.4, "dsconfig".
Log rotation policies dictate how often the files are rotated, that is to say, how long log files are kept based on various criteria. Oracle Unified Directory provides the following four log rotation policies:
24 Hours time limit rotation policy. By default, this policy sets the rotation interval to one day. Time of day can be configured.
7 Days time limit rotation policy. By default, this policy sets the rotation interval to one week. Time of day can be configured.
Fixed time limit rotation policy. By default, this policy sets the time of day that log files are to be rotated, to one minute before midnight.
Size time limit rotation policy. By default, this policy sets a maximum size that log files can reach to 100 Mb, before the log file is rotated.
The type of log rotation policy enabled by default depends on the log type.
For access and audit logs, the following are enabled:
24 Hours time limit rotation policy
Size time limit rotation policy
For error and replication repair logs, the following are enabled:
7 Days time limit rotation policy
Size time limit rotation policy
You can create your own custom log rotation policies.
Note:
When multiple rotation policies are specified for the same log, the first threshold that is reached triggers the rotation.
To view a list of the existing log rotation policies run the following dsconfig
command:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -w pwd-file -X -n \
list-log-rotation-policies
The default output will be similar to the following:
Log Rotation Policy : Type : file-size-limit : rotation-interval : time-of-day ------------------------------------:------------:-----------------:-------------------:------------ 24 Hours Time Limit Rotation Policy : time-limit : - : 1 d : - 7 Days Time Limit Rotation Policy : time-limit : - : 1 w : - Fixed Time Rotation Policy : fixed-time : - : - : 2359 Size Limit Rotation Policy : size-limit : 100 mb : - : -
To display the log rotation policy properties, run the following command:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -w pwd-file -X -n \
get-log-rotation-policy-prop "Fixed Time Rotation Policy"
To create a log rotation policy run the following dsconfig
command:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -w pwd-file -X -n \
create-log-rotation-policy --policy-name my2DayPolicy \
--type time-limit --set rotation-interval:2d
The policy type can be one of the following:
size-limit
fixed-time
time-limit
To set a rotation or retention policy on a specific log file, you must create a log publisher and set the log rotation or log retention policy.
To set log rotation or retention for a specific log file run the following dsconfig
command:
$ dsconfig -h localhost -p 1444 -D "cn=Directoy manager" -j pwd-file -n -X \ create-log-publisher --publisher-name myPublisher \ --type file-based-access --set log-file:logs/myLogs --set enabled:true \ --set retention-policy:MyMaxDiskSpace --set rotation-policy:my2DayPolicy
This section describes how to use ODSM to configure logs. It contains the following topics:
Oracle Unified Directory provides several log publishers, or loggers, by default. Any number of loggers of any type can be defined and active at any time. This means that you can log to different locations or different types of repositories and that you can specify various sets of criteria for what to include in the logs.
You cannot create a new log publisher with ODSM, but you can modify the properties of an existing log publisher.
To configure logger properties by using ODSM, complete the following steps:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."
Select the Configuration tab.
Expand the General Configuration element.
Expand the Logging element.
Expand the Loggers element and click on the logger whose properties you want to modify.
The properties of the logger are displayed in the right hand pane. The configurable properties will depend on the type of logger that you have selected. For a comprehensive list of all configurable properties and their allowed values, see the Oracle Unified Directory Configuration Reference.
Oracle Unified Directory provides the following general configuration policies depending on the type of logger you have selected:
Enabled. It indicates whether the Log Publisher is enabled for use.
Log Publisher File Location. It specifies the file name to use for the log files generated by the File-Based Access Log Publisher. The path to the file is relative to the server root.
Log Publisher Permissions. It indicates the UNIX permissions of the log files created by this File-Based Access Log Publisher.
Operations to Log. It indicates which operations must be logged.
This property is only available for the access and audit log publishers.
Log Request and Response Controls. It indicates whether the request controls and response controls should be logged along with the operations that are requested by the client applications.
This property is only available for the access and audit log publishers.
Default Severity. It specifies the default severity levels for the logger.
This property is only available for the error log publishers.
Default Debug Level. It specifies the lowest severity level of debug messages to log when none of the defined targets match the message.
This property is only available for the debug log publishers.
For a comprehensive list of all configurable properties and their allowed values for each logger, see the Oracle Unified Directory Configuration Reference.
Note:
You can configure the log rotation and log retention policies for the logger that you select in Step 5. For more information about configuring log rotation and log retention policies, see Section 29.3.2.2, "Modify Log Rotation Policies" and Section 29.3.2.3, "Modify Log Retention Policies."
Log rotation policies dictate how often log files are rotated, that is to say, how long log files are kept based on various criteria.
Oracle Unified Directory provides the following four log rotation policies:
24 Hours time limit rotation policy. By default, this policy sets the rotation interval to one day. Time of day can be configured.
7 Days time limit rotation policy. By default, this policy sets the rotation interval to one week. Time of day can be configured.
Fixed time limit rotation policy. By default, this policy sets the time of day that log files are to be rotated, to one minute before midnight.
Size time limit rotation policy. By default, this policy sets a maximum size that log files can reach to 100 Mb, before the log file is rotated.
The type of log rotation policy that is enabled by default depends on the logger type.
You can configure log rotation policies by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."
Select the Configuration tab.
Expand the General Configuration element.
Expand the Logging element.
Select the Rotation Policies element and modify the required properties.
You can also add a new rotation policy or delete an existing rotation policy by clicking the Add or Delete icons on this page, and completing the required information.
Log retention policies dictate size and space limits for log files. Oracle Unified Directory provides the following three log retention policies by default:
File count retention (file-count). By default, this policy sets the maximum number of log files to 10, for a specified type of log file.
Free disk space retention (free-disk-space). By default, this policy sets a minimum remaining free disk space limit to 500 Mb, for a specified type of log file.
Size limit retention (size-limit). By default, this policy sets the disk spaced used to a maximum of 500 Mb, for a specified type of log file. By default, the log retention policy enabled is File count retention.
You can configure log retention policies by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."
Select the Configuration tab.
Expand the General Configuration element.
Expand the Logging element.
Select the Retention Policies element and modify the required properties.
You can also add a new retention policy or delete an existing retention policy by clicking the Add or Delete icons on this page, and completing the required information.
Oracle Unified Directory provides a new parameter to specify the operations to log. This section describes the this new configuration parameter, and contain the following topics:
Oracle Unified Directory provides a mechanism for separating admin logs from user logs by means of Admin connector. Administration operations are now logged into a separate file that provides logging information associated with the administration traffic.
Note:
Oracle Unified Directory out-of-the-box supports a dedicated access logger, namely File-Based Admin Access Logger
, which contains only operations of the administrator connector. Therefore, you don't have to perform any action specific action to log administration operations into a separate file.
You can configure the access logs to specify the type of operation to log using operations-to-log
property. This property is optional, and has the following configurable values:
SYNCHRONIZATION
INTERNAL
ADMINISTRATION
USER
ADMIN_BROWSING
ALL
In that sense, Oracle Unified Directory supports the following operation types:
Synchronization Operations
Synchronization operations, such as locks, process synchronization, attribute mapping and transformation.
Internal Operations
Internal operations are internal, because they are initiated not by external requests from clients, but instead internally by plug-ins. You must use internal operation calls when the plug-in needs Directory Server to perform an operation for which no client request exists.
Administration Operations
Administration operations are performed on the admin network group, excluding operations associated with network group selection control.
User Operations
User operations are performed on any user network group, excluding operations associated with network group selection control.
Admin Browsing Operations
Admin browsing operations are associated with the network group selection control. This excludes operations associated with network group dependency.
Note:
Operations handled by network group that are created by a user and accessing admin suffixes is considered as User operations.
ODSM groups the log publisher properties into three different headers, namely Logger General Properties, Rotation and Retention Properties, and Advanced Properties depending on the nature and behavior of the property. The Logger General Properties region is visible by default for all loggers and allows you to configure operations to log for file-based access loggers.
You can configure operations to log in Access Log Publishers using ODSM, as follows:
Connect to the directory server or directory proxy server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."
Select the Configuration tab.
Expand the General Configuration element.
Expand the Logging element.
Expand the Loggers element.
Click the file-based access logger that you want to modify, for instance File-Based Admin Access Logger.
In the Logger General Properties region, perform the following step:
From the Operation to Log list, select the operations to log.
Click Apply.
Oracle Unified Directory provides mechanisms for transmitting alert and account status notifications by means of JMX extensions or SMTP extensions. You can configure the directory server to send alert notifications when an event occurs during processing. Typical server events include server starts and shut downs, or problems that are detected by the server, such as an attempt to write to the configuration file.
You can also receive account status notifications when an event occurs during password policy processing, such as when accounts are locked out, accounts expire, passwords expire, and so on.
Alerts and account status notification handlers are configured by using the dsconfig
command. For more information, see Section 14.1, "Managing the Server Configuration With dsconfig
".
For additional information about the topics in this section, see Chapter 24, "Managing Password Policies" and "The Alert Handler Configuration" in the Oracle Unified Directory Configuration Reference.
Oracle Unified Directory provides mechanisms for transmitting alert and account status notifications by means of JMX extensions or SMTP extensions.
You can configure Oracle Unified Directory to send alert notifications when an event occurs during processing. Typical server events include server starts and shut downs, or problems that are detected by the server, such as an attempt to write to the configuration file. You can also receive account status notifications when an event occurs during password policy processing, such as when accounts are locked out, accounts expire, passwords expire, and so on.
Oracle Unified Directory supports the following alert handlers:
JMX alert handler for JMX notifications
SMTP alert handler for email notifications.
The following topics describe how to manage the alert handler configuration:
dsconfig
The following sections describe how to manage the alert handler configuration by using dsconfig. For information about configuring alerts by using the ODSM interface, see Section 29.4.1.2, "Managing Alert Handlers by Using ODSM".
This section contains the following topics:
Oracle Unified Directory stores alert handlers information in the configuration file under the cn=Alert Handlers,cn=config
subtree. You can access the information using the dsconfig
command.
To display a list of alert handlers, run the following dsconfig
command:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ list-alert-handlers Alert Handler : Type : enabled ------------------:------:-------- JMX Alert Handler : jmx : false
The JMX alert handler is disabled by default. Before you begin, you must configure JMX on the server. For more information, see Section 29.5.3, "Monitoring the Server With JConsole".
To list the alert handler's properties, use the dsconfig
command as follows.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-alert-handler-prop --handler-name "JMX Alert Handler" Property : Value(s) --------------------:--------------------------------------------- disabled-alert-type : - enabled : false enabled-alert-type : -
To enable the alert handler, use dsconfig
as follows.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-alert-handler-prop --handler-name "JMX Alert Handler" --set enabled:true
Verify the change by using dsconfig
.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-alert-handler-prop --handler-name "JMX Alert Handler" Property : Value(s) --------------------:--------------------------------------------- disabled-alert-type : - enabled : true enabled-alert-type : -
The following example configures a new SMTP handler. Before starting this procedure, you must have configured an SMTP server for Oracle Unified Directory.
To create an alert handler run dsconfig
with the create-alert-handler
subcommand.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ create-alert-handler --handler-name "my SMTP Handler" --type smtp \ --set enabled:true --set message-body:"Alert Type: %%alert-type%% \n\nAlert ID: %%alert-id%%\n\nAlert Message: %%alert-message%%" \ --set message-subject:"Alert Message" \ --set recipient-address:directorymanager@example.com \ --set sender-address:OUD-Alerts@directory.example.com
View the list of alert handlers as follows.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ list-alert-handlers
To delete an alert handler, use the dsconfig delete-alert-handler
command. The following example removes the JMX alert handler.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ delete-alert-handler --handler-name "JMX Alert Handler"
You can simply disable an alert handler instead of deleting it. In this case, the alert handler is available if you need to enable it again in the future. For more information, see Section 29.4.1.1.5, "To Control the Allowed Alert Types".
For a list of all supported alert types, see Section 29.4.1.3, "Supported Alert Types".
By default, all the supported alert types are allowed. If you specify a value for the enabled-alert-type
property, only alerts with one of those types are allowed. If you specify a value for the disabled-alert-type
property, all alert types except for the values in that property are allowed. Alert types are specified by their Java class, as shown in this example.
To disable an alert type, specify its Java class as a value of the disabled-alert-type
property.
This command disables the startup alert from the JMX Alert Handler.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-alert-handler-prop --handler-name "JMX Alert Handler" \ --set disabled-alert-type:org.opends.server.DirectoryServerStarted
The following sections describe how to manage the alert handler configuration by using ODSM. For information about configuring alert handlers by using dsconfig
, see Section 29.4.1.1, "Managing Alert Handlers by Using dsconfig
".
To create an alert handler by using ODSM, follow these steps:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."
Select the Configuration tab.
From the Create menu, select Alert Handler.
Select the type of alert handler that you want to create:
JMX. This alert handler is used to generate JMX notifications to alert administrators of significant events that occur within the server.
SMTP. This alert handler is used to send e-mail messages to notify administrators of significant events that occur within the server.
Enter the properties to configure the connection handler in the right hand pane.
The configurable properties will depend on the type of alert handler that you have selected. For a comprehensive list of all configurable properties, and their allowed values, see "The Alert Handler Configuration" in the Oracle Unified Directory Configuration Reference.
Note:
By default, all alert types are allowed. If you specify one or more values in the Enabled Alert Type field, only alerts with one of those types are allowed. If you specify one or more values in the Disabled Alert Type field, all alert types except for the values in that field are allowed.
For a list of all supported alert types, see Section 29.4.1.3, "Supported Alert Types".
When you have configured the required properties for your specific alert handler type, click Create.
You can use ODSM to modify an existing alert handler, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."
Select the Configuration tab.
Expand the General Configuration element.
Expand the Alert Handlers element.
Select the alert handler whose properties you want to modify.
The properties are display in the right hand pane.
When you have modified the required properties, click Apply.
You can use ODSM to modify an existing alert handler, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."
Select the Configuration tab.
Expand the General Configuration element.
Expand the Alert Handlers element.
Select the alert handler that you want to delete and click the Delete configuration icon.
You are prompted to confirm the deletion. Click Yes.
The server sends out message alerts when an alert type event occurs in the system. The supported alert types are defined in the following table.
Alert Type | Description |
---|---|
Access Control Disabled Java Class: |
Notify administrator that the access control handler has been disabled. |
Access Control Enabled Java Class: |
Notify administrator that the access control handler has been enabled. |
Access Control Parse Failed Java Class: |
Notify administrator if the Oracle Directory Server Enterprise Edition compatible access control subsystem failed to correctly parse one or more ACI rules when the server is first started. |
Backend Environment Unusable Java Class: |
Notify administrator that the JE back end throws a |
Cannot Copy Schema Files Java Class: |
Notify administrator if a problem occurs while attempting to create copies of the existing schema configuration before making a schema update, and the schema configuration is left in a potentially inconsistent state. |
Cannot Find Recurring Task Java Class: |
Notify administrator if the directory server is unable to locate a recurring task definition in order to schedule the next iteration once the previous iteration has completed. |
Cannot Rename Current Task File Java Class: |
Notify administrator if the directory server is unable to rename the current tasks backing file in the process of trying to write an updated version. |
Cannot Rename New Task File Java Class: |
Notify administrator if the directory server is unable to rename the new tasks backing file into place. |
Cannot Schedule Recurring Iteration Java Class: |
Notify administrator if the directory server is unable to schedule an iteration of a recurring task. |
Cannot Write Configuration Java Class: |
Notify administrator if the directory server is unable to write its updated configuration for some reason and so the server cannot exhibit the new configuration if it is restarted. |
Cannot Write New Schema Files Java Class: |
Notify administrator if a problem occurs while attempting to write new versions of the server schema configuration files, and the schema configuration is left in a potentially inconsistent state. |
Cannot Write Task File Java Class: |
Notify administrator if the directory server is unable to write an updated tasks backing file for some reason. |
Distribution Backend Does Not Support PreRead Control Java Class: |
Notify administrators if the distribution is unable to maintain the content of the global index catalog. This will happen \ if one or more servers do not support the Pre-Read Entry Control (RFC 4527) |
Entering Lockdown Mode Java Class: |
Notify administrator that the directory server is entering lockdown mode, in which only root users will be allowed to perform operations and only over the loopback address. |
LDAP Connection Handler Consecutive Failures Java Class: |
Notify administrator of consecutive failures that have occurred in the LDAP connection handler that have caused it to become disabled. |
LDAP Connection Handler Uncaught Error Java Class: |
Notify administrator of uncaught errors in the LDAP connection handler that have caused it to become disabled. |
LDAP Server Extension Failed Java Class: |
Notify administrator that the LDAP Server Extension has been detected as Down. |
LDAP Server Extension is Up Java Class: |
Notify administrator that the LDAP Server Extension has been detected as UP. |
LDIF Backend Cannot Write Update Java Class: |
Notify administrator that an LDIF back end was unable to store an updated copy of the LDIF file after processing a write operation. |
LDIF ConnHandler Parse Error Java Class: |
Notify administrator that the LDIF connection handler encountered an unrecoverable error while attempting to parse an LDIF file. |
LDIF ConnHandler IO Error Java Class: |
Notify administrator that the LDIF connection handler encountered an I/O error that prevented it from completing its processing. |
Leaving Lockdown Mode Java Class: |
Notify administrator that the directory server is leaving lockdown mode. |
Manual Config Edit Handled Java Class: |
Notify administrator if the directory server detects that its configuration has been manually edited with the server online and those changes were overwritten by another change made through the server. The manually-edited configuration will be copied off to another location. |
Manual Config Edit Lost Java Class: |
Notify administrator if the directory server detects that its configuration has been manually edited with the server online and those changes were overwritten by another change made through the server. The manually-edited configuration could not be preserved due to an unexpected error. |
New route elected by the SaturationLoadBalancingAlgorithm Java Class: |
Notify administrator that a new route has been elected as active route by the saturation load balancing algorithm. |
New route elected by the FailoverLoadBalancingAlgorithm Java Class: |
Notify administrator that a new route has been elected as the active route by the failover load balancing algorithm. |
Replication Unresolved Conflict Java Class: |
Notify administrator if the multimaster replication cannot automatically resolve a conflict. |
Server Started Java Class: |
Notify administrator that the directory server has completed its startup process. |
Server Shutdown Java Class: |
Notify administrator that the directory server has begun the process of shutting down. |
State change for a Saturation Load Balancing Route Java Class: |
Notify administrator that the saturation load balancing route state has changed (either from saturated to not saturated or from not saturated to saturated). |
Uncaught Exception Java Class: |
Notify administrator if a directory server thread has encountered an uncaught exception that caused the thread to terminate abnormally. The impact that this problem has on the directory server depends on which thread was impacted and the nature of the exception. |
Unique Attr Sync Conflict Java Class: |
Notify administrator that a unique attribute conflict has been detected during synchronization processing. |
Unique Attr Sync Error Java Class: |
Notify administrator that an error occurred while attempting to perform unique attribute conflict detection during synchronization processing. |
Unsupported Directory Backend Java Class: |
Notify administrator that the distribution is unable to maintain the content of the global index catalog. This will happen if one or more servers do not support the Pre-Read Entry Control (RFC 4527). |
Account status notification handlers provide alerts on events during password policy processing. By default, the Error Log Account Status Notification handler is set to enabled upon initial configuration. The server writes a message to the server error log when one of the following events has been configured in the password policy and occurs during the course of password policy processing:
account-temporarily-locked
account-permanently-locked
account-unlocked
account-idle-locked
account-reset-locked
account-disabled
account-expired
password-expired
password expiring
password-reset
password-changed
The error log is located at instance-dir/OUD/logs/errors
.
Use dsconfig
with the list-account-status-notification-handlers
subcommand.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ list-account-status-notification-handlers Account Status Notification Handler : Type : enabled ------------------------------------:-----------:-------- Error Log Handler : error-log : true SMTP Handler : smtp : false
You can enable an existing account status notification handler using the dsconfig
command. By default, the directory server enables the Error Log Handler when the server is initially configured. This example enables the SMTP notification handler.
To view the enabled
property use dsconfig
with the get-account-status-notification-handler-prop
subcommand.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-account-status-notification-handler-prop --handler-name "SMTP Handler" \ --property enabled Property : Value(s) ---------:--------- enabled : false
To enable the notification handler use dsconfig
with the set-account-status-notification-handler-prop
subcommand.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-account-status-notification-handler-prop --handler-name "SMTP Handler" \ --set property:enabled
Use dsconfig
with the create-account-status-notification-handler
subcommand to create the handler.
When you specify the type, you can use either error-log
or generic
(default).
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ create-account-status-notification-handler \ --handler-name "My Password Reset Logger" --type error-log \ --set enabled:true --set account-status-notification-type:password-reset
Use dsconfig
to view the list of account status notification handlers.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ list-account-status-notification-handlers Account Status Notification Handler : Type : enabled ------------------------------------:-----------:-------- Error Log Handler : error-log : true my Password Reset Logger : error-log : true SMTP Handler : smtp : false
You can disable an account status notification handler instead of deleting it. In this case, the alert handler is available if you need to enable it again in the future.
You can remove an account status notification handler entirely by using dsconfig
.
Use dsconfig
with the delete-account-status-notification-handler
subcommand.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ delete-account-status-notification-handler \ --handler-name "My Password Reset Logger"
Oracle Unified Directory provides a variety of methods to monitor the current state of the server for debugging or troubleshooting purposes.
The topics in this section assume that you have configured monitoring providers on the server. For more information, see Section 29.2, "Configuring Monitor Providers".
You can monitor the server over LDAP in several ways. These are described in the following sections:
cn=monitor
EntryThe directory server records system, performance, and version information as an entry with the base DN of cn=monitor
. This entry provides useful performance metrics and server state information that you can use to monitor and debug a directory server instance.
You can access the cn=monitor
suffix over the administration port only. There are advantages to using the administration port to access monitoring information. The main advantage of the administration connector is the separation of user traffic and administration traffic.
For example, if you monitor the number of connections on the LDAP Connection Handler ("cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port port-number,cn=monitor"
) over the regular LDAP port, your monitoring data are "polluted" by the monitoring request itself. All of the examples in this section use the administration port, over SSL. For more information, see Section 14.3, "Managing Administration Traffic to the Server".
Monitoring information related to the proxy can be collected at the level under cn=Monitor
for dozens of attributes, including those relating to the following:
Workflows: cn=workflow,cn=monitor
Network Groups: cn=Network Groups,cn=monitor
Load balancers: cn=load balancing,cn=monitor
Distributions: cn=distribution,cn=monitor
Global Index Catalogs: cn=Global Index Catalogs,cn=monitor
Client Connections: cn=Client Connections,cn=monitor
or under cn=Client Connections,cn=LDAP Connection Handler
0.0.0.0 port
port number,cn=monitor
LDAP Connection Handler: cn=LDAP Connection Handler
0.0.0.0 port
port number,cn=monitor
LDAP Connection Handler Statistics: cn=LDAP Connection Handler
0.0.0.0 port
port number statistics
,cn=monitor
SNMP Connection Handler: cn=SNMP Connection Handler,cn=Monitor
JMX Connection Handler: cn=JMX Connection Handler
port number,cn=monitor
Administration Connector: cn=Administration Connector
0.0.0.0 port
port number,cn=monitor
System Information: cn=System Information,cn=monitor
Version: cn=Version,cn=monitor
Back-end LDAP servers: cn=LDAP Servers,cn=monitor
JVM stack traces: cn=JVM Stack Trace,cn=monitor
JVM memory usage: cn=JVM Memory Usage,cn=Monitor
SNMP: cn=SNMP,cn=Monitor
Backend Backup: cn=backup Backend,cn=monitor
Monitoring of back-end data: cn=monitor Backend,cn=monitor
Tasks on the Backend Backup: cn=backup Backend,cn=monitor
Entry caches: cn=Entry Caches,cn=monitor
Work queues: cn=Work Queue,cn=monitor
Other attributes are monitored under each of the above in the dn tree. For example, client connections are monitored under both cn=Client Connections,
0.0.0.0 port
port number,cn=monitor
and under cn=Client Connections,
cn=Administration Connector
0.0.0.0 port
port number, cn=monitor
.
A workflow element is monitored under the part of the tree to which that workflow element relates. For example, a load balancing workflow element can be monitored as cn=load-bal-route1,cn=load balancing,cn=monitor
Hundreds of statistics are collected by the proxy for monitoring. For example, for the persistent search function, psearchCount
lists the number of persistent search operations and psearchTotalCount
lists the number of persistent search operations since the last server restart.
You can list all of these statistics by using the ldapsearch
command on the cn=monitor
entry, as described in Section 29.5.1.2, "To View the Available Monitoring Information". Note that access to the cn=monitor
entry is restricted to users who have the bypass ACI privilege.
The following procedures use the ldapsearch
command at the command line interface.
To view status information on the replication of global indexes, you can use the gicadm status-replication
command. For more information, see Section 15.1.7.2.5, "To View the Status of a Replicated Global Index Catalog Configuration".
Use the ldapsearch
command to inspect the attributes of cn=monitor
. This example lists the base DNs of each monitor entry.
Run the ldapsearch
command with a search scope of sub
and the search attribute 1.1
.
This search attribute indicates that no attributes should be included in the matching entries.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s sub -b "cn=monitor" "(objectclass=*)" "1.1" dn: cn=monitor dn: cn=Client Connections,cn=monitor dn: cn=ads-truststore Backend,cn=monitor dn: cn=Network Groups,cn=monitor dn: cn=internal,cn=Network Groups,cn=monitor dn: cn=default,cn=Network Groups,cn=monitor dn: cn=LDAP Connection Handler 0.0.0.0 port 1389 Statistics,cn=monitor dn: cn=Administration Connector 0.0.0.0 port 4444,cn=monitor dn: cn=Client Connections,cn=Administration Connector 0.0.0.0 port 4444,cn=monitor dn: cn=backup Backend,cn=monitor dn: cn=Version,cn=monitor dn: cn=Work Queue,cn=monitor dn: cn=System Information,cn=monitor dn: cn=userRoot Database Environment,cn=monitor dn: cn=tasks Backend,cn=monitor dn: cn=adminRoot Backend,cn=monitor dn: cn=userRoot Backend,cn=monitor dn: cn=schema Backend,cn=monitor dn: cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor dn: cn=admin,cn=Network Groups,cn=monitor dn: cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor dn: cn=JVM Memory Usage,cn=monitor dn: cn=Administration Connector 0.0.0.0 port 4444 Statistics,cn=monitor dn: cn=JVM Stack Trace,cn=monitor dn: cn=Entry Caches,cn=monitor dn: cn=monitor Backend,cn=monitor
Use the ldapsearch
command with a base DN of "cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=monitor" "(objectclass=*)"
Output will be similar to the following:
dn: cn=monitorstartTime: 20120110110156ZobjectClass: extensibleObjectobjectClass: topobjectClass: ds-monitor-entrycn: monitorvendorName: Oracle CorporationcurrentTime: 20120111082026ZvendorVersion: Oracle Unified Directory 11.1.2.0maxConnections: 1productName: Oracle Unified DirectorycurrentConnections: 1totalConnections: 8upTime: 57 days 21 hours 18 minutes 30 seconds
Use the ldapsearch
command with the base DN "cn=System Information,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=System Information,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=System Information,cn=monitor instancePath: /local/asinst_2/OUD javaVersion: 1.6.0_10 jvmArchitecture: 32-bit jvmArguments: "-Dorg.opends.server.scriptName=start-ds" jvmVersion: 11.0-b15 classPath: /local/instances/OUD/classes: /local/asinst_2/OUD/resources/resources.jar: /local/asinst_2/OUD/lib/activation.jar: /local/asinst_2/OUD/lib/aspectjrt.jar: /local/asinst_2/OUD/lib/je.jar: /local/asinst_2/OUD/lib/mail.jar: /local/asinst_2/OUD/lib/OUD_de.jar: /local/asinst_2/OUD/lib/OUD_es.jar: /local/asinst_2/OUD/lib/OUD_fr.jar: /local/asinst_2/OUD/lib/OUD_ja.jar: /local/asinst_2/OUD/lib/OUD.jar: /local/asinst_2/OUD/lib/OUD_zh_CN.jar: /local/asinst_2/OUD/lib/quicksetup.jar usedMemory: 83361792 freeUsedMemory: 21020432 objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry javaVendor: Oracle Corporation operatingSystem: SunOS 5.11 x86 cn: System Information systemName: llandudno workingDirectory: /local/asinst_2/OUD/bin maxMemory: 518717440 availableCPUs: 2 javaHome: /usr/jdk/instances/jdk1.6.0/jre jvmVendor: Oracle Corporation
Use the ldapsearch
command with base DN "cn=Version,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=Version,cn=Monitor" "(objectclass=*)"
The output will be similar to the following:
dn: cn=Version,cn=monitor shortName: OUD labelNumber: 1112231410 objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry cn: Version pointVersion: 2 compactVersion: OUD-11.1 buildID: 20111224012512Z majorVersion: 11 productName: Oracle Unified Directory minorVersion: 1 versionQualifier: 0 fullVersion: Oracle Unified Directory 11.1.2.0
The userRoot
back end is the back-end database (the JE environment) for your data. The monitor displays the back end's general properties, such as writability mode, base DN, back-end IDs, entry count, and other properties.
Use the ldapsearch
command with base DN "cn=userRoot Backend,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=userRoot Backend,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=userRoot Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: FALSE cn: userRoot Backend ds-backend-writability-mode: enabled ds-backend-entry-count: 2002 ds-backend-id: userRoot ds-base-dn-entry-count: 2002 dc=example,dc=com ds-backend-base-dn: dc=example,dc=com
Use the ldapsearch
command with base DN "cn=backup Backend,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=backup Backend,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=backup Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: TRUE cn: backup Backend ds-backend-writability-mode: disabled ds-backend-entry-count: 1 ds-backend-id: backup ds-base-dn-entry-count: 1 cn=backups ds-backend-base-dn: cn=backups
Tasks are administrative functions (such as import-ldif
, export-ldif
, backup
, and restore
) that can be scheduled for processing at some future date or on a recurring basis. The monitor displays the tasks back end's general properties, such as writability mode, base DN, back-end IDs, entry count, and other properties.
Use the ldapsearch
command with base DN "cn=Tasks Backend,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=Tasks Backend,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=tasks Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: TRUE cn: tasks Backend ds-backend-writability-mode: enabled ds-backend-entry-count: 3 ds-backend-id: tasks ds-base-dn-entry-count: 3 cn=tasks ds-backend-base-dn: cn=tasks
monitor
Back EndThis monitor displays the back end's general properties, such as writability mode, base DN, back-end IDs, entry count, and other properties.
Use the ldapsearch
command with base DN "cn=monitor Backend,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=monitor Backend,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=monitor Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: TRUE cn: monitor Backend ds-backend-writability-mode: disabled ds-backend-entry-count: 25 ds-backend-id: monitor ds-base-dn-entry-count: 25 cn=monitor ds-backend-base-dn: cn=monitor
This monitor displays the schema back end's general properties, such as writability mode, base DN, back-end IDs, entry count, and other properties.
Use the ldapsearch
command with base DN "cn=schema Backend,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=schema Backend,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=schema Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: TRUE cn: schema Backend ds-backend-writability-mode: enabled ds-backend-entry-count: 1 ds-backend-id: schema ds-base-dn-entry-count: 1 cn=schema ds-backend-base-dn: cn=schema
adminRoot
Back EndThis monitor displays the adminRoot
back end's general properties, such as writability mode, base DN, back-end IDs, entry count, and other properties.
Use the ldapsearch
command with base DN "cn=adminRoot Backend,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=adminRoot Backend,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=adminRoot Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: TRUE cn: adminRoot Backend ds-backend-writability-mode: enabled ds-backend-entry-count: 7 ds-backend-id: adminRoot ds-base-dn-entry-count: 7 cn=admin data ds-backend-base-dn: cn=admin data
ads-truststore
Back EndThe ads-truststore
holds a mirror, or copy, of the remote Administrative Directory Service (ADS) host's ADS key entry, so that the new instance can establish trust with existing servers in the ADS domain. The monitor displays the back end's general properties, such as writability mode, base DN, back-end IDs, entry count, and other properties.
Use the ldapsearch
command with base DN "cn=ads-truststore Backend,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=ads-truststore Backend,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=ads-truststore Backend,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-backend-monitor-entry ds-backend-is-private: TRUE cn: ads-truststore Backend ds-backend-writability-mode: enabled ds-backend-entry-count: 3 ds-backend-id: ads-truststore ds-base-dn-entry-count: 3 cn=ads-truststore ds-backend-base-dn: cn=ads-truststore
This monitor represents all of the open client connections. Its contents are different to those of the DN "cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor"
, which describes the open client connections on the LDAP connection handler only.
Use the ldapsearch
command with base DN "cn=Client Connections,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=Client Connections,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=Client Connections,cn=monitor connection: connID="11" connectTime="20090702125632Z" source="198.51.100.0:54044" destination="198.51.100.23:1389" ldapVersion="3" authDN="cn=Directory Manager,cn=Root DNs, cn=config" security="none" opsInProgress="1" cn: Client Connections objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry
The LDAP connection handler is used to interact with clients over LDAP.
Use the ldapsearch
command with base DN "cn=LDAP Connection Handler 0.0.0.0 port port-number,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base \ -b "cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor" \ "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor ds-connectionhandler-listener: 0.0.0.0:1389 ds-connectionhandler-num-connections: 1 ds-connectionhandler-protocol: LDAP objectClass: top objectClass: ds-monitor-entry objectClass: ds-connectionhandler-monitor-entry ds-mon-config-dn: cn=ldap connection handler,cn=connection handlers,cn=config cn: LDAP Connection Handler 0.0.0.0 port 1389 ds-connectionhandler-connection: connID="22" connectTime="20120302133936Z" source="198.51.100.0:39574" destination="198.51.100.23:1389" ldapVersion="3" authDN="cn=Directory Manager,cn=Root DNs,cn=config" security="none" opsInProgress="1"
Use the ldapsearch
command with base DN "cn=LDAP Connection Handler 0.0.0.0 port port-number Statistics,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base \ -b "cn=LDAP Connection Handler 0.0.0.0 port 1389 Statistics,cn=monitor" \ "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=LDAP Connection Handler 0.0.0.0 port 1389 Statistics,cn=monitor objectClass: ds-monitor-entry objectClass: top objectClass: extensibleObject operationsCompleted: 37 compareRequests: 0 bytesWritten: 99488 extendedRequests: 0 addRequests: 0 bindRequests: 19 ...(more output)
This monitor represents the open client connections on the LDAP connection handler.
Use the ldapsearch
command with base DN "cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port port-number,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \ --useSSL --trustAll \ -b "cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port 1389 \ cn=monitor" \ "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor connection: connID="0" connectTime="20090706084747Z" source="198.51.100.0:57523" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0" connection: connID="1" connectTime="20090706084747Z" source="198.51.100.0:57524" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0" connection: connID="2" connectTime="20090706084747Z" source="198.51.100.0:57525" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0" connection: connID="3" connectTime="20090706084747Z" source="198.51.100.0:57526" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0" connection: connID="4" connectTime="20090706084747Z" source="198.51.100.0:57527" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0"
This monitor provides basic information about the administration connector. For more information, see Section 14.3, "Managing Administration Traffic to the Server".
Use the ldapsearch
command with base DN "cn=Administration Connector 0.0.0.0 port admin-port-number,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=Administration Connector 0.0.0.0 port 4444,cn=monitor" \ "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-connectionhandler-monitor-entry dn: cn=Administration Connector 0.0.0.0 port 4444,cn=monitor ds-connectionhandler-listener: 0.0.0.0:4444 ds-connectionhandler-num-connections: 0 ds-connectionhandler-protocol: LDAPS cn: Administration Connector 0.0.0.0 port 4444 ds-mon-config-dn: cn=administration connector,cn=config
This monitor provides extensive statistical information about operations that are performed through the administration connector. For more information, see Section 14.3, "Managing Administration Traffic to the Server".
Use the ldapsearch
command with base DN "cn=Administration Connector 0.0.0.0 port admin-port-number Statistics,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll \ -b "cn=Administration Connector 0.0.0.0 port 4444 Statistics,cn=monitor" \ "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=Administration Connector 0.0.0.0 port 4444 Statistics,cn=monitor compareResponses: 0 connectionsClosed: 1 searchResultsDone: 4 ds-mon-resident-time-mod-operations-total-time: 92257568 extendedResponses: 0 bindRequests: 2 operationsAbandoned: 0 bytesWritten: 45056 addResponses: 0 addRequests: 0 ds-mon-resident-time-moddn-operations-total-time: 0 ds-mon-extended-operations-total-count: 0 ds-mon-moddn-operations-total-count: 0 modifyResponses: 1 operationsCompleted: 7 ...(more output)...
This monitor represents the open client connections on the Administration Connector.
Use the ldapsearch
command with base DN "cn=Client Connections,cn=Administration Connector 0.0.0.0 port port-number,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \ --useSSL --trustAll \ -b "cn=Client Connections,cn=Administration Connector 0.0.0.0 \ port 4444,cn=monitor" \ "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject dn: cn=Client Connections,cn=Administration Connector 0.0.0.0 port 4444,cn=monitor connection: connID="339" connectTime="20120307075218Z" source="198.51.100.0:48213" destination="198.51.100.0:4444" ldapVersion="3" authDN="" security="TLS" opsInProgress="1" cn: Client Connections
The LDIF connection handler is used to process changes that are read from an LDIF file, using internal operations. Monitoring information for the LDIF connection handler is only available if the connection handler is enabled.
Use the ldapsearch
command with base DN "cn=LDIF Connection Handler,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=LDIF Connection Handler,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-connectionhandler-monitor-entry dn: cn=LDIF Connection Handler,cn=monitor ds-connectionhandler-num-connections: 0 ds-connectionhandler-protocol: LDIF ds-mon-config-dn: cn=ldif connection handler,cn=connection handlers,cn=config cn: LDIF Connection Handler
The work queue keeps track of outstanding client requests and ensures that they are processed.
Use the ldapsearch
command with base DN "cn=Work Queue,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=Work Queue,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=Work Queue,cn=monitor currentRequestBacklog: 0 objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry requestsSubmitted: 25 cn: Work Queue maxRequestBacklog: 0 averageRequestBacklog: 0 requestsRejectedDueToQueueFull: 0
You can access JVM Stack Trace information for your directory server instance. This resource monitor is implemented in the org.opends.server.monitors.StackTraceMonitorProvider
class and requires no custom configuration.
Use the ldapsearch
command with the base DN "cn=JVM Stack Trace,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=JVM Stack Trace,cn=monitor" "(objectclass=*)"
Depending on your configuration, the beginning of the output will be similar to the following:
dn: cn=JVM Stack Trace,cn=monitor cn: JVM Stack Trace jvmThread: id=2 ---------- Reference Handler ---------- jvmThread: id=2 frame[0]=java.lang.Object.wait(Object.java:native) jvmThread: id=2 frame[1]=java.lang.Object.wait(Object.java:485) jvmThread: id=2 frame[2]=java.lang.ref.Reference$ReferenceHandler.run(Reference. java:116) jvmThread: id=3 ---------- Finalizer ---------- jvmThread: id=3 frame[0]=java.lang.Object.wait(Object.java:native) jvmThread: id=3 frame[1]=java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java :116) jvmThread: id=3 frame[2]=java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java :132) jvmThread: id=3 frame[3]=java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.j ava:159) jvmThread: id=4 ---------- Signal Dispatcher ---------- jvmThread: id=10 ---------- Time Thread ---------- jvmThread: id=10 frame[0]=sun.misc.Unsafe.park(Unsafe.java:native) jvmThread: id=10 frame[1]=java.util.concurrent.locks.LockSupport.parkNanos(LockS upport.java:198) ...(more output)...
Use the ldapsearch
command with base DN "cn=JVM Memory Usage,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=JVM Memory Usage,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=JVM Memory Usage,cn=monitor ps-eden-space-bytes-used-after-last-collection: 0 ps-mark-sweep-total-collection-count: 0 code-cache-bytes-used-after-last-collection: 0 ps-old-gen-current-bytes-used: 25260472 ps-perm-gen-bytes-used-after-last-collection: 0 ps-scavenge-recent-collection-duration: 3 ps-scavenge-total-collection-count: 17 ps-eden-space-current-bytes-used: 32001992 ps-perm-gen-current-bytes-used: 21179960 ps-old-gen-bytes-used-after-last-collection: 0 ps-mark-sweep-total-collection-duration: 0 ps-mark-sweep-average-collection-duration: 0 ps-scavenge-average-collection-duration: 26 ps-scavenge-total-collection-duration: 443 objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry ps-mark-sweep-recent-collection-duration: 0 ps-survivor-space-bytes-used-after-last-collection: 622592 cn: JVM Memory Usage code-cache-current-bytes-used: 2143680 ps-survivor-space-current-bytes-used: 622592
userRoot
Database EnvironmentThe userRoot
database environment utilizes the Berkeley DB Java Edition back end. JE monitoring data (data under cn=*Database Environment,cn=monitor
) is reliable only in the short term. During high server activity (for example, anywhere from an hour to several days depending on the counter), this data can overflow. In such cases, the JE monitoring data can reflect negative values or positive but incorrect values. This is a known issue and is expected to be fixed in the next major release of the Berkeley DB Java Edition. Oracle SR numbers 15979 and 15985 correspond to this issue.
Use the ldapsearch
command with base DN "cn=userRoot Database Environment,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=userRoot Database Environment,cn=monitor" \ "(objectclass=*)" dn: cn=userRoot Database Environment,cn=monitor
Depending on your configuration, output will be similar to the following:
EnvironmentNTempBufferWrites: 0 EnvironmentNNodesExplicitlyEvicted: 0 EnvironmentCleanerBacklog: 0 EnvironmentTotalLogSize: 5386067 EnvironmentLockBytes: 2000 EnvironmentNFullBINFlush: 2 EnvironmentNBINsStripped: 0 EnvironmentLastCheckpointEnd: 5385359 TransactionNCommits: 24 EnvironmentNCleanerEntriesRead: 0 EnvironmentNRepeatFaultReads: 2 TransactionNXACommits: 0 EnvironmentNClusterLNsProcessed: 0 TransactionNBegins: 24 LockNOwners: 25 ...(more output)...
The database (DB) cache is used to store Java Edition nodes. The DB cache is the critical component of your directory server's overall performance. Ensure that you tune and monitor the DB cache carefully. The DB cache includes the following nodes:
Upper node
Inner node
Leaf node
The upper and inner nodes represents the internal B-tree structure and the leaf node represent the user entries. For best possible performance, it is recommended to have all the DB cache nodes in the DB cache. It is recommend to size the dbcache such that it contains at minimum the B-tree internal structure (the upper and inner nodes). If the dbcache is too short this can result in having lots of misses and frequent evictions which will badly affect directory server performance.
Tuning the size of the cache is done by:
Setting the dbcache-percent
Sizing appropriately the OUD JVM heap and especially the old generation.
You can monitor the DB cache by using the ldapsearch
command with base DN cn=userRoot Database Environment,cn=monitor
:
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=userRoot Database Environment,cn=monitor" \ "(objectclass=*)" dn: cn=userRoot Database Environment,cn=monitor
Depending on your configuration, output will be similar to the following:
EnvironmentNTempBufferWrites: 0 EnvironmentNNodesExplicitlyEvicted: 0 EnvironmentCleanerBacklog: 0 EnvironmentTotalLogSize: 5386067 EnvironmentLockBytes: 2000 EnvironmentNFullBINFlush: 2 EnvironmentNBINsStripped: 0 EnvironmentLastCheckpointEnd: 5385359 TransactionNCommits: 24 EnvironmentNCleanerEntriesRead: 0 EnvironmentNRepeatFaultReads: 2 TransactionNXACommits: 0 EnvironmentNClusterLNsProcessed: 0 TransactionNBegins: 24 LockNOwners: 25 ...(more output)...
The following DB cache hits and miss counters are described below:
Counters | Description |
---|---|
|
Accumulated number of upper inner nodes fetched from the cache. |
|
Accumulated number of upper inner nodes miss. |
|
Accumulated number of bottom inner nodes fetched from the cache. |
|
Accumulated number of upper inner nodes miss. |
|
Accumulated number of leaf nodes fetched from the cache. |
|
Accumulated number of leaf nodes miss. |
For OUD to perform well it is recommended to have all the nodes in the dbcache or at least to have all the inner nodes in the dbcache.
As the values in cn=monitor are accumulations, it is important to compute deltas at regular interval (1mn for instance) and monitor the evolution of deltas over time. You must update the following:
DeltaNUpperINsMiss=EnvironmentNUpperINsFetchMiss - EnvironmentNUpperINsFetchMissPrev DeltaNUpperINsFetch=EnvironmentNUpperINsFetch - EnvironmentNUpperINsFetchPrev DeltaBINsMiss=EnvironmentNBINsFetchMiss - EnvironmentNBINsFetchMissPrev DeltaBINsFetch=EnvironmentNBINsFetch - EnvironmentNBINsFetchPrev DeltaNLNsMiss=EnvironmentNLNsFetchMiss - EnvironmentNLNsFetchMissPrev DeltaNLNsFetch=EnvironmentNLNsFetch - EnvironmentNLNsFetchPrev
You can run the Oracle Unified Directory with a minimal level of performance. It is recommend to have the B-Tree structure in the dbcache, as described below:
((DeltaNUpperINsMiss/DeltaNUpperINsFetch)*100) as close to 0 as possible ((DeltaNBINsMiss/DeltaNBINsFetch)*100) as close to 0 as possible (< 5% remains acceptable)
To have the best possible performance, it is recommended for OUD to also have user entries in the dbcache, i-e:
((DeltaNLNsMiss/DeltaNLNsFetch)*100)
as close to 0
as possible.
Start with Deltas ratio close to 0
after the import is complete (and data primed) and with time the Deltas ratio grows due to the database growth (bc of replication metadata, clean-min-utilizat˚ impact, growth of the entry (new apps) as well as the nb of entries ). Due to this, it is recommended to monitor the dbcache (via custom scripts or UI) and take appropriate actions such as increase the dbcache-percent or the OUD JVM heap.
You can access the aggregated state of all active entry caches for your directory server instance by accessing the cn=Entry Caches,cn=Monitor
entry. The server can also request the "per cache" monitor data for a given instance if the entry cache instances are enabled in the directory server configuration:
cn=FIFO Entry Cache,cn=Monitor
cn=Soft Reference Entry Cache,cn=Monitor
cn=File System Entry Cache,cn=Monitor
Additionally, any arbitrarily named active entry cache instance should provide a monitor, which can be accessed by that instance name, for example cn=Any Arbitrary Name Entry Cache,cn=Monitor
.
Use the ldapsearch
command with base DN "cn=Entry Caches,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -s base -b "cn=Entry Caches,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=Entry Caches,cn=monitor entryCacheHits: 0 entryCacheTries: 0 currentEntryCacheCount: 0 objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry entryCacheHitRatio: 0 cn: Entry Caches ...
Use the ldapsearch
command with the base DN "cn=Network Groups,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \ --useSSL --trustAll -b "cn=Network Groups,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-mon-branch dn: cn=Network Groups,cn=monitor dn: cn=admin,cn=Network Groups,cn=monitor ds-mon-compare-operations-total-count: 0 ds-mon-failed-referrals-total-count: 15 ds-mon-unbind-operations-total-count: 13 ds-mon-followed-referrals-total-count: 34 ds-mon-violations-schema-total-count: Not implemented ds-mon-bind-operations-total-count: 98 ds-mon-persistent-searchs-count: Not implemented ds-mon-add-operations-total-count: 37 ds-mon-abandon-operations-total-count: 0 ds-mon-moddn-operations-total-count: 0 ds-mon-extended-operations-total-count: 0 ds-mon-searchsubtree-operations-total-count: 310 objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject ds-mon-discarded-referrals-total-count: Not implemented ds-mon-mod-operations-total-count: 1 ds-mon-forwarded-referrals-total-count: Not implemented cn: admin ds-mon-searchonelevel-operations-total-count: 92966 ds-mon-delete-operations-total-count: 0 dn: cn=default,cn=Network Groups,cn=monitor ...
Use the ldapsearch
command with the base DN "cn=Distribution,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \ --useSSL --trustAll -b "cn=Distribution,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-mon-branch dn: cn=distribution,cn=monitor cn: distrib-we ds-mon-searchonelevel-operations-total-count: 0 ds-mon-residenttime-bind-operations-max-time: 0 ... ds-mon-delete-operations-total-count: 0 dn: cn=algorithm,cn=distrib-we,cn=distribution,cn=monitor ds-mon-residenttime-total-time: 0 ds-mon-residenttime-max-time: 0 cn: algorithm ds-mon-runs-total-count: 0 ds-mon-residenttime-min-time: 0 objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject dn: cn=partitions,cn=algorithm,cn=distrib-we,cn=distribution,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: ds-mon-branch dn: cn=distrib-part1,cn=partitions,cn=algorithm,cn=distrib-we,cn=distribution,cn =monitor ... objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject ds-mon-modify-operations-total-count: 0 cn: distrib-part1 ds-mon-searchonelevel-operations-total-count: 0 ds-mon-delete-operations-total-count: 0 dn: cn=distrib-part2,cn=partitions,cn=algorithm,cn=distrib-we,cn=distribution,cn =monitor ...
Use the ldapsearch
command with the base DN "cn=load balancing,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \ --useSSL --trustAll -b "cn=load balancing,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-mon-branch dn: cn=load balancing,cn=monitor dn: cn=load-bal-we1,cn=load balancing,cn=monitor ds-mon-aborted-add-operations-total-count: 0 ... dn: cn=algorithm,cn=load-bal-we1,cn=load balancing,cn=monitor dn: cn=routes,cn=algorithm,cn=load-bal-we1,cn=load balancing,cn=monitor ... dn: cn=load-bal-route1,cn=routes,cn=algorithm,cn=load-bal-we1,cn=load balancing,cn=monitor ... dn: cn=load-bal-we2,cn=load balancing,cn=monitor ... dn: cn=algorithm,cn=load-bal-we2,cn=load balancing,cn=monitor ... dn: cn=routes,cn=algorithm,cn=load-bal-we2,cn=load balancing,cn=monitor dn: cn=load-bal-route1,cn=routes,cn=algorithm,cn=load-bal-we2,cn=load balancing,cn=monitor ... cn: load-bal-route1 dn: cn=load-bal-route2,cn=routes,cn=algorithm,cn=load-bal-we1,cn=load balancing,cn=monitor ... cn: load-bal-route2 dn: cn=load-bal-route2,cn=routes,cn=algorithm,cn=load-bal-we2,cn=load balancing,cn=monitor cn: load-bal-route2 ds-mon-searchonelevel-operations-total-count: 9 ds-mon-delete-operations-total-count: 0
Use the ldapsearch
command with the base DN "cn=LDAP Servers,cn=monitor"
.
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \ --useSSL --trustAll -b "cn=LDAP Servers,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
objectClass: top objectClass: ds-monitor-entry objectClass: ds-mon-branch dn: cn=LDAP Servers,cn=monitor dn: cn=proxy1,cn=LDAP Servers,cn=monitor ds-mon-aborted-add-operations-total-count: 0 ... cn: proxy1 ds-mon-searchonelevel-operations-total-count: 0 ... objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject dn: cn=proxy2,cn=LDAP Servers,cn=monitor ds-mon-aborted-add-operations-total-count: 0 ... cn: proxy2 ds-mon-searchonelevel-operations-total-count: 0 ... objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject ... dn: cn=proxy3,cn=LDAP Servers,cn=monitor ... cn: proxy3 ds-mon-searchonelevel-operations-total-count: 0 ... objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject ... dn: cn=proxy4,cn=LDAP Servers,cn=monitor ... cn: proxy4 ... objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject
Use the ldapsearch
command with the base DN "cn=givenname,cn=gi-catalog,cn=Global Index Catalogs,cn=monitor"
.
Ensure that givenname
corresponds to the name of the indexed attribute (for example cn
, if you indexed cn
), and that gi-catalog
corresponds to the name of the global index catalog.
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file --useSSL \ --trustAll -b "cn=givenname,cn=gi-catalog,cn=Global Index Catalogs,cn=monitor" "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=givenname,cn=gi-catalog,cn=Global Index Catalogs,cn=monitor ds-mon-add-operations-min-time: 0 ds-mon-add-operations-aborted-count: 0 ds-mon-lookup-operations-min-time: 0 ds-mon-getpartitions-operations-total-count: 0 ds-mon-add-operations-max-time: 0 ds-mon-lookup-operations-total-count: 0 ds-mon-memorized-remove-operations-count: 0 ds-mon-remove-operations-aborted-count: 0 ds-mon-add-operations-total-time: 0 ds-mon-getpartitions-operations-aborted-count: 0 ds-mon-lookup-operations-total-time: 0 ds-mon-index-entries: 0 ds-mon-remove-operations-failed-count: 0 ds-mon-getpartitions-operations-min-time: 0 ds-mon-lookup-operations-max-time: 0 ds-mon-getpartitions-operations-average-time: 0 ds-mon-index-creation-date: 1252483187019 ds-mon-getpartitions-operations-last-access-date: 0 ds-mon-remove-operations-total-count: 0 ds-mon-lookup-operations-failed-count: 0 ds-mon-add-operations-failed-count: 0 ds-mon-remove-operations-min-time: 0 ds-mon-add-operations-average-time: 0 ds-mon-lookup-operations-aborted-count: 0 ds-mon-getpartitions-operations-total-time: 0 ds-mon-remove-operations-max-time: 0 ds-mon-getpartitions-operations-max-time: 0 ds-mon-lookup-operations-last-access-date: 0 ds-mon-add-operations-total-count: 0 ds-mon-remove-operations-total-time: 0 ds-mon-remove-operations-average-time: 0 ds-mon-getpartitions-operations-failed-count: 0 objectClass: ds-monitor-entry objectClass: top objectClass: extensibleObject ds-mon-lookup-operations-average-time: 0 ds-mon-remove-operations-last-access-date: 0 cn: givenname ds-mon-add-operations-last-access-date: 0
Use the ldapsearch
command with the base DN "cn=gi-catalog,cn=Global Index Catalogs,cn=monitor"
.
Ensure that givenname
corresponds to the name of the indexed attribute (for example cn, if you indexed cn), and that gi-catalog
corresponds to the name of the global index catalog.
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file --useSSL \ --trustAll -b "cn=gi-catalog,cn=Global Index Catalogs,cn=monitor" \ "(objectclass=*)"
Depending on your configuration, output will be similar to the following:
dn: cn=gi-catalog,cn=Global Index Catalogs,cn=monitor ds-mon-replication-received-update-message-errors: 0 ds-mon-configured-index-number: 1 ds-mon-replication-full-update-pending-attribute: ds-mon-replication-full-update-status: NONE ds-mon-state: RUNNING_STANDALONE ds-mon-replication-published-update-message-number: 0 ds-mon-replication-active: false ds-mon-replication-auto-sync-retries: 0 ds-mon-replication-published-update-message-errors: 0 ds-mon-replication-full-update-errors: 0 ds-mon-replication-received-update-message-number: 0 ds-mon-replication-auto-sync-is-running: false objectClass: ds-monitor-entry objectClass: top objectClass: extensibleObject ds-mon-replication-configured: false cn: gi-catalog
manage-tasks
CommandOracle Unified Directory provides a tasks back end that provides a mechanism for scheduling and processing certain tasks, such as import-ldif
, export-ldif
, backup
, and restore
. You can schedule a task to run at specific times and at recurring periods. To monitor scheduled tasks, use the manage-tasks
command. For more information, see Section 14.4, "Configuring Commands As Tasks".
The JConsole (jconsole
) Java utility is a JMX-compliant, graphical tool that connects to a running Java Virtual Machine that has been started with the management agent. This generic tool can be used to access server monitoring information.
Start the server.
Enable the JMX Connection Handler and set the port number to be used with JMX.
Choose a port that is not in use and to which the user that is running the server has access rights.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-connection-handler-prop --handler-name "JMX Connection Handler" \ --set enabled:true --set listen-port:1689
Add the JMX read, write, and notify privileges to the root DN.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-root-dn-prop \ --add default-root-privilege-name:jmx-read \ --add default-root-privilege-name:jmx-write \ --add default-root-privilege-name:jmx-notify
Restart the server.
Start the console by typing jconsole
in a terminal window.
To run jconsole
from the command line, you might have to add JAVA_HOME/bin to your path, where JAVA_HOME
is the directory containing the JDK. Alternatively, you can enter the full path when you type the command.
For more information about using JConsole, see Using JConsole (https://download.oracle.com/docs/cd/E17409_01/javase/6/docs/technotes/guides/management/jconsole.html
).
To connect JConsole to a server instance, use the Remote Process fields. The following fields are required:
JMX URL:
service:jmx:rmi:///jndi/rmi://''host'':''port''/org.opends.server.protocols.jmx.client-unknown
host is a host name, an IPv4 numeric host address, or an IPv6 numeric address enclosed in square brackets.
port is the decimal port number of the JMX connector. (See Section 29.4, "Configuring Alerts and Account Status Notification Handlers").
The default JMX URL is:
service:jmx:rmi:///jndi/rmi://198.51.100.0:1689/org.opends.server.protocols.jmx.client-unknown
User Name. A valid LDAP user name.
The default Directory Manager user name is cn=Directory Manager
.
Password. The user's LDAP password.
When JConsole is connected to a server instance, it displays management objects (MBeans). The tree on the left pane shows all MBeans currently available. You can access server monitoring information in the right hand pane by selecting the associated MBean.
The following figure shows the attribute list for a server cn=LDAP Connection Handler 0.0.0.0 port 1389 Statistics,cn=monitor
.
Figure 29-1 Java Monitoring and Management Console
The server provides logging mechanisms to record access, error, or debugging information for the server instance. Multiple loggers of a given type can be active at any time, which makes it possible to create logs for specific subtrees or different repositories. The server does not currently provide logging filters to restrict the type of information in the logs.
The following logs are provided:
Access logs. Access logs record information about the types of operations processed by the directory server. Access logs are provided by default.
Audit logs. Audit logs are a type of access log and record all activity on the directory server. Audit logs are not enabled by default.
Debug logs. Debug logs record information that can be used for troubleshooting directory server problems or for providing detailed information about the directory server's processing. Debug logs are not enabled by default.
Error logs. Error logs record all warnings, errors, or significant events that occur during directory server processing.
Replication repair logs. Replication repair logs record inconsistencies on a single directory server in a topology.
The replication repair log is read-only and its use is restricted to enabling replication conflict resolution.
oud-setup logs. The setup logs record the equivalent command line arguments executed during the installation of an Oracle Unified Directory proxy server instance or replication gateway instance. This enables you to perform a "silent install" of the proxy server or gateway server, based on a previous installation.
This file is not output for directory server instances.
server.out logs. The server.out logs record the bootstrapping configuration process, list extensions loaded from jar files, and indicate connection and alert notification activity.
Change to the logs directory of the server instance.
$ cd INSTANCE_DIR/OUD/logs
Open the access
file by using a text editor or the UNIX cat
command.
$ cat access | more [10/Jan/2012:12:02:11 +0100] CONNECT conn=0 from=198.51.100.0:55416 to=198.51.100.0:5444 protocol=LDAPS [10/Jan/2012:12:02:12 +0100] BIND REQ conn=0 op=0 msgID=1 type=SIMPLE dn="cn=Directory Manager" [10/Jan/2012:12:02:12 +0100] BIND RES conn=0 op=0 msgID=1 result=0 authDN="cn=Directory Manager,cn=Root DNs,cn=config" etime=36 [10/Jan/2012:12:02:12 +0100] UNBIND REQ conn=0 op=1 msgID=2 [10/Jan/2012:12:02:12 +0100] DISCONNECT conn=0 reason="Client Disconnect" ...(more output)...
If the audit log publisher is not already enabled, enable it as described in Section 29.3.1.1.2, "To Enable a Log Publisher".
Change to the logs directory of the server instance.
$ cd INSTANCE_DIR/OUD/logs
Open the audit
file by using a text editor or the UNIX cat
command.
$ cat audit | more # 11/Jan/2012:11:20:00 +0100; conn=10; op=18 dn: cn=File-Based Audit Logger,cn=Loggers,cn=config changetype: modify replace: ds-cfg-enabled ds-cfg-enabled: true - replace: modifiersName modifiersName: cn=directory manager - replace: modifyTimestamp modifyTimestamp: 20120111102000Z # 11/Jan/2012:11:20:20 +0100; conn=11; op=6 dn: cn=File-Based Debug Logger,cn=Loggers,cn=config changetype: modify replace: ds-cfg-enabled ds-cfg-enabled: true - replace: modifiersName modifiersName: cn=directory manager - replace: modifyTimestamp modifyTimestamp: 20120111102020Z ...(more output)...
If the debug log publisher is not already enabled, enable it as described in Section 29.3.1.1.2, "To Enable a Log Publisher".
Change to the logs directory of the server instance.
$ cd INSTANCE_DIR/OUD/logs
Open the debug
file by using a text editor or the UNIX cat
command.
$ cat debug | more [11/Jan/2012:11:39:48 +0100] 0 caught error thread={Worker Thread 43(118)} threadDetail={parentThread=main(1) isDaemon=false clientConnection=LDAP client connection from 198.51.100.0:56288 to 198.51.100.0:2389 operation=SearchOperation(connID=13, opID=1, baseDN=dc=example,dc=com, scope=wholeSubtree, filter=(objectclass=*)) } method={run(SearchOperationBas is.java:1513)} caught={org.opends.server.types.CanceledOperationException: Client Disconnect} ...(more output)...
Change to the logs directory of the server instance.
$ cd INSTANCE_DIR/OUD/logs
Open the errors
file by using a text editor or the UNIX cat
command.
$ cat errors | more [11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381717 msg=Installation Directory: /local/OUD_BASE/Oracle_OUD1[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381719 msg=Instance Directory: /local/OUD_BASE/asinst_4/OUD[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381713 msg=JVM Information: 1.6.0_30-b12 by Sun Microsystems Inc., 32-bit architecture, 957743104 bytes heap size[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381714 msg=JVM Host: host1, running SunOS 5.10 sparc, 103079215104 bytes physical memory size, number of processors available 24[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381715 msg=JVM Arguments: "-Dorg.opends.server.scriptName=start-ds"[11/Jan/2012:15:14:16 +0100] category=PROTOCOL severity=NOTICE msgID=2556180 msg=Started listening for new connections on Administration Connector 0.0.0.0 port 7444[11/Jan/2012:15:14:16 +0100] category=PROTOCOL severity=NOTICE msgID=2556180 msg=Started listening for new connections on LDAP Connection Handler 0.0.0.0 port 4389[11/Jan/2012:15:14:16 +0100] category=CORE severity=NOTICE msgID=458887 msg=TheDirectory Server has started successfully...(more output)...
Change to the logs directory of the server instance.
$ cd INSTANCE_DIR/OUD/logs
Open the replication
file by using a text editor or the UNIX cat
command.
$ cat replication | more [13/Jan/2012:15:00:50 +0100] category=SYNC severity=NOTICE msgID=15139035 msg=The replication server database has version 2 format[13/Jan/2012:15:00:50 +0100] category=SYNC severity=NOTICE msgID=15138878 msg=Replication is up and running for domain cn=admin data with replication server id 18049 host1/198.51.100.0:8989 - local server id is 9338 - data generation is 93408[13/Jan/2012:15:00:52 +0100] category=SYNC severity=NOTICE msgID=15138878 msg=Replication is up and running for domain dc=example,dc=com with replication server id 18049 host1/198.51.100.0:8989 - local server id is 25340 - data generation is 19449577[13/Jan/2012:15:00:53 +0100] category=SYNC severity=NOTICE msgID=15138878 msg=Replication is up and running for domain cn=schema with replication server id 18049 host1/198.51.100.0:8989 - local server id is 13881 - data generation is 8408[13/Jan/2012:15:08:28 +0100] category=SYNC severity=NOTICE msgID=15138893 msg=On suffix cn=admin data, replication server 3844 presented generation ID=-1 when expected generation ID=93408[13/Jan/2012:15:08:28 +0100] category=SYNC severity=MILD_ERROR msgID=14876753 msg=In RS 18049 for dn cn=admin data, update 00000134d765d4b1247a00000001 will not be sent to RS 3844 with generation id -1 different from local generation id 93408[13/Jan/2012:15:08:28 +0100] category=SYNC severity=MILD_ERROR msgID=14876753 msg=In RS 18049 for dn cn=admin data, update 00000134d765d4b1247a00000002 will not be sent to RS 3844 with generation id -1 different from local generation id 93408...(more output)...
Change to the logs directory of the server instance.
$ cd INSTANCE_DIR/OUD/logs
Open the server.out
file by using a text editor or the UNIX cat
command.
$ cat server.out | more [23/May/2011:02:27:59 -0700] category=CORE severity=INFORMATION msgID=132 msg=The Directory Server is beginning the configuration bootstrapping process [23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147 msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/globalindex.jar' (build 1.0.0) [23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147 msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/replication-gateway.jar' (build 1.0.0) [23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147 msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/snmp-mib2605.jar' (build 11.1.1.5.0) [23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147 msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/loadbalancing.jar' (build 1.0.0) [23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147 msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/virtualization.jar' (build 1.0.0) [23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147 msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/distribution.jar' (build 1.0.0) ... more output ...
This log file is available for proxy server and replication gateway instances only.
Change to the logs directory of the server instance.
$ cd INSTANCE_DIR/OUD/logs
Open the oud-setup
file by using a text editor or the UNIX cat
command.
$ cat oud-setup | more May 19, 2011 2:24:36 AM com.sun.dps.ui.deploy.SetupLog initLogFileHandler INFO: oud-setup application launched May 19, 2011 2:24:36 AM PDT ...(more output)...
Oracle Unified Directory provides a jar file extension that contains a Simple Network Management Protocol (SNMP) connection handler for Management Information Base (MIB) 2605 support. The extension contains the SNMP connection handler, the required classes to support MIB 2605 objects and SNMP requests, and the SNMP adapter that allows an SNMP manager to access the server monitoring information.
Before you start on the procedures in this section, ensure that you have set up an SNMP-managed network for your particular system.
Oracle Unified Directory provides an SNMP connection handler that you can enable and configure. The SNMP connection handler is provided as a jar file extension and is located in install-dir/lib/extensions/snmp-mib2605.jar
.
Oracle Unified Directory can be configured for monitoring through the Simple Network Management Protocol (SNMP). The server uses the Java Dynamic Management Kit (JDMK) to create smart agents for the SNMP connection handler.
Verify that the SNMP connection handler is displayed under the list of current connection handlers by using dsconfig
as follows.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ list-connection-handlers Connection Handler : Type : enabled : listen-port : use-ssl -------------------------:------:---------:-------------:-------- JMX Connection Handler : jmx : false : 1689 : false LDAP Connection Handler : ldap : true : 1389 : false LDAPS Connection Handler : ldap : false : 636 : true LDIF Connection Handler : ldif : true : - : - SNMP Connection Handler : snmp : false : 161 : -
Use the dsconfig
command to enable SNMP for the server and to set the listen port.
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -n -X \ set-connection-handler-prop --handler-name "SNMP Connection Handler" \ --set enabled:true --set listen-port:8085
Run the following command to display the list of SNMP connection handler properties.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ get-connection-handler-prop --handler-name "SNMP Connection Handler"
The connection handler properties are listed with their values, as follows.
Property : Value(s) --------------------:------------------------------------------ allowed-client : - allowed-manager : * allowed-user : * community : OUD denied-client : - enabled : false listen-port : 161 opendmk-jarfile : - registered-mbean : false security-agent-file : config/snmp/security/oud-snmp.security security-level : authnopriv trap-port : 162 traps-community : OUD traps-destination : -
Restart the server by using stop-ds
and start-ds
.
If the server was started and no modifications were made to the configuration, the restart operation is not required.
Check that the SNMP Connection Handler is up and running.
$ snmpwalk -v 2c -c OUD@OUD localhost:8085 mib-2.66 SNMPv2-SMI::mib-2.66.1.1.1.1 = STRING: "Oracle Unified Directory Server 11.1.1.5.0 - 20090310152800Z" SNMPv2-SMI::mib-2.66.1.1.2.1 = STRING: "INSTANCE_DIR/bin" SNMPv2-SMI::mib-2.66.1.1.3.1 = Gauge32: 35 SNMPv2-SMI::mib-2.66.1.1.4.1 = Gauge32: 1 SNMPv2-SMI::mib-2.66.1.1.5.1 = Gauge32: 0 SNMPv2-SMI::mib-2.66.1.1.6.1 = Counter32: 0 SNMPv2-SMI::mib-2.66.1.1.7.1 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.1.1.1 = INTEGER: 1 SNMPv2-SMI::mib-2.66.2.1.1.1.2 = INTEGER: 2 SNMPv2-SMI::mib-2.66.2.1.1.1.3 = INTEGER: 3 SNMPv2-SMI::mib-2.66.2.1.2.1.1 = OID: SNMPv2-SMI::internet.27.3.8085 SNMPv2-SMI::mib-2.66.2.1.2.1.2 = OID: SNMPv2-SMI::internet.27.3.1389 SNMPv2-SMI::mib-2.66.2.1.2.1.3 = OID: SNMPv2-SMI::enterprises.42 SNMPv2-SMI::mib-2.66.2.1.3.1.1 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.3.1.2 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.3.1.3 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.4.1.1 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.4.1.2 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.4.1.3 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.5.1.1 = Counter32: 1 SNMPv2-SMI::mib-2.66.2.1.5.1.2 = Counter32: 1 ...
The managed objects included in the MIB 2605 are divided into three tables: dsTable
, dsAppliIfOpsTable
, and dsIntTable
. Currently, the dsIntTable
table is not implemented.
SNMP security configuration depends on the version of SNMP as you are using. This topic discusses security configuration for SNMP V1 and V2c, and V3.
Under SNMP v1 and SNMP v2c, agents act as information servers, and the IP-based access control protects this information from unauthorized access. By default, the MIB 2605 is accessible in v1 and v2c by using the community string OUD@OUD
. All managers are allowed to read the monitoring information exposed by the MIB 2605.
Note:
Only read access is authorized on the MIB 2605.
You can configure SNMP v1 and SNMP v2c by setting the SNMP connection handler properties with the dsconfig
command. Properties related to the SNMP v1 and SNMP v2c security configuration include:
allowed-manager
community
SNMP v1 traps are sent on server startup and server shutdown. By default, these traps are sent to localhost
and use the trap community string "OUD".
Note:
The default trap port might have to be changed to a value that is allowed by the system.
SNMP traps are also configured by setting the SNMP connection properties with the dsconfig
command. Properties related to SNMP traps include:
trap-port
traps-community
traps-destination
The ACL file that corresponds to the default values of the SNMP connection handler would be represented as follows:
acl = { { communities = OUD access = read-only managers = all } } trap = { { traps-community = OUD hosts = localhost } }
The SNMP v3 protocol provides more sophisticated security mechanisms than SNMP v1 and SNMP v2c. SNMP v3 implements a user-based security model (USM) that authenticates and encrypts the requests sent between agents and their managers, and provides user-based access control. A defaultUser
template is provided for adding authorized users in the agent engine using the SNMP cloning mechanism.
Under SNMP v3, the community string described in the previous section is used as the "context" from which the MIB 2605 is registered. By default, the MIB2605 is accessible in v3 by using the context "OUD". All users have access to it.
The SNMP v3 UACL is configured by setting the SNMP connection handler properties with the dsconfig
command-line utility. The properties related to SNMP v3 UACL configuration include:
community
allowed-user
security-level
The UACL file corresponding to the default values of the SNMP connection handler would be represented as follows:
uacl = { { context-names = OUD access = read-only security-level = authNoPriv users = * } }
The USM MIB (that is, the MIB that defines allowed users) is registered in the null
context and only a snmpAdmin
user with a security level authNoPriv
has read-write
access to it. This snmpAdmin
user can add additional users who can access the MIB 2605 information.
The SNMP v3 USM configuration is read from a template file that is located at INSTANCE_DIR/OUD/config/snmp/security/oud-snmp.security
. The template file is not encrypted.
To access the MIB 2605 in the server agent, use the SNMP clone mechanism to add a user in the security file. Use snmpAdmin
to send the SNMP request for the clone mechanism as shown here. The user to clone is defaultUser
. The snmpAdmin
and defaultUser
users cannot access the MIB 2605 information.
Admin User to add and configure other users.
userEntry=localEngineID,snmpAdmin,null,usmHMACMD5AuthProtocol,passadmin
Template user to be cloned with no read or write access.
userEntry=localEngineID,defaultUser,,usmHMACMD5AuthProtocol,password,,,3,true
Note:
The security file is also used to make the users persistent.
These topics describe how to monitor a replicated topology by using the dsreplication status
command, and how to use the ldapsearch
command to obtain more advanced monitoring information.
dsreplication
The simplest way to monitor replication is to use the dsreplication status
command. This command provides a tabular view of the replication status, including the following information:
The topology and its connections
The latency between replicated servers
The data consistency across replicated servers
The security configuration between replicated servers
The replication protocol peer to peer
The examples in the remainder of this section assume the following simple replication topology.
To obtain the replication status, run the following command:
$ dsreplication status --adminUID admin --adminPasswordFile pwd.txt -X \ --hostname host1 --port 4444
The output of this command includes the following:
Server. Lists the LDAP servers in the topology and the port on which they are listening for LDAP connections.
Entries. Indicates the number of entries on each server for the specified base DN. If the information in this column is not the same across all the servers, the replication topology is not synchronized.
M.C. Indicates the number of updates already pushed by the other LDAP servers in the topology, but not yet replayed on the specified LDAP server. If this number is high on a particular server, investigate the latency of that server.
A.O.M.C. Specifies the approximate date of the oldest update pushed by the other directory servers in the topology, but not yet processed on the specified LDAP server.
Port. Indicates the port of the replication server to which the specified LDAP server is directly connected.
Encryption. Indicates whether SSL encryption is enabled between the LDAP server and its replication server.
Trust. Indicates whether this server is configured as a trusted or untrusted server. For more information, see Section 26.10, "Using Isolated Replicas".
U.C. Specifies the number of changes that have been made on an untrusted server, and not yet replicated to the topology. For more information, see Section 26.10, "Using Isolated Replicas".
Status. Indicates the status of the replication domain on this directory server. The status can be one of the following:
Normal. The connection to a replication server is established with the correct data set. Replication is working. If assured mode is used, then acknowledgements from this directory server are sent.
Degraded. The connection to a replication server is established with the correct data set. Replication is working in degraded mode as the directory server has numerous changes that are pending in the replication server queue. If assured mode is used, then acknowledgements from this directory server are not expected.
Full Update. The connection to a replication server is established and a new data set is received from this connection (online import), to initialize the local back end.
Bad Data Set. The connection to a replication server is established with a data set that is different from the rest of the topology. Replication is not working. Either the other directory servers of the topology should be initialized with a compatible data set, or this server should be initialized with another data set that is compatible with the other servers.
Not Connected. The directory server is not connected to any replication server.
Change Log. Indicates whether the external change log is enabled for the base DN on this server. For more information, see Section 26.5, "Using the External Change Log".
Group ID. The ID of the replication group to which the server belongs. For more information, see Section 6.6, "Replication Groups".
Connected To. Displays the name, IP address and replication port of the replication server to which this directory server is connected.
Additional replication monitoring information is available under the cn=monitor
entry. You can use the ldapsearch
command to track specific monitoring attributes, which will provide you with a comprehensive view of the replication status. For more information, see Section 29.7.2, "Advanced Replication Monitoring".
The easiest way to monitor replication status is by using the dsreplication status
command. However, in depth replication monitoring information is available under the cn=monitor
entry. You can use the ldapsearch
command to track specific monitoring attributes, which provide you with a comprehensive view of the replication status. Monitoring information is consolidated by replication servers. Therefore, monitoring information can only be retrieved by searching a directory server that hosts a running replication server.
The examples in the remainder of this section assume the following simple replication topology.
These examples access the cn=monitor
entry on the administration port over SSL (--useSSL
) and automatically trust the certificate that is presented by the server (--trustAll
).
The information under cn=monitor
can be filtered to include a single replicated base DN. You can do this in two ways:
Specify the domain-name
attribute as a filter, for example:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=monitor" "(domain-name=dc=example,dc=com)"
Include the base DN in the search base, for example:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=dc_example_dc_com,cn=replication,cn=monitor" \ "(objectclass=*)"
This section covers the following monitoring topics:
Each directory server contains a list of candidate replication servers for each replicated base DN. However, a directory server is connected to only one replication server at a time.
To obtain an overview of the replication topology and its connections, run the following search on any directory server in the topology that hosts a replication server:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=monitor" "(connected-to=*)" "connected-to" "lost-connections" dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor lost-connections: 0 connected-to: llandudno/0:0:0:0:0:0:0:1:8989 dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor lost-connections: 0 connected-to: llandudno/0:0:0:0:0:0:0:1:8989 dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989 1740,cn=cn_ admin data,cn=replication,cn=monitor connected-to: Replication Server 8989 1740 dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989 1740,cn=dc_ example_dc_com,cn=replication,cn=monitor connected-to: Replication Server 8989 1740 dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989 1740,cn=cn_ schema,cn=replication,cn=monitor connected-to: Replication Server 8989 1740 dn: cn=Undirect Replica 22052,cn=Connected Replication Server noordhoek:9989 71 64,cn=Replication Server 8989 1740,cn=cn_schema,cn=replication,cn=monitor connected-to: Connected Replication Server noordhoek:9989 7164,cn=Replication Se rver 8989 1740,cn=cn_schema,cn=replication dn: cn=Undirect Replica 19984,cn=Connected Replication Server noordhoek:9989 71 64,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=moni tor connected-to: Connected Replication Server noordhoek:9989 7164,cn=Replication Se rver 8989 1740,cn=dc_example_dc_com,cn=replication dn: cn=Undirect Replica 30030,cn=Connected Replication Server noordhoek:9989 71 64,cn=Replication Server 8989 1740,cn=cn_admin data,cn=replication,cn=monitor connected-to: Connected Replication Server noordhoek:9989 7164,cn=Replication Se rver 8989 1740,cn=cn_admin data,cn=replication dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor lost-connections: 0 connected-to: llandudno/0:0:0:0:0:0:0:1:8989
The connected-to
attribute specifies the replication server to which each directory server is currently connected for a particular base DN. If a directory server is directly connected to the replication server, its DN includes cn=Connected Replica
. A directory server that is in the topology but is connected to a different replication server has cn=Undirect Replica
in its DN. Because all replication servers are permanently connected to all other replication servers, the connected-to
attribute does not exist for replication servers.
The lost-connections
attribute indicates the number of connection breaks between directory servers and replication servers. The value of this attribute on each directory server should be close to the number of times that replication has been stopped on that server. If the value of this attribute is much higher, there are unexpected connection losses that must be investigated.
Monitoring replication latency enables you to establish whether a specific replication server is lagging behind other servers in the topology. This provides a complete view of any replication delays and the current quality of service.
To monitor replication latency, run the following search on any server in the topology that hosts a replication server:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \ --trustAll -b "cn=monitor" "domain-name=dc=example,dc=com" "missing-changes" \ "approx-older-change-not-synchronized" dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor dn: cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor missing-changes: 0 dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989 1740,cn=dc_ example_dc_com,cn=replication,cn=monitor missing-changes: 0 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor missing-changes: 0 dn: cn=Undirect Replica 19984,cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor missing-changes: 0
The missing-changes
attribute specifies the number of updates already pushed by the other directory servers in the topology, but not yet replayed on the specified directory server.
The approx-older-change-not-synchronized
attribute specifies the approximate date of the oldest update pushed by the other directory servers in the topology, but not yet processed on the specified directory server.
Note:
If the replication latency, as defined by these attributes, is high, look at the number of updates sent and received to identify the servers in the topology that are causing the latency. These attributes are described later in this document.
Monitoring data consistency enables you to establish whether each replication server in the topology is synchronized and up-to-date with the latest changes that have occurred in the topology.
To monitor the data consistency across the directory servers in the topology, run the following search on any server in the topology that hosts a replication server:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \ -b "cn=monitor" "(generation-id=*)" "generation-id" dn: cn=Replication Server 8989 1740,cn=cn_admin data,cn=replication,cn=monitor generation-id: cn=admin data 94310 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=cn_admin data,cn=replication,cn=monitor generation-id: 94310 dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor generation-id: 19399981 dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor generation-id: 8468 dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989 1740,cn=cn_ admin data,cn=replication,cn=monitor generation-id: 94310 dn: cn=Replication Server 8989 1740,cn=cn_schema,cn=replication,cn=monitor generation-id: cn=schema 8468 dn: cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor generation-id: dc=example,dc=com 19399981 dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989 1740,cn=dc_ example_dc_com,cn=replication,cn=monitor generation-id: 19399981 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=cn_schema,cn=replication,cn=monitor generation-id: 8468 dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989 1740,cn=cn_ schema,cn=replication,cn=monitor generation-id: 8468 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor generation-id: 19399981 dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor generation-id: 94310
The generation-id
attribute indicates the version of the data in each replicated base DN, for each directory server. Note that the generation ID on all servers for the base DN dc=example,dc=com
is 19399981
. The consistency of the generation IDs means that the data on those servers is the same for that base DN.
Each directory server is also aware of the generation ID of the replication server to which it is connected. The generation ID of a replication server relates to the updates that are stored in its change log database for that base DN.
Replication is considered to be working correctly between two directory servers, for a specified base DN, when those servers and their replication server all have the same generation ID.
A secure replication topology has SSL encryption enabled between servers, for a particular base DN.
To monitor replication security, run the following search on any server in the topology that hosts a replication server:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \ -b "cn=monitor" "(ssl-encryption=*)" "ssl-encryption" dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 89 89 1740,cn=cn_admin data,cn=replication,cn=monitor ssl-encryption: true dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor ssl-encryption: true dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor ssl-encryption: true dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989 1740,cn=cn_ admin data,cn=replication,cn=monitor ssl-encryption: true dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989 1740,cn=dc_ example_dc_com,cn=replication,cn=monitor ssl-encryption: true dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 89 89 1740,cn=cn_schema,cn=replication,cn=monitor ssl-encryption: true dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989 1740,cn=cn_ schema,cn=replication,cn=monitor ssl-encryption: true dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor ssl-encryption: true dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor ssl-encryption: true
The ssl-encryption
attribute specifies whether the replication protocol is encrypted between two servers for a specified base DN. This information is available for each directory server or replication server. Authentication of replication sessions is not monitored.
Monitoring the number of updates that have been sent and received by the servers in a topology provides an indication of how well replication is working.
To monitor sent and received updates, type the following command:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \ -b "cn=monitor" "(&(sent-updates=*)(received-updates=*))" \ "sent-updates" "received-updates" dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=cn_admin data,cn=replication,cn=monitor sent-updates: 7 received-updates: 0 dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor received-updates: 28 sent-updates: 0 dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor received-updates: 0 sent-updates: 0 dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989 1740,cn=cn_ admin data,cn=replication,cn=monitor sent-updates: 0 received-updates: 0 dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989 1740,cn=dc_ example_dc_com,cn=replication,cn=monitor sent-updates: 28 received-updates: 0 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=cn_schema,cn=replication,cn=monitor sent-updates: 0 received-updates: 0 dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989 1740,cn=cn_ schema,cn=replication,cn=monitor sent-updates: 0 received-updates: 0 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor sent-updates: 0 received-updates: 28 dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor received-updates: 0 sent-updates: 0
The sent-updates
attribute indicates the number of updates that have been sent by this directory server or replication server.
The received-updates
attribute indicates the number of updates that have been received by this directory server or replication server.
The values of these attributes assist in determining the flow of updates within a topology. When replication appears to be very slow, it is helpful to monitor these attributes. If the number of updates sent by one server is consistently much higher than the number of updates received by another server, it is likely that the second server is a bottleneck in the topology.
The replication protocol controls the flow of updates between two servers. This ensures that when a high number of updates is exchanged between two servers, the servers are not prevented from processing operations with a higher priority. This functionality relies on a window mechanism where the recipient server periodically provides the sending server with the number of updates that the sending server can send.
You can specify the size of the send and receive windows, by setting the max-send-window
and max-rcv-window
configuration attributes. For more information, see Section 26.3, "Modifying the Replication Configuration With dsconfig
".
The current-send-window
monitoring attribute indicates how many changes can be sent by the sending server to the recipient server at that specific time. If the value of the current-send-window
attribute is often equal to 0, transmission is stopped and the recipient server is probably a bottleneck in the topology. If the value of the current-send-window
attribute is often equal to the value of the max-send-window
attribute, and you are experiencing high replication latency, it is likely that the sending server is a bottleneck in the topology.
To obtain the value of the current-send-window
property, type the following command:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \ -b "cn=monitor" "(current-send-window=*)" "current-send-window" dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=cn_admin data,cn=replication,cn=monitor current-send-window: 93 dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor current-send-window: 100 dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor current-send-window: 100 dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989 1740,cn=cn_ admin data,cn=replication,cn=monitor current-send-window: 100 dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989 1740,cn=dc_ example_dc_com,cn=replication,cn=monitor current-send-window: 72 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=cn_schema,cn=replication,cn=monitor current-send-window: 100 dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989 1740,cn=cn_ schema,cn=replication,cn=monitor current-send-window: 100 dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor current-send-window: 100 dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor current-send-window: 100
When multiple operations are performed on the same entry at the same time, replication conflicts can occur. In some cases, the replication mechanism is able to resolve these conflicts. In other cases, manual conflict resolution is required.
Three types of conflict attributes can be monitored:
unresolved-naming-conflicts
. Indicates the number of naming conflicts that could not be resolved by the replication mechanism.
resolved-naming-conflicts
. Indicates the number of naming conflicts that have been resolved.
resolved-modify-conflicts
. Indicates the number of modify conflicts that have been resolved.
To monitor resolved and unresolved replication conflicts, run the following command:
$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \ -b "cn=monitor" "(&(unresolved-naming-conflicts=*) \ (resolved-naming-conflicts=*) (resolved-modify-conflicts=*))" \ "unresolved-naming-conflicts" "resolved-naming-conflicts" \ "resolved-modify-conflicts" dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor resolved-naming-conflicts: 0 unresolved-naming-conflicts: 0 resolved-modify-conflicts: 0 dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor resolved-naming-conflicts: 0 unresolved-naming-conflicts: 0 resolved-modify-conflicts: 0 dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor resolved-naming-conflicts: 0 unresolved-naming-conflicts: 0 resolved-modify-conflicts: 0
You can use a variety of general UNIX tools to monitor your server environment. For information about these tools, see the man pages on your UNIX system.
The following general purpose UNIX monitoring tools can be used with Oracle Unified Directory.
Tool | Description |
---|---|
|
Provides information about disk I/O and CPU usage. |
|
Provides information about open file descriptors. |
|
Provides information about file system locks. |
|
Provides statistics about network functions. |
|
Allows you to query DNS servers for information about hosts and domains. |
|
Allows you to query the status of a remote host or network gateway. |
|
UNIX System V performance monitoring tool. |
|
Allows you to debug and monitor network traffic. |
|
Provides quick, easy monitoring of processes and CPU activities. |
|
Provides information about which system calls a process makes. |
|
Provides the path a packet takes throughout the Internet to reach its final destination. |
|
Provides statistics about process, virtual memory, disk, trap, and CPU activity. |
The following Solaris monitoring tools can be used with Oracle Unified Directory.
Tool | Description |
---|---|
|
Provides information about OS and application locking. Requires DTrace privileges. |
|
Provides statistics about each processor on the system. |
|
Provides a breakdown of how much memory a process is using. |
|
Monitors processes and threads. |
|
Monitors network traffic. Indispensable when debugging low-level packets. |
|
Provides functionality of the above listed tools and more. |
|
Provides information about which system calls a process makes. |
The following HP-UX monitoring tools can be used with Oracle Unified Directory.
Tool | Description |
---|---|
|
Provides detailed system information about open file descriptors, locks, and threads. |
|
GlancePlus is a graphical real-time performance diagnostic tool. Glance is the character-based component. |
|
Provides a system call trapper. |
|
Provides information about kernel parameters. |
|
Monitors network statistics. |
|
Provides a general system administration tool. |