"Go" teaches you how to read the was log (WebSphere Application server) __web

Today, I read the article about was journal, which is very comprehensive, and I turn to everyone to learn.

WebSphere Application Server is a Java-based WEB application server built on open standards to help you deploy and manage many applications from simple WEB sites to powerful e-commerce solutions. It adheres to the Java EE and provides a portable Web deployment platform for the components, XML, and Web services that interact with the database and provide dynamic Web content.

With the growing share of WebSphere Application server products in the mid-market, more and more enterprises using WebSphere Application Server as it-based products, as the IT department of our enterprise, An important part of the job is managing WebSphere application Server. Because of the complexity of the business system and the large number of reasons for IT systems, it is inevitable that our system will have such problems, to locate and solve these problems, the log of WebSphere application server will play a key role. How to manage and view these logs.

The author has been working on WebSphere Application Server related services and has accumulated many management experience in WebSphere Application server. We want to be able to share these experiences with readers through a series of articles to help you better manage your WebSphere application Server.

This article will start with the problem diagnosis, in the process of solving a series of specific problems, introduce the policy of configuration log and the usage of specific parameters, provide you with the way to diagnose the problem and specify the method of logging policy. How to diagnose problems

In our Java EE-based application, the emergence of problems can occur in a variety of related areas. So the first thing to make clear is what is happening on the build, we can isolate the problem by testing the individual components to check their success or failure. Analyze related logs to locate the problem. The following figure is a few common test methods and the location of the relevant logs.

When our system fails to access the phenomenon, we usually follow the steps to analyze:

