Logging services

Commerce+ maintains a detailed set of logs related to a variety of processes and functions. These logs are available upon request.

The Open Liberty Server logs record unexpected errors or abnormal conditions within the Commerce+ application. Additionally, the business auditing feature records business actions that are not errors. Use the business auditing functions if you are interested in tracing specific commands and tasks that are executed during an Commerce+ operation.

Log file locations

You can find the default output files in the following directory:
/opt/ol/wlp/usr/servers/transactionServer/logs/container/ts_a96cf494125a
Where a96cf494125a is an example of a generated string.

Available logs

The following default logs are available. You can use any text editor to view Open Liberty Server trace files, system out log files, or system error log files.
console.log
Created by the server start command. This log contains redirected standard output and standard error streams from the underlying JVM process, formatted for human readability. Because it is optimized for readability, it lacks some details that are useful in automated log analysis. The log file is rewritten when the server is restarted.
messages.log
Contains all messages that are written or captured by the logging component, including information such as the message timestamp and the ID of the thread that wrote the message. This file is optimized for automated log analysis. It does not contain messages from the JVM process.
trace.log
This file is created only if you enable trace. It contains the content of the messages.log file as well as any enabled trace. It does not contain messages written directly by the JVM process.
verbosegc.XXX.log
Files that contain verbose garbage collection output from the JVM, where XXX represents the sequence number of the log file. These log files are created by default when the Java implementation is either IBM Java or IBM Semeru runtimes. Up to 10 rolling log files are created in the log directory, with 1024 GC cycles per file. Custom configurations take precedence over the default behavior. To disable the verbose garbage collection logs, add VERBOSEGC=false to the server.env file. For more information, see Verbose garbage collection logs topic on the Eclipse development site.

Log APIs

Message logs and traces are important diagnostic tools that aid the Site Administrator in determining the source of problems. Tracing is a problem-determination mechanism. Tracing assists developers in debugging the code during the development stage and assists the technical support team in solving customer problems. You can use the following APIs to control Commerce+ logging and tracing behavior.

ECTrace
Traces the data flow. The trace entries are captured in a file for debugging purposes. Tracing is used for problem determination. Tracing assists developers in debugging code during the development stage and assists the technical support team in solving customer problems.

Tracing data is persisted for future reference in a trace file. A data structure consists of context information, such as a class name, a method name, and a text message. Multiple data structures describe the data flow within a software application. By analyzing the data structure sequence, a developer can understand the path that was executed, which can help determine the cause of malfunctions.

ECMessage
Logs diagnostic messages. Messages are locale-sensitive, and are stored in log files in the file system. If error notification is enabled, technical support receives alert notifications. Diagnostic logs are used for problem determination. By default, the log file name is SystemOut.log.

Diagnostic logs are used for problem determination. ECMessageLog logs diagnostic messages, and ECMessages are localized. ECMessages are divided into the following categories:

System messages
System messages display in the logs and are for recording problems or potential problems (that is, warnings). System messages provide diagnostic information for Site Administrators. These messages might follow a system malfunction, or indicate some other significant event.

System messages are assigned a product-specific message ID. Site Administrators can use the message ID to look up more details that are associated with that message; customers can report the message to support personnel for troubleshooting.

Messages from previous versions of Commerce+ use the CMN nnnns format, and messages new for Commerce+ 5.6 use the format CWX ccnnnns. In both cases, be familiar with the following format:

cc
The Commerce+ component that is reporting the system message. For example, CC indicates a message about the catalog component, as in CWXCC1234E.
nnnn
The key number that is used to identify what is affected. For example, 1234, as in CWXCC1234E.
s
The severity of the message. A severity of E indicates an error message, I indicates informational messages, and W indicates warnings.
User messages
Are frequently shown on the browser, and are for the benefit of a customer that is visiting the site. User messages provide details about the problem. For example, messages can indicate whether a parameter specified is invalid, which indicates to the customer what value to fix when they resubmit the request.

Logging levels

There are three logging levels, or severities, in the Commerce+ logging system:

  • error
  • warning
  • informational
Note: Although the Open Liberty Server logging facility also uses the status and debug logging levels, Commerce+ uses and maps to the error, warning, and informational logging levels.
Error messages
Always logged by default. Error messages expose an error condition that can lead to system malfunction.
Warning messages
Reveal a potential problem.
Information messages
Follow events that occur within the Commerce+ system. Information messages are related to events that trigger changes in the system state. For example, an information message is persisted when an order is submitted.

The Open Liberty Server user interface is used to control the enablement of the logging level or severity type. Site Administrators can specify which logging severities to record in the Open Liberty Server Administration Console.