bea.com | products | dev2dev | support | askBEA

Download Docs | Site Map | Glossary
Search

Administration Guide

Using Log Messages to Manage WebLogic Server

WebLogic Server uses log messages to record information about events such as the deployment of new applications or the failure of one or more subsystems. The messages include information about the time and date of the event as well as the ID of the user who initiated the event.

You can view and sort these messages to detect problems, track down the source of a fault, and track system performance. For example, you can determine which user deployed a specific application or which user changed the thread pool count on a specific day. You can also create client applications that listen for these messages and respond automatically. For example, you can create an application that listens for messages indicating a failed subsystem. If a subsystem fails, the application can send email to a system administrator.

This topic contains the following sections:

- WebLogic Server Log Messages

- Exceptions and Stack Traces

- WebLogic Server Log Files

- Output to Standard Out

- Configuration Auditing

- Additional Log Files

For information on setting up your application to listen for messages, refer to the Using WebLogic Logging Services Guide.

WebLogic Server Log Messages

Compiled within the weblogic.jar file are sets of messages that each subsystem within WebLogic Server uses to communicate its status. For example, when you start a WebLogic Server instance, the Security subsystem writes a message to report its initialization status.

This section contains the following subsections:

- Message Attributes

- Message Output

Message Attributes

The messages for all subsystems contain a consistent set of fields (attributes) as described in the following table.

Table 4-1 Message Attributes

Attribute | Description
--- | ---
Timestamp | The time and date when the message originated, in a format that is specific to the locale.
Severity | Indicates the degree of impact or seriousness of the event reported by the message. For more information, refer to Message Severity.
Subsystem | Indicates the subsystem of WebLogic Server that was the source of the message. For example, EJB, RMI, JMS.
Server Name Machine Name Thread ID Transaction ID | Identify the origins of the message. Transaction ID is present only for messages logged within the context of a transaction.
User | The user ID under which the associated event was executed. To execute some pieces of internal code, WebLogic Server authenticates the ID of the user who initiates the execution and then runs the code under a special Kernel Identity user ID. J2EE modules such as EJBs that are deployed onto a server instance report the user ID that the module passes to the server. Log messages that are generated within a client JVM client do not include this field.
Message ID | A unique six-digit identifier. Message IDs through 499999 are reserved for WebLogic Server system messages.
Message Text | A description of the event or condition.

Message Severity

The severity attribute of a WebLogic Server log message indicates the potential impact of the event or condition that the message reports.

The following table lists the severity levels of log messages from WebLogic Server subsystems, starting from the lowest level of impact to the highest.

Table 4-2 Message Severity

Severity | Meaning
--- | ---
INFO | Used for reporting normal operations.
WARNING | A suspicious operation or configuration has occurred but it may not have an impact on normal operation.
ERROR | A user error has occurred. The system or application is able to handle the error with no interruption, and limited degradation, of service.
NOTICE | An INFO or WARNING-level message that is particularly important for monitoring the server.
CRITICAL | A system or service error has occurred. The system is able to recover but there might be a momentary loss, or permanent degradation, of service.
ALERT | A particular service is in an unusable state while other parts of the system continue to function. Automatic recovery is not possible; the immediate attention of the administrator is needed to resolve the problem.
EMERGENCY | The server is in an unusable state. This severity indicates a severe system failure or panic.

WebLogic Server subsystems generate many messages of lower severity and fewer messages of higher severity. For example, under normal circumstances, they generate many INFO messages and no EMERGENCY messages.

If your application uses the WebLogic logging services, it can use an additional severity level, DEBUG. WebLogic Server subsystems do not use this severity level. For more information, refer to Writing Debug Messages in the Using WebLogic Logging Services Guide.

Message Output

When a WebLogic Server instance outputs a message, the first line of each message begins with #### followed by the message attributes. Each attribute is contained between angle brackets.

The following is an example of a log message:

