IBM Lotus Notes/Domino 7 中新的可用性特性

客户机和服务器崩溃是每个人都希望避免的，但是当崩溃发生时，您的首要任务应该是获得防止故障再次出现所需的数据，并快速地恢复。本文讨论 IBM Lotus Notes/Domino 7 中添加的一些新的可用性特性。本文帮助 Domino 管理员获得与崩溃相关的适当数据，以便发送给 IBM Support，帮助用户了解在 Notes 客户机突然停止运行时发生的情况。

关于故障恢复和自动诊断收集的一些背景知识

故障恢复自从第 4 版开始就在 UNIX 平台的 Lotus Domino 上出现了，但是它没有文档记载，而且比较难使用。从 Lotus Notes/Domino 6 开始，故障恢复就可以在运行 Lotus Notes/Domino 的所有平台上工作了，而且可以在 Server 文档中轻松地配置。故障恢复跟踪客户机或服务器正在使用的所有资源，并在发生崩溃时将它们全部清除。对于 Domino 服务器，在收集诊断信息之后重新启动是可选特性。对于用户来说，这意味着他们在崩溃之后可以重新启动 Notes 客户机，而不必终止 Notes 客户机已经启动的所有进程。

利用故障恢复，Lotus Notes/Domino 可以在每次崩溃时收集适当的诊断信息。但是，需要访问发生崩溃的每台机器上的诊断信息，这对于 Notes 客户机崩溃就成了问题。Lotus Notes/Domino 6.0.1 中添加的自动诊断收集（automatic diagnostic collection，ADC）特性使管理员不必从每台机器收集数据。ADC 允许设置一个 mail-in 数据库，从而将从 Notes 客户机和/或 Domino 服务器崩溃中生成的诊断信息收集在一个中心存储库中。

可以通过 Server Configuration 文档（对于服务器）和 Desktop Setting Policy 文档（对于客户机）来配置 ADC。当客户机或服务器重新启动时，数据被发送到 mail-in 数据库。对于客户机崩溃，可以配置 Policy 文档，从而反映是让用户发送诊断信息，还是让用户输入关于崩溃前所做操作的注释。

Lotus Notes/Domino 7 的 ADC 中增加的新特性

在 Lotus Notes/Domino 7 中，ADC 功能已经扩展了。在这一节中，学习新功能以及它如何帮助您收集更好的诊断信息，还可以分析故障随时间变化的趋势。新特性如下：

• 配置在崩溃时要收集的文件
• 为 Sametime 和 QuickPlace 崩溃收集的额外信息
• 向 Domino Domain Monitoring（DDM）发送服务器重新启动通知
• 扩展的日志记录选择
• 邮件通知中的扩展信息
• 限制附件大小
• 如果 NSD 没有配置为运行，那么发出警告
• 故障分析器

配置要收集的文件

在 Lotus Notes/Domino 6.x 中，ADC 收集一组固定的文件，包括 NSD 输出、控制台日志和内存转储。这些信息通常对于调试一般的崩溃足够了，但是如果在客户机或服务器上运行的第三方应用程序有自己的日志文件，那么怎么办？如果希望捕获 SEMDEBUG.TXT 文件（因为其中可能提供故障原因的线索），那么怎么办？

Lotus Notes/Domino 7 扩展了在默认情况下捕获的文件数量，还可以通过选项在崩溃时收集更多的文件。在默认情况下收集的文件是：

• NSD 输出。 系统信息的转储，包括所有 Notes/Domino 进程中的每个线程在崩溃时正在做什么。
• 控制台输出。 一个文本文件，包含写到 Domino 控制台的消息。
• 内存转储。 在给定时刻，由 Notes/Domino 进程分配的内存块的快照。
• Notes_Child_PID 输出。 每个进程的 Process ID 以及它们在终止时的退出状态。
• memcheck 错误。 在扫描 Notes/Domino 内存池时，memcheck 探测到的任何错误。
• 信号量调试。 一个文本文件，显示被争用的信号量。
• HTTP 会话/线程日志。 关于每个 HTTP 会话和线程正在做什么的信息。只有在 HTTP 上发生崩溃并启用了会话/线程日志时，才会收集这个日志。
• NSD-sysinfo 输出。 在客户机/服务器启动时记录的系统信息。
• NSD-kill 输出。 当使用 nsd -kill 终止客户机或服务器时收集的信息。

