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


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


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

1. 导入管理包

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

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第1张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第2张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第3张图片

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

clip_p_w_picpath008


2. 创建APM监视

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第4张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第5张图片

定义名称和目标管理包

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第6张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第7张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第8张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第9张图片

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

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

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第10张图片

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

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第11张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第12张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第13张图片


3. 重启IIS

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第14张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第15张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第16张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第17张图片


4. APM监视

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第18张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第19张图片

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第20张图片


5. APM警报分析

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

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第21张图片

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

Application Diagnostics是SCOM的新监视功能。

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第22张图片

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

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

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

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第23张图片


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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第24张图片


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

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第25张图片 

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

System Center 2012 R2实例3—SCOM之SharePoint全方位监视16—APM监视_第26张图片

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