websphereapplicationserver问题诊断.docx

第一章 websphere问题类型：
1. 不能migrate Websphere Application Server或者不能安装应用程序。
2. WAS管理和配置方面的问题。
3. 一个应用程序或者websphere application server进程不能启动。
4. 应用程序不能响应用户请求。
5. 一个应用程序处理后得到unexpected results（errors/exceptions）。
6. 应用程序无法连接外部系统或资源。
7. 应用响应缓慢或者随着时间推移性能下降。
预防问问题几种途径：
1. 查询IBM官方网站的APAR，下载产品问题补丁，升级产品以便预防问题。
2. 检查was基础硬件和软件环境，确保满足was运行的基本需求。
3. 对部署在was上面的应用做全面的测试。
4. 维护一套同生产环境完全相同的一套测试环境（硬件、网络……）。
5. 定义一套安全的操作流程。确定具体角色的明确职责。
6. 领用V6以后的版本“集群”的新特性，解决高可用和容错管理。
7. 通过监控预防问题发生。
8. 记录应用运行环境下的所有变化。
9. 为问题诊断收集数据
发生问题的时候作什么
1. 恢复成长的生产环境
2. 鉴别问题症状
a.观察到的问题具体症状是什么？是否有报错？应用程序是否产生了一个unexpected result？应用是否对所有请求都不予响应了？
b.问题发生的上下文是什么？用户是否执行什么特定操作？是否在一个异常的高负载情况下发生的问题？是否在应用重启之后就发生了问题？
c.如何知道这种问题何时产生？是否有一个标志性的特征表明问题再次发生？
d.如何知道问题已经解决了？是否不会再产生其他的错误信息了？应用程序的行为是否变化了？怎么显式地证明问题已经解决了？
e.问题出在哪个部分？问题是否只在测试环境出现，或者只在生产环境出现，或者两套环境都出现了？问题是否只在一套系统出现？是否在多套系统环境中都出现了这个问题?问题是出现在集群的每个成员还是只出现在其中的一个成员上？
f.问题什么时候产生？发生问题的和健康状态的时间分解点是什么时候？问题发生了一次还是多次？问题的发生频率？是定期发生还是时间点上没有规律？是否有什么事件引发问题？
g.问题可能因为什么发生的？是否有有什么特殊功能是第一次用到的？最近是否改过程序或者配置是否有所改变？如果只在一套环境中发生，这套环境与其他环境有什么不同？
h.问题诊断数据是否收集了？诊断数据是否提示了问题所在？
3. 调查研究问题。
4. 问题处理策略。
将问题分类并找出问题的根本原因
开始问题分析之前首先要对问题进行分类，确定问题是否属于以下几个类别：
第二章 安装同迁移过程中的问题
安装websphere application server有问题、创建概要文件有问题、验证测试（install verification tests——IVT）有问题。安装过程中的问题场景：
问题一：launchpad或者installation wizard不能启动或者是启动后立即失败
launchpad：显示可执行的任务
常见问题：
没有可支持的浏览器，浏览器的配置不对，硬盘空间不够。
场景：
Launchpad or installation wizard不能启动或者失败
具体场景包含：
a.执行launchpad.bat命令或者launchpad.sh不能启动launchpad。
b.从launch界面选择launch the installation wizard for webshpere application server 不能启动installation wizard或者wizard 没有报错就退出了。
可能原因：
web browser requirements and 磁盘空间需求 或者文件权限需求。
收集错误信息：
The launchpad log：
-UNIX /tmp/IBM_Websphere_launchpad/IBM_Websphere_LaunchPad_log.txt
-WINDOWS %TEMP%\IBM_Webphere_launchpad\IBM_Websphere_Launchpad_log.txt
也许launchpad出现异常过早，还没有launchpad log产生。关注wizard退出之前提供的任何信息。
The installation log： /logs/log.txt
如果安装过程退出过早，还没有产生这个文件，可能存在系统的临时区域，%TEMP%\log.txt(windows)或者/tmp/log.txt(UNIX)。如果此文件文件不存在，从命令行运行install命令使用-log选项创建一个包含所有event
-unix：./install –log !logfile @ALL
-windows：install –log !logfile@ALL
问题诊断：
很多launchpad或者installation wizard往往是因为系统和软件的prerequisite没有达标，首先需要确认这些信息都已经准备好。在如下链接：

