级别： 初级 Daniel Julin (dpj@us.ibm.com), WebSphere 服务能力技术领域负责人, IBM India Software Lab Services and Solutions
2007 年 9 月 27 日 
现在，您可以对您的环境进行 12 项工作，以便在出现问题的时候可以更快速、且更有效地进行故障诊断，而不是重点关注于在问题发生以后所需要进行的工作。
来自 IBM WebSphere Developer Technical Journal。
在每个专栏中，支持权威将讨论 IBM Technical Support 的可用于 WebSphere 产品的资源、工具和其他要素，以及一些可以进一步增强您的 IBM 支持体验的技术和新思想。
最新快报
按照惯例，我们将首先提供关于整个 WebSphere® 社区的一些重要新闻：
-
IBM® Guided Activity Assistant Version 3.1
刚刚发布，并且随着这个版本的发布，IBM Guided Activity Assistant 成为了一种获得充分支持的问题确定工具。它还包括改进了的用户界面和许多新功能。
-
对
IBM Support Assistant
中三种可用的问题确定工具进行了更新：
-
IBM Dump Analyzer for Java™
用于检查 JVM 系统转储的内容，并对最常见的问题和 JVM 的整体状态进行诊断。
-
Extensible Verbose Toolkit (EVTK) 用于检查 JVM 详细的垃圾收集日志，并对垃圾收集的问题进行诊断。
-
IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT) 用于检查 JVM 详细的垃圾收集日志。（对于这个新的发布版，IBM Support Assistant 中 PMAT 的版本与 alphaWorks 中的可用版本是相同的。）
-
上一次，我们介绍了
Fix Central
，它是一个集中的网站，以方便对众多 IBM 产品进行查询、下载和安装修复程序。WebSphere Application Server 刚刚加入到使用 Fix Central 的产品家族中。
继续关注与支持相关的各个网站以及本专栏，以获得有关我们所碰到的其他工具的新闻。
接下来让我们继续今天主要的主题……
为实现更灵活的故障诊断进行仔细地准备
当讨论用于故障诊断和问题确定的技术和工具时，通常大多数的讨论都是关于发现问题之后所要进行的工作。然而，理想情况下，谨慎的系统管理员或者故障诊断者应该早在问题发生之前就开始思考这项工作；换句话说，将环境准备好，以便在问题最终出现时可以更快速并且更有效地执行故障诊断。
本文提出了十二项建议，您可以实现这些建议以帮助提高解决问题的速度，即使是在最复杂的生产环境中。这个建议列表，既不是权威性的、也不是绝对的，它基于对客户端环境的常规观测结果和 IBM WebSphere Support 所发现的问题。然而，每个环境都有其独特的因素和约束，而它们可能使得这些建议中的某些内容更加（或者更不）实际或者适用。在您对这些（以及其他）操作进行评估时，可以为您的环境构建一个自定义故障诊断计划，并使用这个列表作为您的起点。即使您不可能充分地实现这个列表中的每一条建议，但是您所采用的每个步骤仍然可以为您节约时间，并且行之有效：
-
创建并维护系统体系结构图
-
创建并跟踪所有问题确定构件的目录
-
特别注意仅在问题出现时才生成的转储和其他构件
-
查看并优化正常运行期间的诊断级别
-
监视底层操作系统和网络度量
-
准备好在出现问题的时候主动生成附加诊断信息
-
定义诊断信息收集计划，并实施它
-
建立基准
-
周期性地清除、存档或者清理旧的日志和转储
-
消除日志中虚假的错误和其他干扰信息
-
保存更改日志
-
为正在运行的系统设置运行状况监视
接下来的部分将详细地说明以上的每个步骤。
1. 创建并维护系统体系结构图
体系结构图显示了整体系统的所有主要组件（一些计算机和正在这些计算机中操作的软件组件），它们如何通信，以及系统中处理相关请求的主要流程。对于简化和加速许多与故障诊断相关的任务，使用一个好的、且最新的体系结构图是非常有帮助的。特别是，系统体系结构图可以帮助您：
- 确定在系统中寻找相关信息或者线索（关于导致问题发生的原因）的位置。
- 在您的组织内部以及在尝试向 IBM Support 说明复杂环境的时候，需要在故障诊断任务所涉及的各个部门之间进行清晰地交流。
- 回答并验证所有的故障诊断者都特别喜爱的一个问题：最近发生了什么更改？
体系结构图应该明确，并且足够简洁，以便人们能够快速理解。特别是，它应该尽可能地显示每个软件组件的实际当前版本，以及所有硬件组件的名称和地址。
2. 创建并跟踪所有问题确定构件的目录
故障诊断活动最初常常重点关注于寻找和检查各种问题确定构件（如日志文件、转储文件等文件），这些构件是在问题出现前或者出现时生成的。它需要提前知道要寻找哪些文件、它们位于何处，并要确保确实正确地生成了它们，并且在需要的时候它们将是可用的。
为您系统中所有重要问题确定构件建立目录：
- 说明每个文件用于什么情况、它的名称、位置、目的、典型内容及其大小。在这种情况下，使用系统体系结构图是非常方便的，因为它可以帮助您检查整个系统，以及可能产生有价值问题确定构件的所有组件。
- 不要仅满足于“知道”该构件的存在。尽管从理论上讲，可以对所有内容进行设置并进行记录，但是没有任何东西可以替代实际测试来验证该原则。周期性地检查此活动系统，以验证所有期望的日志文件和其他构件被照常写入。
- 确保有足够的磁盘空间（在适当的位置），以便继续写入所有相关的诊断文件，并接收在事故期间可能生成的任何其他文件。
- 请确保不要太快地清除您的构件。如果出现了事故，您可能需要回过头去查阅在检测到该事故之前的数小时内所生成的日志文件。特别是，请确保在事故后重新启动系统时，不会意外地删除或者覆盖这些文件。
| 您可能需要考虑的问题确定构件 |
|---|
|
对于每种不同的环境、产品集以及您所使用的应用程序，相关构件的集合也不相同。一些最常见的构件包括：
- 与 WebSphere Application Server 相关的所有标准日志文件：activity.log、SystemOut.log、SystemErr.log、native_stdout.log、native_stderr.log 等等。
- WebSphere Application Server 中的第一次失败数据捕获（First Failure Data Capture，FFDC）工具的事故文件。
- Web 服务器的日志文件：access.log、error.log。
- 构建于 WebSphere Application Server（如 WebSphere Portal、WebSphere Process Server 等等）之上的所有产品的日志文件。
- 其他与主要的应用服务器进行交互的组件的任何日志文件，如防火墙日志、数据库服务器日志和 LDAP 目录服务器日志。
- 由应用程序显式地产生的任何日志文件。
- 由 Java 虚拟机产生的日志文件和转储：javacore 或者 java 转储、堆转储和系统转储（核心文件）。
|
3. 特别注意仅在问题出现时才生成的转储和其他构件
在查看问题确定构件的时候，人们常常更多关注于日志文件，这些日志文件通常是在系统的整个生命周期中不断生成的。请记住，还有许多非常有价值的问题确定构件，它们仅在问题出现的时候才生成，或者由系统自动生成，或者由管理员的某项特殊操作而生成。
| 仅在问题出现的时候才生成的构件的示例 |
|---|
- 在很多情况下，JVM 可以生成 Java/线程转储、堆转储和系统转储。
- 某些 IBM 产品可以生成其内部状态的各种其他转储类型的数据。例如，WebSphere Application Server 提供了一个第一次失败数据捕获 (FFDC) 工具和一个诊断信息提供者工具。
- 某些 IBM 产品在碰到特定的问题时，还可以生成特殊的跟踪文件（自动地生成、或者按需生成），而无需重新启动系统。
|
在大多数情况下，提供了各种配置选项以控制如何以及何时生成这些构件：
- 对于在检测到问题的时候可以自动生成的任何文件：如果自动地产生这个文件，并且对配置进行相应地设置，那么请仔细考虑这项操作潜在的好处（和影响）。不要遗漏这个问题。如果潜在的好处很大，而影响很小，那么请确保启用这一功能。
- 对于可能由管理员的特定操作而生成的文件：通常在执行特定操作之前，该文件对系统只有很小的或者根本没有影响。如果可能，做好必要的准备和配置更改，以确保该操作在需要的时候是可用的，并进行测试以确保它能够按预期进行工作。
4. 查看并优化正常运行期间的诊断级别
有效的服务能力始终是一种折衷。一方面，为了尽最大可能在问题第一次出现时确定导致该问题的原因，您希望在任何时候都不断地收集系统的尽可能多的诊断数据。但是收集非常详细的诊断信息（例如，始终启用跟踪功能）可能导致性能开销的提高。因此，出于性能方面的原因，您可能希望在系统正常运行期间禁用所有诊断功能。您需要在这两个矛盾的目标之间找到适当的平衡。
在缺省情况下，大多数产品和环境往往因为过于保守（始终启用相对较小的诊断集）而出现错误。如果在系统投入运行之前，不需要任何人查看启用的诊断集，那么这就可能是一种正确的方法。然而，作为设计的主动故障诊断计划中的一部分，检查您的特定环境的特定约束、特定问题的可能性和特定性能需求是非常必要的，然后在正常的稳定状态期间启用尽可能多的附加诊断。
| 可能需要启用的附加诊断 |
|---|
- JVM 的详细垃圾收集日志：通常是非常有用的，并且在优化的系统中通常只需要较低的开销。
- JVM Java 转储、堆转储和系统转储：Java 转储的生成开销通常比较低，并且可以为其启用自动生成。堆转储和系统转储可能需要相当大的开销，因此在将它们设置为自动触发之前，请先仔细地考虑清楚。
- HTTP 服务器中增加了请求日志，以便在为每个请求显示单个日志条目的同时，还可以在每个请求的开头和结尾显示一个分离的日志条目。
- WebSphere Application Server Performance Monitoring Infrastructure 提供的中级监视性能计数器。
- 最小的 WebSphere Application Server 跟踪，以便仅为每个事务（Web 请求或者 EJB 请求）捕获一个或者少数几个条目。
- 应用程序级跟踪和日志记录，如果有的话。
|
5. 监视底层操作系统和网络度量
在查找诊断信息的时候，通常倾向于重点关注日志、转储和其他与失败组件或者应用程序直接相关的文件，但是基础硬件、操作系统和网络通常也可以提供一些有价值的信息，用于跟踪问题的来源。
| 系统级度量 |
|---|
- 整台计算机的整体 CPU 和内存使用情况。
- 单个进程的 CPU 和内存使用情况，该进程是某个应用程序中的一部分（或者是该应用程序所依赖的进程）。
- 分页和磁盘 I/O 活动。
- 各个组件之间的网络通信速度。
- 检查各个组件之间网络连接性的降低或者整体损失。
|
有些度量常常受到忽视，或者仅在复杂问题研究过程的后期才加以考虑，然而它们中的许多内容都比较简单、并且易于捕获。在某些非常困难的情况下，特别是与网络相关的问题，这些信息常常在跟踪问题来源的任务中扮演重要的角色。
当然，要永久性地监视每个单独的系统级度量并不实际，但是在可能的情况下，可以定期地对一个轻量级的系统级度量集进行监视，以便您能够在问题出现之前（捕获问题的发展）和问题出现时获得相关的数据。根据您的软件环境，您可能可以访问各种操作系统工具或者专用的系统管理工具（如 IBM Tivoli® 产品套装），以便对监视工作提供帮助。如果没有这些工具，那么您可以编写一些简单的命令脚本，以便周期性地运行和收集最有价值的统计信息。
6. 准备好在出现问题的时候主动地生成附加诊断信息
除了处理事故发生时所出现的诊断构件之外，您的故障诊断计划还应该考虑在数据消失或者重新启动系统之前需要执行的任何附加显式操作（一旦检测到事故，需要执行该操作以获取附加的信息）。
| 生成附加诊断的显式操作的示例 |
|---|
- 主动地触发各种系统转储，如果还没有自动地生成它们（如 Java 转储、堆转储、系统转储、WebSphere Application Server Diagnostic Provider 转储、或者可能由各种产品和应用程序提供的其他转储）。例如，当一个系统被认为处于“挂起”状态时，可以为每个受到影响的 JVM 进程收集三个连续的 Java 转储，这是一种很常见的做法。
- 捕获重要的操作系统度量的快照，如进程状态、大小、CPU 使用情况等等。
- 启用并收集来自 WebSphere Application Server Performance Monitoring Infrastructure 的信息。
- 当系统当前处于非正常状态时，动态地启用一个特定的跟踪，并按给定的时间间隔收集该跟踪信息。
- 主动地测试或者查验系统的各个方面，以观察与常规的情况相比，它们的行为发生了什么样的更改，以试图在多组件系统中隔离问题的来源。例如：
- 绕过 Web 服务器，直接发送一个 HTTP 请求到应用服务器；或者绕过应用服务器，直接对后端数据库测试某些操作。
- 测试来自不同 WebSphere Application Server 集群成员的响应。
- 如果适用的话，测试该应用程序的不同功能，以观察它们是否受到了不同的影响。
- 选择性地重新启动应用程序或者系统的个别组件。
|
很明显，可能存在无数种这样的操作，并且您不可能执行所有的操作。相反，您必须尝试为系统预测最可能的故障模式，并决定在各种情况下，哪些操作最可能产生最有用的信息。对应用程序和系统体系结构进行仔细查看，这是一个重要信息来源，以便帮助您开始制定这样的计划，与 IBM Support 网站上的 MustGather 文档集一样。每个 MustGather 文档都适用于某一种特定的问题类型，并给出了在各种情况下需要收集的、推荐的诊断信息的明确指示。
7. 定义诊断信息收集计划，并实施它
假设您已经确定了可用于问题确定的关键诊断构件，并且已经确保这些构件是可用的、尽可能保证最好的质量，那么您还需要一个明确的、有良好文档记录的计划，以便在事故出现时实际地收集这些构件。当问题发生的时候，常常会出现混乱，以及将系统恢复到正常运行状态的巨大压力，从而产生各种错误，在故障诊断过程中导致不必要的延迟或者普遍的困难。制定一个操作计划，可以确保每个人都能够清楚具体的操作计划，并提前预演该计划的执行，这些都是非常关键的。
您的计划应该包含诊断构件的集合（它总是在问题发生时出现或者自动生成的），以及一组特定的操作（可以使用这些操作来生成附加的诊断信息，特别是在问题出现的时候），正如前面所建议的。
最简单的诊断收集计划可以采用简单的、手写文档的方式，该文档列出了必须采取的所有手工步骤的细节信息。要想更加有效，可以通过提供一个或者多个命令脚本（可以调用这些脚本以执行一组复杂的操作）、或者通过使用更完善的系统管理工具，尝试为这个计划中尽可能多的操作实现自动化。现在作为 IBM Support Assistant 的一部分提供了各种收集器工具和脚本，它们可以为您提供一个很好的框架，以便开始实现许多诊断收集任务的自动化。
8. 建立基准
“与昨天没有出现问题的时候相比，现在有什么不同呢？”
要帮助回答这个问题，您必须主动地收集并且维护一个基准：有关系统正常运行时的状态的广泛信息。
| 作为基准所包含的信息的示例 |
|---|
- 系统正常运行过程中具有代表性的一段时间（比如一整天）内的各种日志文件、跟踪文件等的副本。
- 一些 Java 转储、堆转储、系统转储、或者通常“按需”生成的其他构件类型的副本。您可以将这项活动与前面的建议相结合，以便在问题出现之前，在良好状态的系统中对这些构件的生成进行测试。
- 关于系统中正常事务的速度、响应时间等的信息。
- 在良好状态的系统中的各种操作系统级统计信息，如所有进程的 CPU 使用情况、内存使用情况、网络流量等等。
- 任何其他构件、信息、或者任何特殊诊断收集操作（前面所推荐的，用于各种预期的问题类型）的预期结果的副本。
|
请记住，可能需要周期性地更新这个基准信息。因为系统在不断地发展、负载在不断地发生变化，所以什么是“正常”状态的代表，通常在一段时间内并非一成不变。同样，如果系统经历了不同的活动周期（例如，在特定的日期或者一天中的某个特定时段），那么对于每个时期，可能需要收集不同的基准。
9. 周期性地清除、存档或者清理旧的日志和转储
这个列表中的一些其他建议表明，生成尽可能多的不同类型的诊断构件，并且尽可能地详细。虽然这看起来是矛盾的，但是大量的信息并不总是好的。在某些环境中，允许日志文件无限制地增长，或者旧的日志和转储文件不断地堆积，经过数月甚至数年。事实上，这很可能会妨碍故障诊断的过程：
- 可能要花费大量宝贵的时间对许多旧的信息进行排序（手动进行排序，或者使用扫描所有文件的工具），以找到当前的信息。
- 对于收集和传输问题确定构件的工具，如收集脚本，如果它们必须传输大量的、不必要的旧信息，那么它们的运行可能会慢得多。如果对于每个新的事故，每次都要传输相同的旧信息，那么将会更加糟糕。
- 在极端的情况下，由于累积大量旧的构件，系统可能会用尽所有的磁盘空间。
您的主要目标应该是在问题发生前和发生时，收集尽可能多的诊断信息。您还希望保存或者存档足够多的历史诊断信息，以作为进行比较的基准，并且在万一没有立即检测到某个问题的情况下，用于观察某些问题的缓慢堆积。但是应该将这种历史数据与当前问题确定构件分开进行保存，这样它们就不会互相干扰。
各种 IBM 产品，如 WebSphere Application Server，提供了自动清除或者轮转某些日志文件的功能。对于其他的日志文件和转储，则必须定期手动地存档或者清除。
10. 消除日志中虚假的错误和其他干扰信息
在 IBM Support 中，有时我们会发现系统和应用程序运行于生成大量错误消息的模式中，甚至在正常运行期间也不例外。很明显，这种良性的、或者常见的错误并不是非常重要，但是它们使得要在所有这些干扰信息中发现不正常的错误变得更加困难。为了简化将来的故障诊断工作，可以排除所有这些常见的错误，或者寻找一种方式来标记它们，以便能够轻松地将它们与重要的错误区分开来。
11. 保存更改日志
正如前面多次提到的，对于大多数故障诊断实践，其中一个重要的方面是在正常工作的系统和存在问题的系统之间找出它们的不同之处，并且使用基准是帮助解决这个问题的一种方法。另一种可以帮助您确定系统差异的操作是，准确地保存一段时间内系统中所应用的所有更改的日志。当问题出现时，您可以通过日志查看可能引起该问题的任何近期的更改。您还可以将这些更改映射到过去收集的各种基准，以确定如何采用这些基准来解释相关的差异。
您的日志至少应该跟踪所有的升级和软件修复（应用于系统中的每个软件组件），包括基础结构产品和应用程序代码。它还应该跟踪任何组件中的每项配置更改。在理想的情况下，它还应该根据系统的使用情况，跟踪所有已知的更改；例如，负载方面预期的增长、用户调用的不同操作的混合、等等。
在复杂的 IT 环境中（许多团队服务于该环境中不同的部分），要维护一个精确的、最新的和全局的更改日志，这项任务可能是相当困难的。您可以使用各种工具和技术来帮助完成这项任务，从使用简单的数据收集脚本（类似于那些用于收集诊断数据的脚本）收集配置的常规快照，到使用复杂的系统管理实用工具。
请注意，更改控制的概念，以及保存更改日志，通常比故障诊断所涉及的领域更加广泛。它也被认为是用于管理复杂系统以防止各种问题（而不是对它们进行故障诊断）的重要的最佳实践之一。
12. 为正在运行的系统设置运行状况监视
在大多数实际情况下，可能导致更大问题的一些小问题或者较大的问题，可能潜伏很久都不会被发现。或者，系统的整体运行状况或者性能随着时间的推移可能会慢慢地下降，直到最后导致出现严重的问题。很显然，您越早检测到出错的地方，您将有越多的时间和机会来收集有价值的诊断信息，并将其用于故障诊断。因此，制定连续监测系统整体运行状况的良好策略，是整个故障诊断计划中一个重要的部分。这可能包括前面已经介绍过的诊断数据的大量相同来源，区别在于，在这种情况下，您不仅希望收集这些信息，还希望对其进行周期性地扫描，以确保不存在任何问题，而不是等待来自外部的问题报告。同样，简单的命令脚本或者复杂的系统管理工具（如果可用的话）都可以用于帮助实施这种监视。
| 可进行监视的内容的示例 |
|---|
- 各种组件所生成的日志中的重大错误。
- 由每个组件产生的度量应该维持在可接受的规范内（例如，操作系统 CPU 和内存的统计信息、WebSphere Application Server 性能度量、应用程序的事务速度等等）。
- 仅在问题出现时自动生成的特殊构件，如 Java 转储、堆转储等等。
- 周期性地向各种系统组件或者应用程序发送“ping”，以验证它是否能够像预期的那样继续做出响应。
|
结束语
要在复杂的环境中正确地对问题进行故障诊断，您需要考虑许多因素和观点，并且对于不同的特定情况，具体的内容也不相同。我们希望，这个列表说明了准备工作将会带来回报，并为您开始定义自己的自定义故障诊断计划提供基础。
致谢
作者要感谢 Yu Tang 和 WebSphere SWAT 团队的所有其他成员，感谢他们提出了许多有价值的论述和见解，本文正是在此基础上提出了相关的建议。
参考资料 学习
获得产品和技术
讨论
关于作者  | 
| |
Daniel Julin 在开发复杂的联机系统及其故障诊断方面具有 20 年的经验。作为 WebSphere Serviceability Team 的技术领域负责人，他目前重点关注于帮助团队定义和实现一组工具和技术的集合，以协助确定 WebSphere Application Server 问题，并实现 IBM Support 工作效率的最大化。他有时候也直接为各种关键的客户支持情况提供协助。 |
对本文的评价
| 
