最佳做法：监视或触发，哪种方法更好？

Orchestrator 和许多集成包中的主要功能之一是能够监视对象（数据库、服务器），并在特定条件发生时启动 Runbook。客户在各种任务中广泛使用监视活动。但这是完成任务的最佳方法吗？

首先，我们了解一下 Runbook 服务器如何处理 Runbook。每个运行的 Runbook 在为每个 Runbook 服务器设置的可用 Runbook 阈值限制中都使用一个“值段”。默认情况下，此限制值设置为 50，但实际上，您可以设置更高的值，具体取决于您的 Runbook 在系统上施加的负载类型、服务器的性能特点等（有关更改此限制值的更多信息，请参阅 TechNet：如何配置 Runbook 阈值（英文））。无论限制值是多少，或者您是否并行运行足够的 Runbook 达到此限制值，但它都有一个限制值。对于每个运行的 Runbook - 每个处于活动状态的监视 Runbook，每个 Runbook 和它们可能调用的所有子 Runbook – 都有一个 PolicyModule.exe 实例，并在阈值限制中使用这些值段之一。

除上述情况以外，还要了解您可能有多个监视 Runbook 根据同一数据源运行。例如，您可能在监视 Operations Manager 的特定条件，如特定类型的新警报或者一组计算机的一个监视器的状态更改。这非常类似于您有多个监视器，每个监视器每 5 秒钟轮询一次 Operations Manager 服务器，在 Operations Manager 服务器上施加额外负载，因为它必须每 5 秒钟为 5 或 10 个（还可能更多）不同的监视器执行数据查询。现在跨其他数据源重复此任务，如 Service Manager、Configuration Manager、Virtual Machine Manager 等。您开始会看到这种情况如何对 Orchestrator 以及其他系统造成性能影响。我还希望您在标题中找到了此问题的答案。

如果能够在 Orchestrator 之外的数据源中实现，则最佳解决方案是触发。我的意思说，当外部系统（如 Operations Manager）看到发生特定条件时，主动调用一个 Runbook 使之启动。例如，在收集监视数据和基于该数据触发操作方面，Operations Manager 针对性能进行了高度优化。将另一操作添加到任务列表并根据指定的条件执行是一个最佳解决方案。对于监视器而言，当 Operations Manager 监视一个系统并检测到故障情况时，它不仅仅发出警报，还可能触发一个 Runbook 的启动甚至为其传递参数。使用一个简单的工具（如命令行 Job Runner 实用程序），您可以执行一个补救任务，即执行一个 Orchestrator Runbook。这不但比固定的管理包更为灵活，它们还有跨多个 IT 孤岛的更多功能，并连接到许多 Operations Manager 连接不到的其他系统。您还可以集成 Runbook 来协调与 Service Manager 或具有集成包的任何其他应用程序的操作。

那么对于不能灵活添加操作来调用 Runbook 的那些系统呢？对于这些情况，使用监视器 Runbook 仍然是一个可行的选项，但取决于您希望拥有的各个监视器的数量，您可能希望尝试将监视器聚合到一种“发布者-订阅者”模型中。此类模型将多个 Runbook 所需的查询合并到一个更大的聚合查询中，以便只有一个（或者至少较少）单独查询轮询数据源。然后，基于收到的数据，您设置条件链接，这些条件链接然后触发执行要求的操作所需的其他 Runbook。结果 Runbook 可能类似于以下所示：

您只需基于数据中的差异在链接上设置条件，这些差异确定要调用哪个 Runbook，如计算机名、监视类或状态。使用此方法可以聚合正在远程数据源上执行的轮询，不但可以提高 Orchestrator 服务器上的性能，而且可以释放阈值限制中的“值段”，之所以能够提高远程服务器上的性能，是因为不需要许多独立监视器不断轮询它。

一个较好的发布者-订阅者模型在 Runbook 中只需有一个监视器并在后台只需有一个数据库表来存储订阅者和他们需要激活的数据条件，而不需要添加许多 Invoke Runbook 活动并保持这些活动处于最新状态。但是，这在其他时间又是一个自定义活动…