1. Use your browser to access your app via port 80 (ex: http://localhost/myWeb/)

2. Use the browser to access the application via 9080 (depending on the actual port) port (for example: HTTP://LOCALHOST:9080/MYWEB) If the access is normal, the HTTP server request does not forward normally, this time by http:// LocalHost to verify that the HTTP server is up and running correctly, if the HTTP server is working properly, check http_plugin.log to view the plug-in log and view the HTTP server Configuration file httpd.conf, find out if the Plugin-cfg.xml file Webspherepluginconfig is loaded is correct.

3. If a port cannot access the application through 9080 (depending on the actual port), you can verify that the application server survives by Http://localhost:9080/snoop. If survival is as shown:

General instructions for application problems, view analysis related logs: System.Out.log, SystemErr.log, activity.log the problem caused by locating the application. Log Introduction

System.Out.log, SystemErr.log belongs to the JVM log. WebSphere Application Server writes formatted messages to the System.out log. In addition, applications and other code can write to these logs, implemented through the print () and println () methods. Some development toolboxes (Developer Kit) built-in Printstacktrace () methods such as the Throwable class can also write to these logs. Typically, the System.out log is used to monitor whether the application server is functioning properly. The System.out log can be used for problem determination, but it is recommended to use the advanced capabilities of the IBM service log and log Analyzer instead. The System.err log contains exception stack trace information, which is useful when you perform a problem analysis.

Because each application server represents the JVM, each application server and all its applications have a set of JVM logs that, by default, are located in the Installation_root/profiles/profile_name/logs/server_ Name directory. In the case of WebSphere application Server Network Deployment configuration, JVM logs are also created for Deployment Manager and each node manager because they also represent the JVM.

Activity.log for IBM logs, the application server creates service or activity log files from the activities of various WebSphere application server components. The service or activity log file (Activity.log) is a binary file that is located in the logs directory of Install_root, and we can use the Log Parser to view the service or activity log files. View JVM Logs

The JVM log is written as a plain text file. Therefore, there are no special requirements for viewing these logs. They are located in the Installation_directory/profiles/profile_name/logs/server_name directory and are named SystemOut.log and SystemErr.log by default.

There are two techniques that you can use to view the JVM logs for an application server.

L Use the administration console. It supports viewing the JVM logs from a remote machine.

l Use a text editor on the machine where the logs are stored.

steps for this task

1. View the JVM logs from the administration console.

Start the administration console.

In the console navigation tree, click Troubleshooting > logging and Tracing . To view the logs for a particular server, click the server name to select it, and then click the JVM log .

Select the Run-time tab.

Click the view that corresponds to the log that you want to view.

2. View the JVM logs on the server hard disk.

Go to the machine where the logs are stored.

Open the file in a text editor or drag and drop the file into the editing and viewing program. Log format:

Depending on the JVM log configuration, formatted messages can be written to the JVM log in either Basic or advanced format.

Message format formatted messages can be written to the JVM log using one of these two formats:

Basic format This is the format used in earlier versions of WebSphere application Server.

Advanced Format if possible, extend the basic format by adding information about the event.

Here are some common formats for logging, which can help us to better view the logs and possibly find various fields in these formats as follows:

TimeStamp

The timestamp is formatted using the process locale in which it was formatted. It contains a standard date (for example, YYMMDD), a 24-hour time and time zone with a precision of milliseconds.

ThreadId

A hexadecimal value of 8 characters generated from the hash code of the thread that emitted the message.

ThreadName

The name of the Java thread that issued the message or trace event.

ShortName

The abbreviated name of the record component that issued the message or trace event. This is typically the class name for the internal components of WebSphere application Server, but can also be other identities for some user applications.

longname

The full name of the record component that issued the message or trace event. This is typically the standard class name for the internal components of WebSphere application Server, but can also be other identities for some user applications.

EventType

A character field that indicates the type of message or trace event. The message type is uppercase. Possible values include:

F

Fatal message.

E

The error message.

W

A warning message.

A

Audit messages.

I

Reference message.

C

Configure the message.

D

The details message.

O

Writes System.out messages directly through the user application or internal components.

R

Writes SYSTEM.ERR messages directly through the user application or internal components.

Z

Represents a placeholder for an unrecognized type.

Class name

The class that emitted the message or traced the event.

Method name

The method that emits the message or tracks the event.

Organization

An organization that has an application that emits messages or tracks events.

Products

The product that issues the message or tracks the event.

Component

Components within the product that emit messages or trace events.

Basic Format

Message events displayed in the basic format use the following format. The symbol indicates a required field that will always appear in the basic format message. The symbol [name] indicates the optional or conditional fields that will be included if they can be determined.

[ClassName] [MethodName]

Advanced format

Message events displayed in advanced format use the following format. notation is used to indicate a required field that will always appear in the high-level format of the message entry. The notation [name] is used to indicate the optional or conditional fields that will be included if they can be determined.

[ClassName] [methodname]<; Product>[thread=threadname]

Configuring the JVM Log

Use the administration console to configure the JVM logs for the application server. The configuration changes made to the JVM logs to run the application server are not applied until the application server is restarted the next time.

Steps for this task

Start the management console

Click Troubleshooting > logging and Tracing , and then click Server > JVM logs .

Select the "Configuration" tab.

Scroll through the panel to display the properties of the log you want to configure.

Change the appropriate configuration properties and click Apply.

Save your configuration changes. Java virtual Machine (JVM) log settings

Use this page to view and modify the settings for the Java virtual machine (JVM) System.out and System.err logs.

To view this Administration console page, click Troubleshoot > Log and trace > server name > JVM logs.

View and modify the settings of the Java virtual machine (JVM) System.out and System.err logs for this managed process. Create a JVM log by redirecting the JVM's System.out and System.err streams to a standalone log file. The System.out log is used to monitor the health of the running Application server. The System.err log contains the exception stack trace information that is useful when you perform a problem analysis. Each application server and all its applications have a set of JVM logs. The JVM logs are also created for Deployment manager and for each node manager. Changes on the configuration panel will be applied when the server is restarted. Changes on the run-time panel are applied immediately.

The Configuration tab

file name

Specifies the name of a log file that is described in this page.

The first file name field specifies the name of the System.out log. The second file name field specifies the name of the System.err file.

Press the view button on the Runtime tab to view the contents of the selected log file.

The file name specified for the System.out log or System.err log must have one of the following values:

file name

The name of the file in the file system. We recommend that you use a standard file name. If the file name is not a standard file name, it is considered relative to the current working directory of the server. Each log must be configured with a dedicated file. For example, we cannot redirect System.out and System.err to the same physical file.

If the directory that contains the file already exists, the user identity that is used by the running server requires read/write access to the directory. If the directory does not exist, it will be created with the appropriate permissions. The user ID used by the running server must have permission to create the directory.

Control Desk

This is the special file name used to redirect the stream to the associated process stream. If this value is specified for System.out, the file is redirected to stdout. If this value is specified for System.err, the file is redirected to stderr.

No

Discard all data written into the stream. Specifies that none equals to redirect the stream to Dev/null on the UNIX system.

The default path to filename is the value of the variable server_log_root. To view the value of the Server_log_root variable:

1. On the admin console, select Environment > WebSphere variables

2. Click the Server radio button, and then click Apply. The value of the Server_log_root variable appears in the displayed list.

To change the value of the Server_log_root:

1. Select Server_log_root

2. Enter a new path in the Value field

3. Click "Apply"

4. Save this configuration. You must restart the server for the changes to take effect.

Of course we can also change the location and name of the ${server_log_root}/and ${server_log_root}/systemerr.log files to any other absolute path and file name (for example,/tmp/mylogfile.log).

file Format

Specifies the format used to save the System.out file.

log file Scrolling (keep old log files to generate new log files)

The application server has the log Self-management feature, which configures the System.out or System.err log files for self-management by using this set of configuration properties.

The self-management log file writes the message to the file until the time or size condition is reached. When the specified time is reached or the file reaches the specified size, the log file scrolls (including closing the file and renaming the saved file), while the record is temporarily suspended. The newly saved file name is the original file name plus a timestamp qualifier indicating when the file was renamed. Once the rename is complete, reopen the new empty log file with the original name and restore the record. Although the log file is scrolled, a message may be split between the saved file and the current file, but all messages will be preserved.

If the associated stream is redirected to a file, only one log can be configured for self-management.

File Size

Click this property of the log file to have it manage itself according to its file size. Automatic scrolling occurs when the file reaches the size specified in the Maximum size field.

Maximum size

Specifies the maximum size of the file, in megabytes. When the file reaches this size, it scrolls.

This property is only valid if you click File size.

Time

Click this property of the log file to have it manage itself according to the time of day. The file is scrolled at the time specified in the Startup Time field.

Start Time

Specifies the time of the first start of the cycle scrolling algorithm after the application server restarts, that is, the number of days (from 1 to 24). The algorithm starts fashion in the application server. Once the scrolling algorithm is started at the hour specified in the Startup Time field, it scrolls the file at a certain time (the number of hours specified in the Repeating Time field). This scrolling mode will continue to be used without adjustment until the application server stops.

Note: Scrolling always occurs at the beginning of the specified hour of the day. The first hour of the first small day of the day (since 00:00:00 (midnight)) is 1 points, while the last one hours of the day (since 23:00:00) is 24 points. Therefore, if you want the log file to scroll at midnight, set the startup time to 1.

Repeat Time

Specifies the number of hours (from 1 to 24) during which periodic scrolling occurs.

Repeat Time

Specifies how many hours per hour the log file scrolls. Valid values range from 1 to 24.

Configure log files to scroll by time, by size, or by time and size. Click File size and time to scroll the file when the condition is first matched. For example, if the repeating time field is 5 hours and the maximum file size is 2 MB, the file will scroll every 5 hours, unless the time interval is not reached and the file size is 2 MB. After scrolling by file size, the file continues to scroll by time interval.

maximum size of the history log file

Specifies the number of historical (scrolled) files to save. The stream is written to the current file until it scrolls. When scrolling, closes the current file and saves the file with a new name that consists of the current name plus a scroll time stamp. The stream will then reopen a new file with the original name to continue writing. The number of history files grows from zero to the value of the Maximum history file Number field. The next time you scroll to delete the oldest history file.

output of installed applications

Specifies whether to record and format the System.out or System.err print statements emitted by the application code.

Show application Print Statements

Click this field to display the message that the application writes to the stream using the print and println streaming methods. WebSphere Application Server system messages are always present.

Format Print Statements

Click this field to format the application print statements (such as WebSphere application Server system messages).

Run Time tab

file name

Specifies the name of a log file that is described in this page.

The first file name field specifies the name of the System.out log. The second file name field specifies the name of the System.err file.

Press the View button on the Runtime tab to view the contents of the selected log file.

The file name specified for the System.out log or System.err log must have one of the following values:

file name

The name of the file in the file system. We recommend that you use a standard file name. If the file name is not a standard file name, it is considered relative to the current working directory of the server. Each stream must be configured with a dedicated file. For example, you cannot redirect System.out and System.err to the same physical file.

If the directory that contains the file already exists, the user identity that is used by the running server requires read/write access to the directory. If the directory does not exist, it will be created with the appropriate permissions. The user ID used by the running server must have permission to create the directory.

Control Desk

This is the special file name used to redirect the stream to the associated process stream. If this value is specified for System.out, the file is redirected to stdout. If this value is specified for System.err, the file is redirected to stderr.

No

Discard all data written into the stream. Specifies that none equals to redirect the stream to Dev/null on the UNIX system.

The default path to filename is the value of the variable server_log_root. To view the value of the Server_log_root variable:

1. On the admin console, select Environment > WebSphere variables

2. Click the Server radio button, and then click Apply. The value of the Server_log_root variable appears in the displayed list.

To change the value of the Server_log_root:

1. Select Server_log_root

2. Enter a new path in the Value field

3. Click "Apply"

Save this configuration. You must restart the server for the changes to take effect. Of course we can also change the location and name of the ${server_log_root}/systemout.log and ${server_log_root}/systemerr.log files to any other absolute path and file name (for example,/tmp/ MyLogfile.log). Conclusion

The JVM logs are very important for our analysis and tracking of the problem. WebSphere Application Server is a powerful log self-management feature that makes our daily work easier and easier, and learning and mastering these features is beneficial to our managers. Resources

L IBM Product Information Citic http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp

L WebSphere Application Server V6 System Management and Configuration Handbook product Redbook

L WebSphere Application Server V6 Scalability and Performance Handbook product Redbook
About the author

Benson Technical Consultant, responsible for IBM software training, technical support, consultant work. Wrote books on Java and EE development.