>     ####<Jun 2, 2002 10:23:02 AM PDT> <Info> <SSL> <bigbox> <myServer>
>         <SSLListenThread> <harry> <> <004500> <Using exportable strength SSL>

In this example, the message attributes are: Timestamp, Severity, Subsystem, Machine Name, Server Name, Thread ID, User ID, Transaction ID, Message ID, and Message Text.

If a message is not logged within the context of a transaction, the angle brackets (separators) for Transaction ID are present even though no Transaction ID is present.

If the message includes a stack trace, the stack trace follows the list of message attributes.

The character encoding used in writing the log files is the default character encoding of the host system.

Exceptions and Stack Traces

Some WebLogic Server log messages indicate an exception has been thrown. If the JVM generates a stack trace with the exception, the WebLogic Server log message includes the stack trace.

You can specify whether a WebLogic Server instance writes the stack traces to its log file.

If an application that uses WebLogic logging services is running in a remote JVM, the application sends its exceptions and stack traces to the WebLogic logging services. You use the Administration Console to determine whether an instance of WebLogic Server writes these remote exceptions and stack traces to its log file.

For more information on configuring logging of exceptions and stack traces, refer to Configuring Debug Information in the Server Log File in the Administration Console Online Help.

WebLogic Server Log Files

To persist the messages that it generates, WebLogic Server writes the messages to log files. You can view these files with a standard text editor or the with log file viewer in the Administration Console.

Note: We recommend that you do not modify log files by manually editing them. Modifying a file changes the timestamp and can confuse log file rotation. In addition, editing a file might lock it and prevent updates from a WebLogic Server.

This section contains the following subsections:

- Local Log Files and Domain Log Files

- Log File Names and Locations

- Log File Rotation

- WebLogic Log File Viewer

Local Log Files and Domain Log Files

Each WebLogic Server instance writes all messages from its subsystems and applications to a log file that is located on the local host machine. In addition, each instance uses Java Management Extensions (JMX) to broadcast its messages as JMX notifications. A server broadcasts all messages and message text except for the following:

- Messages of the DEBUG severity level.

- Any stack traces that are included in a message.

When a WebLogic Server instance starts, the Administration Server's message listener registers itself with the server's log broadcaster. At the time of registration, a default filter is provided that determines which messages the Administration Server listens for. The Administration Server writes these messages to an additional domain-wide log file. (See Figure 4-1.)

Note: If a Managed Server is running in Managed Server Independence (MSI) mode, it writes to the domain log file directly. See "MSI Mode and the Domain Log File."

Figure 4-1 WebLogic Server Logging Services

The default filter selects only messages of severity level ERROR and higher. In this way, the domain log provides a summary of the domain's overall status.

For any given WebLogic Server instance, you can override the default filter and create a domain log filter that causes a different set of messages to be written to the domain log file. For information on setting up a domain log filter for a WebLogic Server instance, refer to Domain Log Filters in the Administration Console Online Help.

If the Administration Server is unavailable, Managed Servers continue to write messages to their local log files, but they do not keep track of which messages they generate while the Administration Server is unavailable. For example, if the Administration Server is unavailable for two hours and then is restored, the domain log will not contain any messages that were generated during the two hours.

Log File Names and Locations

By default, the local server log file is named ./SERVER_NAME/SERVER_NAME.log, where SERVER_NAME is the name of the server. The path is relative to the server's root directory.

The default name for a domain log file is ./DOMAIN_NAME.log, where DOMAIN_NAME is the name of the domain. The path is relative to the root directory of the Administration Server.

To include a time or date stamp in the file name when the log file is rotated add java.text.SimpleDateFormat variables to the log's file name. For more information, see the next section, Log File Rotation.

For information, see the following: on changing the names and locations of the log files, refer to the following topics in the Administration Console Online Help:

- A Server's Root Directory

- "Specifying General Log File Settings" in the Administration Console Help

- "Specifying the Name and Location of the Domain Log File" in the Administration Console Help

Log File Rotation

