从 R7 开始，Domino 为用户提供了一个新的监控、分析工具 -- Domino Domain Monitoring。我们通常简单的称之为 DDM。它为系统管理员提供了一个集中的位置、全面的对 Domino 服务器进行监控。对于使用 Domino R7 以及更高版本 Domino 的用户来说，它是最重要、最有效的服务器监控和故障诊断工具，能够帮助管理员进行快速、有效的工作，保障系统的平稳运行。

Lotus Notes/Domino 8 提高了 DDM 的性能，提供了更多的新功能来帮助管理员更好的工作。在本文中，我们将主要讨论 DDM 在 Domino R8 中的新功能及其应用。

DDM -- Notes/Domino 8 优秀的监控工具

DDM 是 Domino Domain Monitoring 的缩写，是 Domino V8 优秀的服务器监控和故障诊断工具。它使用探测器探测域中每一台服务器，并将监控结果发送到一个中心的数据库 Domino Domain Monitor（DDM.NSF）中。Domino 的系统管理员只需要在这一个数据库中，就能够监控域中所有服务器的运行状态，了解产生问题的严重级别，追踪问题、找到问题解决办法。

为了帮助系统管理员降低在系统问题追踪、解决上所花费的时间、精力，DDM 能够自动识别、判断问题，并且对问题进行诊断、分析，提供问题的解决办法。DDM 能够帮助管理员更加快速的定位、解决系统问题，降低因系统问题给企业带来的风险，降低企业在系统维护方面所投入的时间、精力、资金，从而降低企业的总拥有成本（TCO）。

DDM 介绍

从 R7 开始，Domino 提供了一个新的监控工具 -- Domino网络域监控（Domino Domain Monitoring）。这个工具帮助我们对域中的服务器进行集中的监控、管理。它的监控范围从应用程序的监控、到消息监控、再到安全监控，共覆盖了 10 个主要的功能区域。

DDM 对 Domino 服务器进行监控，并生成事件报告。当发现系统问题时，DDM 会分析可能导致该问题的原因，并且提供解决问题的办法。DDM 协助系统管理员快速的定位、解决问题。

DDM 的组件包括：

1. Probes：通过配置 Probe 文档，可以对 Domino 服务器相应功能进行监控。DDM 提供了一组默认的 Probe 文档，供系统管理员使用。
2. Collection Hierarchy：配置 Collection Hierarchy，Collection Server 能够收集其他服务器的监控信息，并将这些信息存储在自己的 DDM.NSF 数据库中。
3. Filters：配置 Filters，可以在 DDM.NSF 数据库中过滤掉那些自己所不关心或不重要的事件。
4. User interfaces：监控配置数据库（Events4.nsf）和 Domino 网络域监控数据库（DDM.NSF）为用户提供了 Domino 网络域监控的界面。监控配置数据库用来对 Probes，Collection Hierarchy，Filters 进行配置；Domino 网络域监控数据库用来存储监控结果信息。
5. Events：当已被启用的 Probes 或事件发生器监控到满足条件的事件产生时，会产生 Events 文档来报告这个事件。

DDM能帮助您做什么？

域中 Domino 服务器的集中化监控、管理

早在 DDM 诞生之前，Domino 已经提供了一系列优秀的服务器监控、管理工具，但是这些工具都很难真正做到对域中所有服务器进行集中化的监控、管理。DDM 提供了一种新的数据收集机制 -- Server Collection Hierarchy 来实现对 Domino 服务器的集中化监控、管理。

通过配置 Server Collection Hierarchy，用户可以选择指定的服务器作为 Collection 服务器，Collection 服务器将收集其他服务器的监控报告，并将这些报告存储到自己的 Domino 域监控数据库中（DDM.NSF）。作为系统管理员，只需要查看 Collection 服务器上的 Domino 域监控数据库，就能够监控到 Collection Hierarchy 中所有服务器的运行状况，追踪问题，寻找解决方案。

Server Collection Hierarchy 为用户提供了一个核心的位置，来监控域中所有服务器的运行状况，实现了对域中所有服务器的集中化监控、管理。

