was log analysis (WebSphere Application Server)

Keywords: WebSphere log

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

With the growing share of WebSphere Application server products in the intermediary market, the number of enterprises using WebSphere Application Server as the IT infrastructure is increasing, as IT departments of our enterprise, A very important part of the work is managing WebSphere application Server. Because of the complexity of the business system and the sheer size of the IT system, it is inevitable that our system will have such a problem, and that the logs of WebSphere application server will play a key role in locating and resolving these problems. How to manage and view these logs.

The author of this article has been working on the services of WebSphere Application server and has accumulated many of the management experience of WebSphere Application server. We hope 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 configuration log strategy and the use of specific parameters, to provide you with the way to diagnose problems and specify the method and methods of logging policies. the method of problem diagnosis

In our application based on Java EE, problems may arise in various related links. So the first thing to be clear is which build the problem is, and we can isolate the problem by testing individual components, checking them for success or failure. To analyze the relevant log to locate the problem. The following figure is a common test method and the location of the associated log.

When our system does not have access to the phenomenon, we generally follow the steps to analyze:

1. Use the browser to access the application through port 80 (for example: http://localhost/myWeb/)

2. Use the browser to access the application (for example: HTTP://LOCALHOST:9080/MYWEB) through a port of 9080 (depending on the actual port) if access is normal, the HTTP server request is not forwarded properly, by http:// LocalHost to verify that the HTTP server is up and running properly, check Http_plugin.log to view the plug-in log, and view the HTTP server if it's OK to do so Configuration file httpd.conf to find out if the Webspherepluginconfig loaded plugin-cfg.xml file is correct.

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

General description of the problem with the application, view the analysis related log: System.Out.log, SystemErr.log, activity.log positioning application caused problems. Log Introduction

System.Out.log, SystemErr.log belong to the JVM log. WebSphere Application Server writes formatted message to the System.out log. In addition, applications and other code can be written to these logs, implemented by the print () and println () methods. Some development kits (Developer kits) have built-in Printstacktrace () methods, such as the Throwable class, that can also be written to these logs. Typically, the System.out log is used to monitor the functioning of the application server. The System.out log can be used for problem determination, but it is recommended to use advanced capabilities of the IBM service log and log Analyzer instead. The System.err log contains exception stack trace information, which is useful when performing problem analysis.

Because each application server represents the JVM, each application server and all its applications have a set of JVM logs, which by default are located in the Installation_root/profiles/profile_name/logs/server_ The 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 is the IBM log, where 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 can be used to view service or activity log files using the Log Analyzer. 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 can be used to view the JVM logs of an application server.

L Use the management console. It supports viewing JVM logs from remote machines.

l Use a text editor on the machine that stores the logs.

the steps for this task

1. View the JVM log from the admin console.

Start the management console.

Click Troubleshooting > logging and Tracing in the console navigation tree. To view a log for a specific 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 log on the server hard disk.

Go to the machine where the log is 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 a basic or advanced format.

Messages formatted with messages can be written to the JVM log in one of 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 events.

Here are some of the log common format that can help us to better view the log, may find the various fields that adopt these formats are as follows:

TimeStamp

A timestamp is formatted using the process language environment in which it is formatted. It contains standard dates (for example, YYMMDD), 24-hour time in milliseconds, and time zone.

ThreadId

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

ThreadName

The name of the Java thread that emitted the message or traced the event.

ShortName

The abbreviated name of the record component that emitted the message or traced the event. This is typically the class name for the internal component of WebSphere application Server, but it can also be a different identity for some user applications.

longname

The full name of the record component that emitted the message or tracked the event. This is typically the standard class name for the internal components of WebSphere application Server, but it can also be a different identity for some user applications.

EventType

A character field that indicates the message or trace event type. 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

Configuration messages.

D

Detailed information message.

O

Writes System.out messages directly through a user application or internal component.

R

Writes SYSTEM.ERR messages directly through a user application or internal component.

Z

A placeholder indicating a type that is not recognized.

Class name

The class that emits the message or tracks the event.

Method name

The method that emits the message or tracks the event.

Organization

An organization that has applications that emit messages or track events.

Products

A product that emits messages or tracks events.

Component

A component within a product that emits a message or tracks an event.

Basic Format

Message events displayed in basic format use the following format. Symbol <name> indicates that the required fields 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.

<timestamp><threadId><shortName><eventType>[className][methodName]<message>

Advanced format

Message events displayed in advanced format use the following format. Notation <name> A required field that indicates that it will always appear in the advanced format of the message entry. The notation [name] is used to indicate which optional or conditional fields will be included, if they can be determined.

<timestamp><threadid><eventtype><uow><source=longname>[classname][methodname] <organization><product><component>[thread=threadname]

<message>

Configuring the JVM log

Use the management console to configure the JVM log for the application server. The configuration changes made to the JVM log to run the application server will not be applied until the application server is restarted the next time.

The steps for this task

Start the admin console

Click Troubleshooting > logging and Tracing , and then click the server > JVM log .

Select the Configuration tab.

Scroll through the panel to display the properties of the log that 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 settings for the Java virtual machine (JVM) System.out and System.err logs.

To view this Management console page, click the Troubleshooting > Logging and Tracing > server name > JVM log.

View and modify the settings for 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 stand-alone log files. The System.out log is used to monitor the health of running application servers. The System.err log contains exception stack trace information that is useful for performing problem analysis. Each application server and all its applications have a set of JVM logs. JVM logs are also created for Deployment Manager and 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.

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 Run Time 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 used by the running server requires read/write access to that directory. If the directory does not exist, it will be created with the appropriate permissions. The user identity 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 from the write inflow. Specifies that dev/null is not equal to redirecting the stream to a UNIX system.

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

1. On the management 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 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 log self management capabilities that configure the System.out or System.err log files to be self managed by using this set of configuration properties.

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

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

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, in megabytes, of the file. 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 based on the time of day. The file scrolls at the time specified in the Start Time field.

Start Time

Specifies the time of the first boot cycle algorithm after the application server restarts, that is, the number of points in the day (from 1 to 24). The algorithm starts the fashion entry in the application server. Once the scrolling algorithm starts 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 is stopped.

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

Repeat Time

Specifies how many hours (from 1 to 24) The interval is to be scrolled.

Repeat Time

Specifies how many hours log files are scrolled each time. Valid values range from 1 to 24.

Configure log files to scroll by time, by size, or by time and size. Click the file size and time to scroll the file when the criteria are first matched. For example, if the recurrence field is 5 hours and the maximum file size is 2 MB, the file scrolls 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 at intervals.

maximum size of history log file

Specifies the number of history (scrolled) files to save. The stream will be written to the current file until it scrolls. When scrolling, closes the current file and saves the file with a new name consisting of the current name plus the scrolling 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 segment. The next scroll deletes the oldest history file.

the output of the installed application

Specifies whether to record and format System.out or SYSTEM.ERR print statements issued by the application code.

Show application Print Statements

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

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 Run Time 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 used by the running server requires read/write access to that directory. If the directory does not exist, it will be created with the appropriate permissions. The user identity 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 from the write inflow. Specifies that dev/null is not equal to redirecting the stream to a UNIX system.

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

1. On the management 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 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). Concluding remarks

The JVM log is very important to our analysis and tracking of the problem. WebSphere application Server's powerful log self management feature makes our daily work easier and easier, and learning and mastering these features is beneficial to our managers. reference materials

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 Products Redbook

L WebSphere Application Server V6 Scalability and Performance Handbook Products Redbook

about the author

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