Skip navigation.

Administration Console Online Help

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index

Server Log

[Attributes and Console Screen Reference for Logging]

By default, each WebLogic Server instance maintains a server log, an HTTP access log, and a Java Transaction API (JTA) transaction log. You can also configure a server instance to maintain a Java Database Connectivity (JDBC) log.

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 email to a system administrator.

The following sections describe working with the server log:

For related information, refer to:

 


Overview of WebLogic Server Log Messages and Log Files

Each subsystem within WebLogic Server generates server 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 file is located on the computer that hosts the server instance. By default, the server log file is located below the server instance's root directory: root-directory\server-name\server-name.log. For more information, refer to Changing the Name and Location of the Server Log File.

To view messages in a 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. For more information, refer to Viewing Server Logs.

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 WebLogic Server.

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. If you use the Node Manager to start a Managed Server, the Node Manager redirects a server's standard out and standard error to a file on the Node Manager's host computer. By default, a server instance prints only messages of a WARNING 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.

The following sections provide an overview of WebLogic Server log messages and log files:

Message Attributes

The messages for all WebLogic Server subsystems contain a consistent set of fields (attributes) as described in Table 70-1. In addition, if your application uses WebLogic logging services to generate messages, its messages will contain these attributes.


 

Table 70-1 Log Message Attributes

Attribute

Description

Timestamp

Time and date when the message originated, in a format that is specific to the locale. The Java Virtual Machine (JVM) that runs each WebLogic Server instance refers to the host computer's operating system for information about the local time zone and format.

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, Enterprise Java Bean (EJB) container or Java Messaging Service (JMS).

Server Name
Machine Name
Thread ID

Identify the origins of the message:

  • Server Name is the name of the WebLogic Server instance on which the message was generated.

  • Machine Name is the DNS name of the computer that hosts the server instance.

  • Thread ID is the ID that the JVM assigns to the thread in which the message originated.

Log messages that are generated within a client JVM client do not include these fields. For example, if your application runs in a client JVM and it uses the WebLogic logging services, the messages that it generates and sends to the WebLogic Server log files will not include these fields.

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.

Transaction ID

Present only for messages logged within the context of a transaction.

Message ID

A unique six-digit identifier.

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. For more information, refer to "Writing Messages to the WebLogic Server Log."

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.

Table 70-2 lists the severity levels of log messages from WebLogic Server subsystems, starting from the lowest level of impact to the highest.


 

Table 70-2 Message Severity

Severity

Meaning

INFO

Used for reporting normal operations.

WARNING

A suspicious operation or configuration has occurred but it might not affect normal operation.

ERROR

A user error has occurred. The system or application can 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.

Only WebLogic Server and its subsystems generate messages of this severity.

CRITICAL

A system or service error has occurred. The system can recover but there might be a momentary loss or permanent degradation of service.

Only WebLogic Server and its subsystems generate messages of this severity.

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.

Only WebLogic Server and its subsystems generate messages of this severity.

EMERGENCY

The server is in an unusable state. This severity indicates a severe system failure or panic.

Only WebLogic Server and its subsystems generate messages of this severity.


 

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."

Format of Message Output

When a WebLogic Server instance writes a message to the 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 a log file:

####<Nov 11, 2002 2:07:57 PM EST> <Notice> <WebLogicServer> <MyComputer>
<MedRecServer> <main> <kernel identity> <> <BEA-000360>
<Server started in RUNNING mode>

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 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.

WebLogic Server uses the host computer's default character encoding for the messages it writes.

Format of Output to Standard Out and Standard Error

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, and User ID fields.

The following is an example of how the message from the previous section would be printed to standard out:

<Nov 11, 2002 2:07:57 PM EST> <Notice> <WebLogicServer> <BEA-000360> 
<Server started in RUNNING mode>

In this example, the message attributes are: Timestamp, Severity, Subsystem, Message ID, and Message Text.

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 computer.

In addition to writing messages to its local 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 ERROR or higher. While you can modify the set of messages that are forwarded, servers can never forward messages of the DEBUG severity level or any stack traces that are included in a message.

The domain log file provides a central location from which to view the overall status of the domain.

For more information, refer to Specifying the Messages That a Server Forwards to the Domain Log.

How a Server Instance Forwards Messages to the Domain Log