除了这些文件之外，还可以收集在崩溃时可能存在的任何其他文件，这需要设置 Server Configuration 文档或 Desktop Settings Policy 文档中的信息。如果点击这些文件之一的 Diagnostics 附签，那么会看到图 1 所示的部分，它使用 Domino 7 Directory 设计。

图 1. Diagnostic Collection Options 部分

在 Diagnostic file patterns 域中，可以输入在崩溃时要搜索的文件名的列表和/或模式；如果没有超过配置的大小限制的话（关于大小限制的信息，请参考本文后面的 “限制附件大小” 小节），这些信息会附加到发送给 mail-in 数据库的文档。模式可以包含星号（*，表示一个或多个字符）或问号（?，表示一个字符）。

如果文件在当前诊断目录（常常是 <data directory>/IBM_TECHNICAL_SUPPORT）中，那么只需要文件名。但是，如果文件在这个目录之外，那么需要文件的完整路径。

针对 Sametime/QuickPlace 崩溃的额外信息

如果崩溃发生在 Sametime 或 QuickPlace 服务器上，默认情况下会收集更多信息并添加到发送给 mail-in 数据库的文档中。具体地说，如果崩溃发生在 Sametime 中，那么 stdiags_* 文件被自动添加到 mail-in 文档中。如果是 QuickPlace 崩溃，那么 Lotus Domino 尝试附加 qpconfig.xml 和 admin.nsf 文件来帮助诊断问题。

发送给 Domino Domain Monitoring 的服务器重新启动信息

Domino Domain Monitoring（DDM）是 Lotus Domino 7 中的一个新特性，它为管理员提供了整个域的执行情况的高级视图。当服务器在崩溃之后重新启动时，一个消息发送到 DDM，这样就可以在管理员控制台上跟踪这个事件。它还提供这些事件的跨域历史跟踪。

扩展的日志记录选择

在 Lotus Notes/Domino 6.x 中，如果在客户机或服务器上没有启用控制台日志记录，那么在 mail-in 数据库中就不捕获控制台信息。但是，在某些情况下，需要利用此信息来寻找问题的原因，所以 Lotus Notes/Domino 7 改进了获得此信息的方法。

如果服务器在 Domino Controller（也称为 Java Controller）下运行，那么无论是否启用了控制台日志记录，ADC 寻找控制台信息的第一个位置都是 Domino Controller 日志（在服务器上）。如果服务器在 Domino Controller 下运行，那么 ADC 使用它的日志（仍然受到 Configuration 文档中的大小限制的控制），因为这个日志是控制台输出中信息的超集；即，这个日志包含每个消息加上消息的严重性编码。

如果 ADC 运行在客户机上，或者服务器没有在 Domino Controller 下运行，那么 ADC 检查是否启用了控制台日志记录。如果启用了，那么就像 Lotus Domino 6.x 中那样使用控制台输出。

如果没有启用控制台日志记录，那么 ADC 使用写入 log.nsf 中的信息（这是控制台日志中信息的子集）。它采用的办法是将崩溃时的文本从 log.nsf 的 Miscellaneous Events 视图提取出来，并创建一个伪控制台输出文件。然后，将这个文件附加到文档，就像有控制台日志一样。为什么不将整个 log.nsf 附加到文档呢？因为在大多数情况下，这个文件比配置的大小限制要大，而且因为 log.nsf 是二进制文件，不能简单地截短它并发送最后一部分。

邮件通知中的扩展信息

在 Lotus Domino 6.x 中，有一个配置选项可以在服务器重新启动时向一个人或一个组发送通知。但是，这个通知只提供基本信息，比如服务器崩溃的时间以及它现在已经备份的事实（见图 2）。

图 2. Domino 6 服务器重新启动通知

在 Lotus Notes/Domino 7 中，这个通知得到了改进，在 Subject 和 Body 域中包含更多信息，所以得到通知的人可以更快速地获得关于崩溃的更多信息。正如在图 3 中看到的，Subject 域包含 Domino 版本、崩溃的进程以及崩溃的时间。Body 域包含发送到 mail-in 数据库的几乎所有信息（不包括附件），以及到 mail-in 数据库的数据库链接（如果数据库位于与崩溃的服务器相同的域）。