By default, local log files and domain log files grow in size indefinitely. You can specify that a WebLogic Server instance renames (rotates) a log file periodically. Old messages remain in the renamed log file and new messages accumulate in the new log file. You can base log file rotation on the size of the log file or on a time interval.

To include a time or date stamp in the file name when the log file is rotated, add java.text.SimpleDateFormat variables to the log's file name. Surround each variable with percentage (%) characters.

For example, if you enter the following value for a server's local log file name:
myserver_%yyyy%_%MM%_%dd%_%hh%_%mm%.log

the server's log file will be named:
myserver_yyyy_MM_dd_hh_mm.log

When the server instance rotates the log file, the rotated file name contains the date stamp. For example, if the server instance rotates its local log file on 2 April, 2003 at 10:05 AM, the log file that contains the old log messages will be named:
myserver_2003_04_02_10_05.log

If you do not include a time and date stamp, the rotated log files are numbered in order of creation filename nnnnn, where filename is the name configured for the log file. For example: myserver.log00007.

You use the Administration Console to specify rotation criteria for each WebLogic Server instance's local log file. You also use the Administration Console to specify criteria for rotating the domain message log file.

You can also specify the maximum number of rotated files that can accumulate. After the number of log files reaches this number, subsequent file rotations overwrite the oldest log file.

Note: Log rotation by time is based on the timestamp of the files. Modifying a log file changes the timestamp and can confuse log rotation.

For information on specifying rotation criteria, refer to the following sections in the Administration Console Online Help:

- Specifying Log File Rotation

- Specifying Criteria for Rotating Domain Log Files

WebLogic Log File Viewer

The Administration Console provides separate but similar log viewers for the local server log and the domain-wide message log. The log viewer can search for messages based on fields within the message. For example, it can find and display messages based on the severity, time of occurrence, user ID, subsystem, or the short description. It can also display messages as they are logged, or search for past log messages.

Figure 4-2 Log Viewer in the Administration Console

For information about viewing, configuring, and searching message logs from the Administration Console, refer to the following topics in the Administration Console Online Help:

- Viewing Server Logs

- Viewing the Domain Log

Because log files are simple text files, you can also use other applications to view them. For information about finding the log files, refer to Log File Names and Locations.

Output to Standard Out

In addition to writing messages to log files, a WebLogic Server instance can print a subset of its messages to standard out. By default, all messages of ERROR severity or higher are printed to standard out and messages of the DEBUG severity are not printed to standard out. If you configure a server to print stack traces to its log file, the stack traces are also printed to standard out.

If you use the Node Manager to start a Managed Server, the Node Manager writes standard out and standard error messages to its log file. You can view these messages from the Administration Console on the Machine—>Monitoring tab.

For more information, refer to the following topics:

- For information on determining which WebLogic Server messages are sent to standard out, refer to Specifying General Log File Settings in the Administration Console Online Help.

- For information on printing stack traces to a log file, refer to Configuring Debug Information in the Server Log File in the Administration Console Online Help.

- For information on viewing messages for a Managed Server that you start with the Node Manager, refer to Managed Server Log Files in the Creating and Configuring WebLogic Server Domains guide.

- For information on viewing the standard output stream for server instances that run as Windows services, refer to Redirecting Standard Out and Standard Error to a File.

Redirecting System.out and System.err to a File

In addition to the configurable set of log messages that a server instance prints to standard out, servlets can invoke system.out.println and the JVM within which a WebLogic Server instance runs can send messages to standard error and standard out. If you use a WebLogic Server script to start a server instance, there is no default, persistent storage for the standard error and standard out messages.

The JVM within which a WebLogic Server instance runs also can send messages to standard error and standard out. If you use a WebLogic Server script to start a server instance, there is no default, persistent storage for the standard error and standard out messages.

If you want to keep a record of these messages, edit the WebLogic Server start script so it specifies the following Java options:

-Dweblogic.Stdout="stdout-filename"
-Dweblogic.Stderr="stderr-filename"

