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

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

什么是真正的APM?

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

1. End User Experience

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

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

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

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

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

什么是真正的APM?

什么是真正的APM?

什么是真正的APM?

什么是真正的APM?

2. Runtime Application Architecture

What:应用架构映射。

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

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

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

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

什么是真正的APM?

与单次请求的应用架构:

什么是真正的APM?

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

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

3. Business Transactions

What:应用事务分析

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

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

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

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

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

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

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

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

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

什么是真正的APM?

4. Deep Dive Component Monitoring

What:深度应用诊断

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

How:这里有几个难点是:

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

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

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

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

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

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

什么是真正的APM?

5. Analytics / Reporting

What:分析与报告

Why:简单地讲,APM对数据有两点要求:

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

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

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

1、数据模型语言要统一

2、数据存储与查询

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

什么是真正的APM?

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

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

什么是真正的APM?