图 3. Domino 7 服务器重新启动通知

有了扩展的 Subject 行，通知列表上的手持设备用户或 pager 用户就可以获得所需的信息，而不需要访问 mail-in 数据库。如果您喜欢 6.x 格式，那么可以在希望发送 6.x 样式消息的所有服务器的 Notes.ini 文件中设置 Notes.ini 参数 ADC_USE_OLD_EMAIL_FORMAT=1。

Notes.ini 参数 FR_ATTACH_NSD 在 Lotus Domino 7 中仍然有作用。这个参数决定是否将 NSD 输出文件附加到在服务器重新启动时发送的通知消息。如果这个参数设置为 1，那么将 NSD 输出附加到通知消息。如果设置为大于 1 的值，那么 NSD 输出只在小于或等于这个参数值（以 KB 为单位）时附加到通知消息；因此，FR_ATTACH_NSD=5 意味着只在小于或等于 5 KB 时附加 NSD 输出。这个设置只应用于将 NSD 输出附加到通知消息，并不影响将什么附加到发送给 mail-in 数据库的消息。

限制附件大小

对于在 ADC 发送给 mail-in 数据库的消息上添加附件，问题之一是这会大大增加消息的大小。如果没有足够的硬盘空间来传递消息，或者您的公司使用路由器控制来限制在环境中发送的消息的大小，那么这会造成问题。

在 Lotus Notes/Domino 7 中，可以在 Diagnostic Collection Options 部分中限制发送给 mail-in 数据库的消息的总大小，以及附加多少 NSD 输出（这与前一节提到的 INI 参数无关），见图 4。

图 4. Diagnostic Collection Options 部分中的 Maximum size 域

图 4 显示消息总大小的默认值是 5 MB，NSD 输出是 2 MB，因为 NSD 输出是从文件的开头开始读取的，所以它是文件的前 2 MB。

当 ADC 构建消息时，它按照以下次序附加文件：

1. NSD 输出（不超过配置的大小）
2. 控制台输出（不超过配置的大小）
3. Diagindex.nbf 文件，其中包含自从服务器上一次重新启动以来生成的所有诊断文件的列表
4. 所有其他文件，包括其他默认文件和您配置的要收集的文件

如果需要截短 NSD 文件，或者任何文件由于超过了限制而不能附加到消息中，那么在 mail-in 文档中列出它们，这样您就能够手工获得它们。图 5 给出一个来自服务器崩溃的示例。

图 5. 一次服务器崩溃的 ADC 消息示例

对于客户机崩溃，可以获得关于正在起作用的 Desktop Setting Policy 的更多信息（见图 6）。

图 6. 一次客户机崩溃的 ADC 消息示例

当没有配置 NSD 时发出警告

ADC 依靠 NSD 输出获得它的许多信息，所以如果在崩溃时没有将 NSD 配置为运行，那么在 ADC 报告中就没有多少有用的信息。具体地说，缺少 IBM Support 用来帮助解决您的问题的信息。为了向管理员警告这种情况，如果在崩溃时没有找到 NSD 输出，那么会在 mail-in 数据库中显示以下警告：

WARNING: Crash information not extracted! Make sure NSD is configured to run on the Server document.

回页首

故障分析器

Lotus Domino 7 中 ADC 的最大的新特性是故障分析器。故障分析器是一个新的 Domino 服务器附加任务，它可以将 mail-in 数据库中的崩溃报告与发送此信息的 ADC 匹配起来。

故障分析器可以处理许多 mail-in 数据库（例如，如果对于客户机和服务器崩溃有不同的数据库），但是它只在当前处理的数据库中寻找匹配；并不跨多个数据库寻找匹配。

如果故障分析器没有为新崩溃找到匹配，那么它被指定为父崩溃（这意味着这是第一次看到这个崩溃）。如果找到了匹配，那么它被指定为子崩溃，而这个崩溃的第一次出现变成它的父崩溃。本文后面会讨论这种父/子关系，但是现在我们讨论一下用来判断两个崩溃是否匹配的过程。

匹配过程

判断两次 Notes/Domino 崩溃是否是由于相同的原因造成的，这并不总是轻松的任务。由于 Lotus Notes/Domino 具有层次化的体系结构，所以不能仅仅依靠错误消息来惟一地识别问题，因为不同的代码路径可能导致同样的错误消息。