Where stdout-filename is the name of a file that you want to save standard out messages and stderr-filename is the name of a file that you want to save standard error messages.

To view the contents of these files, use a text editor or command prompt utility such as the DOS tail program. You cannot view them from the Administration Console.

Note: WebLogic Server prompts for entering your username and password are sent to standard out. If you use -Dweblogic.Stdout, you will no longer see the prompts to enter your username and password. To bypass this prompt, use a boot identity file as described in Bypassing the Prompt for Username and Password.

For information on passing arguments to the weblogic.Server command, refer to Frequently Used Optional Arguments.

Garbage Collection Comments

While the -Dweblogic.Stdout and -Dweblogic.Stderr options cause a JVM to redirect all of its java.lang.System.out and java.lang.System.err messages to a file, a JVM does not print its garbage collection comments to System.out or System.err. If you start a JVM with the -verbosegc option, the JVM will print the verbosegc output to the shell in which the JVM is running, regardless of whether you specify -Dweblogic.Stdout or -Dweblogic.Stderr. Some JVMs provide non-standard options for printing garbage collection comments to a file. For more information, view the help for your JVM's non-standard options by entering java -X in a shell.

Configuration Auditing

You can configure the Administration Server to emit log messages when a user changes the configuration or invokes management operations on any resource within a domain. For example, if a user disables SSL on a Managed Server in a domain, the Administration Server emits log messages. These messages provide an audit trail of changes within a domain's configuration (configuration auditing).

The following sections describe configuration auditing:

- Enabling Configuration Auditing

- Configuration Auditing Messages

The Administration Server writes configuration auditing messages to its local log file. Because all configuration auditing messages are of the Info severity, they are not written to the domain-wide message log by default. For information on changing this default, see "Domain Log Filters" in the Administration Console Online Help.

In addition to writing messages to its local log file, the Administration Server broadcasts configuration auditing messages as JMX notifications. You can create a JMX listener and filter that responds to these messages. For example, if the Administration Server emits a message that indicates an unauthorized user has attempted to change the domain's configuration, the JMX listener and filter can send email. See "Listening for Configuration Auditing Messages" in Programming WebLogic Management Services with JMX.

Enabling Configuration Auditing

To enable the Administration Server to emit configuration-auditing messages, do one of the following:

- Start the Administration Console and enable configuration auditing.

  See "Enabling Configuration Auditing" in the Administration Console Online Help.

- When you start the Administration Server, include the following Java option in the weblogic.Server command:

  -Dweblogic.AdministrationMBeanAuditingEnabled=true

  See Using the weblogic.Server Command.

- After the Administration Server has started, use the weblogic.Admin utility to change the value of the DomainMBean's AdministrationMBeanAuditingEnabled attribute.

  For example, the following command disables configuration auditing for the examples domain:

  java weblogic.Admin SET
  -mbean examples:Name=examples,Type=Domain
  -property AdministrationMBeanAuditingEnabled true

  For information about using weblogic.Admin to change values of MBean attributes, "MBean Management Command Reference."

Configuration Auditing Messages

All configuration auditing messages are of the Info severity and are identified by message IDs that fall within the range of 159900-159910.

The messages use managed bean (MBean) object names to identify resources. MBean object names provide an unambiguous identification regardless of the interface (Administration Console, command-line utility, or API) that is used to invoke operations or modify the resource. See "Using WebLogicObjectNames for WebLogic Server MBeans" in Programming WebLogic Management Services with JMX.

Table 4-3 summarizes the messages.

Table 4-3 Summary of Configuration Auditing Messages