Domino系统的全面监控

不仅实现了对 Domino 服务器的集中化监控、管理，DDM 还提供了对 Domino 系统的全面监控。DDM 能够监控多种系统问题，监控范围包括：

• Administration
• Application Code
• Database
• Directory
• Messaging
• Operating System
• Replication
• Security
• Server
• Web

用户可以选择对其中的一类或者几类问题进行监控，DDM 会将监控报告发送到 DDM.NSF 数据库中。

问题的自动识别、分析

DDM 不仅仅是简单的监控问题、报告问题，它还提供了对问题自动识别、分析的功能。它能够：

• 判断事件状态

  DDM 会根据当前的系统状况，自动报告事件的状态。DDM 事件状态分为：Open、Close、Permanently Close。作为系统管理员，可以根据 DDM 报告的事件状态，来判断当前系统存在的问题。

• 判断事件严重级别

  对于 Domino 服务器产生的问题，DDM 会根据 DDM Probe 中的定义，判断问题的严重性等级，并将它记录到 DDM 事件报告中。严重性等级按照从重到轻是：Fatal、Failure、Warning (High)、Warning (Low)、Normal。作为管理员，可以优先处理严重级别高的系统问题。

• 对事件进行分类

  DDM 会根据事件的不同类型，自动对 DDM 事件进行分类，问题的类型包括：Administration、Application Code、Database、Directory、Messaging、Operating System、Replication、Security、Server、Web。对于一个庞大而复杂的系统来说，系统管理员能够从众多的监控报告中，选择自己所关心的系统问题来查看、追踪、处理。

• 合并相同问题

  同样的问题，可能会在 Domino 服务器上产生多次。在使用 DDM 之前，每产生一次，就会生成一个文档来报告这个问题，这样，系统管理员需要处理大量冗余的数据。使用 DDM，当产生相同问题时，它会对已有的事件进行更新，并且记录每一次事件状态改变的信息。

• 关联相关问题

  在对 Domino 系统的监控中，同一个问题，可能会产生多个事件报告。例如，当某台服务器到目的服务器遇到一个网络问题时，会导致路由、复制或其他更多的问题。每一个问题，都会产生一个相应的事件。

  DDM 能够将所有这些事件进行关联。通过其中的一个事件，可以查看所有相互关联的事件，为快速定位、解决问题提供帮助。

• 分析可能导致问题的原因

  为了帮助管理员的工作，DDM 还会帮助管理员分析可能导致问题的原因。对于系统当前存在的大多数问题，DDM 都会分析可能导致该问题的原因，并将分析结果记录到事件报告中。根据事件的不同，DDM 会提出导致该问题的可能原因或根本原因。它把自己对问题的分析提供给管理员作为参考，帮助管理员快速发现导致问题的原因。

• 提供问题解决方法

  针对系统存在的问题，DDM 还提供了可能修复该问题的解决方法。系统管理员可以参考 DDM 的建议，解决系统问题。

降低企业的 TCO

一直以来，IBM 的工作人员都致力于提供更多、更好、更有效的工具来帮助用户对 Domino 系统进行管理，以降低企业的总拥有成本（Total Cost of Ownership），实现全面管理，DDM 就是其中之一。

DDM 的目的就是帮助管理员快速的发现问题、准确定位问题原因、有效的解决问题。从而保障系统环境的平稳运行，降低因系统问题而带来的风险。

DDM 在 Domino V8 中的新特性

随着 Domino R8 的来临，DDM 也迎来了它的第一次飞跃。在 Domino R8 中，DDM 监控范围更加广泛、使用更安全、能更加有效的协助系统管理员进行工作。

协助工作方面

Event Clearing 的增强

在 ND7 中的事件清理机制中有如下的问题：

