 | 级别： 初级 Don Bourne (dbourne@ca.ibm.com), WebSphere Serviceability 架构师, IBM
Keys Botzum (keys@us.ibm.com), 高级技术人员, IBM
Daniel Julin (dpj@us.ibm.com), 高级技术人员, IBM
2008 年 6 月 12 日 
日志消息和跟踪信息在问题诊断的初始阶段可以作为非常重要的节省时间元素加以利用，并且通常能够减少重现问题来进行故障排除的需求。本文将讨论 IBM® WebSphere® Application Server 中的日志和跟踪工具，介绍二者之间的差别，并说明如何在您的应用程序中对其加以利用。
来自 IBM WebSphere Developer Technical Journal.
在每个专栏中，支持权威将讨论 IBM Technical Support 的可用于 WebSphere 产品的资源、工具和其他元素，以及一些可以进一步增强您的 IBM 支持体验的技术和新思想。
最新快报
按照惯例，我们将首先提供关于整个 WebSphere® 社区的一些重要新闻：
- 这个月 IBM 宣布了一项新的增强软件支持生命周期政策，将很多产品的较旧版本的最低技术支持有效时限延长到了五年。之所以推出此政策，是为了消除客户对频繁升级到主要产品发布版本的繁重负担的顾虑。
- 我们将继续推出针对组织的各种增强计划，并努力提高 ibm.com 上各种软件支持资源的可用性。本周，我们将推出很多产品支持页面的新设计版本，其中包括 IBM WebSphere Application Server 的一个支持页面。请访问示例。
-
IBM Education Assistant 网站也进行了一些增强，最值得注意的是，推出了一组新的 RSS Feed（在每个产品的首页上）来帮助您了解新的培训模块。顺便提一句，2008 年已经发布了超过 100 个培训模块，其中很多都讨论了与故障排除相关的主题。
- 刚刚对 IBM Support Assistant 中的几个问题确定工具进行了更新。目前推出的更新和新工具远远超过了平时每个月的情况，但我们应该特别注意以下内容：
-
alphaWorks 也对若干工具进行了更新，其更新的主要目的是为了支持新 Java 版本和平台。特别是以下工具：
-
WebSphere Technical Exchange 网络广播系列仍然是重要的信息来源，在接下来几个月将特别集中讨论与问题确定相关的主题。我们不在这里列出所有的主题，但其中最值得我们关注的主题包括 Guided troubleshooting using the IBM Guided Activity Assistant (IGAA)、IBM Support Assistant Diagnostic Tools Overview、Debugging OutOfMemory errors on WebSphere AppServer z/OS、Resource starvation in Java and its diagnosis 和 Automating problem identification using IBM Autonomic Computing Technology。
继续关注与支持相关的各个网站以及本专栏，以获得有关我们所碰到的其他工具的新闻。
接下来让我们继续今天主要的主题……
好的程序会在自身情况不对的时候让您知道
作为开发人员，我们了解的第一件事是将消息打印到控制台。后来，我们了解到了此类打印语句在调试代码时的宝贵价值，特别是在找到喜欢的开发工作台之前更是如此。获得了解代码流和确定变量值变化的能力后，我们就能够充分理解清楚的调试语句在快速确定代码中的问题方面的价值。对每个方法进行了调试后，我们将从中剔除打印语句，从而更容易将重点放在代码的下一部分内容上。一切就绪后，在知道代码可供正常使用后，我们很高兴地删除了最后的打印语句。
对于任何重要的程序，诊断代码在单元测试之外都具有很大的价值。随后在某些情况下，可以在不用诊断代码辅助就能诊断问题，但使用代码和跟踪语句也能极大地缩短诊断时间。日志记录代码是第一手故障诊断信息中非常重要的部分，通常能够减少重现问题来进行诊断的需求。IBM WebSphere Application Server 提供了非常有价值的日志和跟踪工具，可供在您自己的应用程序中使用。作为开发人员，您要将有效的日志记录和跟踪代码写入到将与 WebSphere Application Server 一起运行的应用程序，本文将说明所需了解的信息。
日志记录和跟踪基础知识
日志记录和跟踪之间的区别何在？
-
日志记录通常用于希望在日志文件中记录的重要事件。日志记录用于指示状态的重要更改（例如，服务启动或停止时）、指示警告（例如，当所写入的磁盘空间不足时）或指示错误（例如，当代码由于预期服务不可用而无法再继续）。日志记录通常是始终启用，因此日志记录代码必须体积相当小，通常为您应该注意的重要事项。另一个重要的特征是，日志记录对应用程序管理员非常有用。由于所记录的消息旨在供管理员使用，因此应用服务器所记录的消息将转换为服务器进程的其余部分所配置的语言并写入日志（应用程序还可以利用消息本地化的优势，但这通常并不是必需的）。创建日志消息时必须谨慎，要确保任何使用此代码的人都能够容易地了解其含义。因此，通常添加日志记录语句所需的时间比添加跟踪语句的时间更长。
-
跟踪通常用于记录在调试代码问题时可能有用的任何信息。跟踪通常用于指示调用了哪些方法、向方法传入了哪些数据（或从方法返回了什么值）以及从对代码边界之外的其他方法的调用返回了什么数据。跟踪事件体积可能比较大，因此只有在诊断问题时启用。由于跟踪事件的内容极为详细，而且是技术信息，因此经常只对编写应用程序的人有价值。打开跟踪的情况下，应该能够了解在代码中可能出现的任何问题。如果跟踪检测未成功完成，则可能需要用户遇到问题时将代码的调试版本（包含更多的跟踪检测）发送给他们；这可能不可行（或者不希望这样做），通常最好通过在向最终用户提供代码前谨慎处理跟踪来加以避免。
哪些内容对日志和跟踪重要？
在日志和跟踪文件中包含正确的内容，可帮助更快地诊断问题。日志和跟踪内容至少应该明确以下信息：
- 指示消息生成时间的准确时间戳。
- 作为消息源的类名称和方法名称。
- 消息发出者的线程 ID。
- 消息反映的事件的严重级。
- 标识负责发出消息的记录器的名称，用于设置日志/跟踪级别，以控制启用或禁用哪些消息。
- 明确的消息。
哪些功能对日志记录和跟踪运行时对象重要？
除了在日志和跟踪事件中包含正确的内容外，日志记录和跟踪运行时对象还必须满足以下要求：
- 支持对启用或禁用哪些消息的足够细粒度的控制。
- 支持在不需要服务器重启的情况下控制日志和跟踪级别。
- 提供自动归档或截断日志和跟踪的方法（不用服务器重启），从而防止文件过大。
- 提供远程监视日志的方法。
选择正确的日志和跟踪 API
最常见的日志记录 API 有哪些？
有多个日志记录 API 选项可以在 WebSphere Application Server 应用程序中使用。最常见候选选项如表 1 中所示。
表 1. 日志记录 API
| 日志记录 API | 是否与 WebSphere Application Server 日志集成 | 是否建议在 WebSphere Application Server 应用程序中使用 |
|---|
| java.util.logging (JUL) | 是（从 V6.0 起） | 是（V6.0 或更高版本） | | JRAS | 是 | 是（仅仅适用于 V6.0 之前的版本） | | Log4J | 否 | 否 | | Jakarta Commons Logging (JCL) | 是 | 否 | | System.out.println and System.err.println | 是 | 否 |
-
java.util.logging (JUL)
JUL 从 2002 年 J2SE 1.4 发布之后一直是 Java SDK 的标准组成部分。从体系结构的角度而言，它与 Log4J 类似。JUL API 包含五个主要概念：记录器、处理器、筛选器、格式设置器和日志记录。JUL 的主要优势是，基于 J2SE 1.4（或更高版本）的所有运行时都将其包含在其中，提供了支持日志记录设置控制的灵活体系结构，而且能够方便地进行自定义。
JUL 是 WebSphere Application Server 中的首选日志记录实现，而且在 WebSphere Application Server 自己的实现中使用。JUL 的日志记录使用非常简单，而且具有足够的自定义能力，能满足大部分日志记录需求。JUL 与 WebSphere Application Server 实现了很好的集成，任何对 JUL 记录器 API 的任何请求（甚至包括来自应用程序代码的请求）都将由 WebSphere Application Server 日志记录基础设施进行处理。对于任何将在 WebSphere Application Server 内操作的新应用程序代码，都强烈建议使用 JUL。
-
JRAS
JRAS 是从 V3.5 之后随 WebSphere Application Server 提供的公用 API。JRAS API 及其所基于的 API 是 Log4J 和 JUL 的前身。JRAS API 已在 WebSphere Application Server V6.0 弃用，应用服务器将转而利用 JUL API。因此，不要对任何新代码使用 JRAS。
-
Log4J
Log4J 是一个 Apache 项目，旨在提供灵活而强大的日志记录实现。Log4J 最初在 1999 年发布，其体系结构与 JUL 类似。JUL 具有记录器、处理器、格式设置器和日志记录，而与此对应，Log4J 具有记录器、追加器、布局和日志记录事件。Log4J 的标准配置中包含很多追加器和布局。
Log4J 作为 Apache 的开源项目提供，但并不属于 Java 语言标准。Log4J 的主要优势在于，它提供与 JUL 类似的功能，而且具有大量的预先构建的追加器和布局实现。
虽然体系结构与 JUL 类似，但 Log4J 并未与 WebSphere Application Server 日志记录基础设施集成。通常，除非迫切需要 Log4J 的追加器或布局的高级功能，否则请不要将 Log4J 与 WebSphere Application Server 一起使用。您可能决定将 Log4J 和 WebSphere Application Server 结合使用，然后发现能够正常工作，但您并不能获得 JUL 所利用的集成所带来的好处。
-
Jakarta Commons Logging (JCL)
JCL 是旨在提供可编写的包装 API 的 Apache 项目。与其他日志记录 API 不同，JCL 在运行时就将日志记录呼叫委派给适合包含环境的具体日志记录实现。例如，在 WebSphere Application Server 中，JCL 的事件将发送到 WebSphere Application Server 日志和跟踪工具。在其他环境中，将 JCL 输出发送到 Log4J 的做法并不常见。这里的要点是，JCL 并不是基于标准的 API，而是让开发人员“不必担心”其跟踪输出的输出位置的框架。JCL 在标准 API 之前就存在。
JCL 的主要优势是，它允许代码使用日志记录调用进行检测，而且不用考虑在运行时存在哪些日志记录工具，或代码将最终在哪些运行时上运行。
JCL 与 WebSphere Application Server 集成并打包在一起。绑定自己的 JCL JAR 副本并希望将输出发送到不是 IBM 提供缺省项的目的地的应用程序需要特别谨慎，以避免与应用服务器运行时中包括的 JCL 版本出现类加载冲突。这通常很难很好地完成，因此不建议这样做。
由于在所有 J2SE 1.4 和较高版本的 JVM 都提供 JUL，就减少了将 JCL 作为可移植日志记录包装的需求。因此，不要在任何新的应用程序代码中使用 JCL。
-
System.out.println and System.err.println
虽然这不是真正的日志或跟踪 API，但很多开发人员都喜欢使用 System.out.println 检测其代码。WebSphere Application Server 将对传递给 System.out 和 System.err 的数据进行充实。WebSphere Application Server 不会将 System.out 和 System.err 写到控制台，而会：
- 将传递到每个流的数据转换为日志事件（不精确进程）。
- 确定事件的创建时间。
- 确定事件发出者的线程 ID。
- 将事件连同上述信息写入托管日志文件。
不过，应用服务器并不能使用 System.out 和 System.err 确定消息的准确来源（类或方法），无法确定消息的严重程度，而且无法提供比基本的开/关功能（服务器范围内）更强的功能来控制这些消息的输出。或许最重要的是，将大量跟踪输出发送到 System.out 开销非常大，而且将导致大量的性能问题（并需要面临减少输出量的压力）。这些差异使 System.out 和 System.err 不适合大规模使用。因此，不要在应用程序代码中使用 System.out.println 和 System.err.println。
应该将哪个日志记录 API 用于 WebSphere Application Server？
正如上面所述，有各种日志记录可供选择。以下是 WebSphere Application Server 服务能力团队针对应用程序代码的建议：
-
将 JUL 用于将在 WebSphere Application Server V6.0 或更高版本上运行的新代码。
由于 JUL 的普遍性及与应用服务器日志和跟踪工具的紧密集成，因此 JUL 是最适合用于新 WebSphere Application Server 应用程序代码的 API。只有在应用程序所需的所有运行时中都不提供 JUL 时才应考虑其他日志记录 API。
-
如果（且仅在此情况下）需要支持不能正确支持 JUL 的环境，则请对新代码继续使用现有日志记录框架。
通常，如果继续部署到 J2SE 1.4 之前的环境，则您已经具有其他应用程序和已经建立的日志记录 API。您有两个选择，一个是继续使用现有日志记录 API，另一个是寻找其他 API。既然 JUL 中有日志记录标准，则投资新的日志记录基础设施就不那么急迫了，因为任何投资都将只是暂时性的。
-
不要出于日志记录 API 纯净度的原因替换数千行经过测试的日志记录和跟踪检测的代码行。
对于迁移到支持 JUL 的应用服务器的情况，可能很想对现有日志和跟踪检测进行重新设计。由于要在一个日志记录 API 进行标准化而重写数千行跟踪代码（而且必须进行重新测试），这样的做法通常并不能很好地利用开发资源。在可能的情况下，请考虑将现有的日志记录 API 过渡到采用 JUL 编写代码。如果您无法通过 JUL 整合日志事件，则可以使用 Log Analyzer 之类的工具在查看时将日志与应用服务器日志合并。
使用 JUL 检测代码
-
记录器在需要日志记录和跟踪的代码中使用。记录器通常基于所在的 Java 类或包分配名称（例如，com.acme.birdtrap.PurchaseOrder）。记录器由独立日志管理器存储采用层次结构方式存储，允许记录器从其父级记录器继承特征。每个记录器的名称确定记录器所属的层次结构，每个记录器的父项具有与子项相同的名称，不过减少了子项名称中最后一个英文句点之后的部分（例如，com.acme 是 com.acme.birdtrap 的父级记录器，而后者是 com.acme.birdtrap.PurchaseOrder 的父级记录器）。每个记录器都具有对应的级别，这是一个可设置的阈值，控制必须记录的事件（称为日志记录）的严重级别，以免被丢弃。如果不明确设置记录器级别，则该记录器将从其父项继承级别。记录器可以具有筛选器，筛选器是记录器用于根据日志记录的内容决定是否丢弃日志记录请求的类。
-
处理器是记录器用于将日志记录写入输出设备的类。处理器可以自行设置日志记录的格式，或使用格式设置器来将日志记录转换为字符串。处理器还具有级别设置，级别的用途与记录器中的级别相同。处理器也可以具有筛选器，其用途与记录器的筛选器相同。处理器通常将日志记录的格式化结果写入日志文件，但可以设计为输出到内存内的缓冲区、套接字、即时消息传递目的地或任何其他认为有用的位置。JUL 以标准形式提供，包含一系列处理器和格式设置器来满足您的基本需求。
图 1. JUL 日志请求处理中的关键组件
清单 1 包含演示使用 JUL 时的编码最佳实践的代码示例。将在示例后对这些最佳实践进行说明。
清单 1. 演示 JUL 使用的示例代码
1 package com.acme;
2 import java.util.logging.Level;
3 import java.util.logging.Logger;
4 public class JULExample {
5 // define a Logger for use by this class
6 static String className = JULExample.class.getName();
7 public static Logger logger = Logger.getLogger(className);
8 public String lookupContactPhoneNumber(String contactName) {
9 String methodName = "lookupContactPhoneNumber";
10 logger.entering(className, methodName);
11 // connect to contact repository
12 ContactRepository cr = ContactRepository.connect();
13 if (cr == null) {
14 // LOGGING
15 logger.logp(Level.WARNING, className, methodName,
16 "Contact repository not available");
17 return "";
18 }
19 // lookup the contact phone number
20 String contactPhoneNumber = cr.getContactPhoneNumber(contactName);
21 // TRACE
22 if (logger.isLoggable(Level.FINEST)) {
23 // use isLoggable so we don't concatenate strings
24 // below unless trace is enabled
25 String traceString = "name " + contactName + "number: "
26 + contactPhoneNumber;
27 logger.logp(Level.FINEST, className, methodName,
28 traceString);
29 }
30 logger.exiting(className, methodName, contactPhoneNumber);
31 return contactPhoneNumber;
32 }
33 public String getSomeString() {
34 return "SomeString";
35 }
36 } |
使用 JUL API 将日志记录和跟踪代码添加到应用程序，将极大地改进您应用程序的服务能力。以下是一些建议的原则，可帮助您获得极佳的结果：
-
存储记录器实例，而不要重复调用 Logger.getLogger。
在清单 1 中，Logger.getLogger() 仅仅调用了一次，以获得类的记录器。记录器是线程安全的，因此可以安全地将其存储在静态变量中，以供任何类实例使用。这样您就能够在类中的任何位置使用记录器，而且不必再次调用 Logger.getLogger()，从而提高您代码的性能。
-
使用完全限定类名称作为记录器名称。
记录器名称在需要更改记录器级别时用于标识记录器（例如，在管理控制台中）。通过为记录器分配完全限定类名称，可方便地指定需要调整哪个记录器的级别来从用户获得所需的跟踪。
-
确保日志和跟踪条目易于链接回代码。
通过在日志和跟踪条目中指定类名称和方法名称，将能够立即指出事件在代码中的生成位置。
您还需要使用 entering() 方法调用来标记方法的开始位置，但要记住 entering() 方法调用将生成 Level.FINER 事件，而在 WebSphere Application Server 中缺省禁止 Level.FINER 事件。
有些 JUL 实现将尝试在未指定这些参数的情况下计算哪个方法和类生成了事件，但这可能会产生不希望的性能影响——在 JIT 删除了堆栈框架的情况下甚至可能会不正确。在 WebSphere Application Server 中，不会尝试计算代表调用方的方法和类名称（这项功能是可选的，而且被视为非常低效的功能）。在能够提供自己的类和方法名称的情况下，使用 JUL 记录器方法更好。
表 2. 允许指定类和方法名称的记录器方法
| 记录器方法 |
|---|
entering(String sourceClass, String sourceMethod)
|
entering(String sourceClass, String sourceMethod, Object param1)
|
entering(String sourceClass, String sourceMethod, Object[] params)
|
exiting(String sourceClass, String sourceMethod)
|
exiting(String sourceClass, String sourceMethod, Object result)
|
Logp(Level level, String sourceClass, String sourceMethod, String msg)
|
Logp(Level level, String sourceClass, String sourceMethod, String msg, Object param1)
|
logp(Level level, String sourceClass, String sourceMethod, String msg, Object[] params)
|
logp(Level level, String sourceClass, String sourceMethod, String msg, Throwable thrown)
|
throwing(String sourceClass, String sourceMethod, Throwable thrown)
|
-
遵循应用服务器的日志和跟踪级别约定。
WebSphere Application Server 缺省配置在缺省情况下支持 Level.INFO 和更高的 JUL 级别。应用服务器将从 Level.CONFIG 到 Level.SEVERE 的所有 JUL 级别作为日志事件级别对待，旨在供管理员使用。
表 3. 日志记录级别
| 日志记录级别 |
|---|
Level.SEVERE
|
Level.WARNING
|
Level.INFO
|
Level.CONFIG
|
应用服务器将从 Level.FINE 到 Level.FINEST 的级别作为跟踪级别对待（这些级别用于旨在帮助代码的作者进行调试的事件）。
表 4. 跟踪级别
| 跟踪级别 |
|---|
Level.FINE
|
Level.FINER
|
Level.FINEST
|
通过在代码中遵循这些约定，就将能够在缺省情况下记录正确的事件集。
-
不要在代码中设置日志记录级别。每个 JUL 记录器都具有关联的级别。此级别控制忽略哪些事件和记录哪些事件。记录器级别在应用服务器启动时使用应用服务器配置文件中存储的数据设置。管理员可以利用脚本（使用 wsadmin）或以编程方式（使用 JMX Mbean 客户端）通过管理控制台更改记录器级别。应用服务器控制记录器级别。
通过直接调用 logger setLevel() 方法对记录器级别设置的更改并不更改应用服务器的中央日志记录配置，因此，通过 setLevel() 设置的记录器级别将不会反映在管理控制台中，而且可能在日志记录基础设施基于管理员更改应用新日志记录设置时被忽略。所以请避免使用此方法：setLevel(Level newLevel)。更改服务器的中央记录器配置时，会将这些更改推送到所有受影响的记录器。这意味着，对记录器 getLevel() 方法的调用将按照预期的方式工作。
-
请仅将记录器 entering() 和 exiting() 方法用于重要方法。
JUL 提供了建议在方法的开始和结束时使用的 Logger.entering() 和 Logger.exiting() 方法。将这些跟踪点添加到代码中的每个方法所涉及工作量将非常大，而且并不会提高应用程序的服务能力。通常，对于特定方法的内部不重要的情况（如简单的 getter 或 setter 方法），请避免使用 entering() 和 exiting() 方法。
-
最好将应用程序日志和跟踪写入到应用服务器日志。
虽然 JUL 提供了只需最少代码或配置来添加新日志文件的能力（处理器），但通常这样做没有什么优势。在调试时让日志和跟踪信息与应用服务器日志和跟踪交织在一起的做法很好。对于不能将日志写入相同的日志文件的情况，或者涉及多个系统时，Log Analyzer（作为 IBM Support Assistant 的插件提供）之类的工具可以帮助您合并日志文件。
-
在合适的情况使用 Logger.isLoggable()。
因为 WebSphere Application Server 缺省情况下禁用跟踪，因此务必尽可能高效地禁用跟踪语句。为了避免计算跟踪方法参数的性能成本，JUL 提供了 Logger.isLoggable() 方法，此方法将进行检查，确定记录器的设置是否等于或高于您所指定的级别。请记住，记录器将执行相同的检查，因此，在计算日志和跟踪参数将带来一定性能成本的情况下，并没有必要将日志或跟踪语句与 Logger.isLoggable() 检查包装在一起。
|
|
与 WebSphere Application Server 的 JUL 集成
从 V6.0 开始，所有的 WebSphere Application Server 版本都可以利用 JUL。以下是通过使用 JUL 来检测代码将获得的一些额外好处：
-
内置日志和跟踪文件
WebSphere Application Server 将设置日志和跟踪事件的格式，并将其写入到相应的应用服务器日志文件中（在 Windows®、Linux®、HP/UX、Solaris™、AIX® 和 i5/OS 操作系统上，所指的是 SystemOut.log、trace.log 和 activity.log 文件；而在 System z™ 上，所指的是平台日志记录工具）。应用服务器将为您管理这些日志文件，并提供易于配置的存档策略。您可以使用知道如何处理应用服务器日志文件的工具（如 IBM Rational® Application Developer 或 IBM Support Assistant 中的 Log Analyzer）或各种 IBM Tivoli® 工具来使用日志内容。
-
用于应用程序的内置记录器级别管理
WebSphere Application Server 提供了为任何指定 JUL 记录器设置级别的方法，包括您在自己的应用程序中创建的记录器。JUL 记录器级别可以使用管理控制台、wsadmin 或 JMX 配置设置。
图 2. WebSphere Application Server Change Log Detail Levels 面板显示您的 JUL 记录器
-
事件和应用服务器事件间的固有相关性
应用服务器日志和跟踪事件将与您自己的日志和跟踪事件交织在一起，因此消除了将这些独立事件集相关的需求。这样可以在使用日志和跟踪诊断问题时节省时间。对于不希望存在这种交织的情况，可以选择创建自己的日志文件（以后的文章中将对此进行更多的讨论）。
-
WebSphere Application Server 的 JUL 扩展
WebSphere Application Server 提供了（通过 Logger.properties 文件）将一系列有用属性与记录器关联的方法。通过这些属性，您可以将记录器添加到组，或通过将记录器与本地化资源包使用来提高性能。
-
企业级别配置
WebSphere Application Server 基于服务器配置设置初始化日志记录环境，而不会使用 JRE/lib 目录中的 JUL logging.properties 设置（后者是 JUL 缺省方式）。这样的好处在于，日志设置与您的服务器关联。这意味着将服务器添加到集群时，所有服务器上的日志记录行为将保持一致，将仅仅依赖于与您 J2EE™ 环境关联的设置。
|
|
结束语
日志记录和跟踪是应用程序代码中重要的组成部分。通过遵循一些最佳实践，您可以确保服务能力代码与所在的运行时很好地集成，提供在现场调试代码的必要信息，而且不会对代码的性能造成大的影响。
本专栏后面的部分将讨论一些更为高级的日志和跟踪主题，如：
- 如果存在使用应用服务器中的 Log4J 或 JCL 的代码，该如何处理？
- 如何在使用 JUL 时添加自己的日志文件？
- 如何将本地化资源包与 JUL 结合使用？
参考资料 学习
获得产品和技术
讨论
作者简介 | | |
Don Bourne 是 IBM Toronto Lab 的 WebSphere Serviceability 架构师。Don 于 1996 年加入 IBM，自从 2003 年加入 WebSphere Application Server 团队后一直专门从事服务能力方面的工作。目前 Don 正在与 IBM Support Assistant 团队合作设计未来的解决方案的体系结构，以帮助用户快速解决问题。 |
| 
| |
Daniel Julin 在开发复杂的联机系统及其故障诊断方面具有 20 年的经验。作为 WebSphere Serviceability Team 的技术领域负责人，他目前重点关注于帮助团队定义和实现一组工具和技术的集合，以协助确定 WebSphere Application Server 问题，并实现 IBM Support 工作效率的最大化。他有时候也直接为各种关键的客户支持情况提供协助。 |
对本文的评价
| |
