What is diagnostic trace

WebSphere Application server components as well as most of the enterprise level applications use Logging framework to generate detailed trace for execution. By default this trace is disabled because it causes performance overhead but you can turn the trace on for either your application or the particular websphere component when you want to debug issue.

When you open a support request with IBM support, most of the time they will ask you to enable the trace for particular area and send the generated trace to them for further analysis of the problem.

You can turn the trace on using the WAS Admin Console GUI by going to TroubleShooting -> Logs and Trace -< Servrname. On the Logging and Tracing screen, select the Diagnostic trace.



On the Diagnostic Trace Services screen you can enable the trace by checking Enable Log checkbox.



On this screen you can also define where the output of the trace should go, you have following two options

• Memory Buffer: If you select the Memory buffer option then your messages wont be written to any file instead they will be kept in memory. But in order for you to view the messages you will have to dump the memory in file and then view it. This is not recommended option


• File: Once you decide to send the log messages to the file system it allows you to configure following properties
  
  
  
  • Maximum File Size: What should be maximum size of the trace file. Once the trace file size reaches this limit, the trace.log file would be renamed to trace+timestamp.log file and a new trace.log file would be created
  
  
  • Maximum Number of Historical Files: What is the maximum no. of historical files that should be preserved. When the trace.log reaches maximum first the WAS server would check if no. of historical files is reached if yes delete the oldest trace file.
  
  
  • File Name: Fully qualified path name where the trace file should be generated
  
  
  
  

Whatever changes you make on Configuration tab are persisted in server.xml and they require server restart for those changes to take effect. But if you want to change trace file location for running server then you can make those changes on the Runtime tab.

Process (native) logs

The process logs are created by redirecting the STDOUT and STDERR streams of the process to independent log files. Native code, including the Java virtual machine (JVM) itself, writes to these files. As a general rule, WebSphere Application Server 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. For WebSphere Application Server Network Deployment configuration, a set of process logs is created for the deployment manager and each node agent.

The only configuration that is possible for the process logs is changing the directory location or file names for the logs. You can do this in the WAS Admin console by going to Troubleshooting -< Logs and Traces and clicking on process name. On the Logging and Tracing screen select Process Logs



Then on the Process Logs screen you can change the location of native_stdout.log or native_stderr.log file.



You can view the native_stderr.log and native_stdout.log file either using any text editor or you can view it using the WAS Admin Console (even for remote location) by going to the Runtime tab. Select the log file that you want to see

Configuring JVM Logs

You can configure the JVM logs using WAS Admin Console. Follow these steps in order to do that

• Log into the WAS Admin Console


• Go to TroubleShooting -< Logs and Trace. Select the server/process whose log you want to configure and you will get a screen like this
  
  


• Click on JVM Logs to get the JVM Logs Configuration Screen like this
  
  
  You can configure following parameters on this tab
  
  
  
  • File Name: The name of a file in the file system. It is recommended that you use a fully qualified file name. If the file name is not fully qualified, it is considered to be relative to the current working directory for the server. Each stream must be configured with a dedicated file. For example, you cannot redirect both System.out and System.err to the same physical file.
  
  
  • File formatting: Specifies the format to use in saving the System.out file. It is recommended to use the default value of basic format
  
  
  • Log file rotation: The SystemOut and SystemErr logs are self-managing. They write to the specified file until either the maximum file size or certain time is reached. When that happens the current log file renamed as the current file name plus the current time stamp. Then a new SystemOut and SystemErr file is created for further logging. The older log files are called historical log files.
    Depending on your needs you can choose to have the log file rotate when they reach a specified size(Say 5 MB) or certain time(Every morning) or both.
    
  
  
  • Maximum Number of Historical Log Files. Number in range 1 through 200. The value that is entered here is the number of historical log files that are kept. If the value is reached and another historical log file needs to be created, the oldest one is removed from your system.
  
  
  • Installed application output: These properties affect how print and println statement from your application are output. There are two options
    
    
    
    • Show application print statements: This is enabled by default. If you de select it, application print and println statements are not logged to the SystemOut and SystemErr log file
    
    
    • Format Print Statement: This is also enabled by default. You can deselect it if you do not want your application print and println statement to be formatted similar to the WAS messages in the log