故障分析器使用由崩溃的线程调用的函数序列来为崩溃生成一个惟一的签名。这个函数调用序列显示了造成崩溃的代码路径。

如果您查看过各种 Notes/Domino 平台上的 NSD 输出文件，就会发现各种操作系统以很不一样的方式显示调用堆栈信息。在将报告发送到 mail-in 数据库之前，ADC 负责对这些差异进行规范化。这包括确保以反时间次序列出函数，以及对 C++ 函数进行 de-mangled 处理（这意味着它们采用 <class>::<function> 格式）。

在匹配过程中，故障分析器从堆栈的顶部开始向下读取，直到遇到在两个堆栈之间不匹配的函数名。堆栈的顶部由 Panic 函数决定，这在 Windows 32 平台上是用于访问违规的堆栈上的第一个函数，在 UNIX 平台上是 fatal_error 之后的第一个函数。

故障分析器遍历 stack1 中的每个函数并在 stack2 中的相同位置寻找匹配。重复这个过程，直到函数名不匹配为止。此时，确定两个堆栈之间的匹配百分数。匹配百分数的计算方法是，堆栈中相同函数的数量除以两个堆栈中函数的平均数量。

如果 stack1 有 10 个函数，stack2 有 15 个函数，在两个堆栈之间前 5 个函数是匹配的，那么匹配百分数是 5 / ((10+15) / 2) = 41%。

如果两个堆栈中的函数都相同，那么匹配百分数是 100%，这称为精确匹配。不难判断这两个崩溃的原因是相同的。但是，对于原因相同的两个崩溃，有可能具有不同的调用堆栈。出现这种情况的原因是，Lotus Domino 是采用层次化模型编写的，因此各种子系统构建在其他子系统之上。如果在访问数据库的层（NSF）中出现问题，那么许多其他子系统（例如，路由器、复制器等等）都可能受到这个问题的影响，但是导致问题的调用堆栈是不同的。

为了判断两个堆栈是否是部分匹配，使用基于两个调用堆栈的平均堆栈长度的截止百分数。计算堆栈平均长度的办法是，stack1 中的函数数量加 stack2 中的函数数量，再除以 2。基于堆栈平均长度的截止百分数见下表。

随着堆栈平均长度的增加，判断部分匹配所需的百分数降低；这是因为在比较长的堆栈中，堆栈顶部有更多相同的函数，这样就更有把握认为问题是相同的。

可以手工调整这个算法，办法是在运行故障分析器的服务器上，设置 Notes.ini 文件中的参数 FAULT_ANALYZER_MATCH_PERCENTAGE。可以将这个参数设置为 1 到 99 之间的数字。如果使用这个设置，那么它应用于所有部分匹配，而不管堆栈平均长度是多少。

故障分析器配置

故障分析器在默认情况下是关闭的。需要一个 Domino 7 服务器来容纳 mail-in 数据库，以便让故障分析器在它们上面运行。另外，必须将 Domino Directory 升级到第 7 版设计，这样就可以在 Server Configuration 文档的 Diagnostics 附签上看到对故障分析器进行配置的新域（见图 7）。

图 7. Server Configuration 文档中的故障分析器域

在默认情况下，如果启用故障分析器，那么它在服务器上的所有 mail-in 数据库上运行，并在服务器启动时启动（不需要将它添加到 Notes.ini 文件中的 ServerTasks 行）。通过扫描定义了 mail-in 数据库的 Server Configuration 和 Desktop Setting Policy 文档的本地 Domino Directory，故障分析器判断服务器上的哪些数据库是 ADC mail-in 数据库。如果这些数据库在本地服务器上，那么就监视它们。如果在本地服务器上没有找到数据库，那么故障分析器关闭。

在故障分析器启动时，它处理 mail-in 数据库中的任何新崩溃，然后保持空闲状态，直到提交新的崩溃。此时，它立即运行并处理新的崩溃。

还可以将故障分析器配置为在选择的数据库上运行（见图 8）。如果希望让故障分析器只在服务器上的一部分数据库上运行，或者如果希望将所有 mail-in 数据库复制到一个服务器上，以便在一个地方集中处理它们，而不是在多个地方运行故障分析器，那么可以选择这个选项。

图 8. 将故障分析器设置为在选择的数据库上运行

