标签：情况 步骤 大量 依赖 硬件架构 听云 打不开 数据库服务 ansi
为了加深EGO会员之间的相互了解，同时也为大家提供更多线上相互学习交流的机会，EGO正式启动会员群线上分享活动。本文是根据陈靖华分享主题“APM的价值”的内容整理而成。
第二期分享嘉宾：陈靖华，EGO会员、听云CTO、北京基调网络股份有限公司联合创始人之一。
今天我们来聊聊APM技术，首先APM是应用性能监控（Application Performance Monitoring）或应用性能管理（Application Performance Management）的缩写。所谓应用性能管理，就是指使用特定的工具和过程对软件应用的性能和可用性进行监控和管理，致力于发现、诊断并定位复杂应用的性能瓶颈和故障，以保证应用达到预期的服务水平和用户体验。
APM的历史
应用性能的监控和管理作为一个运维的监控和管理手段实际上已经存在了很长的时间，但是APM被作为一个细分领域的IT解决方案行业被单独提出来还是在近几年的事情，大概在2010年左右吧。
这个从Google趋势上可以很明显看出来。而著名的IT研究和分析公司Gartner也是在2012年开始每年发布APM行业的魔力象限报告的。
APM从其发展阶段上可以分为两个阶段，第一代的APM（我们称作APM 1.0）是在上世纪末期由Wily, Quest Software, Mercury等公司提供的一系列系统和应用的性能采集工具，可以用来监控和分析当时典型的三层架构的应用的性能，APM 1.0相对比较笨重，基本以本地软件加硬件的形式来提供，需要用户投入大量的精力和成本来进行实施和维护。
第二代APM，也就是所谓的APM 2.0大概就是在2010年左右兴起的，这一代的APM产品面向的是大量采用分布式SOA架构、消息总线和弹性虚拟化、云计算框架的应用，因此APM 2.0引入了应用拓扑逻辑的自动发现来更好地监测分布式的应用。
同时为了适应敏捷开发和持续交付带来的应用代码的频繁更改，APM 2.0引入了自动插桩技术来实现监控代码的部署，用户不需要修改任何代码或者仅需要修改极少的代码即可快速灵活地部署APM探针实现监控，极大地节省了部署和维护APM的成本。
相比APM 1.0另外一个比较重大的变化就是APM 2.0中终端用户的用户体验成为了关键的监测项目，这是由于在互联网和移动互联网的应用交付场景下，越来越多的业务表现都依赖于应用本身的服务质量和最终的用户体验。
APM服务的SaaS化也是APM 2.0的一个重大变化，原有的APM 1.0产品基本上都是私有化部署的本地软件形式提供的，APM 2.0的服务SaaS化让用户可以以更便利、更低成本的方式来快速部署和使用以前价格高昂，部署和维护困难的APM产品。
APM的作用
APM能帮我们做什么，或者说在我们已有的运维监控体系中，APM能带来哪些不同的价值呢？我们可以从Gartner APM魔力象限里对APM服务5个维度的定义来看看APM到底能做什么，这5个维度的定义从2012年到现在基本上没有太大的改变。
第一个维度最终用户体验监测（EUEM）
这要求从端到端（客户端到服务器端）来采集最终用户访问应用时的性能体验，包括端到端的网络延时，应用响应时间，响应的成功率和质量等等。最终用户的体验监测除了从真实用户的访问（RUM，Real User Monitoring）来进行之外，还可以通过主动式的模拟最终用户监测（Synthetic Monitoring）来进行应用可用性的评估。
最终用户体验监测始终是APM最重要的维度没有之一，这也是APM与传统运维监控的最主要差别。
传统运维监控一般都是自下而上的监控，关注点在系统和服务层面，通过对基础架构、系统、服务、应用的监控来保证服务的高可用和应用的体验效果。而APM是自上而下的监控，关注点在最终用户的体验层面，通过对用户体验、网络、应用以及服务的监控来保证应用的高可用和体验效果。
举个例子
从传统运维的后端监控上除了流量和访问量的异常之外，往往很难感知到某些区域或者某个运营商的最终用户已经访问不了我们的网站和应用了，即使从流量异常感知到了用户访问量的减少也很难定位问题。而从APM的EUEM上，我们可以非常及时准确地发现并定位最终用户无法访问的原因。由于EUEM，我们经常比我们的IDC服务商和云服务商更早发现他们的各种网络故障，往往我们给他们打电话、发消息投诉的时候他们自己还完全一无所知。
第二个维度应用拓扑逻辑发现和可视化
它指的是能自动识别应用在执行的过程中涉及的软硬件架构和组件，并且可以描绘出应用交付链中相互通讯的各种组件的访问路径，也就是我们通常说的调用链。
这一个维度也是非常重要的，通过该维度的实现，我们可以将应用的调用链通过拓扑图，调用图等图表可视化，直观地展示应用的拓扑逻辑。这个维度最直观的的一个实现就是提供全链路的应用拓扑图。
第三个维度用户定义的事务剖析
它要求从用户请求的角度来对事务中的用户定义的事件进行追踪。这个字面上可能不太好理解，实际上这个意思是可以根据要求对特定的用户访问特定的事务请求进行完整的追踪，包括在整个请求过程中涉及到的第二个维度要求中发现的服务和组件。例如当发现性能问题的时候，可以跟踪一个特定（用户名，手机号，用户ID等等）的用户在使用App访问购物流程中的的每一个步骤的访问情况，采集每一个请求中的最详细的代码和服务、组件访问性能和异常数据。
第四个维度应用组件深度钻取
这要求对第二个维度里发现的服务和组件的资源消耗和事件提供足够细粒度的监控。例如对应用访问的数据库服务，MQ服务等提供深度的监控，当发现有数据库服务查询性能问题的时候，可以提供包括完整的SQL语句，执行计划，数据库状态等在内的详细监控数据。
第五个维度IT运营分析（ITOA）
它其实就是运维数据分析，要求使用以下技术的组合来进行运维数据分析：复杂事件处理，统计模式发现与识别，非结构化数据索引、查询和推断，拓扑逻辑分析，多维数据库检索和分析。这里的数据分析技术都是为了对APM采集到的大量的各维度性能数据进行实时的运算和处理，从而对应用的运维和优化起到辅助决策和驱动。例如通过实时的智能基线和异常监测来驱动警报系统。
从实际的应用场景上，APM可以在以下方面为我们提供帮助：
最终用户体验评估和优化，提升用户体验，提高应用DAU和留存
链路监控，线路优化
机房选型，第三方服务（CDN、云服务、推送等）选型
竞品性能对标
劫持分析和优化
实时告警和通知
业务流程代码级的监控和优化
业务压测和性能剖析
快速发现和定位性能问题，减少业务故障恢复时间
实际案例分析
分享几个我们处理过的案例：
案 例 1
大概一年前我们有个客户通过最终用户的监测发现上海联通大概有30%的手机用户无法访问他们的App，但是从他们自己的后端运维监控系统上完全看不出来这样的区域故障，甚至愤怒的用户跑到他们上海的办公室闹事了都还不知道怎么回事。
最初我们通过真实用户的监控（RUM）数据发现无法访问的错误大部分都是“无法建连：连接被重置”的错误，然后通过主动式的对比监测发现同样的上海联通3G手机，访问其他域名没有任何问题，而一旦访问这个客户的域名就出现上面说的那个错误，非常像是对特定域名的劫持。但是和运营商沟通之后他们否认有劫持。
然后我们又对比了主动测试里可以正常访问和无法访问该域名的探测点的数据，结果发现使用联通预付费电话卡的访问是正常的，而使用后付费电话卡的无法访问。很明显这与费用的结算有关系，于是又与运营商沟通，最终确认是客户公司与联通在做活动，对使用该客户App的用户进行免流量的活动，但是由于联通内部工单下错，一个需要后做的步骤给提前做了，最终导致所有后付费的用户无法使用。定位了问题之后，运营商那边很快就把问题解决了。
定位和解决客户端的问题，特别是运营商和网络方面的问题通常是比较费时费力的，有了最终用户的体验数据之后往往可以快速帮助我们缩小问题的范围，实现更快地定位。而对应服务端的应用来说，问题的解决相对比较可控，而我们需要的就是快速发现和定位代码和服务上的性能问题，以便更快地解决，减少故障恢复时间和对业务的影响。
案 例 2
大概也是去年3月份中旬的时候，一个电商客户做他们一款新产品的上线和微信促销活动。
活动当晚8点多的时候，当流量上来以后，整个系统完全都不能用了，App和微信平台上的访问几十秒都打不开。整个项目组的人都忙作一团希望尽快定位问题，但是由于系统的架构复杂，调用的组件多，并且在之前开发的时候没有输出足够详细的日志，导致问题定位非常困难。
最后他们的技术老大临时决定要装上APM探针试试，9点钟开始找了几个应用实例部署了应用探针，跑了十几分钟数据后就基本上定位了问题：
一个是应用代码的问题导致Redis缓存层失效，所有的访问都基本直接访问数据库，导致数据压力瞬间变大，数据库的单次连接时间飙升到了15秒多；另外一个是调用他们公司另外一个系统的接口问题，当时的接口调用也到了每次请求7，8秒的耗时。
定位问题后，很快找研发修改代码，大概在10点的时候把问题解决掉，系统的响应趋于平稳。整个过程，从安装探针到定位问题大概用了十多分钟，到最终把问题解决掉一共不到一个小时的时间。
现在很多电商客户在上新的产品或各种x18,双xx活动前都会使用APM工具进行压测和性能分析，提早发现可能存在的性能问题。活动的时候也会实时关注各应用的性能数据，来进行及时的应用扩展和故障恢复。
上面列举了一些APM的典型应用场景，来帮我们理解APM可以帮助我们干什么，总结下来就是：APM可以帮助我们从最终用户角度和业务角度了解我们的应用的性能和业务表现，为优化用户体验和提升业务表现提供依据和驱动力。
标签：情况 步骤 大量 依赖 硬件架构 听云 打不开 数据库服务 ansi
原文地址：http://www.cnblogs.com/licheng/p/6443147.html
