|
 |
| e-docs > WebLogic Server > Administration Guide > Using Log Messages to Manage WebLogic Server |
|
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:
For information on setting up your application to listen for messages, refer to the Using WebLogic Logging Services Guide.
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:
The messages for all subsystems contain a consistent set of fields (attributes) as described in the following table.
|
The time and date when the message originated, in a format that is specific to the locale. |
|
|
Indicates the degree of impact or seriousness of the event reported by the message. For more information, refer to Message Severity. |
|
|
Indicates the subsystem of WebLogic Server that was the source of the message. For example, EJB, RMI, JMS. |
|
|
Identify the origins of the message. Transaction ID is present only for messages logged within the context of a transaction. |
|
|
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. |
|
|
A unique six-digit identifier. Message IDs through 499999 are reserved for WebLogic Server system messages. |
|
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.
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.
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.
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.
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
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:
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.
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:
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 filenamennnnn, 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:
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:
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.
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
For more information, refer to the following topics:
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.
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.
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:
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:
See "Enabling Configuration Auditing" in the Administration Console Online Help.
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.
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.
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:
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