To forward messages to the domain log, each server instance broadcasts its log messages as Java Management Extensions (JMX) notifications. A server broadcasts all messages and message text except for the following:

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 JMX listener with each Managed Server. By default, the listener includes a filter that allows only messages of severity level ERROR and higher to be forwarded to the Administration Server. (See Figure 70-3.)

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 70-3 WebLogic Server Logging Services

WebLogic Server Logging Services


 

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.

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.

 


Viewing Server Logs

The following tasks describe how to view server logs:

Viewing Server Logs from the Administration Console

You can use the Administration Console to view the log file for any server in the domain, regardless of whether the server is located on a remote computer for which you might not have login privileges. In addition, the Administration Console's log file viewer provides filtering tools that you can use to limit the set of messages that it displays. For example, you can use the filtering tools to view only the messages that the JDBC subsystem has generated.

To view a server's log messages from the Administration Console:

  1. Start the server if it is not already running.
  2. In the left pane of the Administration Console, expand the Servers folder and right-click the server whose log you want to view. (See Figure 70-4.)
  3. Figure 70-4 Right-click the Name of the Server

    Right-click the Name of the Server


     
  4. From the pop-up menu, select View Server Log.
  5. The right pane of the Administration Console displays the Search Log page. By default, the Search Log page displays up to 500 messages in reverse chronological order. The messages at the top of the window are the most recent messages that the server has generated.

    The log viewer does not display messages that have been rotated into archive log files. For more information, refer to Rotating Log Files.

  6. To view the probable cause and any action you can take to remedy an error that a message describes, in the Message ID column, click the message ID. (See Figure 70-5.)
  7. Figure 70-5 View Message Details

    View Message Details


     

    A pop-up window displays the probable cause and any actions to take.

  8. To change the default set of message attributes that the log viewer displays:
    1. Click Customize this view, which is located at the top of the Search Log page.
    2. To add message attributes to the log viewer display, on the customize page, next to Columns, move message attributes from the Available column to the Chosen column.
    3. To remove message attributes from the log viewer display, on the customize page, next to Columns, move message attributes from the Chosen column to the Available column.
    4. Click Apply.
  9. To filter the list of messages:
    1. Click Customize this view, which is located at the top of the Search Log page.
    2. On the customize page, select filtering criteria.
    3. By default, Subsystem, Users, Sub String and Since fields are undefined. If you leave them undefined, then the log viewer returns messages from all subsystems and security contexts since the earliest message in the file was generated.

      If you select Forward, the Administration Console reverses the order in which it displays messages. The oldest messages in the log file display at the top of the Search Log page.

    4. Click Apply.

    The Administration Console constructs a query that returns the log-message data you request. The query searches in the current log file only. If the log file has been rotated, the query does not search through old messages that have been moved to another file.

    None of the items on this page affects the messages that are actually stored in the log file; instead, they determine the log file data that the Administration Console displays.

    The Administration Console does not save your filter criteria. The next time you access the Search Log page, the Administration Console uses the default criteria to display messages.

Viewing Server Logs from a Text Editor

You can use a text editor to view messages in the current log file as well as older log files that the server creates per its log file rotation scheme. A text editor displays all attributes of all messages that are in the log file.

You cannot access the additional message details if you view messages from a text editor. Only the Administration Console log viewer provides access to the message details as described in step 4. in Viewing Server Logs from the Administration Console.

To view log messages from a text editor:

Note: Do not open the log file that the server is using to store current messages. Instead, create a copy of the log file and open the copy in the text editor.

You do this because, depending on your text editor and operating system, you could prevent the server from logging messages while the original file is open in the text editor. Any changes to the file's timestamp can confuse log file rotation.

  1. To determine the location of the server's log file:
    1. In the left pane of the Administration Server, expand the Servers folder and select the name of a server.
    2. In the right pane, select Logging —> Server and note the value in the Server File Name field.
    3. If the pathname is relative, it is relative to the server's root directory.

      For example, if you created a domain in the
      c:\user_projects\domains\MyDomain directory, and you used the c:\user_projects\domains\MyDomain\startWebLogicServer.cmd script to start the server, then, by default, the log file is located in c:\user_projects\domains\MyDomain\MyServer\MyServer.log.

      If the Server File Name field contains only a filename, the log file is located in the root-directory\server-name directory.

      For more information, refer to "A Server's Root Directory."

  2. Log on to the computer that hosts the server instance and change to the directory that contains the log file.
  3. Create a copy of the log file and open the copy in the text editor.

 


Viewing the Domain Log

The following tasks describe how to view the domain log:

Viewing Domain Logs from the Administration Console

You can use the Administration Console to view the domain log file without logging on to the Administration Server's host computer. In addition, the Administration Console's log file viewer provides filtering tools that you can use to limit the set of messages that it displays. For example, you can use the filtering tools to view only the messages that the JDBC subsystem has generated.

To view a domain's log messages from the Administration Console:

  1. In the left pane of the Administration Console, right-click on the name of the domain. (See Figure 70-6.)
  2. Figure 70-6 Right-click the Name of the Domain

    Right-click the Name of the Domain


     
  3. From the pop-up menu, select View Domain Log.
  4. The right pane of the Administration Console displays the Search Log page. By default, the Search Log page displays up to 500 messages in reverse chronological order. The messages at the top of the window are the most recent messages that servers have forwarded to the domain log.

    The log viewer does not display messages that have been rotated into archive log files. For more information, refer to Rotating Log Files.

  5. To view the probable cause and any action you can take to remedy an error that a message describes, in the Message ID column, click the message ID. (See Figure 70-7.)
  6. Figure 70-7 View Message Details

    View Message Details


     

    A pop-up window displays the probable cause and any actions to take.

  7. To change the default set of message attributes that the log viewer displays:
    1. Click Customize this view, which is located at the top of the Search Log page.
    2. To add message attributes to the log viewer display, on the customize page, next to Columns, move message attributes from the Available column to the Chosen column.
    3. To remove message attributes from the log viewer display, on the customize page, next to Columns, move message attributes from the Chosen column to the Available column.
    4. Click Apply.
  8. To filter the list of messages:
    1. Click Customize this view, which is located at the top of the Search Log page.
    2. On the customize page, select filtering criteria.
    3. By default, Subsystem, Server, Users, Sub String and Since fields are undefined. If you leave them undefined, then the log viewer returns messages from all subsystems, servers, and security contexts since the earliest message in the file was generated.

      If you select Forward, the Administration Console reverses the order in which it displays messages. The oldest messages in the log file display at the top of the Search Log page.

    4. Click Apply.

    The Administration Console constructs a query that returns the log-message data you request. The query searches in the current domain log file only. If the log file has been rotated, the query does not search through old messages that have been moved to another file.

    None of the items on this page affect the messages that are actually stored in the domain log file; instead, they determine the log file data that the Administration Console displays.

    The Administration Console does not save your filter criteria. The next time you access the Search Log page, the Administration Console uses the default criteria to displays messages.

Viewing Domain Logs from a Text Editor

You can use a text editor to view messages in the current domain log file as well as older log files that the Administration Server creates per its domain-log file rotation scheme. A text editor displays all attributes of all messages that are in the log file.

You cannot access the additional message details if you view messages from a text editor. Only the Administration Console log viewer provides access to the message details as described in Viewing Server Logs from the Administration Console.

To view domain-log messages from a text editor:

Note: Do not open the log file that the server is using to store current messages. Instead, create a copy of the log file and open the copy in the text editor.

You do this because, depending on your text editor and operating system, you could prevent the server from logging messages while the original file is open in the text editor. Any changes to the file's timestamp can confuse log file rotation.

  1. To determine the location of the domain's log file:
    1. In the left pane of the Administration Server, select the domain.
    2. In the right pane, select Configuration —> Logging.
    3. On the Logging subtab, note the value in the File Name field.
    4. If the pathname is relative, it is relative to the root directory of the Administration Server. This is the same directory that contains the domain's config.xml file.

      For example, if you created a domain in the c:\user_projects\domains\MyDomain directory, then, by default, the log file is located in c:\user_projects\domains\MyDomain\wl-domain.log.

  2. Log on to the computer that hosts the Administration Server and change to the directory that contains the domain log file.
  3. Create a copy of the log file and open the copy in the text editor.

 


Rotating Log Files

By default, when you start a WebLogic Server instance in development mode, the server automatically renames (rotates) its local server log file as server-name.log.n. For the remainder of the server session, log messages accumulate in server-name.log until the file grows to a size of 500 kilobytes.

Each time the local log file reaches this size, the server renames the log file and creates a new server-name.log to store new messages. By default, the rotated log files are numbered in order of creation filenamennnn, where filename is the name configured for the log file. You can configure a server instance to include a time and date stamp in the file name of rotated log files.

