![]() ![]() ![]() ![]() ![]() ![]() |
WebLogic logging services provide facilities for writing, viewing, filtering, and listening for log messages. These log messages are generated by WebLogic Server instances, subsystems, and Java EE applications that run on WebLogic Server or in client JVMs.
The following sections describe the WebLogic logging services environment, logging process, and log files:
WebLogic Server subsystems use logging services to provide information about events such as the deployment of new applications or the failure of one or more subsystems. A server instance uses them to communicate its status and respond to specific events. For example, you can use WebLogic logging services to report error conditions or listen for log messages from a specific subsystem.
Each WebLogic Server instance maintains a server log. Because each WebLogic Server domain can run concurrent, multiple instances of WebLogic Server, the logging services collect messages that are generated on multiple server instances into a single, domain-wide message log. The domain log provides the overall status of the domain. See Server Log Files and Domain Log Files.
The following sections describe the logging environment and provide an overview of the logging process.
There are two basic components in any logging system: a component that produces log messages and another component to distribute (publish) messages. WebLogic Server subsystems use a message catalog feature to produce messages and the Java Logging APIs to distribute them, by default. Developers can also use message catalogs for applications they develop.
The message catalog framework provides a set of utilities and APIs that your application can use to send its own set of messages to the WebLogic server log. The framework is ideal for applications that need to localize the language in their log messages, but even for those applications that do not need to localize, it provides a rich, flexible set of tools for communicating status and output.
See “ Using Message Catalogs with WebLogic Server” in Using WebLogic Logging Services for Application Logging.
In addition to using the message catalog framework, your application can use the weblogic.logging.NonCatalogLogger
APIs to send messages to the WebLogic server log, for logging messages that do not need to be internationalized or are internationalized outside the WebLogic I18n framework. With NonCatalogLogger
, instead of calling messages from a catalog, you place the message text directly in your application code.
See “ Using the NonCatalogLogger APIs” in Using WebLogic Logging Services for Application Logging.
To distribute messages, WebLogic Server supports Java based logging by default. The LoggingHelper
class provides access to the java.util.logging.Logger
object used for server logging. This lets developers take advantage of the Java Logging APIs to add custom handlers, filters, and formatters. See the Sun API documentation at
http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/package-summary.html.
Alternatively, you can configure WebLogic Server to use the Jakarta Project Log4j APIs to distribute log messages. See Log4j and the Commons Logging API.
Logger—A Logger
object logs messages for a specific subsystem or application component. WebLogic logging services use a single instance of java.util.logging.Logger
for logging messages from the Message Catalogs, NonCatalogLogger
, and the Debugging system.
Handler—A class that extends java.util.logging.Handler
and receives log requests sent to a logger. Each Logger
instance can be associated with a number of handlers to which it dispatches log messages. A handler attaches to a specific type of a log message; for example, the File Handler for the server log file.
Appender—An appender is Log4j terminology for a handler, in this case, an instance of a class that implements org.apache.log4j.Appender
and is registered with an org.apache.log4j.Logger
to receive log events.
WebLogic Server subsystems or application code send log requests to Logger
objects. These Logger
objects allocate LogRecord
objects which are passed to Handler
objects for publication. Both loggers and handlers use severity levels and (optionally) filters to determine if they are interested in a particular LogRecord
object. When it is necessary to publish a LogRecord
object externally, a handler can (optionally) use a formatter to localize and format the log message before publishing it to an I/O stream.
Figure 2-1 shows the WebLogic Server logging process: WebLogic Catalog APIs or Commons Logging APIs are used for producing messages; Java Logging (default) and Log4j are options for distributing messages.
Figure 2-1 illustrates the following process:
NonCatalogLogger
generate messages, they distribute their messages to the server Logger
object. Logger
reference which dispatches log requests to the server Logger
object.
The server Logger
object can be an instance of java.util.logging.Logger
or org.apache.log4j.Logger
.
Logger
object publishes the messages to any message handler that has subscribed to the Logger
.For example, the Stdout Handler prints a formatted message to standard out and the File Handler writes formatted output to the server log file. The Domain Log Broadcaster sends log messages to the domain log, which resides on the Administration Server, and the JMX Log Broadcaster sends log messages to JMX listeners on remote clients.
Consider the following recommendations for using WebLogic logging services with Java Logging or Log4j:
Logger
reference for adding custom handlers, appenders, or filters to WebLogic logging services for publishing messages.For more information, see How to Use Log4j with WebLogic Logging Services.
Each WebLogic Server instance writes all messages from its subsystems and applications to a server log file that is located on the local host computer. By default, the server log file is located in the logs
directory below the server instance root directory; for example, DOMAIN_NAME\
servers
\SERVER_NAME\
logs
\SERVER_NAME.
log
, where DOMAIN_NAME
is the name of the directory in which you located the domain and SERVER_NAME
is the name of the server.
In addition to writing messages to the server log file, each server instance forwards a subset of its messages to a domain-wide log file. By default, servers forward only messages of severity level NOTICE
or higher. While you can modify the set of messages that are forwarded, servers can never forward messages of the DEBUG
severity level. See “
Specifying the Messages That a Server Forwards to the Domain Log” in the Administration Console Online Help.
The domain log file provides a central location from which to view the overall status of the domain. The domain log resides in the Administration Server logs
directory. The default name and location for the domain log file is DOMAIN_NAME\
servers
\ADMIN_SERVER_NAME\
logs
\DOMAIN_NAME.
log
, where DOMAIN_NAME
is the name of the directory in which you located the domain and ADMIN_SERVER_NAME
is the name of the Administration Server. See “
Changing the Name and Location of the Domain Log File” in the Administration Console Online Help.
The timestamp for a record in the domain log is the timestamp of the server where the message originated. Log records in the domain log are not written in the order of their timestamps; the messages are written as soon as they arrive. It may happen that a Managed Server remains out of contact with the Administration Server for some period of time. In that case, the messages are buffered locally and sent to the Administration Server once the servers are reconnected.
To forward messages to the domain log, each server instance broadcasts its log messages. A server broadcasts all messages and message text except for messages of the DEBUG
severity level.
The Administration Server listens for a subset of these messages and writes them to the domain log file. To listen for these messages, the Administration Server registers a listener with each Managed Server. By default, the listener includes a filter that allows only messages of severity level NOTICE
and higher to be forwarded to the Administration Server. (See Figure 2-2.)
For any given WebLogic Server instance, you can override the default filter and create a log filter that causes a different set of messages to be written to the domain log file. For information on setting up a log filter for a WebLogic Server instance, see “ Create Log Filters” in the Administration Console Online Help.
If the Administration Server is unavailable, Managed Servers continue to write messages to their local server log files. However, by default, when the servers are reconnected, not all the messages written during the disconnected period are forwarded to the domain log file. A Managed Server keeps a specified number of messages in a buffer so they can be forwarded to the Administration Server when the servers are reconnected. The number of messages kept in the buffer is configured by the DomainLogBroadcasterBufferSize
attribute on the LogMBean. The default is 1
. With that default value, only the last logged message is forwarded to the Administration Server once it is reconnected. 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. See “
MSI Mode and the Domain Log File” in Managing Server Startup and Shutdown.
If you have configured a value greater than 1
, that number of messages will be forwarded to the domain log when the Managed Server is reconnected to the Administration Server.
Note: | This can result in a domain log file that lists messages with earlier timestamps after messages with later timestamps. When messages from the buffer of a previously disconnected Managed Server are flushed to the Administration Server, those messages are simply appended to the domain log, even though they were generated before the previous messages in the domain log. |
Each subsystem within WebLogic Server generates log messages to communicate its status. For example, when you start a WebLogic Server instance, the Security subsystem writes a message to report its initialization status. To keep a record of the messages that its subsystems generate, WebLogic Server writes the messages to log files.
The server log records information about events such as the startup and shutdown of servers, 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 server log messages to detect problems, track down the source of a fault, and track system performance. 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 and sends E-mail to a system administrator.
The server log file is located on the computer that hosts the server instance. Each server instance has its own server log file. By default, the server log file is located in the logs
directory below the server instance root directory; for example, DOMAIN_NAME\
servers
\SERVER_NAME\
logs
\SERVER_NAME.
log
, where DOMAIN_NAME
is the name of the directory in which you located the domain and SERVER_NAME
is the name of the server. See “
Changing the Name and Location of the Server Log File” in the Administration Console Online Help.
To view messages in the server log file, you can log on the WebLogic Server host computer and use a standard text editor, or you can log on to any computer and use the log file viewer in the Administration Console. See “ Viewing Server Logs” in the Administration Console Online Help.
Note: | BEA Systems recommends that you do not modify log files by editing them manually. Modifying a file changes the timestamp and can confuse log file rotation. In addition, editing a file might lock it and prevent updates from WebLogic Server and interfere with the Accessor functionality. |
Note: | For information about the Diagnostic Accessor Service, see “ Accessing Diagnostic Data Using the Data Accessor” in Configuring and Using the Weblogic Diagnostic Framework. |
In addition to writing messages to a log file, each server instance prints a subset of its messages to standard out. Usually, standard out is the shell (command prompt) in which you are running the server instance. However, some operating systems enable you to redirect standard out to some other location. By default, a server instance prints only messages of a NOTICE
severity level or higher to standard out. (A subsequent section, Message Severity, describes severity levels.) You can modify the severity threshold so that the server prints more or fewer messages to standard out.
If you use the Node Manager to start a Managed Server, the messages that would otherwise be output to stdout
or stderr
when starting a Managed Server, are instead displayed in the Administration Console and written to a single log file for that server instance, SERVER_NAME
.out
. The server instance’s output log is located in the same logs
directory, below the server instance root directory, along with the WebLogic Server SERVER_NAME.
log
file; for example, DOMAIN_NAME\
servers
\SERVER_NAME\
logs
\SERVER_NAME.
out
, where DOMAIN_NAME
is the name of the directory in which you located the domain and SERVER_NAME
is the name of the server.
The Node Manager writes its own startup and status messages to a single log file, NM_HOME
/nodemanager.log
, where NM_HOME
designates the Node Manager installation directory, by default, WL_HOME
/common/nodemanager
.
For more information on Node Manager log files, see “ Node Manager Log and Configuration Files” in Managing Server Startup and Shutdown.
The server log messages and log file 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 Transaction Manager uses the default persistent store to store transaction log files. Using the Administration Console, you can change where the default store is located. See “ Configure the default persistent store for Transaction Recovery Service migration” in the Administration Console Online Help.
All auditing information recorded by the WebLogic Auditing provider is saved in WL_HOME\
DOMAIN_NAME
\servers\
SERVER_NAME
\logs\DefaultAuditRecorder.log
. Although an Auditing provider is configured per security realm, each server writes auditing data to its own log file in the server directory.
JMS server log files contain information on basic message life cycle events, such as message production, consumption, and removal. When a JMS destination hosting the subject message is configured with message logging enabled, then each of the basic message life cycle events will generate a message log event in the JMS message log file.
The message log is located in the logs
directory, below the server instance root directory, DOMAIN_NAME\
servers
\SERVER_NAME\
logs
\
jmsServers
\SERVER_NAME
JMSServer
\
jms.messages.log
, where DOMAIN_NAME
is the name of the directory in which you located the domain and SERVER_NAME
is the name of the server.
After you create a JMS server, you can change the default name of its log file, as well as configure criteria for moving (rotating) old log messages to a separate file. See “ Configure Message Logging” in the Administration Console Online Help and “ Monitoring JMS Statistics and Managing Messages” in Configuring and Managing WebLogic JMS.
When a WebLogic Server instance writes a message to the server log file, 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 message in the server log file:
####<Sept 22, 2004 10:46:51 AM EST> <Notice> <WebLogicServer> <MyComputer> <examplesServer> <main> <<WLS Kernel>> <> <null> <1080575211904> <BEA-000360>
<Server started in RUNNING mode>
In this example, the message attributes are: Locale-formatted Timestamp, Severity, Subsystem, Machine Name, Server Name, Thread ID, User ID, Transaction ID, Diagnostic Context ID, Raw Time Value, Message ID, and Message Text. (A subsequent section, Message Attributes, describes each attribute.)
If a message is not logged within the context of a transaction, the angle brackets for Transaction ID are present even though no Transaction ID is present.
If the message includes a stack trace, the stack trace is included in the message text.
WebLogic Server uses the host computer’s default character encoding for the messages it writes.
When a WebLogic Server instance writes a message to standard out, the output does not include the ####
prefix and does not include the Server Name, Machine Name, Thread ID, User ID, Transaction ID, Diagnostic Context ID, and Raw Time Value fields.
The following is an example of how the message from the previous section would be printed to standard out:
<Sept 22, 2004 10:51:10 AM EST> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>
In this example, the message attributes are: Locale-formatted Timestamp, Severity, Subsystem, Message ID, and Message Text.
The messages for all WebLogic Server instances contain a consistent set of attributes as described in Table 2-1. In addition, if your application uses WebLogic logging services to generate messages, its messages will contain these attributes.
Indicates the degree of impact or seriousness of the event reported by the message. See Message Severity.
|
|
|
|
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.
|
|
All message IDs that WebLogic Server system messages generate start with
BEA- and fall within a numerical range of 0-499999.
Your applications can use a Java class called
NonCatalogLogger to generate log messages instead of using an internationalized message catalog. The message ID for NonCatalogLogger messages is always 000000 .
See "
Writing Messages to the WebLogic Server Log" in Using WebLogic Logging Services for Application Logging.
|
|
The severity attribute of a WebLogic Server log message indicates the potential impact of the event or condition that the message reports.
Table 2-2 lists the severity levels of log messages from WebLogic Server subsystems, starting from the lowest level of impact to the highest.
Used for messages from the Diagnostic Action Library. Upon enabling diagnostic instrumentation of server and application classes,
TRACE messages follow the request path of a method.
See “
Diagnostic Action Library” in Configuring and Using the Weblogic Diagnostic Framework.
|
|
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 WebLogic logging services, it can use an additional severity level, DEBUG
. See “
Writing Debug Messages” in Using WebLogic Logging Services for Application Logging.
The WebLogic Server Administration Console provides a log viewer for all the log files in a domain. The log viewer can find and display the messages based on any of the following message attributes: date, susbsystem, severity, machine, server, thread, user ID, transaction ID, context ID, timestamp, message ID, or message. It can also display messages as they are logged or search for past log messages. (See Figure 2-3.)
For information about viewing, configuring, and searching message logs, see the following topics in the Administration Console Online Help:
For a detailed description of log messages in WebLogic Server message catalogs, see “ WebLogic Server Message Catalogs.” This index of messages describes all of the messages emitted by WebLogic subsystems and provides a detailed description of the error, a possible cause, and a recommended action to avoid or fix the error.
![]() ![]() ![]() |