上节咱们对SharePoint的Web服务所依赖的IIS进行了监视,本节咱们继续深刻对IIS所托管的.NET应用程序性能进行监视,即Application Performance Monitoring,简称APM监视。前端
经过APM监视,咱们能够从服务器端和客户端两方面的角度来监视IIS所托管的.NET应用程序,以得到有关应用程序性能和可用性的详细信息。好比了解问题出现的频率、出现问题时服务器的表现,以及当请求响应慢或引起异常时相关的事件链等。经过这些信息,能够帮助软件开发人员或数据库管理员分析和确认应用程序的问题所在,从而帮助找出事件的根本缘由。数据库
接下来咱们来配置对于SharePoint的APM监视。服务器
1. 导入管理包分布式
APM的管理包可在SCOM的安装目录下的ManagementPacks文件夹中找到。ide
由于.NET应用程序是IIS所托管的,因此上节导入的IIS管理包也同时必要。性能
导入本身系统相对应的管理包,我这里选择的是IIS8,固然也能够都选择。测试
导入完成后,能够在管理包项中确认APM IIS8管理包spa
稍等几分钟就能够在IIS监视的Application Pool State中确认到SharePoint的应用池状态。3d
2. 建立APM监视orm
咱们到创做—>管理包模板中,添加监视向导
选择.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监视,能够极大的帮助咱们分析应用程序性能问题的根本缘由,提升咱们解决问题的效率。