By default, when you start a server instance in production mode, the server rotates its local log file whenever the file grows to 5000 kilobytes in size. It does not rotate the local server log file when you start the server. For more information about changing the mode in which a server starts, refer to Changing the Runtime Mode.

You can change these default settings for log file rotation. For example, you can change the file size at which the server rotates the log file or you can configure a server to rotate log files based on a time interval. 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 delete the oldest log file and create a new log file with the latest suffix.

Note: WebLogic Server sets a threshold size limit of 500 MB before it forces a hard rotation to prevent excessive log file growth.

To set up log file rotation:

  1. To specify log file rotation for a server log, do the following from the Administration Console:
    1. In the left pane, expand the Server folder and select a server. (See Figure 70-8.)
    2. Figure 70-8 Click on the Name of a Server

      Click on the Name of a Server


       
    3. In the right pane, select Logging —> Server.

    To specify log file rotation for the domain log:

    1. In the left pane, select the Domain.
    2. In the right pane, select the Logging tab.
  2. To move old messages to another file when the current log file reaches a specific size:
    1. In Rotation Type, choose By Size.
    2. In Minimum File Size, enter the minimum file size that triggers the server to move log messages to a separate file. After the log file reaches the specified minimum size, the next time the server checks the file size, it renames the current log file. After the server renames a file, subsequent messages accumulate in a new file named FileName.
    3. If you want to limit the number of log files that the server creates to store old log messages, select Limit Number of Retained Log Files. Then in Log Files to Retain, enter the maximum number of files. If the server receives additional log messages after reaching the capacity of the last log file, it deletes the oldest log file and creates a new log file with the latest suffix.
    4. Click Apply.
  3. If you want to move old messages to another file at specific time intervals:
    1. In Rotation Type, choose By Time.
    2. In Rotation Time, enter the start time.
    3. Use the following format: hh:mm, where hh is the hour in a 24-hour format and mm is the minute.

      At the time that you specify, the server rotates the current log file. If the time that you specify is already past, the server starts its file rotation immediately. Thereafter, the server rotates the log file at an interval that you specify in File Time Span.

    4. In File Time Span, enter the interval at which the server saves old messages to another file.
    5. If you want to limit the number of log files that the server creates to store old log messages, select Limit Number of Retained Log Files. Then in Log Files to Retain, enter the maximum number of files. If the server receives additional log messages after reaching the capacity of the last log file, it deletes the oldest log file and creates a new log file with the latest suffix when the next interval expires.
    6. Click Apply.
  4. To include a time or date stamp in the file name when the log file is rotated, in the File Name field, add java.text.SimpleDateFormat variables to the file name. Surround each variable with percentage (%) characters.
  5. For example, if you enter the following value in the File Name field:
    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 filenamennnn, where filename is the name configured for the log file. For example: myserver.log0007.

Notification of Rotation

When the log file exceeds the rotation threshold that you specify, the server instance prints a log message that states that the log file will be rotated. Then it rotates the log file and prints an additional message that indicates the name of the file that contains the old messages.

For example, if you set up log files to rotate by size and you specify 500K as the minimum rotation size, when the server determines that the file is at least 500K in size, the server prints the following message:

<Dec 13, 2002 2:48:46 PM EST> <Info> <Log Management> <BEA-170017> <The log file .\MedRecServer\MedRecServer.log will be rotated. Please reopen the log file if tailing has stopped. This can happen on some platforms like Windows.>

The server immediately rotates the file and prints the following message:

<Dec 13, 2002 2:48:46 PM EST> <Info> <Log Management> <BEA-170018> <The log file has been rotated to MedRecServer.log0001. Log messages will continue to be logged in .\MedRecServer\MedRecServer.log.>

The message ID for the message before rotation is always BEA-170017 and the ID for the message after rotation is always BEA-170018.

File systems such as the standard Windows file system place a lock on files that are open for reading. On such file systems, if your application is tailing the log file, or if you are using a command such as the DOS tail -f command in a command prompt, the tail operation fails after the server has rotated the log file. The tail -f command prints messages to standard out as lines are added to a file. For more information, enter help tail in a DOS prompt.

To remedy this situation for an application that tails the log file, you can create a JMX listener that notifies your application when the server emits the log rotation message. When your application receives the message, it can restart its tailing operation. To see an example of a JMX listener, refer to "Subscribing to Messages" in the Using WebLogic Logging Services guide.

 


