近年来APM行业被愈来愈多的企业所关注，尤为是在2014年底，NewRelic的成功上市，更加激发了人们对这个行业前景的无限遐想。那么究竟什么是APM?APM的目的是什么?要求咱们作什么?有很多企业对APM的理解实际上是有误差的，本文将向您阐述一个真正完整的APM概念。html
APM 是Application Performance Managment的缩写，字面意思很容易理解，“应用性能管理”。它是由Gartner概括抽象出的一个管理模型。注意，这个管理模型的由来，是通过大量调研与分析后的概括与抽象，这些切实需求由来已久，IT从业者们对它的理解与实践也几乎是从IT诞生至今就已开始，这并非一次发明。web
从上图中能够清楚看到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)所进行的全部操做，很明显，是有序的。要完成应用事务的记录，要完成的需求其实只是两个唯一性：
一、肯定上下文的事务操做，是同一个用户;
二、肯定全部事务操做的每个步骤，是唯一一个动做。
因而咱们即可对某一个应用取得的数据分析出如下应用事务，而整个过程当中，用户不须要修改任何一行代码(无须埋点)。具体的实现细节，后续会专门出文介绍。
4. Deep Dive Component Monitoring
What：深度应用诊断
Why：关键词是“深度”。好比某在线商城，接到了上海用户的反馈，登陆慢，不响应。这其中可能出现问题的环节太多了：CDN可能有问题、Web Server或DB Server负载可能太高、业务代码中可能有bug、中间件可能不响应、甚至任何一个环节的物理磁盘或物理网卡可能出现了故障，等等。想要准确地找到问题所在，即便不经一番寒彻骨，八成也要先打个冷战。
How：这里有几个难点是：
一、在不修改用户代码的前提下，取得代码运行时性能数据;
二、终端用户数据、运行时性能数据、物理指标数据、服务运行指标数据，有效关联;
三、有太多需关注的点，怎样方便快捷地部署采集端;
四、不影响或不多影响原应用性能。
以上也正是APM提出的需求。
一键式的、无干预的安装部署与更新升级，以替代繁琐的部署与升级;采用各个语言的底层Hook来针对性地编写语言Agent插件，以此实现不修改用户代码而取得运行时性能数据;经过主机、应用、服务、请求的唯一标识，来进行有效的数据关联;经过特有的数据采样算法来达到2%如下的性能影响;一体化的数据模型，以替代密集的数据孤岛。这段特征，描述的是云智慧透视宝的Smart Agent。(一样，实现细节请待后文。)
5. Analytics / Reporting
What：分析与报告
Why：简单地讲，APM对数据有两点要求：
一、数据处理要及时，必要时候要作到实时的处理，问题可能随时都会发生;
二、数据的分析报告要精确，大量的数据自己是无价值的，按照业务模型进行精确分析、预测才有其价值体现。
How：APM数据是自然的大数据，符合4V特征。所以难点几乎与大数据处理的难点相重合：
一、数据模型语言要统一
二、数据存储与查询
三、大量复杂数据的关系建模
能够看到，云智慧透视宝架构中Pipe Cluster的设计是对流数据的处理的核心部分，分布式、集群部署的Pipe Worker可实现实时的消息消费，同时基于此架构的Data Platform与Alter Engine可实时对任意维度的数据进行分析与预警。目前数据采集量720亿条/天天，共存储200,000亿条数据。(后续将对此架构进行专文介绍。)
下图是对比了国内外APM行业的各厂商对以上APM模型中五个层次的认识与支持程度：
欢迎关注微信公众号：shoshana