还可以发出控制台命令 load faultanalyzer 来手工运行故障分析器。如果没有传递任何参数，那么故障分析器使用前面描述的方法来寻找当前服务器上的所有 ADC mail-in 数据库。还可以传递参数来指定故障分析器要处理的数据库、目录或间接文件（包含数据库列表的 *.IND）。当手工运行故障分析器时，它处理数据库中的任何新崩溃，然后终止；它不会留在空闲状态来等待提交下一次崩溃。

为了节省 mail-in 数据库中的空间，还可以使用一个选项从子崩溃（包括精确匹配和部分匹配）中删除附件。这里的思路是，您知道它是相同的崩溃，所以不需要两次存储诊断信息。即使选择从 mail-in 数据库中删除此数据，仍然可以在客户机或服务器上获得它。

注： 如果在 Lotus Domino 6.x 上运行 ADC，那么在升级到 Lotus Domino 7 并启用故障分析器时，它在首次运行时会处理 mail-in 数据库中的所有当前条目。

对 Notes/Domino Fault Reports 数据库的修改

在 Domino 7 服务器上，Notes/Domino Fault Reports（lndfr.ntf）模板已经更新了，以便查看 ADC mail-in 数据库中存在的所有新信息。当将服务器升级到第 7 版并运行设计任务时，当前 mail-in 数据库升级到新设计。

图 9 显示数据库的新布局。Standard 和 Fault Analyzed 视图被添加到 By Date、Clients 和 Servers 视图中，这样就可以看到父/子关系以及当前的按日期分类。

图 9. Domino 7 Fault Report 数据库的布局

在新的 Fault Analyzed 视图中，子崩溃被分类在与它对应的父崩溃下面。在打开父崩溃文档时，顶部有一个嵌入视图，其中显示与它相关联的任何子崩溃。双击这些文档可以从嵌入视图直接打开它们。精确匹配和部分匹配都包含到父崩溃的文档链接，所以也可以使用这些链接进行导航。另外，部分匹配还显示匹配百分数，这样就能够看出两个堆栈相互匹配的程度。

发生计数

每个父崩溃的发生计数是这个崩溃在当前 mail-in 数据库中出现的总次数。这个计数列在父崩溃文档的 Administrative Section 中（见图 10），还显示在 mail-in 数据库中的所有视图中。

图 10. 父崩溃文档的 Administrative Section 中的发生计数域

惟一 ID 计数

除了总发生计数之外，故障分析器还跟踪受到某一崩溃影响的惟一客户机和/或服务器的数量。这对于判断问题的严重程度有帮助。例如，如果 20 个不同的用户 20 次遇到同一崩溃，那么这种情况比同一个用户遇到 20 次崩溃要严重。惟一 ID 在父崩溃文档的 Administrative Section 中列出，并按照他们遇到这个问题的次数进行降序排序。还可以在 mail-in 数据库中的视图中看到这个计数。

已经解决的崩溃

在判断出一个崩溃的原因并升级到包含补丁的版本或应用了热补丁之后，就不希望将以后具有相同堆栈的崩溃分类为它的子崩溃（因为这种崩溃已经解决了）。

为了将以后匹配的调用堆栈作为新的父崩溃，可以在父崩溃文档的 Administrative Section 中将崩溃标为已经解决。在视图中，在已经解决的崩溃旁边显示一个绿色的复选标记。

在将崩溃标为已经解决时，可以指出所有客户机/服务器都应用了补丁，也可以输入包含补丁的 Notes/Domino 版本的列表和/或热补丁（见图 11）。故障分析器假设，如果在一个版本中修复了某个问题，那么在以后的版本中它也被修复了（这个规则应用于 Notes/Domino 版本和热补丁，即复合热补丁）。故障分析器还考虑 6.x 和 6.5x 版之间的关系；因此，如果某一崩溃在 6.0.4 中标为已经解决，那么认为它在 6.5.2 中也修复了。

图 11. 将父崩溃标为已经解决

回页首

结束语

您已经学习了 Lotus Notes/Domino 7 中添加或改进的一些可用性特性，这些特性使您能够更好地处理客户机和服务器崩溃。现在就升级到 Lotus Notes/Domino 7，并展望 IBM Lotus Notes 的下一个版本（代号为 Hannover）！