Specifying Which Messages a Server Sends 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. 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. If you use the Node Manager to start a Managed Server, the Node Manager redirects a server's standard out to a file on the Node Manager's host computer. For more information, refer to Viewing Standard Out for a Server Started by the Node Manager.

By default, all messages of WARNING severity or higher are printed to standard out and messages of the DEBUG severity are not printed to standard out.

To specify which messages a server sends to standard out:

  1. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 70-8.)
  2. In the right pane, select Logging —> Server.
  3. Click the Log to Stdout checkbox to place a checkmark there.
  4. If you want to send any messages of DEBUG severity to standard out, click the Debug to Stdout to place a checkmark there.
  5. WebLogic Server does not generate DEBUG messages, but you can configure an application that you write to do so. For more information, refer to Writing Debug Messages in the Using WebLogic Logging Services Guide.

  6. In Stdout severity threshold, choose the minimum severity level of the messages that you want to send to standard out. For information about message severity, refer to Message Severity.
  7. Click Apply to save the settings.

Printing Messages to Standard Error

A WebLogic Server instance can also print messages to standard error, which, by default, is the command prompt in which the server is running. The server prints to standard error under the following circumstances:

For information about redirecting standard error messages to a file, refer to Redirecting System.out and System.err to a File.

 


Viewing Standard Out for a Server Started by the Node Manager

If you use the Node Manager to start a Managed Server, the Node Manager redirects to a file on the Node Manager's host computer all messages that the server instance and its JVM would normally print to the shell (including verbosegc output). You can use the Administration Console to view the contents of the file. For more information, refer to "Managed Server Log Files."

To view standard out messages for a server that was started by the Node Manager:

  1. If it is not already running, start the Node Manager on the computer that hosts the Managed Server instance.
  2. In the left pane of the Administration Console, expand the Servers folder and select the server. (See Figure 70-8.)
  3. In the right pane, select Control —> Remote Start Output.
  4. On the Remote Start Output tab, click the View Server output link.

The right pane of the Administration Console displays standard out messages from the most recent (or current) server session.

 


Configuration Auditing

You can configure a domain to generate log messages and Audit Events 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 domain writes a message to the Administration Server's local log file. If you have enabled the WebLogic Auditing provider, it writes the Audit Events to an additional security log. These messages and Audit Events provide an audit trail of changes within a domain's configuration (configuration auditing).

The following sections describe configuration auditing:

Enabling Configuration Auditing

To enable a domain to emit configuration-auditing messages and Audit Events:

  1. In the left pane of the Administration Console, click the name of the domain.
  2. In the right pane, on the Configuration tab, click the General tab.
  3. On the General tab, under Configuration Auditing, select one of the following:
    • If you want the domain to generate only log messages in the Administration Server's local log file, select log
    • If you want the domain to generate only Audit Events, which can be handled by Audit providers, select audit
    • You must enable at least one Audit provider to handle these events. See Audit Events and Auditing Providers.

    • If you want the domain to generate log messages and Audit Events, select logaudit
  4. Click Apply.

You can also do the following to enable configuration auditing:

Configuration Auditing Log Messages

If you enable the domain to generate configuration auditing log messages, the domain writes the messages to the Administration Server's local log file. All configuration auditing messages are of the Info severity and are identified by message IDs that fall within the range of 159900-159910. Because all the 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 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.

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 "WebLogic Server Management Namespace."

Table 70-1 summarizes the messages.

Table 70-1 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 70-2 lists additional message attributes for configuration auditing messages. All configuration auditing messages specify the same values for these attributes.

Table 70-2 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.

Audit Events and Auditing Providers

An Audit Event is an object that Auditing providers can read and process in specific ways. An Auditing provider is a pluggable component that the security realm uses to collect, store, and distribute information about operating requests and the outcome of those requests for the purposes of non-repudiation.

If you enable a domain to emit Audit Events, the domain emits the events described in Table 70-1. All Auditing providers that are configured for the domain can handle these events.

All of the events are of severity level SUCCESS and describe the security principal who initiated the action, whether permission was granted, and the object (MBean or MBean attribute) of the requested action.

Table 70-3 Summary of Audit Events for Configuration Auditing 

When This Event Occurs...

WebLogic Server Generates This Audit Event Object...

A request to create a new configuration artifact has been allowed or prevented.

weblogic.security.spi.AuditCreateConfigurationEvent

See Javadoc.

A request to delete an existing configuration artifact has been allowed or prevented.

weblogic.security.spi.AuditDeleteConfigurationEvent