1. 绝大多数的事件报告（多于 90%）在解决后不会被清理， 虽然当初的问题已经不再出现，但是它们仍然只是静静的以 open 状态在 DDM.NSF 中，等待管理员去手动关闭。
2. 管理员没有一种有效的方式去分辨，哪种报告是可以自动关闭的，哪种报告是需要手动关闭的，自动关闭的报告不应该被手动关闭，而没有自动关闭功能的报告应该被及时的手动关闭,这样就大大的增加了管理员的维护成本。
3. 因为我们针对事件报告没有一个有效的自动关闭或者管理工具，许多我们希望忽略的或者已经通过折衷方式处理解决的事件报告，仍然会以 open 的状态存在 DDM.NSF 中，原因就在于这样的忽略或者折中处理方式不会被 DDM 所识别、接受、并处理。

下面我们就来看一下在 ND8 中，这些问题是如何被解决的：

1. 在 ND8 中，我们在一些事件中加入了自动探测问题是否已被解决的代码，这样大大增加了具有自动关闭功能的事件报告数量；
2. 加强型事件报告会在报告中指示出是否需要被自动清除；
3. 增加了事件清理探针（Event Clearing probe），这个就是我们新增加的探针类型（Administration/Automatic Report Closing），Domino 管理员可以利用这个新增的探针去指定在哪一台 Domino 服务器上的哪一种(或几种)报告需要被关闭，管理员还能够指定事件报告在打开多少天之后自动关闭。

Automatic Report Closing Probe

我们都知道在 DDM 中，大多数的探针都是用来监测系统问题的。 我们下面要介绍的事件清理探针则是用来处理当前事件报告的。

新建 Probe

打开 Monitoring Configuration 数据库（event4.nsf）在“DDM Probes” 任一子项下点击 “New DDM Probe” 然后选择 “Administration” 建立事件清理探针（Event Clearing Probe）的配置文档。

设置 Probe

Basics选项卡：

在 Basic -> Probe Subtype 下拉框中，选择“Automatic Report Closing”（缺省），在 “Probe Description ”中写入自己的描述，以便探针的区分和管理。

跟以往的探针设置一样，在“Target”栏中，我们提供了三种方式去选择运行 Probe 的服务器：“All Servers in the domain”、“Special Target Servers”和 “Only the following Servers”在默认情况下，系统会选择 Monitoring Configuration(event4.nsf) 数据库所在的服务器为目标服务器。

Specifics 栏是事件清理探针的主功能区，我们可以点击栏中的“Add Error Codes To List”按钮添加需要 DDM 关闭的错误代码，在“Error Codes”选择对话框中，可以在相应的错误代码前端分栏中点击进行多项选择.如果要在已选的列表中删除某些需要关闭的错误代码，我们只需点击“Remove Error Codes from List”，在弹出的“Error Code” 对话框中选中要删除的错误代码点击“OK”完成删除。

在“Number of days to remain open”中写入上边列表中要关闭的错误代码维持 open 状态的时间段,图中输入为“7”，即列表中需要关闭的错误代码可以仍然在 DDM.NSF 中以 open 的状态存在 7 天，目前这里只支持 1～90 天的时间设置。

Schedule选项卡：

在 Schedule 选项卡中我们可以灵活的设定 Probe 的运行频率，在 Schedule 中分为“Run multiple times per day”，“Daily”，“Weekly”和 “Monthly”。 管理员可以根据域中服务器的活动规律和数据处理量来自行的选择 Probe 运行周期，为了避免由于 Probe 所在服务器宕机导致运行周期比较长的 Probe 在指定时间无法运行的问题，当 Probe 被设为“Weekly” 或 “Monthly”时，我们可以在“Missed Probes” 栏中对 Domino 服务器宕机期间不能按指定时间运行的 Probe 进行再次运行的设置，包括“Ignore missed probe”， “Run missed probe on startup”，“Run missed probe at next time range”。

运行 Probe

设置完成后点击 Probe 配置文档左上方的“Save & Close”完成 Probe 设置的保存，然后在 Probe 运行的 Domino 服务器端服务器控制台上键入“restart task event”使新增加的 Probe 加到探测队列中开始工作。

