近年来，APM行业备受关注，特别是NewRelic的成功上市使得人们对这个行业前景更加乐观。APM的目的是帮助应用管理者准确了解用户体验，通过应用架构映射、应用事务分析和深度应用诊断实现。同时，APM还需要进行数据的分析与报告，以提供精确的分析和预测。
在过去几年中，越来越多的企业开始关注APM行业，尤其是在2014年末，NewRelic成功上市的事件进一步加深了人们对该行业前景的看好。那么，究竟什么是APM？APM的目的是什么？我们需要做些什么？很多企业对APM的理解存在偏差，本文将向您提供一个真正完整的APM概念的阐述。
APM（Application Performance Management）是一种管理模型，其全称为“应用性能管理”，由Gartner公司通过大量的调研和分析归纳抽象而来。IT从业者们对APM的理解与实践已经存在了很长时间，它并不是一次新的发明。
从上图中可以清楚看到APM模型中一共分了五个层次，下面就这五个层次逐一说明。
1. End User Experience
What：终端用户体验。APM首先关注的是终端用户对应用性能的真实体验。
Why：不是监测点的，也不是骨干网核心机房的，而是真实用户的切实体验到的性能。可能一个电影播放服务的性能优化做得很棒，但是用户打开浏览器或打开APP，发现点播某个电影时却慢得离谱，问题会出在哪里呢?用户不清楚点击播放按钮之后，发生的一切事情，用户只是感知到了慢、不能播放、往复播放等等很多不好的体验，用户反馈了问题或投诉了，产品和研发不能准确重现，问题来了。
这些问题可能是由多种因素引起的。其中可能包括用户使用的浏览器版本过旧，某些JavaScript脚本不兼容。此外，用户本地网络连接不稳定，导致数据包丢失和首字节响应时间延长。还有可能是服务器集群中某些机器的网络不稳定，导致负载均衡出现问题。总之，这些问题都与用户的客户端环境有关，而服务器端只能获得有限的信息。就好比自家菜地的情况虽然清楚，但是如果把菜卖到饭馆，厨房的厨师又怎么能知道农田的情况呢？
帮助应用管理者准确、详尽地了解真实的用户体验是什么样子，这是APM首先要解决的问题。
How：对于Web应用来说，在用户请求到的每一个页面下面追加一段js脚本，用js收集并发回数据，是最普遍的做法;对于移动App来说，在APP发布前build进SDK，通过系统与语言Hook来收集数据，也是很直截了当的。至于这二者具体的做法，容后文再细聊，此篇不赘。下列简单截取了几张图片，来源透视宝。
2. Runtime Application Architecture
What：应用架构映射。
为什么: 在与多位首席技术官(CTO)进行深入讨论时，包括一些已上市企业，我发现有一个常见问题：你们是否拥有完整的应用架构图？得到的回答并不乐观，有些CTO含糊其辞，甚至直接否定。有些公司的应用系统经历了长时间的发展，即使他们有专职架构师绘制图表，也很难在短时间内完成全部的应用架构图。
大多数企业的应用架构，是黑盒或灰盒，这就是现状。
如果应用架构图是完整的，那么我们还需要一个需求，即了解某次故障请求的真实请求链路拓扑。尽管负载均衡将请求分发到了N台机器作为集群，但是我们需要确定承接该具体请求的是集群中的哪些机器，以及它们在那个时间点的性能状况如何。我们还需要了解该请求在集群中的机器上的顺序。
How: 云智慧透视宝实现了应用的完整架构：
与单次请求的应用架构：
可以看到，在上面的示例中，完美了解决了我们在应用架构层面遇到的问题。
具体做法，我们将在后续文章中单独介绍，其中包含了web容器插件、编程语言Hook插件等技术细节。
3. Business Transactions
What：应用事务分析
下面是对上述段落重新表达的专业版本： 在这里，我们指的不是数据库事务，而是应用程序和用户之间的交互操作事务。举个例子来说明：用户登录网站后，执行了一系列操作，包括使用搜索功能搜索耳机、从耳机列表中选择合适的耳机、打开查看耳机详情，并对款式、音效和价格等进行评估，将选定的耳机放入购物车，最后打开购物车并完成支付。
整个例子中，我们所说的事务可以抽象为：
登录 -> 搜索 -> 挑选 -> 购买 -> 支付
因此，仅仅记录登录成功率和购买成功率的意义并不足以对整个应用的健壮稳定程度进行全面分析。只有准确地分析整体事务之间的相互影响，才能真正评估应用的稳定性和健壮性。
熟悉Google Analytics（GA）的用户都会明白，在我们所描述的应用事务中，GA需要付出大量努力来实现追踪。然而，对开发者来说，一直令他们痛苦的是需要在代码中进行"埋点"操作。也就是在代码的关键位置插入一行代码，以实现在关键位置的追踪功能。然而，业务在不断发展，需要不断修改和发布应用，因此这个"埋点"的操作使得应用频繁进行修改和发布，给开发者带来了困扰。
用户在使用客户端（包括浏览器和应用程序）时进行的所有操作都是有序的。对于应用事务的记录和满足需求，我们只需要考虑两个关键因素：
1、确定上下文的事务操作，是同一个用户;
2、确定所有事务操作的每一个步骤，是惟一一个动作。
因此，我们可以通过对某个应用的数据进行分析，获得以下应用事务，而用户在整个过程中无需修改任何代码（无需埋点）。关于具体的实现细节，我们将在后续的文档中进行专门介绍。
4. Deep Dive Component Monitoring
What：深度应用诊断
原文中提到了一个在线商城在上海用户反馈登录慢、不响应的问题。根据问题所在的多个可能环节，比如CDN、Web Server、DB Server、业务代码、中间件、物理磁盘和物理网卡等，需要进行深入的排查和分析。为了准确地找到问题所在，我们需要经过彻底的冷静思考和调查。
How：这里有几个难点是：
1、在不修改用户代码的前提下，取得代码运行时性能数据;
2、终端用户数据、运行时性能数据、物理指标数据、服务运行指标数据，有效关联;
3、有太多需关注的点，怎样方便快捷地部署采集端;
4、不影响或很少影响原应用性能。
以上也正是APM提出的需求。
采用一键式的、无干预的安装部署与更新升级，云智慧透视宝的Smart Agent能够替代传统繁琐的部署与升级过程。我们利用各个语言的底层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模型中五个层次的认识与支持程度：
转自：什么是真正的APM？ - 让编程成为一种习惯 - 博客园
APM行业在近年来备受关注，并在应用性能管理方面发挥着重要作用。通过应用架构映射、应用事务分析和深度应用诊断，APM帮助应用管理者准确了解用户体验，并解决各种可能影响应用性能的问题。此外，APM还需要进行数据的分析与报告，以提供精确的分析和预测。整体而言，APM的发展前景广阔，对于提升应用性能和用户体验至关重要。
