1. Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server
  2. Configuring WebLogic Logging Services

2 Configuring WebLogic Logging Services

You can configure the logging output to receive log messages for specific events in Oracle WebLogic Server. Use WebLogic Remote Console, WLST commands or the Java Logging APIs to configure the logging output.

For detailed instructions on filtering and subscribing to messages, see Filtering WebLogic Server Log Messages and Subscribing to Messages.

This chapter describes WebLogic Server logging scenarios and basic configuration tasks:

  • Configuration Scenarios
    WebLogic Server system administrators and developers configure logging output and filter log messages to troubleshoot errors or to receive notification for specific events.
  • Overview of Logging Services Configuration
    In the logging process, a logging request is dispatched to subscribed handlers or appenders. Volume control of logging is provided through the LogMBean interface.
  • Logging Configuration Tasks: Main Steps
    You can configure and filter log messages that the WebLogic Server generates. You can use the WebLogic Remote Console, WebLogic Scripting Tool, or the Java APIs.
  • How to Use the Commons API with WebLogic Logging Services
    WebLogic logging services provide the Commons LogFactory and Log interface implementations that direct requests to the underlying logging implementation being used by WebLogic logging services.
  • Rotating Log Files
    The log messages are accumulated in predefined numbered log files. Whenever the file grows in size from the set size, depending on whether it is in development or production mode, the server rotates its server log file.
  • Redirecting JVM Output
    The JVM in which a WebLogic Server instance runs sends messages to standard error and standard out. Server as well as application code write directly to these streams instead of using the logging mechanism. However, you can use a configuration option to redirect the JVM output to all registered log destinations, such as the server terminal console and the server log file. 
  • Redirecting Standard Error and Standard Output
    The weblogic.RotatingFileRedirector is a standalone utility tool for redirecting standard error and standard output streams to a rotating log file.
  • Preventing Excessive Logging
    Depending on the situation, log messages may become generated at a very high frequency, and often with the same message. This can flood the system with log messages and put excessive load on the system.

Configuration Scenarios

WebLogic Server system administrators and developers configure logging output and filter log messages to troubleshoot errors or to receive notification for specific events.The following tasks describe some logging configuration scenarios:

  • Stop Debug and Info messages from going to the log file.

  • Allow Info level messages from the HTTP subsystem to be published to the log file, but not to standard out.

  • Specify that a handler publishes messages that are Warning severity level or higher.

  • Track log information for individual servers in a cluster.

Parent topic: Configuring WebLogic Logging Services

Overview of Logging Services Configuration

In the logging process, a logging request is dispatched to subscribed handlers or appenders. Volume control of logging is provided through the LogMBean interface.

WebLogic Server provides handlers for sending log messages to standard out, the server log file, broadcasting messages to the domain log, remote clients, and a memory buffer for tail viewing log events. You can achieve volume control for each type of handler by filtering log messages based on severity level and other criteria. The LogMBean, described in MBean Reference for Oracle WebLogic Server, defines attributes for setting the severity level and specifying filter criteria for WebLogic Server handlers.

In earlier versions of WebLogic Server, system administrators and developers had only programmatic access to loggers and handlers. In this release of WebLogic Server, you can configure handlers using MBeans, eliminating the need to write code for most basic logging configurations. The WebLogic Server Scripting Tool (WLST) provide an interface for interacting with logging MBeans. Additionally, you can specify LogMBean parameters on the command line using Dweblogic.log.attribute-name=value; for example, Dweblogic.log.StdoutSeverity=Debug. See Message Output and Logging in Command Reference for Oracle WebLogic Server.

For advanced usage scenarios and for configuring loggers, you use the Java Logging APIs.

Setting the severity level on a handler is the simplest type of volume control; for example, any message of a lower severity than the specified threshold severity level, will be rejected. For example, by default, the Stdout Handler has a Notice threshold severity level. Therefore, Info and Debug level messages are not sent to standard out.

Configuring a filter on a handler lets you specify criteria for accepting log messages for publishing; for example, only messages from the HTTP and JDBC subsystems are sent to standard out.

Note:

The java.util.logging.LoggingPermission class, described at http://docs.oracle.com/javase/8/docs/api/java/util/logging/LoggingPermission.html, is required for a user to change the configuration of a logger or handler. In production environments, we recommend using the Java Security Manager with java.util.logging.LoggingPermission enabled for the current user.

