为有效进行产品故障诊断做好准备的 12 种方式（2）

look_w

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 文档都适用于某一种特定的问题类型，并给出了在各种情况下需要收集的、推荐的诊断信息的明确指示。
7. 定义诊断信息收集计划，并实施它假设您已经确定了可用于问题确定的关键诊断构件，并且已经确保这些构件是可用的、尽可能保证最好的质量，那么您还需要一个明确的、有良好文档记录的计划，以便在事故出现时实际地收集这些构件。当问题发生的时候，常常会出现混乱，以及将系统恢复到正常运行状态的巨大压力，从而产生各种错误，在故障诊断过程中导致不必要的延迟或者普遍的困难。制定一个操作计划，可以确保每个人都能够清楚具体的操作计划，并提前预演该计划的执行，这些都是非常关键的。
您的计划应该包含诊断构件的集合（它总是在问题发生时出现或者自动生成的），以及一组特定的操作（可以使用这些操作来生成附加的诊断信息，特别是在问题出现的时候），正如前面所建议的。
最简单的诊断收集计划可以采用简单的、手写文档的方式，该文档列出了必须采取的所有手工步骤的细节信息。要想更加有效，可以通过提供一个或者多个命令脚本（可以调用这些脚本以执行一组复杂的操作）、或者通过使用更完善的系统管理工具，尝试为这个计划中尽可能多的操作实现自动化。现在作为  的一部分提供了各种收集器工具和脚本，它们可以为您提供一个很好的框架，以便开始实现许多诊断收集任务的自动化。