近年来APM行业被越来越多的企业所关注，尤其是在2014年末，NewRelic的成功上市，更加激发了人们对这个行业前景的无限遐想。那么究竟什么是APM?APM的目的是什么?要求我们做什么?有不少企业对APM的理解其实是有偏差的，本文将向您阐述一个真正完整的APM概念。

APM 是Application Performance Managment的缩写，字面意思很容易理解，“应用性能管理”。它是由Gartner归纳抽象出的一个管理模型。注意，这个管理模型的由来，是经过大量调研与分析后的归纳与抽象，这些切实需求由来已久，IT从业者们对它的理解与实践也几乎是从IT诞生至今就已开始，这并不是一次发明。

从上图中可以清楚看到APM模型中一共分了五个层次，下面就这五个层次逐一说明。

1. End User Experience

What：终端用户体验。APM首先关注的是终端用户对应用性能的真实体验。

Why：不是监测点的，也不是骨干网核心机房的，而是真实用户的切实体验到的性能。可能一个电影播放服务的性能优化做得很棒，但是用户打开浏览器或打开APP，发现点播某个电影时却慢得离谱，问题会出在哪里呢?用户不清楚点击播放按钮之后，发生的一切事情，用户只是感知到了慢、不能播放、往复播放等等很多不好的体验，用户反馈了问题或投诉了，产品和研发不能准确重现，问题来了。

也许用户浏览器太过陈旧，也许是某个JS脚本的兼容性问题，也许用户本地网络丢包严重、首字节响应时间很长，也许是服务器集群网络不稳定、某组机器脱离了均衡池…… 太多也许了。而这些猜测是，最不好把控的，就是用户客户端环境，Server端好比自家的菜地，菜好菜赖总是清楚的，可再好的菜卖到饭馆，厨子怎么样菜农怎么知道?

帮助应用管理者准确、详尽地了解真实的用户体验是什么样子，这是APM首先要解决的问题。

How：对于Web应用来说，在用户请求到的每一个页面下面追加一段js脚本，用js收集并发回数据，是最普遍的做法;对于移动App来说，在APP发布前build进SDK，通过系统与语言Hook来收集数据，也是很直截了当的。至于这二者具体的做法，容后文再细聊，此篇不赘。下列简单截取了几张图片，来源透视宝。

2. Runtime Application Architecture

What：应用架构映射。

Why: 曾经与多名CTO深入探讨过这个问题(其中不乏已经上市的企业)：你们有完整的应用架构图吗?得到的回答不少是闪烁其词的，有的CTO很直接地摇摇头。更有甚者是这么回答的，公司应用系统年代久远，就算目前所有的架构师专职绘图，也很难在短时间内完成全部的应用架构图。

大多数企业的应用架构，是黑盒或灰盒，这就是现状。

假如应用架构图是完整的，那么还有一个需求即：针对于某次故障请求的真实请求链路拓扑。是的，负载均衡一共分发了N台机器作为集群，但承接某次具体请求的是集群中的某些机器，那么，是哪些机器?它们当时的性能是什么样子?请求顺序是怎样的?

How: 云智慧透视宝实现了应用的完整架构：

与单次请求的应用架构：

可以看到，在上面的示例中，完美了解决了我们在应用架构层面遇到的问题。

具体做法，我们将在后续文章中单独介绍，其中包含了web容器插件、编程语言Hook插件等技术细节。

3. Business Transactions

What：应用事务分析

Why：当然这里说的事务不是DB事务。这里指应用与用户交互的操作事务。举个例子：用户登录网站后，使用搜索功能搜索了耳机，从耳机列表中，选择了自己喜欢的耳机，打开查看详情，款式音效价格看来都不错，放入购物车，然后打开购物车进行购买，完成支付。

整个例子中，我们所说的事务可以抽象为：

登录 -> 搜索 -> 挑选 -> 购买 -> 支付

所以，单纯的记录登录成功率、购买成功率的意义不会至于大到分析整个应用的健壮稳定程度，准确地分析出整体事务的相互影响象限，才会。

How：熟悉GA的朋友都知道，GA花费了大量的力量以实现上述我们所描述的应用事务。但令开发者痛苦的是，必须要在代码中“埋点”，即在代码中的关键位置写入一行代码，以实现在关键位置的追踪，而业务总不是一成不变的，于是随着业务发展，“埋点”这个事情使得应用总在不停地修改、发布、修改、发布。

其实，用户在客户端(浏览器、APP)所进行的所有操作，很明显，是有序的。要完成应用事务的记录，要完成的需求其实只是两个惟一性：

1、确定上下文的事务操作，是同一个用户;

2、确定所有事务操作的每一个步骤，是惟一一个动作。

于是我们便可对某一个应用取得的数据分析出以下应用事务，而整个过程中，用户不需要修改任何一行代码(无须埋点)。具体的实现细节，后续会专门出文介绍。

4. Deep Dive Component Monitoring

What：深度应用诊断

Why：关键词是“深度”。比如某在线商城，接到了上海用户的反馈，登录慢，不响应。这其中可能出现问题的环节太多了：CDN可能有问题、Web Server或DB Server负载可能过高、业务代码中可能有bug、中间件可能不响应、甚至任何一个环节的物理磁盘或物理网卡可能出现了故障，等等。想要准确地找到问题所在，即使不经一番寒彻骨，八成也要先打个冷战。

How：这里有几个难点是：

1、在不修改用户代码的前提下，取得代码运行时性能数据;

2、终端用户数据、运行时性能数据、物理指标数据、服务运行指标数据，有效关联;

3、有太多需关注的点，怎样方便快捷地部署采集端;

4、不影响或很少影响原应用性能。

以上也正是APM提出的需求。

一键式的、无干预的安装部署与更新升级，以替代繁琐的部署与升级;采用各个语言的底层Hook来针对性地编写语言Agent插件，以此实现不修改用户代码而取得运行时性能数据;通过主机、应用、服务、请求的惟一标识，来进行有效的数据关联;通过特有的数据采样算法来达到2%以下的性能影响;一体化的数据模型，以替代密集的数据孤岛。这段特征，描述的是云智慧透视宝的Smart Agent。(同样，实现细节请待后文。)

5. Analytics / Reporting

What：分析与报告

Why：简单地讲，APM对数据有两点要求：

1、数据处理要及时，必要时候要做到实时的处理，问题可能随时都会发生;

2、数据的分析报告要精确，大量的数据本身是无价值的，按照业务模型进行精确分析、预测才有其价值体现。

How：APM数据是天然的大数据，符合4V特征。因此难点几乎与大数据处理的难点相重合：

1、数据模型语言要统一

2、数据存储与查询

3、大量复杂数据的关系建模

可以看到，云智慧透视宝架构中Pipe Cluster的设计是对流数据的处理的核心部分，分布式、集群部署的Pipe Worker可实现实时的消息消费，同时基于此架构的Data Platform与Alter Engine可实时对任意维度的数据进行分析与预警。目前数据采集量720亿条/每天，共存储200,000亿条数据。(后续将对此架构进行专文介绍。)

下图是对比了国内外APM行业的各厂商对以上APM模型中五个层次的认识与支持程度：