See Javadoc.

A request to modify an existing configuration artifact has been allowed or prevented.

weblogic.security.spi.AuditInvokeConfigurationEvent

See Javadoc.

A invoke an operation on an existing configuration artifact has been allowed or prevented.

weblogic.security.spi.AuditSetAttributeConfigurationEvent

See Javadoc.

If you enable the default WebLogic Server Auditing provider, it writes all Audit Events as log messages in its own log file. (See Configuring a WebLogic Auditing Provider in Managing WebLogic Security.)

Other Auditing providers that you create or purchase can filter these events and write them to output repositories such as an LDAP server, database, or a simple file. In addition, other types of security providers can request audit services from an Auditing provider. See Auditing Providers in Developing Security Providers for WebLogic Server.

 


Other Logging Tasks

The following sections describe other tasks related to WebLogic Server log messages:

For more logging tasks, refer to Specifying the Messages That a Server Forwards to the Domain Log.

Viewing Standard Out for a Server Set Up as a Windows Service

By default, if you set up a server to run as a Windows service, you cannot view the server's standard out. For information on redirecting the server and JVM's standard out to a file, refer to "Redirecting JVM Messages to a File."

Viewing Localized Time Stamps on Windows

On a Windows computer, you can use the Regional Options Control Panel to enable support for localized currencies, times, and dates. Most SDKs detect the setting on the Regional Options Control Panel and modify their standard out and standard error output to print time and date stamps in a format that matches your locale.

If you have selected a locale and language other than English, modify the settings for your Windows command prompt so that messages that WebLogic Server prints to standard out contain properly-formatted time and date stamps:

Note: You do not need to follow this procedure for server instances that a Node Manager starts. Node Manager redirects its standard out to a file, which you can view from the Administration Console. See Viewing Standard Out for a Server Started by the Node Manager.

  1. In your WebLogic Server startup script, add the following command before the command that invokes the weblogic.Server class:
  2. chcp 1252

    This command causes the command prompt to encode all output in the ANSI character set.

    For example:

    chcp 1252

    "%JAVA_HOME%\bin\java" %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS%
    -Dweblogic.Name=%SERVER_NAME%
    -Dweblogic.management.username=%WLS_USER%
    -Dweblogic.management.password=%WLS_PW%
    -Dweblogic.ProductionModeEnabled=%PRODUCTION_MODE%
    -Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy"
    weblogic.Server

    ENDLOCAL

  3. Open a Windows command prompt and do the following:
    1. To display the properties sheet, right-click in the title bar and select Properties.
    2. In the Properties window, select the Font tab.
    3. In the Font list, select a TrueType font.
    4. Click OK.
    5. In the Apply Properties window, select Save properties for future windows with same title. Then click OK.
  4. Invoke the WebLogic Server start script.

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.

If you want to keep a record of these messages, edit the WebLogic Server script so that the JAVA_OPTIONS variable specifies the following:

-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 Boot Identity Files.

Redirecting 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 prints 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.

Disabling a Server from Forwarding Messages to the Domain Log

By default, a server instance forwards log messages of an ERROR or higher severity to domain log.

To prevent a server from sending messages to the domain log:

  1. In the left pane of the Administration Console, expand the Servers folder and select the server. (See Figure 70-8.)
  2. In the right pane, click Logging —> Domain.
  3. Click on the Log to Domain Logfile checkbox to remove the checkmark.
  4. Click Apply.

Changing the Name and Location of the Server Log File

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.

To change the default name or location of a server's local log file:

  1. In the left pane of the Administration Console, expand the Servers folder and select the server. (See Figure 70-8.)
  2. In the right pane, select—>Logging —>Server.
  3. In the File Name box, enter a path and filename for the server log.
  4. Enter an absolute pathname or a pathname that is relative to the server's root directory. If you use the Node Manager to start a Managed Server, the root directory is located on the computer that hosts the Node Manager process. For more information, refer to "A Server's Root Directory."

    For information about including a time stamp in the server log's file name, refer to Rotating Log Files.

  5. Click Apply to apply your changes.
  6. Restart the server.
  7. The server writes all subsequent domain messages to the new file.

Changing the Name and Location of the Domain Log File

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

