1. Business Transactions

What：应用事务分析

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

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

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

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

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

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

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

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

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

2. Deep Dive Component Monitoring

What：深度应用诊断

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

How：这里有几个难点是：

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

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

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

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

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

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

3. Analytics / Reporting

What：分析与报告

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

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

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

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

1、数据模型语言要统一

2、数据存储与查询

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

 

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

-------

End

关于作者：

高驰涛(Neeke)，云智慧高级架构师，PHP开发组成员，同时也是PECL/SeasLog等多个开源软件作者与贡献者。8年研发管理经验，早期从事大规模企业信息化研发架构，09年涉足互联网数字营销领域并深入研究架构与性能优化。对高并发、高性能、高可用系统设计实现有丰富经验。崇尚规范、敏捷、高效、GettingReal。目前在云智慧致力于APM产品的架构与研发。主要负责PHP、Python、Go等语言的底层扩展与SmartAgent的架构研发。