当 Probe 到达了设定的触发时间点，就会发现在 DDM.NSF 中，我们选定的符合关闭时间条件的事件报告已经被置成关闭状态。

当关闭事件被再次触发的时候，DDM 就会将事件报告再次变为“Open” 状态，以提示管理员，所报告的问题仍然存在。

Common Actions 按钮

Common Actions 是 ND8 中新增加的一个按钮列表，它提供了一些为了调查、解决问题所最常用的操作。用户可以选择需要解决的 Event，并且选择一个相应的操作来进行处理。在这项操作中，管理员必须在存取控制列表中具有“Execute CA”的角色。

以当前截图为例（截图是 probtest.nsf 超过数据库容量限制的事件报告），在报告中：

• 点击“Open Server Document”的子项可以打开 probtest.nsf 所属服务器的 Server document。
• 点击“Open Domino Server Log”的子项，可以打开 probtest.nsf 所属服务器的 log.nsf。
• 点击“View Notes.INI”的子项，可以打开 probtest.nsf 所属服务器的 NOTES.INI。
• 点击“Open Remote Server Console”可以打开一个 live 状态的 remote console 输入窗口。通过这个窗口，我们可以向域中所有服务器发送命令，并能在窗口中看见命令的执行反馈。
• 点击“Send Email to Managers of probtest.nsf”可以直接创建一封新邮件，在“to”一栏被自动填入 probtest.nsf 存取控制列表中，所有具有 manager 权限的用户。

Modular文档与“Server and Addin Task Event”文档

在 ND8 中 DDM 新增加了模块化文档。这种文档是用于“可能原因（Probable Cause）”、“可能解决方案（Possible Solution）”、“补救措施（Corrective Actions）”语句的参考文档。每个参考语句都对应一个模块化的文档。创建“Server and Addin Task Event”后，选择要包括在该文当中的“可能原因”、“可能解决方案”和“补救措施”的语句则可从模块化文档中引用。使用模块化文档的好处正在于模块化的概念，您只需要定义这些语句一次，便可以将它用于任意数量的事件。模块化文档的修改也是全局变量的修改。

在 ND8 中提供了一整套完善的模块化文档。随 Domino 提供的所有 Lotus 生成的“可能原因”、“可能解决方案”和“补救措施”文档都是缺省启用的，而且不允许被改动。我们可以根据自己的需要新建模块化文档。

Modular 文档

打开 event4.nsf，点击“Advanced”－>“Modular Documents” 视图，我们就可以看见当前包含的所有模块化文档。

点击“New Modular Document”进入新模块的定义文档，我们可以将新模块定义成五种类型：“Probable Cause Text”、“Possible Solution Text”、“Corrective Action－Formula Code”、“Corrective Action－LotusScript. Code”、“Corrective Action－Agent”。

• Probable Cause Text：选中“Probable Cause Text”，在“Text”域中写入想要填写的事件发生可能原因，保存并关闭。
• Possible Solution Text：选中“Possible Solution Text”，在“Text”域中写入想要填写的解决方案，保存并关闭。
• Corrective Action－Formula Code：选中“Corrective Action－Formula Code”，在“Descriprton”中填写对这个模块的简单描述，然后在“Code”域中，加入你想写入的 Formula，保存并退出。
• Corrective Action－LotusScript. Code：选中“Corrective Action－LotusScript. Code”，在“Descriprton”中填写对这个模块的简单描述，然后在“Code”域中，加入你想写入的 LotusScript，保存并退出。
• Corrective Action－Agent：选中“Corrective Action－Agent”在“Descriprton”域中填写对这个模块的简单描述，然后将“Server Type”选成包含 Agent 的数据库所在的服务器，在“Agent Database”中写入 Agent 所在数据库的名字，最后将 Agent 的名字写入“Agent Name”中，保存并退出。

“Server and Addin Task Event”文档

在上述定义好自己的模块文档后，我们就可以在“Server and Addin Task Event”选取、添加我们的自定义模块文档。打开 DDM.NSF 中的一个事件报告，点击“Serverity and type”的链接，就会进入到与当前事件相关的“Server and Addin Task Event”文档。我们可以对该文档进行编辑，并加入我们自己定义好的模块文档。我们还可以对“Server and Addin Task Event”的基本属性进行修改。