See Using the Java Security Manager to Protect WebLogic Resources in Developing Applications with the WebLogic Security Service, and the Java Logging Overview at http://docs.oracle.com/javase/8/docs/technotes/guides/logging/overview.html.

Note:

By default, the query string parameters may show up in the HTTP log files. This allow attackers, access to sensitive data such as passwords, personal information, database details, and so on. To overcome this vulnerability, we have removed the query string as part of the default access log entries.

To restore the query strings to default HTTP access log entires or previous behavior, set this system property weblogic.servlet.access.log.default.format.with.query to TRUE.

Parent topic: Configuring WebLogic Logging Services

Using Log Severity Levels

Each log message has an associated severity level. The level gives a rough guide to the importance and urgency of a log message. WebLogic Server has predefined severities, ranging from Trace to Emergency, which are converted to a log level when dispatching a log request to the logger. A log level object can specify any of the following values, from lowest to highest impact:

Trace, Debug, Info, Notice, Warning, Error, Critical, Alert, Emergency

You can set a log severity level on the logger and the handler. When set on the logger, none of the handlers receive an event which is rejected by the logger. For example, if you set the log level to Notice on the logger, none of the handlers will receive Info level events. When you set a log level on the handler, the restriction only applies to that handler and not the others. For example, turning Debug off for the File Handler means no Debug messages will be written to the log file, however, Debug messages will be written to standard out.

For the description of supported severity levels, see weblogic.logging.Severities in Java API Reference for Oracle WebLogic Server.

You set log levels for handlers and loggers using the WebLogic Remote Console, WLST, or the command line. See Specifying Severity Level for Loggers. Loggers and handlers can also be configured through the API. See Setting the Severity Level for Loggers and Handlers.

Parent topic: Overview of Logging Services Configuration

Using Log Filters

To provide more control over the messages that a Logger object publishes, you can create and set a filter. A filter is a class that uses custom logic to evaluate the log record content which you use to accept or reject a log message; for example, to filter out messages of a certain severity level, from a particular subsystem, or according to specified criteria. The Logger object publishes only the log messages that satisfy the filter criteria. You can create separate filters for the messages that each server instance writes to its server log file, standard out, memory buffer, or broadcasts to the domain-wide message log.

You can associate a filter with loggers and handlers. You configure filters for handlers using the WebLogic Remote Console, WLST, or the command line. There are LogFilterMBean attributes to define filters for Stdout, Log File, Log Broadcaster, and Memory Handlers, or you can implement custom filtering logic programmatically. The LogFilterMBean, described in the MBean Reference for Oracle WebLogic Server, defines the filtering criteria based on user ID and subsystem. Filters for loggers are configured only through the API.

See Setting a Filter for Loggers and Handlers.

Parent topic: Overview of Logging Services Configuration

Logging Configuration Tasks: Main Steps

You can configure and filter log messages that the WebLogic Server generates. You can use the WebLogic Remote Console, WebLogic Scripting Tool, or the Java APIs.

The following steps summarize how you can configure and filter the log messages. Related documentation and later sections in this guide describe these steps in more detail.

  1. Use WebLogic Remote Console to configure WebLogic Logging services. See Log Messages in Oracle WebLogic Remote Console Online Help.

  2. Alternatively, configure log message filtering on the message handler using the WebLogic Scripting Tool. See Configuring Existing Domains in Understanding the WebLogic Scripting Tool.

  3. Filter log messages published by the logger using the Java APIs. See Filtering Messages by Severity Level or Other Criteria.

Parent topic: Configuring WebLogic Logging Services

How to Use the Commons API with WebLogic Logging Services

WebLogic logging services provide the Commons LogFactory and Log interface implementations that direct requests to the underlying logging implementation being used by WebLogic logging services.

To use Commons Logging, put the WebLogic-specific Commons classes, $WL_HOME/modules/com.bea.core.weblogic.commons.logging_1.3.0.0.jar, together with the commons-logging.jar file in one of the following locations:

  • APP-INF/LIB or WEB-INF/LIB directory

  • DOMAIN_NAME/LIB directory

  • server CLASSPATH

    Note:

    WebLogic Server does not provide a Commons logging version in its distribution.

Example 2-1 illustrates how to use the Commons interface by setting the appropriate system property.

Note:

When you use the org.apache.commons.logging.LogFactory system property to implement the Commons interface as described here, you are implementing it for all application instances running on the server. For information on how to implement Commons logging for specific application instances, without affecting other applications, use the JDK service discovery mechanism or commons-logging.properties mechanism to specify the LogFactory as described at http://commons.apache.org/logging/apidocs/org/apache/commons/logging/LogFactory.html#getFactory().

  1. Set the system property org.apache.commons.logging.LogFactory to weblogic.logging.commons.LogFactoryImpl.

    This LogFactory creates instances of weblogic.logging.commons.LogFactoryImpl that implement the org.apache.commons.logging.Log interface.

  2. From the LogFactory, get a reference to the Commons Log object by name.

    This name appears as the subsystem name in the log file.

  3. Use the Log object to issue log requests to WebLogic logging services.

    The Commons Log interface methods accept an object. In most cases, this will be a string containing the message text.

    The Commons LogObject takes a message ID, subsystem name, and a string message argument in its constructor. See org.apache.commons.logging at http://commons.apache.org/logging/apidocs/index.html.

  4. The weblogic.logging.commons.LogImpl log methods direct the message to the server log.

Example 2-1 Commons Code Example

import org.apache.commons.logging.LogFactory;
import org.apache.commons.logging.Log;

public class MyCommonsTest {
  public void testWLSCommonsLogging() {
    System.setProperty(LogFactory.FACTORY_PROPERTY,
      "weblogic.logging.commons.LogFactoryImpl");
    Log clog = LogFactory.getFactory().getInstance("MyCommonsLogger");
    // Log String objects
    clog.debug("Hey this is common debug");
    clog.fatal("Hey this is common fatal", new Exception());
    clog.error("Hey this is common error", new Exception());
    clog.trace("Dont leave your footprints on the sands of time");
  }
}

Parent topic: Configuring WebLogic Logging Services

Specifying Severity Level for Loggers

WebLogic Server provides a hierarchical Logger tree that lets you specify the Severity level for:

  • Generated Message Catalog Logger classes from the XML I18N catalog using weblogic.i18ngen.

  • Instances of the Commons Logging APIs when the WebLogic Server implementation of the Commons org.apache.commons.logging.LogFactory interface is enabled.

All Loggers inherit their Severity level from the nearest parent in the tree. You can, however, explicitly set the Severity level of a Logger, thereby overriding the level that is set for the nearest parent. You can set the Severity level for loggers from the WebLogic Remote Console, WLST, or the command line.

Parent topic: How to Use the Commons API with WebLogic Logging Services

Specifying Severity Level for WebLogic Server Subsystem Loggers

If you are using the Message Catalog Loggers, the Severity level for messages coming from a specific subsystem are determined by the Severity level of the root Logger. You can override the root Logger Severity level for individual subsystem Loggers such as the DeploymentService Logger, Security Logger, or EJB Logger. For example, suppose the root Logger severity level is Critical, and you want to set the Severity Level to Notice for the Security subsystem logger and to Warning for the EJB subsystem logger. You can do this from the WLST or from the command line:

  • Via WLST, use the set command to set the value of the LoggerSeverityProperties attribute of the LogMBean. See Configuring Logging in Understanding the WebLogic Scripting Tool.

  • From the command line, specify the following parameter in the startup command:

    -Dweblogic.Log.LoggerSeverityProperties="Security=Notice;EJB=Warning"

    For a complete index of all subsystem names, see Error Messages. The subsystem name is case-sensitive and must be entered exactly as shown in the Subsystem column of the index.

Specifying the Severity Level for Commons Logging API Loggers

If you are using the Commons Logging API, logger names follow the Java package dot notation naming convention. For example, logger names could be a.b.FooLogger or a.b.c.Barlogger, corresponding to the name of the classes in which they are used. In this case, each dot-separated identifier appears as a node in the Logger tree. For example, there will be a child node named "a" under the root Logger, a child node named "b" whose parent is "a", and so on.

You can configure the Severity for a package or for any Logger at any level in the tree. For example, if you specify the Severity level for package a.b=Info, then Debug and Trace messages coming from all child nodes of package a.b will be blocked. You can, however, override the Severity level of a parent node by explicitly setting a value for a child node. For example, if you specify the Severity level for logger a.b.FooLogger=Debug, all log messages from FooLogger will be allowed, while Debug and Trace messages will still be filtered for other child nodes under a.b.