如果之前所述两个log文件没有产生或者没有错误解释说明。确定你有一个受支持的浏览器并且正常配置。
安装介质的目录下log.txt文件记录安装状态，包含：INSTCONFSUCCESS,INSTCONFPARTIALSUCCESS,INSTCONFFAILED，记录了当前安装状态。如果包含INSTCONFPARTIALSUCCESS,INSTCONFFAILED，应该在之前会有错误的提示信息（如磁盘空间不够，JVM异常，segmentation faults-段错误）
例如：如下信息指出了磁盘空间不足，installer无法运行，注意这不同于准备安装websphere application server的目录，即使打算安装websphere application server的目录有足够的空间也可能会报这个错误。需要确认C:\Temp或者%TEMP%（windows）或者/tmp目录（UNIX）有足够的空间来保证installer的运行。需要对照安装文档决定临时磁盘空间需求的确切大小，一般最小建议值为100M：

或者可以通过使用 –is:tempdir运行installation wizard。可以通过这个选项指定具有足够空间的临时目录。
问题二：installation wizard hang住
installShield wizard：预检查（pre-requisites）、处理安装过程的各个部分（解压、安装、复制等等）、部署配置信息。
常见问题：
资源不足（磁盘空间、虚拟内存）、JVM虚拟机的问题
installation wizard hang住的原因：
a. 系统资源过低（如虚拟内存、swap sapce）
b. 网络负载过高可能是引起远程安装installation wizard hang住的一个原因
c. 一个任务或者线程可能进入了无限等待或者循环
数据收集：
installation hangs检查以下两个日志：
a./logs/log.txt不存在这个文件的话查看%TEMP%\log.txt或者/tmp/log.txt如果需要理出所有需要的信息使用-log选项运行安装程序。
b./profiles//logs/pctLog.txt这个log文件在创建profiles的wizard执行过程中被创建。这个log在使用wasprofile命令创建profile的过程不产生。
问题诊断：
还是查看log.txt查看安装状态。如果安装失败或者部分成功。一定会有提示信息。同时查看系统活动情况，包括CPU利用率、磁盘使用情况、网络负载（如果远程安装）确保不是外部资源影响安装过程。如果安装过程看起来hang住了主意观察log文件中的最后一条记录。这条记录提醒你安装挂起前在做什么。
安装过程有两部分：一部分是一个copy线程，另一部分是一个profile创建线程。这个过程在ND版本中分离开来。但是在简易版和单机版中是不可选的。
如果log.txt中文件出现以下信息表明copy process已经成功完成。如果不是查找日志，观察错误信息。

如果没有看到log中（log.txt express ；pctLog.txt ND）有如下信息，说明在创建profile的过程中出现了错误。

如果已经有这条记录，重新评估问题”the next step”。
问题三：创建概要文件有问题
profile creation wizard：创建一个新的application server，deployment manager，custom profile
常见问题：
路径过长、文件的权限问题、主机名问题、端口冲突
数据收集及问题诊断：
/logs/wasprofile/wasprofile_create_.log这个日志文件在三种情况下均被创建：a.完成copy线程，开始创建一个默认profile。b.使用profile creation wizard或者wasprofile命令均产生上述日志。
上述日志格式为xml格式的，类似于如下格式：