在下表中列出了文档的基本属性：

我们自己定义的模块文档需要在“Custom Entries”选项卡里进行添加、更换和删除。

在下一次同一类型的新事件被触发时，事件报告给出更改以后的“可能原因”、“可能解决方案”和“补救措施”。

我们除了在原有的“Server and Addin Task Event”文档中进行改动之外，还可以自己新建。在 event4.nsf 中点击“Advanced”下的任一“Event Messages by ......”视图，点击上方“New Message”按钮，就可以建立自己需要的“Server and Addin Task Event”文档。

“By Database”视图

在 DDM.NSF 中增加了“By Database”视图，管理员可以通过这个视图很方便的去关注自己所关心的具体数据库中的事件报告，这样就大大缩减了管理员原来在查找具体数据库问题时所花费的时间。

打开 DDM.NSF，点击“By Database”右侧视图就会将现有的事件报告按数据库（模板）分组的方式显示出来。

监控范围方面

LDAP Search Response Probe

目录部分，以前在 ND7 中，我们可以通过 DDM 监测：LDAP 处理是否正在运行， LDAP 是否监听在它的端口并且响应迅速，服务器正在使用的 LDAP 视图更新算法等。 在 ND8 中增加了一个新的探针 —— LDAP Search Response Probe。这是目录探针的一个子类型，可以有效的探测 LDAP 搜索的平均响应时间，管理员可以选择监测运行服务器上执行的所有搜索，还可以将监测限制在 LDAP 服务器内存中运行时间最长的搜索。LDAP Search Response Probe 会对 LDAP statistics 进行收集，如果收集的相应数据超过了设置的边界值，探针就会在 DDM.NSF 中建立事件报告，反映给服务器管理员。探针一旦建立便会实时产生事件报告，而不需要管理员对时间表进行设置。

新建 Probe

打开 Monitoring Configuration 数据库在“DDM Probes”任一子项下点击“New DDM Probe” 然后选择“Directory”建立目录探针的配置文档。

设置 Probe

在探针配置文档将“Probe Subtype”选成“LDAP Search Response”既可以对探针进行配置（注: 如果在“Probe Subtype”选项列表中没有“LDAP Search Response”，可以先选择别的子项，然后再重新打开下拉菜单，即可看见“LDAP Search Response”选项) 。

关于“Target”一栏的设置，我们在事件清理部分已作详细说明，这里就不再介绍。

用户在“Specifics”栏中可以设置“Warning Low”、“Warning High”、“Failure”、“Fatal” 和各个严重性等级的触发边界，在每一个边界的设置上我们可以提供两个条件，一个是具体时间，一个是响应延时的百分比。

在设置与 LDAP Server timeout 百分比时，我们需要在 ALL Server Configurations Document 里将 LDAP 选项卡里边的“Timeout”，“0”换成想要设置的具体数值，具体的设置可以根据 LDAP 服务器的实际情况，给出一个合理的边界。

如果不勾选“Limit reporting to the average search responses times stored by the LDAP Server”DDM 就将“LDAP.Average LDAP Search time”与设定边界值比较，反之则会将“LDAP.Search.Longest.AverageTime.01”与设定边界值进行比较，进行时间报告的触发。

运行 Probe

设置完成后点击探针配置文档左上方的“Save & Close” 完成探针设置的保存，然后在 Probe 运行的 Domino 服务器端服务器控制台上，键入“restart task event”使新增加的Probe加到探测队列中开始工作。

打开一个 LDAP 终端，进行大流量的 LDAP 搜索，如果变量（根据设置）“LDAP.Average LDAP Search time”或“LDAP.Search.Longest.AverageTime.01”满足触发条件，我们就会在 DDM.NSF 中看见有关 LDAP Search Response 的事件报告。

