System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视

 上节我们对SharePoint的Web服务所依赖的IIS进行了监视，本节我们继续深入对IIS所托管的.NET应用程序性能进行监视，即Application Performance Monitoring，简称APM监视。

通过APM监视，我们可以从服务器端和客户端两方面的角度来监视IIS所托管的.NET应用程序，以获得有关应用程序性能和可用性的详细信息。比如了解问题出现的频率、出现问题时服务器的表现，以及当请求响应慢或引发异常时相关的事件链等。通过这些信息，可以帮助软件开发人员或数据库管理员分析和确认应用程序的问题所在，从而帮助找出事件的根本原因。

接下来我们来配置对于SharePoint的APM监视。

1. 导入管理包

APM的管理包可在SCOM的安装目录下的ManagementPacks文件夹中找到。

因为.NET应用程序是IIS所托管的，所以上节导入的IIS管理包也同时必要。

导入自己系统相对应的管理包，我这里选择的是IIS8，当然也可以都选择。

导入完成后，可以在管理包项中确认APM IIS8管理包

稍等几分钟就可以在IIS监视的Application Pool State中确认到SharePoint的应用池状态。

2. 创建APM监视

我们到创作—>管理包模板中，添加监视向导

选择.NET应用程序性能监视

定义名称和目标管理包

现在我们选择SharePoint的Web应用程序

定义环境：这个可以根据实际情况选择，最后会体现在监视名称上。

目标组：我们选择之前定义的SharePoint前端组，表示这里成员是测试环境的服务器。

在服务器端配置中，可以启用客户端监视。

但是要注意：SharePoint不支持客户端APM监视，如果强行启用SharePoint的APM监视，则可能会导致不可预计的应用程序行为和故障，比如CPU过载问题等。

所以这里不勾选客户端监视

点击高级设置，可以对敏感度阈值，监视器阈值等进行详细设置。

这里阈值还是使用默认的15000毫秒，即15秒。

最后在摘要中，我们发现一个警告，需要在目标的服务器上重启IIS。

创建完毕后可以在APM监视项中发现我们刚才创建的监视

3. 重启IIS

我们可以直接到前端服务器上去重启IIS

或者也可以到计算机监视中，点开警告德的运行状况管理器

在解决方法中，进入运行重启IIS的运行任务

运行后成功重启目标计算机的IIS

4. APM监视

现在进入应用程序监视，稍等片刻后，就会出现我们之前创建的SharePoint APM监视。

进入所有性能数据，可以查看各个前端的性能数据。比如我这里选择了2个前端的平均请求时间，从性能上来说，这个数据很不理想。

现在进入活动警报，发现已经有一些性能异常的警报了，都是网页的相应时间超出性能阈值引起的警报，包括有关其来源、规则、创建日期以及导致发出警报的监视设置的信息。

5. APM警报分析

接下来我们来简单分析下这些APM警报

点开警报属性，可以查看警报描述。

点击描述中的链接，可以打开Application Diagnostics，查看详细信息。

Application Diagnostics是SCOM的新监视功能。

比如，在事件属性项中，可以查看性能指标、调用堆栈和集合注释等性能信息。

进入资源组视图，可以分析导致问题的原因，定位问题的地点，查看问题发生是的具体的行为等等。

比如这里，分析发现WCF : Microsoft.Office.Server.UserProfiles.IProfilePropertyService.GetProfileProperties (). Client side行为花了20,741毫秒，严重的影响性能。

即在客户端处在取得用户的账户属性时，超时。问题原因一下就找出来了。

结合实际，因为这个警报是第一次进入SharePoint首页时发出的，系统在得到初始数据时花了不少时间，还属于正常，可以原谅。

在相关事件项中，可以查看和此事件相关的事件。相关事件是大约与正在调查的事件在同一时间发生的事件，可以告诉我们大约与正在调查的事件在同一时间发生的其他事件，帮助调查事件原因。

在分布式链项中，可以查看此事件与事件链中的其他事件之间的关系。要确定问题或事件的根本原因，可以单击链中的最后一个事件，这是突破性能阈值的最后一个事件。

因为我这事件链中只有一项，所以也就是这项导致阈值超出警报。

 

   
在性能计数器项中，显示了事件发生之前15分钟的系统情况。这提供了事件之前的基准度量，利用此度量，可以查看事件之前的系统状态，以便知道系统是否影响了应用程序的性能。

怎么样，APM监视的功能还是很强大的吧？利用好APM监视，可以极大的帮助我们分析应用程序性能问题的根本原因,提高我们解决问题的效率。