Administer >


Log services

WebSphere Commerce provides facilities for logging. For existing customers, we continue to support ECTrace and ECMessage. For new implementations, use the WebSphere Application Server recommendation for logging and tracing.

The purpose of logging messages in the WebSphere Commerce Server is to record unexpected errors or abnormal conditions within the WebSphere Commerce application. (For information about recording commands and tasks that are executed during a WebSphere Commerce operation, refer to business auditing.) 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. Since logging from WebSphere Commerce makes use of the logging facility from WebSphere Application Server, the Log Analyzer can be used. The Log Analyzer is a graphical utility that facilitates viewing and analyzing log files.

The WebSphere Commerce Log APIs are:

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.

Trace 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 may 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 associated with that message; customers can report the message to support personnel for troubleshooting.

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

cc

The WebSphere 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 used to identify what is affected. For example, 1234, as in CWXCC1234E.

s

The severity of the message; that is, 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 visiting the site. User messages will give details about the problem. For example they will indicate whether a parameter specified is invalid, which indicates to the customer what value to fix when they resubmit the request.

Consists of multiple java packages that form a logging toolkit that provides message logging and diagnostic trace primitives. These primitives are not tied to any particular product or platform. JRas is composed of several components:

Loggers

A logger is the primary object with which the user code interacts. There are two types of loggers:

  • message loggers

    • create only message records.

  • trace loggers

    • create trace records.

A logger contains one or more Handlers to which it forwards events for further processing.

Handlers

A handler receives events from a logger, and provides an abstraction over an output device or event consumer. An example is a file handler, which knows how to write an event to a file.

Formatters

Handlers are configured with Formatters, which know how to format events of certain types.

Event Types

Messages and traces have their own pre-defined event types.

Event Classes

The JRas logging toolkit defines both message and trace event classes.

WebSphere JRas extensions

In order to integrate into the WebSphere Application Server run time or for usage in a Java EE environment, WebSphere provides a set of extension classes. Logging from WebSphere Commerce makes use of the WebSphere Application Server logging facility, and these extension classes provide a better correlation of messages and traces generated from different WebSphere products. This collection of extension classes are referred to as JRas extensions. JRas extensions provide appropriate logger implementation classes. Instances of these message and trace logger classes are obtained directly and exclusively from the WebSphere Manager class which is located in the com.ibm.websphere.ras package. Other components such as Payments and the JCA messaging framework also make use of JRas extensions.

WebSphere Commerce provides a wrapper for ECMessage and ECTrace that calls the WebSphere JRas extension APIs, however it is recommended that Site Administrators call the JRas APIs directly.

For more information about the JRas logging toolkit, see the Understanding the JRas facility topic in the WebSphere Application Server Information Center.


Log file location

The location of the default output files is:

The default output files are:

native_stderr.log

A process log that contains text written to the stderr stream.

native_stdout.log

A process log that contains text written to the stdout stream.

startServer.log

A log written when starting the server.

stopServer.log

A log written when stopping the server.

SystemErr.log

Logs any system error while the server is running.

SystemOut.log

Logs the system output file while the server is running.

activity.log

Logs continuous activity. This log is located in the WAS_HOME/logs directory.

trace.log

If trace is enabled, logs the components trace messages while the service is running.

Note:

When working with IBM to debug request processing problems, there might be occasions where low-level tracing components must be enabled to capture details for how the request is processed. These low-level Application server trace components do not have knowledge of the request intent or the potential data within. Therefore, when enabled, it is possible that these tracing components might potentially include sensitive information, in plain text, in the trace file.

IBM recommends whenever possible to not enable these types of tracing components on a production system and attempt to simulate the problem on a quality assurance environment to capture the appropriate information. However, when this is not possible and the tracing components might have to be enabled on a production system, it is recommend to take the necessary precautions when handling the trace files. Before sending the trace, any sensitive data contained in the trace should be removed when a third party is using them for diagnosing the problem. Further, when the trace is no longer required, the files should be removed using a military-grade data wiping process. Once the problem has been determined and the tracing component is no longer required, those tracing components should immediately be disabled.


Log levels

There are three logging levels, or severities, in the WebSphere Commerce logging system. The system message severities are:

Although the WebSphere Application Server logging facility also uses the status and debug logging levels, WebSphere Commerce utilizes and maps to the error, warning, and informational logging levels.

Error messages

Are logged at all times by default. Error messages expose an error condition that can lead to system malfunction. An error message can be sent as an e-mail, WebSphere MQ message, or by another form of notification to a Site Administrator registered with messaging.

Warning messages

Reveal a potential problem.

Information messages

Follow events that occur within the WebSphere 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 has been submitted.

Since WebSphere Commerce uses the WebSphere Application Server logging facility, refer to the following table to learn about how the WebSphere Commerce logging levels are mapped to the WebSphere Application Server...

Log levels in WebSphere Commerce Log levels in WebSphere Application Server
DEBUG TYPE_INFORMATION/TYPE_INFO
ERROR/ERR TYPE_ERROR/TYPE_ERR
INFORMATION/INFO TYPE_INFORMATION/TYPE_INFO
STATUS TYPE_INFORMATION/TYPE_INFO
WARNING/WARN TYPE_WARNING/TYPE_WARN

The WebSphere Application 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 WebSphere Application Server Administration Console.


View log files

You can view log files in various ways. Typically, depending on the type of log file, there are suggested methods to view...

The following diagram illustrates these suggested view methods:


Related concepts

Business auditing

Requirement 10: Track and monitor all access to network resources and cardholder data


+

Search Tips   |   Advanced Search