PingDirectory Server provides the following health checks:

Measure the response time for searches and examine the entry contents
The health check might retrieve a monitoring entry from a server and base the health check result on whether the entry was returned, how long it took to be returned, and whether the value of the returned entry matches what was expected.
Monitor the replication backlog
If a server falls too far behind in replication, then the Directory Proxy Server can stop sending requests to it. A server is classified as degraded or unavailable if the threshold is reached for the number of missing changes, the age of the oldest missing change, or both.
Consume Directory Server administrative alerts
If the Directory Server indicates there is a problem, such as an index that must be rebuilt, then it flags itself as degraded or unavailable. When the Directory Proxy Server detects this, it stops sending requests to the server. The Directory Proxy Server detects administrative alerts as soon as they are issued by maintaining an LDAP persistent search for changes within the cn=alerts branch of the Directory Server.

When the Directory Proxy Server is notified by the Directory Server of a new alert, it immediately retrieves the base cn=monitor entry of the Directory Server. If this entry has a value for the unavailable-alert-type attribute, then the Directory Proxy Server considers it unavailable. If this entry has a value for the degraded-alert-type attribute, then the Directory Proxy Server considers it degraded. Clients of the Directory Proxy Server can use a similar mechanism to detect and react when a Directory Proxy Server flags itself as degraded or unavailable.

Monitor the busyness of the server
If a server becomes too busy, you can mark it as degraded or unavailable so that less heavily-loaded servers are preferred.


The health check results contain the following server states:

Completely accessible for use.
The server can be used if necessary but has a condition which can make it less desirable than other servers. For example, it is slow to respond or has fallen behind in replication.
Completely unsuitable for use. For example, the server is offline or is missing critical data.

Health check results include a numeric score that has a value between 1 and 10. This score helps rank servers with the same state. For example, two servers are available and one has a score of 8 and the other a score of 7, you can configure the Directory Proxy Server to prefer the server with the higher score.

The results of health checks are made available to the load-balancing algorithms to help determine where to send requests. The Directory Server attempts to use servers with a state of available before trying servers with a state of degraded. It never attempts to use servers with a state of unavailable.

Some load-balancing algorithms also take the health check score into account, such as the health-weighted load-balancing algorithm that prefers servers with higher scores over those with lower scores. You should configure the algorithms that work best for you environment.


The Directory Server periodically invokes health checks to monitor each LDAP external server and initiates health checks in response to failed operations. It checks the health of the LDAP external servers at intervals configured in the LDAP server’s health-check-frequency property. The Directory Proxy Server contains safeguards to ensure that only one health check is in progress at any time against a backend server to avoid affecting its ability to process other requests.

To associate a health check with an LDAP external server and set the health check frequency, you must configure the health-check and health-check-frequency properties of the LDAP external server.

For more information about configuring the properties of the external server, see Configuring an external server using dsconfig.

Server states and search response times

In some cases, an LDAP health check defines different sets of criteria for promoting and demoting the state of a server. A degraded server might need to meet more stringent requirements to be reclassified as available than originally for it to be considered degraded.

If response time is used in the process of determining the health of a server, then the Directory Server might have a faster response time threshold for transitioning a server from degraded back to available than the threshold used to consider it degraded in the first place. This threshold difference helps avoid cases in which a server repeatedly transitions between the two states because it is operating near the threshold.

For example, the health check used to measure search response time is configured to mark any server as degraded when the search response time is greater than 1 second. You can configure that the response time must be less than 500 ms before the server is made available again so that the Directory Server does not flip back and forth between available and degraded.

For more information about configuring health checks, see Configuring Server Health Checks.