常用技术和非常好的实践

    下面提供了一些常用技术和非常好的实践，可以帮助您解决或避免与共存应用程序相关的一些问题。尽管有些问题十分普通或显而易见，有些非常复杂，但它们在所有情形中都同样有效和值得考虑：

    1.对与每个应用程序关联的每个对象和资源使用不同的名称
    2.实现简明易懂的应用程序日志和错误消息
    3.仔细评估可能在应用程序之间共享的所有资源和其他对象
    4.执行对每个应用程序的端到端监视
    5.在应用程序之间分离管理功能
    6.始终考虑系统范围的整体情况

    1. 对与每个应用程序关联的每个对象和资源使用不同的名称

    在尝试进行故障诊断的过程中，通常会遇到与问题有关的各种命名对象或资源。一个关键任务是确定这些对象或资源属于哪个应用程序，或者与哪个应用程序关联。因此，在可能情况下，您应该使用一个清楚的命名约定，为与每个应用程序关联的每项内容分配不同的并且易于识别的名称。

    存在许多有用的内容可能与运行的应用服务器中可识别名称关联：

    *用于实现每个应用程序的所有类的 Java™ 包在可能情况下，不同应用程序应使用不同的 Java 包名称。这在许多情况下非常有用，例如：

    当服务器报告一个意外的异常时，您可以检查关联堆栈跟踪的类和方法，来确定哪个应用程序导致了异常或者与异常有关。

    如果服务器崩溃或挂起，通常需要检查从 javacore 中获得的线程转储或系统转储中的一个或多个堆栈跟踪。而且，这些堆栈跟踪中的类和方法可以映射回某个应用程序。

    如果出现内存泄漏，则通过确定致使 Java 堆明显增长的对象的类，并跟踪这些对象，追溯到某个给定的应用程序，通常（而不是始终）可以确定泄漏的根源。

    WebSphere Application Server 运行时使用一个类似的策略帮助区分可能与给定故障情形或缺陷有关的各种内部组件。例如，WebSphere Application Server 系统管理组件的大多数实现类都存在于 com.ibm.ws.sm 之类的包中；WebSphere Application Server 连接管理组件的实现类存在于 com.ibm.ws.j2c 之类的包中，等等。

    *每个应用程序、每个模块、每个 Servlet、属于给定应用程序的每个 EJB 组件的管理名称，以及专门与给定应用程序关联的任何资源。管理名称是在使用 J2EE™ 开发工具或 WebSphere Application Server 管理工具创建应用程序组件或资源时指定的名称。在执行过程中，此名称可能出现在日志和跟踪文件中，通常还用于各种管理和监视工具的命令和显示中。

    *与属于每个应用程序的组件或资源关联的 JNDI 名称。在执行过程中，这些名称可能出现在各种跟踪文件中，在使用确定特殊问题的工具或脚本列出 JNDI 命名空间的内容，以及监视它引用的各种项目的运行状态时，也可以看到这些名称。

    在为每个应用程序中的每个元素分配了定义良好、区别分明的名称后，最后一步是创建并继续维护一个列出这些名称及其关联应用程序的中心文档。然后，在研究某个问题时，系统管理员可以参考此文档，快速确定受影响的文档，并联系可以提供进一步帮助的相应人员。

    2. 实现简明易懂的应用程序日志和错误消息

    反映 WebSphere Application Server 运行时操作的日志通常包含在以下几个定义良好的文件中：SystemOut.log、SystemErr.log、native_stdout.log、native_stderr.log 等等。但是，大多数应用程序还需要生成流式日志记录信息，来帮助监视这些应用程序的正常操作和诊断在应用程序级别遇到的问题。

    为使应用程序日志消息对监视和确定问题尽可能提供帮助，每条消息除了文本消息本身外，还应包括若干关键信息：

    *明确指示是哪个应用程序发出的消息。这可以通过以下方法做到，把来自各个应用程序的日志发送到不同的文件，或者在每个消息前面加上与应用程序相关的标记。WebSphere Application Server 运行时使用的就是这一方法；WebSphere Application Server 发出的每个消息都由一个独特前缀和消息标识符开始，可以直接反映是哪个子系统生成的。IBM 支持人员经常使用此信息来跟踪运行时日志中报告的消息和问题的来源。

    *指示消息发出时间的准确时间戳。这样可以将出现的消息与可能观察到的其他外部事件关联起来（例如，某个负载特别大的期间或系统崩溃），并能够与 WebSphere Application Server 和可能由其他应用程序发出的其他消息关联起来。

    *指示服务器中的哪个线程负责发出此消息。此信息自动随 WebSphere Application Server 运行时发出的所有消息提供；使应用程序日志消息具有相同的信息，可以更容易地将 WebSphere Application Server 报告的一些事件与应用程序报告的事件关联起来，以便跟踪问题的根源。

    *可能情况下，在每个应用程序消息中提供指示，帮助确定在发出消息时应用程序正在处理的特定请求——但并不是永远都这样。这在应用程序处理单个请求过程中发出多个消息时特别有用，这样能够确定哪些消息事实上与同一请求相关，与哪些不相关，从而在系统中跟踪请求的路径。

    经常碰到的问题是，对每个应用程序使用单独的日志文件比较可取，还是将所有应用程序的日志记录合并到单一的输出文件中比较可取。如果所有日志消息都包含上述所有信息，则分不出哪种方法更可取。但是，请注意以下指导原则：

    *使用单一的组合日志文件可以在发生事件时简化收集和扫描反常情况的数据，并简化管理日志文件的增长和轮替。单一日志还可以提供服务器中发生的所有事件时间线的直接视图。如果有必要提取与某个特定应用程序关联的一组事件，则可以通过将所有项与关联该应用程序的特定标记或前缀相匹配做到这一点。

    *相反，使用多个单独的日志文件则在某种程度上较难跟踪、管理和收集不同日志中的所有数据，但它也按每个应用程序提供事件的完整视图。如果有必要确定服务器范围内事件的完整时间线，则可以根据每个日志中与各项关联的时间戳将日志合并在一起。

    实际上，最容易的方法通常是使用 WebSphere Application Server 提供的内置日志记录工具同时写入应用程序日志消息。使用写入 System.out 或 System.err 流的标准 Java 元素，或使用 java.util.logging 包中的方法和 WebSphere Application Server 定义的缺省日志程序，可以很容易地调用这些工具。在这两种情况下，应用程序日志消息将出现在标准的服务器 SystemOut 或 SystemErr 文件中，并且已经使用时间戳和线程标识符预先设定格式（但是，应用程序仍可以在每个消息中提供唯一的应用程序名前缀和适用的请求标识符）。

    另外，每个应用程序可以使用 java.util.logging 工具及其本身自定义的日志程序和处理程序，例如，可以为每个应用程序写入不同输出文件的日志程序和处理程序。在此情况下，应用程序本身负责确保所有日志消息的格式正确（如上所述），并确保正确管理输出文件。

    出于性能原因，无论使用哪种机制，在构建实际日志消息之前，应对应用程序进行编码，首先检查是否启用给定的日志记录级别。创建复杂的日志消息并将其写入只能丢弃该日志消息的日志程序或其他某个工具会带来负面影响，直接影响到每个应用程序请求的执行时间，间接影响到服务器的垃圾收集行为。