WAS v8.5 > Troubleshoot

Use basic or traditional message logs

WebSphere Application Server can write system messages to several general purpose logs, including JVM, process, and IBM service logs, which can be examined for problem determination.

The JVM logs are created by redirecting the System.out and System.err streams of the JVM to independent log files. WAS writes formatted messages to the System.out stream. In addition, applications and other code can write to these streams using the print() and println() methods defined by the streams. Some Developer Kit built-ins such as the printStackTrace() method on the Throwable class can also write to these streams. Typically, the System.out log is used to monitor the health of the running application server. The System.out log and System.err log can be used for problem determination. The System.err log contains exception stack trace information that is useful when performing problem analysis.

Because each application server represents a JVM, there is one set of JVM logs for each application server and all of its applications located by default in the following directory:

• install_root/profiles/profile_name/logs/server_name

The process logs are created by redirecting the STDOUT and STDERR streams of the process to independent log files. Native code, including the JVM itself, writes to these files. As a general rule, WAS does not write to these files. However, these logs can contain information relating to problems in native code or diagnostic information written by the JVM.

As with JVM logs, there is a set of process logs for each application server, since each JVM is an operating system process.

Deprecated feature: The IBM service log contains both the WAS messages that are written to the System.out stream and some special messages containing extended service information that is normally not of interest, but can be important when analyzing problems. There is one service log for all WAS JVMs on a node, including all application servers. The IBM Service log is maintained in a binary format and requires a special tool to view. This viewer, the Log and Trace Analyzer, provides additional diagnostic capabilities. In addition, the binary format provides capabilities that are utilized by IBM support organizations.

In addition to these general purpose logs, WAS contains other specialized logs specific to a particular component or activity. For example, the HTTP server plug-in maintains a special log. Normally, these logs are not of interest, but you might be instructed to examine one or more of these logs while performing specific problem determination procedures. For details on how and when to view the plug-in log, see the Accessing a web resource through the application server and bypassing the HTTP server subsection of the A web resource does not display topic.

The system log (SYSLOG) is only supported on WAS for z/OS . WAS logging does not utilize operating system logs except in the case of z/OS.

Sometimes server and application problems can be diagnosed by examining log output from the WAS.

Determine which type of logs you would like to implement:

• JVM logs
• Process logs
• IBM service logs

Example

How to direct SYSPRINT and SYSOUT output to an HFS file.

If you are familiar with UNIX or Windows environments, you might be reluctant to use the facilities of SDSF (or IOF) to view the SYSPRINT and SYSOUT output from servants. If you would rather use a familiar editor (such as vi) in a Telnet session to view your output, it is possible to redirect the SYSPRINT and SYSOUT outputs to files in an HFS.

The JCL example below shows how to modify the SYSPRINT DD card in your startup procedure to redirect the output to an HFS file. The old SYSPRINT DD card has been commented out by preceding it with /*, and a new SYSPRINT DD card points to a file in the "/myDir/myServer" directory, in this case named was.log.d&LYYMMDD..t&LHHMMSS.log.

The extra period between the date and time variables is not a typographical error, but rather an instance of JCL syntax that is necessary to terminate the first variable. &LYYMMDD will be replaced with the local date in YYMMDD format and &LHHMMSS will be replaced by the local time in HHMMSS format. The PATHMODE subparameter sets the file mode to 775 and the PATHOPTS subparameter OWRONLY opens the file for WRITE access. The sub-parameter OCREAT indicates that if the file does not already exist, create it.

We can modify the SYSPRINT DD card in either your Servant or Controller startup procedure. In addition, the SYSOUT DD card can be modified in the same way to redirect the SYSOUT output.

//*YSPRINT  DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE
//SYSPRINT  DD PATHMODE=(SIRWXU,SIRWXG,SIROTH),
//   PATHOPTS=(OWRONLY,OCREAT),
//   PATH='/myDir/myServer/was.log.d&LYYMMDD..t&LHHMMSS'

If you try to direct the output for multiple streams to the same file, such as setting both DEFALTDD and HRDCPYDD variables, the allocation for the HRDCPYDD file fails and output is sent to the default location (JOBLOG/SYSLOG).

Subtopics

• View JVM logs
  The JVM logs are written as plain text files.
• JVM log interpretation
  View the JVM log files to determine problems within application environments.
• Configure the JVM logs
  Use the dmgr console to configure the JVM logs for an application server.
• Process logs
  WAS processes contain two output streams that are accessible to native code running in the process. These streams are the stdout and stderr streams. Native code, including JVMs, might write data to these process streams. In addition, JVM provided System.out and System.err streams can be configured to write their data to these streams also.
• Configure the service log
  The settings for service logs are typically shared for all servers, but we can configure a separate service log for each server process by overriding the configuration values at the server level.
• View the service log
  Service logs are logs written in a binary format. We cannot view a service log directly using a text editor. You should never directly edit the service log, as doing so will corrupt the log.
• View JVM logs
  The JVM logs are written as plain text files.
• JVM log interpretation
  View the JVM log files to determine problems within application environments.
• Configure the JVM logs
  Use the dmgr console to configure the JVM logs for an application server.
• Monitoring application logging using JMX notifications
  Java developers can create programs to monitor application server logs using JMX notifications.
• Process logs
  WAS processes contain two output streams that are accessible to native code running in the process. These streams are the stdout and stderr streams. Native code, including JVMs, might write data to these process streams. In addition, JVM provided System.out and System.err streams can be configured to write their data to these streams also.
• Configure the service log
  The settings for service logs are typically shared for all servers, but we can configure a separate service log for each server process by overriding the configuration values at the server level.
• View the service log
  Service logs are logs written in a binary format. We cannot view a service log directly using a text editor. You should never directly edit the service log, as doing so will corrupt the log.

Reference:

>Web resource is not displayed

+

Search Tips   |   Advanced Search