To change the default name or location of the domain's log file:

  1. In the left pane of the Administration Console, select the domain. (See Figure 70-9.)
  2. Figure 70-9 Click on the Name of the Domain

    Click on the Name of the Domain


     
  3. In the right pane, select Configuration —> Logging.
  4. In the File Name box, enter a path and filename for the domain log.
  5. Enter an absolute pathname or a pathname that is relative to the root directory of the Administration Server. For more information, refer to "A Server's Root Directory."

    For information about including a time and date stamp in the name of rotated domain log files, refer to Rotating Log Files.

  6. Click Apply to apply your changes.
  7. Restart the Administration Server. The Administration Server writes all subsequent domain messages to the new file.

Enabling JDBC Logging

To enable JDBC logging:

  1. In the left pane of the Administration Console, expand the Servers folder and select the server. (See Figure 70-8.)
  2. In the right pane, select Logging —> JDBC.
  3. On the JDBC tab, select Enable JDBC Logging.
  4. Click Apply.
  5. Restart the server.

Enabling and Configuring an HTTP Log

To keep a log of all HTTP requests on a given server instance:

  1. In the left pane of the Administration Console, expand the Servers folder and select the server. (See Figure 70-8.)
  2. In the right pane, select Logging —> HTTP.
  3. On the HTTP tab, click Enable HTTP Logging.
  4. In the Format list, determine the format of the HTTP log file by selecting Common or Extended.
  5. To determine the frequency with which the server empties its HTTP-request buffer and writes the data to the HTTP log file:
    1. In Log Buffer Size, specify the maximum size (in kilobytes) of the HTTP-request buffer.
    2. In the Flush Every box, specify the interval (in seconds) at which the server checks the size of the HTTP-request buffer. If the buffer has reached the maximum size, the server writes the data to the HTTP log file.
  6. By default, the server moves old HTTP requests to another file when the current HTTP log file grows beyond 5000 kilobytes. Also by default, the server can create an unlimited number of these archive log files.
  7. To change these defaults:

    1. In Maximum Log File Size, enter the file size that triggers the server to move HTTP requests to a separate file. After the HTTP log file reaches the specified size, the next time the server checks the file size, it will rename the current log file. After the server renames a file, subsequent messages accumulate in a new file named access.log.
    2. To limit the number of HTTP log files that the server creates to store old HTTP requests, select Limit Number of Retained Log Files. Then in Log Files to Retain, enter the maximum number of files. If the server receives additional HTTP requests after reaching the capacity of the last log file, it overwrites the oldest log file.
  8. To create another file at specific time intervals instead of when the log file reaches a specific size:
    1. In Rotation Type, choose date.
    2. In Rotation Period, enter the interval at which the server saves old HTTP requests to another file.
    3. In Rotation Time, enter the start time.
    4. Use the following java.text.SimpleDateFormat format to specify a date and time: MM-dd-yyyy-k:mm:ss. For information about this format, refer to the J2EE Javadoc.

      At the time that you specify, the server rotates the current log file. If the time that you specify is already past, the server calculates the initial rotation time based on the rotation start time and the rotation period, as shown in the following example.

      In config.xml:

	<WebServer LogRotationPeriodMins="10"
            LogRotationTimeBegin="08-03-2004-15:30:00"
            LogRotationType="date" Name="myserver"/>

If you start WebLogic Server at 08-03-2004-15:45:00, the server calculates the initial rotation time as 15:30 + (10 * 2) minutes, and starts the HTTP log file rotation at 15:50.

Thereafter, the server rotates the HTTP log file at an interval that you specify in Rotation Period.

  1. To limit the number of log files that the server creates to store old HTTP requests, select Limit Number of Retained Log Files. In Log Files to Retain, enter the maximum number of files. If the server receives additional HTTP requests after reaching the capacity of the last log file, it overwrites the oldest log file.
  1. To include a time or date stamp in the file name when the log file is rotated, in the File Name field, add java.text.SimpleDateFormat variables to the file name. Surround each variable with percentage (%) characters.
  2. For example, if you enter the following value in the File Name field:
    access_%yyyy%_%MM%_%dd%_%hh%_%mm%.log

    the virtual host's HTTP log file will be named:
    access_yyyy_MM_dd_hh_mm.log

    When the server instance rotates the HTTP log file, the rotated file name contains the date stamp. For example, if the server instance rotates the log file on 2 April, 2003 at 10:05 AM, the log file that contains the old log messages will be named:
    access_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 filenamennnn, where filename is the name configured for the log file. For example: access.log0007.

  3. Click Apply.
  4. Restart the server.

 

Skip navigation bar  Back to Top Previous Next