You can specify the severity level for a package or Logger from the WLST or the command line:

  • Via WLST, use the set command to set the value of the LoggerSeverityProperties attribute of the LogMBean. See Configuring Logging in Understanding the WebLogic Scripting Tool.

  • From the command line, specify the following parameter in the startup command:

    -Dweblogic.Log.LoggerSeverityProperties="a.b=Info;a.b.FooLogger=Debug"

Rotating Log Files

The log messages are accumulated in predefined numbered log files. Whenever the file grows in size from the set size, depending on whether it is in development or production mode, the server rotates its server log file.

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 server 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 filenamennnnn, 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; for example, server-name-%yyyy%-%mm%-%dd%-%hh%-%mm%.log.

By default, when you start a server instance in production mode, the server rotates its server 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.

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.

For information about setting up log file rotation, see Rotate Log Files in Oracle WebLogic Remote Console Online Help.

To cause the immediate rotation of the server, domain, or HTTP access log file, use the LogRuntime.forceLogRotation() method. See LogRuntimeMBean in MBean Reference for Oracle WebLogic Server.

Note:

Though the LogMBean property defines 2 GB as the legal maximum limit for the FileMinsize attribute, WebLogic Server sets a threshold size limit of 500 MB before it forces a hard rotation to prevent excessive log file growth.

The WLST commands in Example 2-2 cause the immediate rotation of the server log file.

Example 2-2 Log Rotation on Demand

#invoke WLST
C:\>java weblogic.WLST
#connect WLST to an Administration Server
wls:/offline> connect('username','password')
#navigate to the ServerRuntime MBean hierarchy
wls:/mydomain/serverConfig> serverRuntime()
wls:/mydomain/serverRuntime>ls()
#navigate to the server LogRuntimeMBean
wls:/mydomain/serverRuntime> cd('LogRuntime/myserver')
wls:/mydomain/serverRuntime/LogRuntime/myserver> ls()
-r--   Name                                         myserver
-r--   Type                                         LogRuntime
-r-x   forceLogRotation                             java.lang.Void :
#force the immediate rotation of the server log file
wls:/mydomain/serverRuntime/LogRuntime/myserver> cmo.forceLogRotation()
wls:/mydomain/serverRuntime/LogRuntime/myserver>

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

<Mar 2, 2005 3:23:01 PM EST> <Info> <Log Management> <BEA-170017> <The log file
C:\diablodomain\servers\myserver\logs\myserver.log will be rotated. Reopen the
log file if tailing has stopped. This can happen on some platforms like Windows.>
<Mar 2, 2005 3:23:01 PM EST> <Info> <Log Management> <BEA-170018> <The log file
has been rotated to C:\diablodomain\servers\myserver\logs\myserver.log00001. Log
messages will continue to be logged in C:\diablodomain\servers\myserver\logs\myserver.log.>

Parent topic: Configuring WebLogic Logging Services

Specifying the Location of Archived Log Files

By default, the rotated files are stored in the same directory where the log file is stored. You can specify a different directory location for the archived log files by setting the LogFileRotationDir property of the LogFileMBean from the command line. See LogFileMBean in the MBean Reference for Oracle WebLogic Server.

The following command specifies the directory location for the archived log files using the -Dweblogic.log.LogFileRotationDir Java startup option: 

java -Dweblogic.log.LogFileRotationDir=c:\foo
-Dweblogic.management.username=installadministrator
-Dweblogic.management.password=installadministrator weblogic.Server

Parent topic: Rotating Log Files

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 greater than 500K in size, the server prints the following message:

<Sept 20, 2004 1:51:09 PM EST> <Info> <Log Management> <MachineName>
<MedRecServer> <ExecuteThread: '2' for queue: 'weblogic.kernel.System'> <<WLS
Kernel>> <> <> <1095692939895> <BEA-170017> <The log file
C:\Oracle\Middleware\wlserver_12.1\samples\domains\medrec\servers\MedRecServer\logs\medrec.log will be rotated.
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:

<Sept 20, 2004 1:51:09 PM EST> <Info> <Log Management> <MachineName>
<MedRecServer> <ExecuteThread: '2' for queue: 'weblogic.kernel.System'> 
<<WLS Kernel>> <> <> <1095692939895> <BEA-170018> <The log file has been rotated
to C:\Oracle\Middleware\wlserver_12.1\samples\domains\medrec\servers\MedRecServer\logs\medrec.log00001. 
Log messages will continue to be logged in C:\Oracle\Middleware\wlserver_12.1\samples\domains\medrec\servers\MedRecServer\logs\medrec.log.>