/logs/log.txt
如下日志被创建在/profiles//logs文件夹：
pctLog.txt尽在profile creation wizard 创建的时候执行。使用wasprofile或者安装产品的时候默认创建profile不产生这个日志文件。
amjrte_config.log Tivoli Access Manager JAVA RUNTIME的配置文件
collect_metadata.log 收集关于管理对象的metadata information，用来避免安装冲突。
createDefaultServer.log wsadmin产生的日志记录创建默认默认profile中的server1的相关信息。
createshortcutforprofile.log Windows tool log for creating menu entries and shortcuts.
defaultapp_config.log JACL script log from configuring default application resources.
Service.log Start and stop events for server1.
Application installation and configuration logs for system and sample
applications:
– filetransfer_config.log for the file transfer application
– ivt_config.log for the ivtAPP application
– mejb_config.log for the ManagementEJB application
– hamanager_config.log for the high availability application
– query_config.log for the Query application
– samples_config.log for the PlantsByWebSphere sample application
– samples_install.log for the SamplesGallery and PlantsByWebSphere
sample applications
– scheduler.cal_config.log for the SchedulerCalendars application
– webui_config.log for the administrative console application
– defaultapp_deploy.log for the DefaultApplication application
_ SIBDefineChains.log
Creation log for service integration bus endpoints, inbound channels and
channel chains, outbound thread pool, and outbound channel and channel
chains.
_ SIBDeployRA.log
Deployment log for the service integration bus function.
_ winservice_config.log
Service log for the Windows service created for server1.
_ addNode.log
Log for federating a node to a cell (Custom profile).
下面这个图示表示profile创建成功。如果没有如下信息，表明创建概要文件的时候有问题。

如果看到下面这样的信息，查看wasprofile_create_.log文件。查看创建profile过程。

问题四：IVT有问题
installation verification tool：验证安装是否成功。查看server的profile configuration，并且在特定的端口上寻找运行在server port number上的一个server。如果相应的端口上已经有一个server，IVT会直接检查那个server，即使那个server不是你新创建的那个。如果没有启动的server，IVT会尝试首先启动刚刚创建的porfile中的server。进行各种检查，包括servlet引擎验证，JSP验证，EJB验证等等。一般创建完profile都推荐使用IVT验证一下。如果验证通过，问题后来再发生一般是由后续的配置引起的问题。
常见问题：
server由于端口冲突造成的启动问题、应用程序堆内存分配过小等资源不足的情况。
数据收集及问题诊断：
_ /profiles//logs/ivtClient.log
This log contains messages from the IVT execution.
_ The following log files created in:
/profiles//logs/server1 directory
They are created as a result of the IVT and start/stop of server.
– startServer.log - Log of start server events
– SystemOut.log - Log of all activity within the WAS environment
– SystemErr.log - Record system errors
IVTL和ADMU标签后面的信息标识IVT运行状态。
如果发现以下记录信息

表明server已经成功启动了，但是IVT的某项test失败了。查看ivtClient.log里面的错误信息定位错误。
如果是另外一个DM在相同端口启动，你应该会看到以下信息。

如果server一直没有启动，查看server port number。确保这个端口没有被占用。如果感觉不是端口的问题，查看startServer.log SystemErr.log SystemOut.log，如下信息：
a.查看所有以WSVR（server runtime）或者ADMU（management utility）开头的信息（在startServer.log和SystemOut.log中）
b.查看SystemErr.log这个信息是以如下格式记录的：

安装过程中存在INST、ADMU（创建概要文件过程中）、WSVRT（IVT过程中）
小结：分析定位问题
通过分析问题，将问题定位到以下几个方面。
一 web browser requirements
如果不能启动launchpad，有可能是因为没有支持的web浏览器或者浏览器没有被正确的配置。
If you are having problems in starting the launchpad, it is possible that you do not
have a supported Web browser installed or configured properly. If this is the
case:
_ 确保已经安装了最新被支持的浏览器版本。安装和配置需要Mozilla and IE浏览器。
_ On UNIX platforms, ensure that the location of the supported browser is exported. For example if the Mozilla executable is located in the /usr/bin directory, then export its location as follows:
export BROWSER=/usr/bin/mozilla
_ Ensure that JavaScript™ is enabled in the browser options or preferences. For example:
– In Mozilla, select Edit → Preferences → Advanced → Scripts & Plugins - Enable JavaScript for: Navigator, Allow Scripts to: (select all boxes)
– In Internet Explorer, select Tools → Internet Options → Security → Custom Level for Internet Scripting → Active scripting → Enable
二 Application server startup problems
首先要确保各个profile被创建的时候各个websphere application server service的端口是唯一的。（同时也要确保这些端口不同其他软件的端口冲突）
IVT验证过程中如果server没有启动，或者使用startServer启动server的时候如果看到如下信息：