事件报告触发后，只显示最高级别的事件。在事件描述中也会显示对应的搜索时间。当触发条件不满足时，系统会自动将报告状态置为“Close”，严重级别变为“Normal”。

安全方面

“Excute CA”角色

“Excute CA”角色是 ND8 专门为加强 DDM 安全性而量身定做的,用户通过加载“Excute CA”角色，可以实现对“Corrective Action”、文本和链接的访问和修改。

在 DDM.NSF 的存取控制列表中，点击想要添加角色的用户，在右下方的角色添加栏中选中“Excute CA”即使用户获得了 Excute CA 的角色。

DDM 使用方法及建议

DDM 使用方法

如何使用 DDM 来帮助我们工作呢？让我们首先来看一下 DDM 的使用流程，如图：

• 定义服务器收集层次结构

  我们已经知道，DDM 能够将系统中多个服务器的监控事件报告到一个收集服务器上，供管理员使用。如何实现呢？这就需要我们配置服务器收集层次结构来指定收集服务器去收集被监控服务器的 DDM 事件。

  在配置服务器收集层次结构之前，作为系统管理员，首先需要根据系统的实际情况，规划这个层次结构。

• 配置 Probe

  目前，DDM 能够监控 10 个方面的系统问题，但并不是方方面面的问题，我们都需要进行监控。作为系统管理员，我们首先要确定我们所关注的方面，然后配置适当 Probe 对系统进行监控。

• 查看 DDM 产生的事件

  当 Probe 开始工作时，它会对系统进行探测，并将探测结果报告到 Domino 域监控数据库（DDM.NSF）中。在 DDM.NSF 数据库中，提供了多种查询视图，系统管理员可以根据需要以不同方式查看事件。

• 分配事件给系统管理员（可选）

  DDM 有另外一个功能，就是可以把指定的事件分配给指定的系统管理员。当事件被分配以后，被指定的系统管理员可以仅仅关注、处理所有自己名下的系统问题。这样就减少了系统维护过程中出现的混乱情况。

  该步骤为可选步骤，用户可以根据实际情况来确定是否需要对 DDM 事件进行分配。

• 分析、解决、追踪问题

  接下来，系统管理员就可以根据 DDM 事件中报告的内容，对系统问题进行分析、解决。DDM 不是简单的对系统问题进行描述性的报告，它会对系统问题进行分析，并提供解决方案，供系统管理员参考。

  系统管理员还能够通过 DDM 对相关、相同问题的关联、合并来对系统问题进行追踪。

DDM 使用建议

以上是一个概要的使用方法说明，在部署 DDM 的时候，我们首先需要对实际情况进行分析、规划后，再进行配置。在部署 DDM 过程中，建议注意以下几点：

• 在部署 DDM 之前，首先需要根据 Domino 系统环境的实际情况，规划好 DDM 层级结构。如果系统环境中服务器数量较多，建议部署成多个层级的树型结构。在规划的时候，建议配置两个或以上的服务器收集层次结构，来对服务器进行收集。需要注意的是，DDM 只能收集 Domino R7 及以后版本服务器探测事件。
• 大多数 DDM Probes 只支持 Domino R7 以及以后的版本，所以在比较复杂的混合环境中，要注意配置适当的 probe 对系统进行监控。
• 在配置 Probe 的运行时间时，建议根据服务器情况以及 Probe 的类型，选择服务器相对空闲时间运行 Probe。
• 当想要从域中撤销服务器的时候，首先需要检查服务器收集层次结构中是否包含该服务器。如果包含，需要首先将其从服务器收集层次结构中删除，然后再将其从域中撤销。否则，可能会导致撤销服务器之后数据积累出现问题。

结束语

DDM 是一个强大的监控和事件管理工具。正确地部署 DDM，能够帮助系统维护、管理人员快速定位、解决 Domino 系统问题，从而提高 Domino 系统环境运行的稳定性。本文目的是希望能够通过介绍 DDM 以及 DDM 在 Domino V8 中的改进与增强，帮助系统管理、维护人员了解 DDM，对 DDM 进行部署。