When This Event Occurs... | WebLogic Server Generates a Message With This ID... | And This Message Text...
--- | --- | ---
Authorized user creates a resource. | 159900 | USER username CREATED MBean-name where username identifies the WebLogic Server user who logged in and created a resource.
Unauthorized user attempts to create a resource. | 159901 | USER username CREATED MBean-name FAILED weblogic.management. NoAccessRuntimeException: exception-text stack-trace where username identifies the unauthorized WebLogic Server user.
Authorized user deletes a resource. | 159902 | USER username REMOVED MBean-name where username identifies the WebLogic Server user who logged in and created a resource.
Unauthorized user attempts to delete a resource. | 159903 | USER username REMOVE MBean-name FAILED weblogic.management. NoAccessRuntimeException: exception-text stack-trace where username identifies the WebLogic Server user who logged in and created a resource.
Authorized user changes a resource's configuration. | 159904 | USER username MODIFIED MBean-name ATTRIBUTE attribute-name FROM old-value TO new-value where username identifies the WebLogic Server user who logged in and changed the resource's configuration.
Unauthorized user attempts to change a resource's configuration. | 159905 | USER username MODIFY MBean-name ATTRIBUTE attribute-name FROM old-value TO new-value FAILED weblogic.management. NoAccessRuntimeException: exception-text stack-trace where username identifies the unauthorized WebLogic Server user.
Authorized user invokes an operation on a resource. For example, a user deploys an application or starts a server instance. | 159907 | USER username INVOKED ON MBean-name METHOD operation-name PARAMS specified-parameters where username identifies the WebLogic Server user who logged in and invoked a resource operation.
Unauthorized user attempts to invoke an operation on a resource. | 159908 | USER username INVOKED ON MBean-name METHOD operation-name PARAMS specified-parameters FAILED weblogic.management. NoAccessRuntimeException: exception-text stack-trace where username identifies the unauthorized WebLogic Server user.
Authorized user enables configuration auditing. | 159909 | USER username, Configuration Auditing is enabled where username identifies the WebLogic Server user who enabled configuration auditing.
Authorized user disables configuration auditing. | 159910 | USER username, Configuration Auditing is disabled where username identifies the WebLogic Server user who disabled configuration auditing.

Note: Each time an authorized user adds, modifies, or deletes a resource the Management subsystem also generates Info message with the ID 140009. For example:

<Sep 15, 2003 11:54:47 AM EDT> <Info> <Management> <140009> <Configuration changes for domain saved to the repository.>

The Management subsystem generates this message regardless of whether configuration auditing is enabled.

While the message informs you that the domain's configuration has changed, it does not provide the detailed information that configuration auditing messages provide. Nor does the Management subsystem generate this message when you invoke operations on resources.

Table 4-4 lists additional message attributes for configuration auditing messages. All configuration auditing messages specify the same values for these attributes.

Table 4-4 Common Message Attributes and Values

Message Attribute | Attribute Value
--- | ---
Severity | Info
Subsystem | Configuration Audit
User ID | kernel identity This value is always kernel identity, regardless of which user modified the resource or invoked the resource operation.
Server Name | AdminServerName Because the Administration Server maintains the configuration data for all resources in a domain, this value is always the name of the Administration Server.
Machine Name | AdminServerHostName Because the Administration Server maintains the configuration data for all resources in a domain, this value is always the name of the Administration Server's host machine.
Thread ID | execute-thread The value depends on the number of execute threads that are currently running on the Administration Server.
Timestamp | timeStamp at which the message is generated.

Additional Log Files

The log messages and files that are discussed in previous sections of this topic communicate events and conditions that affect the operation of the server or the application.

Some subsystems maintain additional log files to provide an audit of the subsystem's interactions under normal operating conditions. The following list describes each of the additional log files:

- The HTTP subsystem can keep a log of all HTTP transactions in a text file. You can set the attributes that define the behavior of HTTP access logs for each server or for each virtual host that you define. For more information, refer to Setting Up HTTP Access Logs.

- The JDBC subsystem keeps a log of various events related to JDBC connections, including registering JDBC drivers and SQL exceptions. Note that some events related to JDBC are written to the server log, such as when connections are created or refreshed or when configuration changes are made to JDBC objects.

- The JTA subsystem keeps a transaction log to report statistics on transactions. For more information, refer to Monitoring and Logging Transactions.