表明另外一个server已经在相同的端口被启动。

如果遇见如下信息：

表明下面这个文件中为listener thread声明的Port number不能使用
/profiles//config/cells//nodes//serverindex.xml
为了解决这个问题使用如下方法：
1. 使用serverStatus命令确定相应的server是不是已经被启动了。
2. 检查application server process需要的端口，如下文件中标识的端口。
3. /profiles//config/cells//nodes//serverindex.xml
4. 列出系统当前占用的端口netstat –a命令，如果存在端口冲突，修改serverindex.xml中相应的端口保证不再发生端口冲突。
三 Profile creation problems
File path length errors
windows2000限制命令最长不超过258个字节。路径的最长长度是60个字节。profiles创建路径（root directory）的最长路径是80个字节。
如果日志文件中提醒”Input line is too long”，可能是因为文件路径或者是node name过长引起了整个创建或者配置命令长度超过操作系统的限制而引起的错误。
若果使用图形界面，这个错误应该是被展示在a message box during the wizard，如果使用wasprofile命令，错误信息被记载在/profiles//logs/collect_metadata.log文件中.
解决方法：使用短路径名和短node名重新创建profile。如果还在安装阶段，建议使用短路径名重新安装。
Host name error
如果发现” localhost is not a valid host name for remote access”信息，是因为在提示框提示输入主机名的时候使用“localhost“作为了主机名。网络环境中的其他主机不能根据localhost这个主机名查找到这台主机。所以在需要输入主机名的步骤，需要使用网络中的主机名。
Template path error
如果在UNIX环境中发现如下错误，需要检查具体所选择的模板路径和权限是否符合要求：

Custom profile error
如果创建custom profile时候出现问题，需要查看addNode.log文件。查找更多的错误信息。例如如下错误：

如果发现上面这条提示信息，看起来是因为DM profile没有启动。在创建custom profile之前需要确保dm已经在特定的端口正常运行。
第三章 迁移问题
待填充
第四章 系统管理和配置问题
管理问题诊断主要针对以下几个场景：
1. 不能访问管理控制台。
2. 不能使用wsadmin或者管理脚本（例如：stopServer）访问server进程。
3. 执行管理任务时出错（如管理application servers , node agents , Web servers 或者applications）。
4. 不能将一个node federate到deployment manager。
5. 管理控制台提示save conflict messages。
6. 企业应用程序突然从管理控制台消失（不显示）。
7. websphere rapid deployment问题。
8. 使用SSL进行通信的时候有问题，收到信息成证书过期提示信息。
介绍
本章主要解决管理WAS过程中的问题。WAS配置主要靠XML文件维护。XML文件文件的保存结构如下图：

overview of system administration
WAS的管理控制台和wsadmin命令read,maintain,and modify这些XML文件。建议对刚装完WAS的基础config repository进行备份。可以直接使用文件系统提供的拷贝方式备份，也可以使用WAS提供的backupConfig命令进行备份。backupConfig命令提供一个zipped文件包含所有配置文件。
V6版的stand-alone一个典型配置文件保存结构如下图所示

the config directories and files
管理控制台通过调用management beans（MBeans in the websphere application server process）完成管理功能。
在ND环境中，deployment manager维护自己所在cell下的所有WAS节点和server的master repository。每个节点上保存一份这些管理文件的副本（同步操作）。
下图是一个带有两个节点的ND环境，所有和Node1，Node2和DM相关的配置文件都保存在一起。同Node1相关的配置文件被拷贝到Node1上，同Node2相关的文件被复制到Node2上。每个node都包含一份所有节点的serverindex.xml文件，因为这个文件中包含其他节点的连接信息——主机名&端口号。

可以将节点配置为自动或者手动同步

只有修改过的文件才会被同步，所以如果你的系统即使每分钟自动同步一次（默认内部值），也不会对系统其他性能有影响。node agent只是连接到deployment manager并且被告知没有什么需要更新的。
可以自己手动同步：

Synchronlze只是同步通过控制台所作的配置更新。
Full Resynchronlze将通过文件编辑器直接编辑xml文件的改变也同步到节点上。
也可以通过节点端使用syncNode.bat|sh脚本进行同步操作。

