Logging and Trace

The product has a unified logging component that handles messages that are written by the product and provides First Failure Data Capture (FFDC) services.

In version 20.0.0.7 and later, see the Open Liberty website for Liberty logging documentation.

Additionally, the logging component captures messages that are written to System.out, System.err, java.util.logging, and OSGi logging. The logging component unifies the handling of these messages with other messages that are written by the product. The logging component does not capture or control the destination of messages that are written directly by the JVM process, such as -verbose:gc output. These messages are routed to the file system according to the active JVM settings A server has the following three primary log files:

1. console.log - Contains the redirected standard output and standard error streams from the JVM process. This console output is intended for direct human consumption. The logging component writes major events to the standard output stream and errors to the standard error stream if we use the default consoleLogLevel configuration. If we use the default copySystemStreams configuration, the logging component also copies any messages that are written to the System.out stream to the standard output stream and any messages that are written to the System.err stream to the standard error stream. The standard output and standard error streams always contain messages that are written directly by the JVM process, such as -verbose:gc output. This file is created only if the server start command is used, and its location can be altered only using the LOG_DIR environment variable.

   See Administer Liberty from the command line.

2. messages.log - Contains all messages that are written or captured by the logging component. All messages that are written to this file contain additional information such as the message time stamp and the ID of the thread that wrote the message. This file does not contain messages that are written directly by the JVM process.

3. trace.log - Created if we enable trace. Contains all the content of messages.log file plus any enabled trace. This file does not contain messages that are written directly by the JVM process.

Tip: We can use the user.timezone property to set the time zone for the application environments. Set the user.timezone property in the jvm.properties file. The updated time zone information is displayed in the messages.log file and the trace.log file. The following example shows how to set the time zone.

-Duser.timezone=time_zone_code

Logging configuration

The logging component can be controlled through the server configuration. The primary location for the logging configuration is in the server.xml file. Occasionally, we might need to configure trace to diagnose a problem that occurs before the server.xml file is processed. In this case, the equivalent configuration properties can be specified in the bootstrap.properties file. If a configuration property is specified in both the bootstrap.properties file and the server.xml file, the value in bootstrap.properties is used until the server.xml file is processed. Then, the value in the server.xml file is used.

Avoid specifying different values for the same configuration property in both the bootstrap.properties and the server.xml file.

Tip: For the latest logging property descriptions, see the Open Liberty logging documentation or the WebSphere Liberty server configuration documentation for Logging (logging). The latest information might not be in Table 1.

We can set logging properties in the server configuration file by selecting Logging and Tracing in the Server Configuration view in the developer tools. Or by adding a logging element to the server configuration file as follows:

<logging traceSpecification="*=audit:com.myco.mypackage.*=finest"/>

The format of the log detail level specification:

<component> = <level>

where <component> is the component for which to set a log detail level, and <level> is one of the valid logger levels (off, fatal, severe, warning, audit, info, config, detail, fine, finer, finest, all). Separate multiple log detail level specifications with colons (:).

Attention: For a given logger, the level is determined by the most specific trace specification that applies to that logger.

Components correspond to Java packages and classes, or to collections of Java packages. Use an asterisk (*) as a wildcard to indicate components that include all the classes in all the packages that are contained by the specified component. For example:

*	All traceable code running in the application server, including the product system code and customer code.
com.ibm.ws.*	All classes with the package name beginning with com.ibm.ws.
com.ibm.ws.classloading.AppClassLoader	The AppClassLoader class only.

The console.log file does not have the same level of management as other log files. The only properties we can change are consoleLogLevel, consoleSource, and consoleFormat. If we are concerned about the increasing size of the console.log file, we can set the console.log file to OFF and use the message log file instead. All the server logging messages that are sent to the console log file are written to the message log file, and we can control the size and number of message log files using the maxFileSize and maxFiles attributes. However, when you set the console log level to OFF, messages from the underlying JVM and any messages that are written to the native standard out or standard error streams are still written to the console.log file.

For example, the following bootstrap.properties file results in a console.log file with no server logging messages and a maximum of three rolling 1 MB loggingMessages.log files. Sets in the bootstrap.properties file take effect before the message log file is created, so the message log file is initially created as loggingMessages.log and not the default messages.log.

com.ibm.ws.logging.max.file.size=1
com.ibm.ws.logging.max.files=3
com.ibm.ws.logging.console.log.level=OFF
com.ibm.ws.logging.message.file.name=loggingMessages.log

The console.log file is reset when the server is restarted.

Note: On all operating systems, logs are written in the default system encoding.

• On Windows systems, there are two types of encoding: OEM code page, which is used for console output, and ANSI code page, which is used to read and write files. The console.log file uses the OEM code page, and all other logs use the ANSI code page.

• On all other operating systems, all log files use the default encoding.

The following samples illustrate example configurations for JSON logging:

• To set messages.log to JSON format in the server.xml file.
  <logging messageFormat="json" messageSource="message,trace,accessLog,ffdc,audit" />

• To set the console to JSON format in the server.env file.
  WLP_LOGGING_CONSOLE_FORMAT=json
  WLP_LOGGING_CONSOLE_LOGLEVEL=info
  WLP_LOGGING_CONSOLE_SOURCE=message,trace,accessLog,ffdc,audit

• To set the console to JSON format in the bootstrap.properties file.
  com.ibm.ws.logging.console.format=json
  com.ibm.ws.logging.console.log.level=info
  com.ibm.ws.logging.console.source=message,trace,accessLog,ffdc,audit

• To set the console to JSON format when running a Liberty Docker image:

  docker run \
      -e "WLP_LOGGING_CONSOLE_SOURCE=message,trace,accessLog,ffdc" \
      -e "WLP_LOGGING_CONSOLE_FORMAT=json" \
      -e "WLP_LOGGING_CONSOLE_LOGLEVEL=info" \
      websphere-liberty

Parent topic: Troubleshooting tips for Liberty

Related information

• Specifying Liberty bootstrap properties
• Enable JDBC Tracing for Liberty
• Logging (logging)