Note that the severity level for both messages is Info. 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 stops 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, see Subscribing to Messages.

Parent topic: Rotating Log Files

Redirecting JVM Output

The JVM in which a WebLogic Server instance runs sends messages to standard error and standard out. Server as well as application code write directly to these streams instead of using the logging mechanism. However, you can use a configuration option to redirect the JVM output to all registered log destinations, such as the server terminal console and the server log file. 

When this redirect is enabled, a log entry appears as a message of Notice severity. Note that redirecting the JVM output does not capture output from native code; for example, thread dumps from the JVM are not captured.

Note:

Redirecting JVM standard out and standard error messages to the WebLogic logging service by enabling the LogMBean attributes, as described in this section, has two key disadvantages you should be aware of:

  • JVM messages are redirected asynchronously. In the event of an overload situation, these messages may be dropped.

  • Redirecting JVM messages to the WebLogic logging service in high volume can have a significantly negative impact on system performance and is therefore not recommended.

As a best practice for storing JVM standard out and standard error messages in a log file, Oracle recommends using one of the supported logging APIs instead. Using a logging API ensures that even during times of peak system load, messages are not lost, including the times when those messages are generated in high volume.

Parent topic: Configuring WebLogic Logging Services

Configuring WebLogic Server to Redirect the JVM Output

To configure WebLogic Server to redirect JVM standard out or standard error messages to the WebLogic logging service, you can do one of the following:

  • In the weblogic.Server command that starts WebLogic Server, include either or both of the following options, as desired:

    • -Dweblogic.log.RedirectStdoutToServerLogEnabled=true

      This option redirects JVM standard out messages to the WebLogic logging service.

    • -Dweblogic.log.RedirectStderrToServerLogEnabled=true

      This option redirects JVM standard error messages to the WebLogic logging service.

    See weblogic.Server Configuration Options in Command Reference for Oracle WebLogic Server.

  • After the Administration Server has started, you can use the WebLogic Remote Console to redirect the JVM standard out or standard error messages. See Filter Log Messages in Oracle WebLogic Remote Console Online Help.

  • Use WLST to set either or both of the following attribute values of the LogMBean and restart the server:

    • RedirectStdoutToServerLogEnabled=true—Redirects the JVM standard out messages to the WebLogic logging service.

    • RedirectStderrToServerLogEnabled=true—Redirects the JVM standard error messages to the WebLogic logging service.

    The WLST commands in the following example redirect the JVM standard out messages in the Administration Server to the server logging destinations.

    C:\>java weblogic.WLST
wls:/offline> connect('username','password')
wls:/mydomain/serverConfig> edit()
wls:/mydomain/edit> startEdit()
wls:/mydomain/edit !> cd("Servers/myserver/Log/myserver")
wls:/mydomain/edit/Servers/myserver/Log/myserver !> cmo.setRedirectStdoutToServerLogEnabled(true)
wls:/mydomain/edit/Servers/myserver/Log/myserver !> save()
wls:/mydomain/edit/Servers/myserver/Log/myserver !> activate()

    See Navigating MBeans (WLST Online) inUnderstanding the WebLogic Scripting Tool. For more information about the RedirectStdoutToServerLogEnabled and RedirectStderrToServerLogEnabled attributes, see LogMBean in the MBean Reference for Oracle WebLogic Server.

Parent topic: Redirecting JVM Output

Redirecting Standard Error and Standard Output

The weblogic.RotatingFileRedirector is a standalone utility tool for redirecting standard error and standard output streams to a rotating log file.Use the following command to run the utility:

java weblogic.RotatingFileRedirector [options]

The options include:

  • -help: Prints help about supported options and flags

  • -verbose: Prints additional output during execution

  • -config Config Properties File: (Optional) Properties file which specifies the log rotation file parameters as key-value pairs. If not specified, the rotation parameters are defaulted.

  • -configOverride: Override of a key-value config property pair. This is useful if the same config.properties is shared for multiple servers and only the baseLogFileName needs to be different for each server. Multiple overrides can be specified, for example

    -configOverride baseLogFileName=${SERVER_NAME}.out -configOverride rotatedFileCount=10

