服务管理自动化的监控和故障排除
虽然我写了这篇文章，但希望您不会经常用到其中所介绍的内容。但我们知道，有些时候系统不会像预期的那样运行。当这种情况发生时，我们需要采取一些行动来弄清楚到底是怎么回事，并让系统恢复到健康状态。在本文中，我将向您展示如何监控和诊断 Service Management Automation 中可能出现的问题。
我将介绍三种管理 SMA 基础结构时可能出现的场景，并讨论出现问题时如何接收通知，并提出可行的解决方案。我主要使用 System Center 2012 R2 自带的 SMA 管理包来监控 SMA，然后让 MP 将可以识别的故障排除掉。
让我们从最基本的场景开始，顺便熟悉一下 Operations Manager SMA 管理包及其功能。也许在维护托管 SMA 数据库的 SQL 服务器期间，也许在备份或恢复期间，一件时常发生的事是 SMA 数据库脱机或 SQL 服务器自身没有启动。MP 内置的规则会迅速识别出来并告诉您发生了什么。
从上图可以看出，在 Alerts 视图中触发了一个警报，表明与 SMA Runbook Worker 和 SMA 网络服务数据库的一个连接失败了。该监控还内置了一些有用的知识，告诉您可能产生的原因以及如何对此情况进行补救。然后您可以让数据库重新联机，执行下次测试时，该监控则会自动解决问题。
介绍下一个场景之前，强烈建议您阅读一下 SMA 管理包指南，以便熟悉其中所有的视图、规则和警报，从而调整MP，使其适合您的具体环境。
第二个场景，让我们看看 Runbook 作业在 Runbook Worker 中排队时会发生什么，以及您可以采取的行动。当 SMA 消息队列长度超过指定的阈值（队列默认值是 20 条消息，但是您可以更改该数值），就会触发警报，如下图所示。
在下图中的 Alert Details （警报详细信息）中您可以看到为什么会产生这个警报，原因是什么，以及可能的解决方案等信息。它还显示了警报的配置，如有需要，可以在您的特定环境中重写这些配置。
正如您所看到的，一个可行的解决方案就是在环境中增加 Worker 的角色数量，它允许您同时处理更多的作业，无需形成任务队列。当然，即使我们真的需要这样做，也不会在不了解的情况下贸然添加 Runbook Worker，因为这种情况可能只是一种反常现象（由于某种特殊原因而突然激增的作业），一旦这些作业在队列中被处理完成，Runbook Worker 将回到正常工作状态。
您可以通过调查 Runbook Worker 的过往表现来进行确定。展开 Microsoft Service Management Automation 文件夹，单击 Performance Counters，选择您感兴趣的计数器，并进一步查看具体情况。
从上图中可以看到，消息队列长度中有一个峰值，是我通过运行的 PowerShell 和 SMA cmdlets 产生的：
| 001 002 003 004 | for ($i = 0; $i -le 70;$i++) { Start-SmaRunbook -WebServiceEndpoint $web –Name Sleep5 } |
峰值只持续了几分钟，然后恢复正常。在这种情况下，您可以安全地离开 Runbook Workers，因为这不常发生，现在增加额外的 Worker 也没有意义。
但是如果您发现这种情况已经出现了很多次，并且队列长度也一直在增长，很少返回到零，那么您就需要对其进行关注并采取行动了。当然，警报所给出的解决建议（添加额外的 Runbook Worker ）可能是正确的，应该可以使系统恢复到健康状态。
在开始行动之前，您或许想知道如果让现有的 Runbook Worker 充分发挥它们的潜力将会怎样。MP 团队中的一位同事 Beth Cooper 写过一篇文章，标题为《配置性能最佳的Service Management Automation》，文中讲到，根据系统的能力调整处理作业的 Runbook Worker 数量是可行的。
从以上的性能视图截图中可以看到，我还添加了一个“% Processor Time”计数器，从中可以看出 Runbook Worker 的整体表现如何。接着又添加了“Memory Consumption”计数器来查看过程中是否有任何限制，并了解 Runbook Worker 在正常和峰值条件下的整体概况。如果发现系统中的 Runbook 作业并不是真正的内存或处理器密集型（比如它们主要进行监控和调用其他系统来协调任务），我就可以修改配置，让它可以处理并发作业。
以下内容节选自 Beth 的博客：
在我们的测试中， SQL 的速度一直是最大的瓶颈，特别是在压力条件下。需要弄清楚存储作业的数量以及写入数据库的频率。我们还发现，最好是在特定的Worker 上限制并行作业的总数，并在SMA的配置文件Orchestrator.Settings.config 中设置默认值。
文件中的数值为：
- MaxRunningJobs – 一个Sandbox 可同时运行作业的数量。
- TotalAllowedJobs – 一个Sandbox 在其生存期内可以处理作业的总数。到达限制后，将不再给该Sandbox 分配作业并允许其完成现有的作业。然后释放该Sandbox 。
- MaxRunningJobsPerWorker – 一个Runbook Worker 中现有的Sandbox 一次可以运行并行作业的数量。
- MaxConcurrentSandboxes – 一个Runbook Worker 上可同时运行Sandbox 的数量。当现有Sandbox 达到TotalAllowedJobs 的设定限制时，新的Sandbox 就会被创建，继而处理新的模块版本或其他情况。
建议将任一特定Worker （ MaxRunningJobsPerWorker ）中运行并行作业的数量默认值限制为120 ，您可以修改这个数字，尽管我们不建议增加数字，除非您知道工作负载主要由非资源密集型的Runbook 构成，比如不消耗大量资源却长时间运行的监控作业。
在最后一个场景里，我将向您展示如何监控 Runbook 作业本身，以及当您看到警报时可以采取的行动。针对 Runbook 作业的警报不会自动触发，如果您想生成警报，可以重写其配置。如果您只想全面了解一下这些作业，可以查看 Jobs Failed （已失败作业）、 Jobs Stopped （已停止作业）或 Jobs Suspended （已暂停作业）视图。
上图是一个关于“因异常而暂停的作业状态”的警报，并给出了导致这一暂停的具体问题信息。也可以为停止作业和暂停作业生成类似的警报触发。有了这个信息，您就可以决定这是一个需要注意的问题还是只是在一段时间内就可以解决的瞬态问题（或许在维护期间 Runbook 正在监控的系统已经关闭）。
这些警报都基于写入 Runbook Worker 和网络服务运行日志的 ETW （Windows事件跟踪）事件。
如果您在某一特定计算机上主动排除故障，可以远程进入 Runbook Worker 并查看详细日志。需要注意的是，我们有与 SMA 提供程序相关联的 GUID，如下所示：
<Provider Name="Microsoft-ServiceManagementAutomation" Guid=" {2225E960-DE42-45EA-9940-DB3C9DC96AAF} " />
它所产生的日志事件只针对该提供程序。如果您想获取更多关于 SMA Runbook Worker 或网络服务的附加信息，可以通过启用跟踪特定 Worker 或网络服务来收集更多日志（谁不想要更多的进程日志呢！）
在上图的命令提示符中，我使用了内置的 Windows Longman 工具，通过为 SMA 指定 GUID （如事件日志视图所示）来启动指定的数据收集器。然后就可以重现我在这一特定主机上所看到的问题，最后停止跟踪。
生成的 dumpfile.xml 和 summary.txt 文件中包含了大量 SMA 工作期间所遇到问题的详细信息。
您可以通过该文件解决特定问题，进而帮助您获取整个事件的完整视图。希望您永远不会用到这些跟踪信息，但是如果您发觉某处有些反常，那么它可能是个有用的信息来源。当无需再添加任何额外负载时，请记得停止这些跟踪日志收集器。
最后一点我想说的是，由于我使用的是管理包，虽然我们有“因异常已暂停作业”而发出的警报，但我没有看到针对这些事件的视图。
幸运的是，由于 Operations Manager 的灵活性，使得这样的问题很容易解决。我针对第 3186 号事件创建了一个新的视图（因异常而引起的作业暂停并且不是由客户停止的）。
当您管理 SMA 时，以上内容基本涵盖了您需要注意的监控类型和诊断场景，以及如何解决问题、正确调整环境大小等信息。可想而知，SMA 管理包中还有很多问题我们没有讨论。所以请下载 MP，这是一个非常有用的工具。
祝愿大家的 SMA 监控和故障排除过程顺利！