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

look_w

8. 建立基准“与昨天没有出现问题的时候相比，现在有什么不同呢？”
要帮助回答这个问题，您必须主动地收集并且维护一个基准：有关系统正常运行时的状态的广泛信息。
作为基准所包含的信息的示例

• 系统正常运行过程中具有代表性的一段时间（比如一整天）内的各种日志文件、跟踪文件等的副本。
• 一些 Java 转储、堆转储、系统转储、或者通常“按需”生成的其他构件类型的副本。您可以将这项活动与前面的建议相结合，以便在问题出现之前，在良好状态的系统中对这些构件的生成进行测试。
• 关于系统中正常事务的速度、响应时间等的信息。
• 在良好状态的系统中的各种操作系统级统计信息，如所有进程的 CPU 使用情况、内存使用情况、网络流量等等。
• 任何其他构件、信息、或者任何特殊诊断收集操作（前面所推荐的，用于各种预期的问题类型）的预期结果的副本。

请记住，可能需要周期性地更新这个基准信息。因为系统在不断地发展、负载在不断地发生变化，所以什么是“正常”状态的代表，通常在一段时间内并非一成不变。同样，如果系统经历了不同的活动周期（例如，在特定的日期或者一天中的某个特定时段），那么对于每个时期，可能需要收集不同的基准。
9. 周期性地清除、存档或者清理旧的日志和转储这个列表中的一些其他建议表明，生成尽可能多的不同类型的诊断构件，并且尽可能地详细。虽然这看起来是矛盾的，但是大量的信息并不总是好的。在某些环境中，允许日志文件无限制地增长，或者旧的日志和转储文件不断地堆积，经过数月甚至数年。事实上，这很可能会妨碍故障诊断的过程：

• 可能要花费大量宝贵的时间对许多旧的信息进行排序（手动进行排序，或者使用扫描所有文件的工具），以找到当前的信息。
• 对于收集和传输问题确定构件的工具，如收集脚本，如果它们必须传输大量的、不必要的旧信息，那么它们的运行可能会慢得多。如果对于每个新的事故，每次都要传输相同的旧信息，那么将会更加糟糕。
• 在极端的情况下，由于累积大量旧的构件，系统可能会用尽所有的磁盘空间。

您的主要目标应该是在问题发生前和发生时，收集尽可能多的诊断信息。您还希望保存或者存档足够多的历史诊断信息，以作为进行比较的基准，并且在万一没有立即检测到某个问题的情况下，用于观察某些问题的缓慢堆积。但是应该将这种历史数据与当前问题确定构件分开进行保存，这样它们就不会互相干扰。
各种 IBM 产品，如 WebSphere Application Server，提供了自动清除或者轮转某些日志文件的功能。对于其他的日志文件和转储，则必须定期手动地存档或者清除。
10. 消除日志中虚假的错误和其他干扰信息在 IBM Support 中，有时我们会发现系统和应用程序运行于生成大量错误消息的模式中，甚至在正常运行期间也不例外。很明显，这种良性的、或者常见的错误并不是非常重要，但是它们使得要在所有这些干扰信息中发现不正常的错误变得更加困难。为了简化将来的故障诊断工作，可以排除所有这些常见的错误，或者寻找一种方式来标记它们，以便能够轻松地将它们与重要的错误区分开来。
11. 保存更改日志正如前面多次提到的，对于大多数故障诊断实践，其中一个重要的方面是在正常工作的系统和存在问题的系统之间找出它们的不同之处，并且使用基准是帮助解决这个问题的一种方法。另一种可以帮助您确定系统差异的操作是，准确地保存一段时间内系统中所应用的所有更改的日志。当问题出现时，您可以通过日志查看可能引起该问题的任何近期的更改。您还可以将这些更改映射到过去收集的各种基准，以确定如何采用这些基准来解释相关的差异。
您的日志至少应该跟踪所有的升级和软件修复（应用于系统中的每个软件组件），包括基础结构产品和应用程序代码。它还应该跟踪任何组件中的每项配置更改。在理想的情况下，它还应该根据系统的使用情况，跟踪所有已知的更改；例如，负载方面预期的增长、用户调用的不同操作的混合、等等。
在复杂的 IT 环境中（许多团队服务于该环境中不同的部分），要维护一个精确的、最新的和全局的更改日志，这项任务可能是相当困难的。您可以使用各种工具和技术来帮助完成这项任务，从使用简单的数据收集脚本（类似于那些用于收集诊断数据的脚本）收集配置的常规快照，到使用复杂的系统管理实用工具。
请注意，更改控制的概念，以及保存更改日志，通常比故障诊断所涉及的领域更加广泛。它也被认为是用于管理复杂系统以防止各种问题（而不是对它们进行故障诊断）的重要的最佳实践之一。
12. 为正在运行的系统设置运行状况监视在大多数实际情况下，可能导致更大问题的一些小问题或者较大的问题，可能潜伏很久都不会被发现。或者，系统的整体运行状况或者性能随着时间的推移可能会慢慢地下降，直到最后导致出现严重的问题。很显然，您越早检测到出错的地方，您将有越多的时间和机会来收集有价值的诊断信息，并将其用于故障诊断。因此，制定连续监测系统整体运行状况的良好策略，是整个故障诊断计划中一个重要的部分。这可能包括前面已经介绍过的诊断数据的大量相同来源，区别在于，在这种情况下，您不仅希望收集这些信息，还希望对其进行周期性地扫描，以确保不存在任何问题，而不是等待来自外部的问题报告。同样，简单的命令脚本或者复杂的系统管理工具（如果可用的话）都可以用于帮助实施这种监视。
可进行监视的内容的示例

• 各种组件所生成的日志中的重大错误。
• 由每个组件产生的度量应该维持在可接受的规范内（例如，操作系统 CPU 和内存的统计信息、WebSphere Application Server 性能度量、应用程序的事务速度等等）。
• 仅在问题出现时自动生成的特殊构件，如 Java 转储、堆转储等等。
• 周期性地向各种系统组件或者应用程序发送“ping”，以验证它是否能够像预期的那样继续做出响应。