The following table lists the properties that can be configured and the default values.

Table 2-1 Properties and Default Values

Property Name Default Value Comments

baseLogFileName

OR

baseLogFilePath

redirect.log

baseLogFilePath is valid for WebLogic Server versions 12.2.1 and later. Use baseLogFileName for earlier versions.

Specifies the log file to which stdin will be redirected.

logFileRotationDir

null

When not specified rotated log files are created in the same directory as the base log file.

numberOfFilesLimited

false

Specifies whether to limit the number of old rotated files on disk.

bufferSizeKB

8

Buffer size of the output stream in KB before the contents are flushed to the disk.

rotateLogOnStartupEnabled

true

Rotate the log file from previous run if it exists on start up.

rotatedFileCount

7

Used in conjunction with numberOfFilesLimited. Specifies the number of old rotated logs to keep.

rotationSize

500

Size limit when rotation occurs, specified in KB.

rotationTime

00:00

Specifies the start time for the rotation when using time based rotation.

rotationTimeSpan

24

The interval in hours to rotate the log files. Defaults to 24 hours.

rotationType

bySize

Valid values are either bySize or byTime.

Example 2-3 Using the Utility

An example of config.properties file contents: 

rotationSize=100 
baseLogFilePath=foo.log

The utility is executed as follows:

{JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} -Dweblogic.Name=${SERVER_NAME} weblogic.Server 2>$DOMAIN_HOME/logs/mps/${SERVER_NAME}_stderr.log | ${JAVA_HOME}/bin/java -Xms128m -Xmx256m -cp $WL_HOME/server/lib/weblogic.jar weblogic.RotatingFileRedirector -configOverride baseLogFilePath=$DOMAIN_HOME/logs/mps/${SERVER_NAME}_stdout.log -config $DOMAIN_HOME/bt_stdout.prop &

Parent topic: Configuring WebLogic Logging Services

Preventing Excessive Logging

Depending on the situation, log messages may become generated at a very high frequency, and often with the same message. This can flood the system with log messages and put excessive load on the system. Excessive logging can occasionally occur due to a number of reasons. For example, a network outage can cause several components to log messages on repeated connection retries, or an incorrect configuration can result in a component emitting log messages repeatedly. Excessive logging can create a number of problems, such as:

  • System performance is reduced.

  • Log files fill up, and are rotated frequently, increasing the risk of losing useful messages.

  • Captured standard out (stdout) files grow indefinitely.

  • Messages from Managed Servers are broadcast to the domain log, which floods the domain log broadcaster and thereby creating another bottleneck.

  • Threads become stuck.

To prevent this problem, the WebLogic logging service provides a feature that monitors the domain for the presence of excessive logging. Log monitoring, which is enabled by default, works by counting the number of messages generated during a specified period of time. If messages are generated at a rate above a set threshold, the logging service inspects individual messages to determine if a specific message is being logged repeatedly. If so, the logging service suppresses, or throttles, that message to reduce the overall rate of logging. Throttling is automatically disabled when the overall message generation volume falls.

A message that is being logged repeatedly is identified by its signature, which consists of the following parameters:

  • The logger name that is generating the message

  • The message ID

  • A portion of the beginning of the message, which is established by the LogMonitoringThrottleMessageLength attribute. (The default value is 50, which limits the portion of the message that is evaluated to the first 50 characters.)

To enable log monitoring, configure the following values on the LogMBean:

Table 2-2 Attribute

Attribute Description
LogMonitoringEnabled={true|false}

Flag to indicate whether log monitoring is enabled. By default, this value is set to true.

LogMonitoringIntervalSecs=seconds

Timer interval, in seconds, during which the number of messages logged is counted. The default is 30.

LogMonitoringThrottleThreshold=value

Threshold number of messages logged during the specified time interval that either begins or stops message throttling. The default is 1500.

LogMonitoringThrottleMessageLength=value

Length of the initial portion of the log message that is evaluated during the throttle period. The default is 50.

LogMonitoringMaxThrottleMessageSignatureCount=value

Maximum number of unique message signatures that are monitored during the throttle interval. This value provides a cap on the number of signatures that are stored in an internal cache, which prevents the cache from growing indefinitely and causing an OutOfMemoryError.

Parent topic: Configuring WebLogic Logging Services