安全
如果你启动了global security选项，就同时secure了administrative console，all administrative interfaces（包括wsadmin和各种management scripts）。（例如：启动和停止服务器都需要使用用户名和密码）。可以选择性地修改下面两个文件中的一个，这样进行命令行和脚本管理的时候不需要输入用户名和密码。（安全方式提供两种认证本地认证和LDAP，当多台服务器需要安全认证的时候使用LDAP进行认证）
/profiles//properties/sas.client.props
/profiles//properties/soap.client.props
第一个文件被调用RMI同application server进行通信的方法调用。
第二个文件被使用SOAP同application server进行通信的方法调用。wsadmin使用SOAP作为默认的通信方式。
WebSphere Rapid Deployment
simplifies and speeds up the process of deploying enterprise applications or their components for development purposes
WebSphere Rapid Deployment是一个前台处理线程，他监视一个特定的文件夹。如果developer将一个企业应用程序的EAR文件放在这个文件加下，WebSphere Rapid Deployment可以自动发现并部署他。WebSphere Rapid Deployment 也可以监视文件下的应用程序组件（不一定必须是完整的EAR，例如：可以通过一个JSP更新现有的应用程序或者创建一个应用程序）

WebSphere Rapid Deployment components
数据收集
为了问题诊断，你需要收集如下log文件。
_ WebSphere Application Server logs
_ wsadmin output
_ Management script logs
_ Profile management logs
_ WebSphere Rapid Development logs
WebSphere Application Server logs
Stand-alone server
In a stand-alone server, the administrative console application and the
administrative MBeans run in the server process. So, you need to look at the logs
for that application server. The log files are:
/profiles//logs//SystemOut.log
/profiles//logs//SystemErr.log
Deployment manager
In a Network Deployment installation, system management involves more than
one application server process. So, you need to look at the logs for each
component. The deployment manager logs are:
/profiles//logs/dmgr/SystemOut.log
/profiles//logs/dmgr/SystemErr.log
Node agent
Node agent log files are:
/profiles//logs/nodeagent/SystemOut.log
/profiles//logs/nodeagent/SystemErr.log
Application server
With some problem types, you might also need to look at the logs for the
application server that you are trying to manage. These log files are:
/profiles//logs//SystemOut.log
/profiles//logs//SystemErr.log

如何配置tracing:
控制台配置
For more detailed information about how to set up tracing, see the WebSphere
Information Center section, Configuring logging properties using the
administrative console, at:

websphere.base.doc/info/aes/ae/ttrb_configjavalog.html
wsadmin配置
You can also set trace strings using wsadmin. For further details, see the
WebSphere Information Center section, Tracing operations with the wsadmin
tool, at

websphere.base.doc/info/aes/ae/txml_traceadmincontrol.html
可以手工修改server.xml配置tracing
If you cannot connect to the WebSphere administrative console or wsadmin, you
can set tracing by updating the server.xml file for the application server that you
need to trace. You can find the server.xml file under the server’s entry in the
configuration file directory structure:
/profiles//config/cells//nodes//servers/
/server.xml

修改server.xml需要重启server。
wsadmin output
wsadmin操作的记录被记录在wsadmin.traceout日志文件中：
/profiles//logs/wsadmin.traceout
可以通过修改如下文件，丰富日志内容：
/properties/wsadmin.properties
（把“com.ibm.ws.scripting.traceString=com.ibm.*=all=enabled”的注释去掉，这个日志的内容用处有限。）
Management script logs
每个管理脚本运行的过程都会记录自己的日志，例如stopServer记录
/profiles//logs//stopServer.log
Profile management logs
wasprofiles命令记录如下日志
/logs/wasprofile/.log
解决问题
首先通过显式现象进行初步诊断显式现象是否能够定位问题。如果不能则需要收集适当的数据进行问题分析。
问题一：不能访问管理控制台
访问管理控制台返回空白页面或者HTTP 404 ERROR/page not found error。可能在下面几个时间点发生这种错误：
1. 刚刚装好websphere application server
2. 开启安全性
3. add a node to DM
4. 重启websphere application server
收集日志，ND环境下the process run i