Error log
By default, this log file is available at logs/errors below the server install root, and it provides information about warnings, errors, and other significant events that occur within the server. A number of messages are written to this file on startup and shutdown, but while the server is running, there is normally little information written to it. In the event that a problem does occur, the server writes information about that problem to this file.
The following is an example of a message that might be written to the error log:
[11/Apr/2011:10:31:53.783 -0500] category=CORE severity=NOTICE msgID=458887 msg="The {pingauthorize} Server has started successfully."
The category field provides information about the area of the server from which the message was generated. Available categories include:
ACCESS_CONTROL, ADMIN, ADMIN_TOOL, BACKEND, CONFIG, CORE, DSCONFIG, EXTENSIONS, PROTOCOL, SCHEMA, JEB, SYNC, LOG, PLUGIN, PROXY, QUICKSETUP, REPLICATION, RUNTIME_INFORMATION, TASK, THIRD_PARTY, TOOLS, USER_DEFINED, UTIL, VERSION
The severity field provides information about how severe the server considers the problem to be. Available severities include:
DEBUG-
Used for messages that provide verbose debugging information and do not indicate any kind of problem. Note that this severity level is rarely used for error logging, because the server provides a separate debug logging facility.
INFORMATION-
Used for informational messages that can be useful from time to time but are not normally something that administrators need to see.
MILD_WARNING-
Used for problems that the server detects, which can indicate something unusual occurred, but the warning does not prevent the server from completing the task it was working on. These warnings are not normally something that should be of concern to administrators.
MILD_ERROR-
Used for problems detected by the server that prevented it from completing some processing normally but that are not considered to be a significant problem requiring administrative action.
NOTICE-
Used for information messages about significant events that occur within the server and are considered important enough to warrant making available to administrators under normal conditions.
SEVERE_WARNING-
Used for problems that the server detects that might lead to bigger problems in the future and should be addressed by administrators.
SEVERE_ERROR-
Used for significant problems that have prevented the server from successfully completing processing and are considered important.
FATAL_ERROR-
Used for critical problems that arise which might leave the server unable to continue processing operations normally.
The messages written to the error log can be filtered based on their severities in two ways. First, the error log publisher has a default-severity property, which can be used to specify the severity of messages logged regardless of their category. By default, this includes the NOTICE, SEVERE_WARNING, SEVERE_ERROR, and FATAL_ERROR severities.
You can override these severities on a per-category basis using the override-severity property. If this property is used, then each value should consist of a category name followed by an equal sign and a comma-delimited set of severities that should be logged for messages in that category. For example, the following override severity would enable logging at all severity levels in the PROTOCOL category:
protocol=debug,information,mild-warning,mild-error,notice,severe-warning,severe-error,fatal-error
Note that for the purposes of this configuration property, any underscores in category or severity names should be replaced with dashes. Also, severities are not inherently hierarchical, so enabling the DEBUG severity for a category will not automatically enable logging at the INFORMATION, MILD_WARNING, or MILD_ERROR severities.
The error log configuration can be altered on the fly using tools like dsconfig, the Administrative Console, or the LDIF connection handler, and changes will take effect immediately. You can configure multiple error logs that are active in the server at the same time, writing to different log files with different configurations. For example, a new error logger can be activated with a different set of default severities to debug a short-term problem, and then that logger can be removed after the problem is resolved, so that the normal error log does not contain any of the more verbose information.