大家好，今天我来为大家介绍SCOM中的APM监控。
很多人都知道，SCOM可以针对于企业的IT基础架构做一个自下向上360度的监控，其实SCOM除了可以针对于企业IT基础架构做出这种完整的监控
它还可以针对于我们企业的应用程序进行监控，也就是今天我要讲的APM
那么，到底什么是APM呢？APM，全称是Application Performance Monitoring，翻译过来就是应用程序性能监控，许多初学者或者不了解的人，可能会问，你这个应用程序性能监控，到底是什么意思？企业有必要做这种监控吗？ 其实，这种应用程序监控，我想绝大部分公司都会去做，尤其是互联网公司。我举个例子，比如说，一家XX电商公司，这个月上线了一个新的web应用程序，包括Web前端，中间层，数据库层，构建出来的一套完整应用程序，这套程序现在代码已经写好了，马上准备上线，上线前我们会对这个应用程序，进行很多的监控，测试，修复，调试，最终确认，这个应用程序可以推上线了，再进行正式的上线，APM就是负责，应用程序上线前，以及上线初期的监控，APM可以帮助我们进行端到端的监控，监控一个应用程序从web层到中间层到数据库层的整体的应用程序性能以及应用程序故障，甚至可以深入到代码级别，数据库查询语句级别，这就为企业的IT运维带来了很大的便利。
设想一下，原来企业中，应用开发组与服务器运维组是分开的，服务器运维人员只负责服务器以及机房的监控，应用开发的人，只负责代码，需要服务器，服务器运维人员给他开一台就是了，两者之间根本没有什么过多的交集，应用程序出现性能故障了，服务器运维人员也不知道，也不懂，可能等过一段时间应用程序确实出现了很严重的性能问题，开发人员才会知道，我打的这比方，我想也许就是传统的IT企业现状，那么有了微软的私有云，有了微软的SCOM之后，你再也不需要这样做了，我们可以SCOM去监控我们企业所有的IT基础架构，以及应用程序，所有的这些监控数据，都在SCOM的统一界面进行展示，管理员只需要在一个SCOM界面下，就可以总览全局。
假设，XX应用程序出现性能故障问题，SCOM就会第一时间产生警报，企业的IT管理员发现之后，就可以第一时间在SCOM中，将这个警报分配给应用程序的管理员，然后应用程序管理员通过不同的警告方式查看到这个警报，登录到SCOM专门为应用程序开发人员准备的APM网站，去查看具体是那个应用程序，那个模块，那个组件，那个代码，数据库的那个查询出现的问题，然后开发人员根据网站上的提示，去修复自己的程序，程序好了后，SCOM中的警报自动解除，应用程序重新上线，同时将这个错误记录在SCOM应用程序的数据仓库内以供日后分析，这就是有了APM监控之后的一套流程。
其实这种APM很多软件公司，都在做，一套完整的APM，一般具备以下特征：深入诊断应用程序、服务端可用性监控，客户端最终体验监控，基于异构Web应用程序监控，分布式应用程序监控，业务事务监控，应用程序SQL与web前端的关联性监控，如下图所示。
一套完整的APM监控系统，监控的流程如下：首先最终用户，打开网页，与应用程序发生交互，APM程序以一种钩子的形式，将监控程序挂在.NET运行时，当用户与网页发生交互的时候，APM就会捕捉到用户的体验，比如用户访问网站的最终时间，DNS解析的时间，从这个web页面查询数据到数据库花了多少时间，Ajax加载用了多久，每一个请求所花费的时间，以及请求中详细的代码，APM都会监控到，监控到了客户端的体验后，APM就会再深入一层，去深入诊断应用的性能，比如说按照性能计数器，查看Web应用程序的每秒请求，去诊断整体web应用程序之间的关键组件的关联性，然后最后，是通过ASP.NET探测， JMX，JDBC，脚本，事务，可用性探测等方式，帮助我们准确的服务器端定位到问题所在，最终把问题呈现在警报，性能，分布式应用程序，APM界面，供管理员分析，应用程序人员调试。
在上面，我简单的为大家介绍了一下，我所理解的APM，说的可能也会有不对的地方，也欢迎大家给我指正，多谢。
那么，说完了APM的大概，接下来我们再来说说微软SCOM中针对于应用程序监视的解决方案。
在最新的SCOM中，针对于应用程序监视监控，有以下几个模块
l 服务端
Web应用程序事务监控:通过Web应用程序事务监控，可以在服务端，针对于指定的URL，Web服务器，进行HTTP，DNS相应，应用程序整体相应时间的探测，我们还可以在服务器端配置基于浏览器的捕获，捕获指定URL的状态代码，响应时间，DNS解析时间，内容哈希，还可以根据自己的需求，定义，如果访问出现指定代码，或者响应时间，大于指定时间，则生成警报。针对于Web应用程序事务监视的数据，可以在警报，报表，AppAdvisor进行查看
Web应用程序可用性监控：通过Web应用可用性监控，我们可以去监视指定URL的可用性，同时也可以选择URL的所在地，也就是URL是由那几台Web服务器构成，然后通过指定的观察点，每隔60秒，去探测应用程序的可用性，可以自定义测试间隔，以及探测过程中，满足那些其它规则进行产生警报，Web应用程序可用性也可以针对于HTTP代码，内容匹配，重定向，HTTP相应，DNS解析，内容匹配，进行详细的监视设置，针对于Web应用程序可用性的监视，可以在Web应用程序可用性的仪表板中，查看到详细到关于Web应用程序的详细性能图表，也可以在可用性报表，AppAdvisor中查看。
TCP/IP监控：通过TCP/IP监控，我们可以以最简单的方式去探测一个IP地址端口的可用性，比如说，我们输入一个Web服务器的地址，端口为80，然后指定一台观察点，比如说观察点是一台普通机器，通过这台观察点，就会每隔60秒去telnet这个IP地址的端口，如果能通，就是正常的，如果不通，则产生警报，在我日常做项目中，一般TCP/IP监控，都是用一台机器作为观察点，去探测一个Web应用程序的NLB IP地址，注意，TCP/IP监控中的IP地址，可以是一个NLB地址，通过观察点去探测一个应用程序前端NLB的IP地址，一般来说，NLB都至少是由两台组成的，一般来说，如果一台当掉，那么这个NLB IP地址，仍然是可以可以正常telnet到的，如果是NLB地址都探测不到，不通了，那么就说明前端的Web服务器彻底当掉，所以这也是警报级别较高的一个警报，再有就是，以后端的Web服务器作为观察点，定时去探测后端SQL服务器的端口可用性。
APM应用程序监控：通过SCOM中的APM，可以进行深入的应用程序故障诊断，通过WCF，MVC， .NET Windows services的方式为应用程序提供深入代码级别的监视，从服务器到客户端，端到端级别的监视， APM的服务器端监视会在后台自动帮助我们关联应用程序的web层，中间层，数据库层以一个整体来进行监视，通过定义应用程序监视参数，以满足企业针对于应用程序SLA的要求，APM的监视信息一共分为两种，一种是应用程序性能，一种是应用程序故障，那么应用程序性能里面存放了些什么数据呢？比如说，用户访问一个网站，正常来说我的这个应用程序构建出来的网站，访问只需要10秒，但是实际上，访问这个网站用户竟然用了30秒，这就明显的出现了性能问题，这种情况下，在应用程序性能视图里面，就会将APM捕捉到用户访问从客户端到服务器，整体的过程重现出来，并且会告诉应用管理员，在每一个步骤，用户所花费的时间，比如用户在web services调用那里，花了10秒，在数据库查询某某某字段的时候，花了10秒，实现了耗时体验的功能，这样的话，对于企业的开发人员应用程序管理员来说，就更加容易去进行分析。另外一个应用程序故障，则是存储着应用程序错误的一些信息，比如说，用户查询一个网站的内容，没有查找到，用户没办法提交内容，等等，这些错误信息，就会被记录到应用程序错误里面，然后应用管理员登录到APM网站之后，就会看见这个错误，点开之后，APM就会告诉你，是哪个模块，哪个查询，哪个语句，导致出现的问题。在SCOM的APM网站中，应用管理员既可以针对单个错误或者性能数据进行监控，也可以针对于某个时间段所产生的错误和性能信息进行统一的监控。还可以针对于某个特定的错误事件，发现历史上与它关联的事件，还可以在APM网站，直接去查看应用程序后台服务器的运行情况。
全球服务监控：通过SCOM中的GSM全球服务监控，我们可以实现，针对于应用程序分布在全球各地的站点，进行集中的监控，通过SCOM中的GSM，可以帮助我们在地图上，定位出不同站点的坐标，然后在一个类似于地图的摘要仪表板中，为用户展示分布在不同城市的应用程序可用性状态，最新的GSM更新了多级联合网络测试的功能，这项功能可以帮助我们测试，不同城市，不同站点，访问网站时网站的性能。
SLA仪表板：在SCOM中，我们可以基于应用程序，或者基于服务器的运行情况来进行SLA的配置，所谓SLA，其实就是让某些IT服务，满足一个你与IT服务商一起共同制定的服务级别协议，来校验实现高效的IT服务，比如说，我定义了一个SLA值，我的应用程序可用性，停机率低于百分之10就是正常，高于百分之10就是不正常，那么你就可以在SCOM中进行这样的定义，定义好了后就会在SCOM中的SLA仪表板进行显示，如果满足服务级别协议，就是绿色，不满足就是红色。
l 客户端
APM应用程序监控：在SCOM中，APM同样支持针对于客户端的监视，如果要配置客户端监视，要求必须已经配置了服务端监视，通过APM监视收集最终用户使用浏览器访问网站所产生的性能信息和异常信息，一旦我们为APM监视向导启用了客户端监视后，那么APM就会为你的应用程序动态网站，在前端注入一小段js程序，当最终用户通过浏览器与应用发生交互的时候，这一小段js程序，就会去捕捉用户访问的过程，然后把这个过程，传回到SCOM中，这个过程就包括了，用户访问网站所耗费的时间，DNS解析的时间，Ajax加载的时间， 用户访问网站的方法调用，访问过程与应用程序一些脚本，asp.net控件的交互，都会包括在这个过程中。一旦SCOM的GSM接收到了最终浏览器传入过来的数据后，就会把数据存放在SCOM的数据仓库，然后调用到APM网站。
Web应用程序事务监控：启用了Web应用程序事务监控后，同样也可以在客户端进行基于浏览器的事务监视。
l 应用程序关联
分布式应用程序监控：通过SCOM中的分布式应用程序监控，可以自己设计，服务企业内部的分布式应用程序监控模板，比如说，可以在分布式应用程序模板中设计，XX应用程序，具备Web层，中间层，数据库层。然后，就是分布式应用程序监控发挥作用的时候了，通过分布式应用程序监控，可以帮我们定义业务之间的关联关系，我们可以在数据库层，添加进来应用程序所需要的数据库，数据库日志，在中间层添加进来中间件，比如说sharepoint的运行状况，在前端添加，Web应用程序，一个IIS网站，或者是java的网站。然后，配置他们之间的依赖关系，通过关联线的方式，比如说，指定，前端依赖于中间层，中间层依赖于数据库层，然后将设计好了的模板创建，就会出现这样一个整体的分布式应用程序的视图，SCOM中的分布式应用程序设计，是非常简单的，只需要通过拖拽，选择的方式，就可以帮助我们快速的定义出应用程序之间的关联性，有了这样的一个自定义的分布式应用程序视图，就可以帮助业务人员，更好的了解的业务系统整体的组件，运行情况。
应用程序系统级别监控：在SCOM中，有一个很重要的概念，叫做组，其实也是属于class类，我们可以在创作视图里面，通过创建组的方式，将不同的对象，加进来，然后在监控视图中，创建针对于组的视图，视图创建出来，显示的视图就是针对于整个组的数据，举个例子来说，有一个人力资源管理系统，下面有Web层，中间层，数据库层，现在我想要了解整个人力资源系统的可用性，我们应该怎么做？一种方式是通过web应用程序可用性监视，另外一种，就是针对于组进行监视，我们在Web层，添加Web层的服务器，在中间层，添加中间层的服务器，在数据库层，添加数据库层的服务器。然后，我们将web层，数据库层，中间层，这三个组作为“子组”的形式，统一加入到人力资源管理系统这个大组，这时候，这个人力资源管理系统大组，就包括了这个系统所有的的服务器。然后我们去创建一个图示视图，在对象中，选择人力资源系统这个组来作为监控，这样做出来的效果就是，在一个图示视图中，最上层，是人力资源系统这个大组，整体的可用性状态，点开加号，在下面，分别是web层，中间层，数据库层的可用性，然后点开web层，下面就是web层中每一个服务器的可用性状态。这样，我们就实现了应用程序系统级别监控，这也是SCOM中很重要的一个概念，我接触很多国外的公司，在应用SCOM的时候，都会采取这种方案来做，或者你可以再将所有系统的web可用性，加入到一个大组中，然后通过统一的一个大组，来展示所有系统的整体可用性。
以上，就是我根据自己理解所总结的微软SCOM中针对于应用程序监视的一整套解决方案，其实微软SCOM中，不仅可以监视针对于sharepoint，exchange，Dynamics CRM，ERP等原生产品进行APM监控，也可以对基于.NET开发的应用程序进行APM监视，还可以监视WebSphere、WebbLogic、JBOSS和Tomcat上运行的Java程序，同时，支持针对于Java应用程序的深入监控，最新的SCOM2012R2，也可以针对于Java应用程序配置APM。
下面，我通过一个demo，来为大家演示，SCOM中如何配置APM。
首先，我们先来看一下SCOM中配置APM的思路
配置步骤如下
u为需要进行APM监视的计算机添加SCOM代理
u确保已经导入对应Windows OS系统管理包
u导入APM对应IIS平台的管理包
u导入CRM系统的管理包
u导入APM管理包
u新建.NET APM监视
u根据提示重新启动IIS
u服务器自动启动APM监视服务
u等待Web应用程序数据收集
首先，我们先来配置一下，SCOM针对于Dynamics.CRM的APM监视，添加客户端代理的步骤，我就不写了，如果需要进行APM监视，需要导入如下这些的管理包，你是什么平台，就导入什么样子的管理包，一定要是对应的。
Microsoft.Dynamics.CRM.2011.mp
Microsoft.Windows.InternetInformationServices.2008.CHS.mp
Microsoft.Windows.InternetInformationServices.CommonLibrary.CHS.mp
Microsoft.Windows.InternetInformationServices.CommonLibrary.MP
Microsoft.SystemCenter.Apm.Web.IIS7.mp
Microsoft.SystemCenter.Apm.Web.IIS8.mp
Microsoft.SystemCenter.Apm.Web.mpb
Microsoft.Windows.Server.2008.Discovery.mp
Microsoft.Windows.Server.2008.Monitoring.mp
打开SCOM管理控制台，选择‘创作’新建.NET应用程序性能监视
输入友好名称及创建目标管理包，这个目标管理包，建议手动新建，不要使用默认的，而且建议不同的创作，使用不同的管理包。
选择要监视的CRM Web内容，默认对服务器推送了SCOM代理，并且导入了相应的管理包后，就会自动发现出环境里面所有的Web 应用程序和服务，这里就是根据需要进行APM监视的应用程序，去选择添加对应的Web应用程序。
添加应用程序组件
配置服务端性能监视警报及性能阀值，注意，下面那个，启用用于服务器端和客户端监视的其他配置选项，如果你希望启用客户端监视，那么你就把它勾选上。
进行服务器配置，在这里我们就可以定义，需要监视那些性能，那些异常，以及应用程序监视的阀值。
分别创建Web应用程序的ASP.NET事务页面设置
确认服务器端自定义设置
进行客户端配置，选择监视性能事件警报和异常事件警报，选择高级设置，可以进一步配置客户端监视的详细规则。
选择需要启用客户端监视的Web应用程序
确认一遍摘要，查看自己的设置是否有问题，如果配置没问题的话，根据提示重启目标服务器IIS，注意，这里如果你希望进行APM监视，是必须要重启一次Web应用程序服务器IIS的，但是你不必立刻重启，可以等到一个方便重启的时间再进行重启，总之，等到重启之后，才会在服务器上启动APM监视服务，APM监视才会生效。
.NET APM监视创建完成
打开Windows计算机，选择CRM计算机，查看警报
在警报视图中，远程重启目标服务器IIS
查看输出，重启成功
目标服务器 APM服务自动启动
等待收集几分钟后SCOM控制台就可以收集到APM基本信息，此过程视服务器性能，以及应用程序多少，来决定
打开Application Diagnostic网站 查看CRM网站APM性能及应用程序错误，这个也就是我之前一直说过的APM监视网站，这个网站就是专门用来给应用程序人员来做应用程序监视的。
我们随便点开一个请求，就可以查看到，该请求的耗时体验，
以及详细的，代码级别的APM数据
还有一个AppAdvisor，这个是用于SCOM本地私有云环境的，Web方式SCOM应用程序报表展示，该网站存放了许多关于应用程序，客户端监视，服务器监视，网站访问请求，问题统计等关于应用程序报表，供应用程序人员分析。
以上就是SCOM中APM的配置步骤，以及效果展示，希望可以为您带来帮助。
其实关于应用程序监视，并不只是可以用在应用程序测试上线的时候会用到，有的比较关键的业务系统，也可以通过微软的APM进行长期的监视，出现问题，第一时间知道，第一时间修复，如果不想针对指定的服务器进行监控了，把APM服务停止掉就可以了，很多人可能会担心，一旦我针对我的业务系统上了微软的APM，那么会不会对我的业务系统产生性能的影响，根据微软内部的专家人士说法，SCOM中的APM是基于.NET运行时进行监视，并不会降低服务器的性能，只会占用几兆的使用，所以说，大家可以放心的去使用，只要配置正确，绝对不会对应用程序产生影响，APM监视对于企业应用程序，绝对是有必要的，也是私有云帮助企业优化IT管理必要的一环。
-------------------------------------------------------------------------------------------------------
扩展知识：还有一个比较有趣的概念，想要和大家分享一下，那就是Devops，什么是Devops呢？Devops简称研发运维一体化，举个例子，一个应用程序从编码到上线，大概是这样一个生命周期的过程：代码编写—代码发布—代码测试——应用部署—应用测试——应用上线，而我们要讨论的就是就是关于后两个过程，应用测试，应用上线，传统来讲，企业开发了一个业务系统，部署好了后，是要经过一段时间的监视测试过程，才能正式上线的，而这个监视过程，一般就是由服务器运维人员来做，极少数情况是应用程序开发人员来做，那么这个时候，就会由于知识交集问题，导致应用程序测试出现性能问题后，服务器维护人员不能及时的告知应用运维人员，而通过SCOM的APM，就可以第一时间帮助监控应用程序的性能以及故障，发现问题，第一时间在SCOM中产生警报，服务器运维人员，发现了这个警报后，快速把这个警报指派给应用管理员，应用管理员收到警报后，查看APM网站，发现问题后，快速修复，然后快速重新上线，这样就是一套Devops研发运维一体化，通过Devops就可以帮助应用程序实现联合监视，快速修复，快速上线。从而最大的提高应用系统监视、运维、上线的效率，在SCOM2012R2中针对于Devops，其实还有另外一个更好的体现，那就是SCOM2012R2和TFS2013的集成，一旦配置了SCOM2012R2和TFS2013的集成后，如果发现VS中的程序出现故障后，就可以在SCOM中，把这个警报，分配给TFS工作账户，同时传入到TFS的WorkItem或者Bug中，然后应用人员发现之后，去VS中修复代码，重新发布，代码修复好了后，TFS工作项自动解除，SCOM警报也自动解除。