Application server log files
When we are starting and stopping an application server, a number of log files are generated. After you start or stop an application server, check the log files to ensure that both the application server and the application that runs inside the application server started or stopped successfully.
The application server log files are in the following directory:
- In the Transaction server Docker container, WC_profiledir/logs/server1
(Developer) WCDE_installdir/wasprofile/logs/server1
Examine the following log files after you start or stop an application server:
- stopServer.log
- This log file contains messages that are generated when the application server was stopping. The application server is stopped successfully if this log file contains the text, Server server_name stop completed, where server_name is the name of the application server that was stopped.
- SystemErr.log
- This log file contains Java exceptions and stack traces. These exceptions are caught by enterprise applications and their associated application servers.
An empty SystemErr.log file does not necessarily indicate success since not all error messages that are generated by an application are considered to be error messages by the operating system. We must also examine the contents of the SystemOut.log file.
- SystemOut.log
- This log file contains messages that are generated when the applications running inside the application server are being started or stopped. This log file does not include error messages - such messages are in the SystemErr.log file. However, this log file does include error messages that the operating system does not see as error messages.
Check both this log file and the SystemErr.log file after you start an application server to confirm that the applications inside the application server that start with the server are also started successfully.
- trace.log
- The log file contains the components trace messages while the service is running, if the trace is enabled in the server.
Note:
When you work 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 know 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 that you do 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, if the tracing components must be enabled on a production system, handle the trace files with caution. Before you send the trace, remove sensitive data that might be in the trace before you allow a third party to use the trace for diagnosis. Further, when the trace is no longer required, remove the files with a military-grade data wiping process. When the problem is found and the tracing component is no longer required, immediately disable the low-level tracing components.
Related concepts
Logging services