应用性能管理（APM）简介
1、简介
应用性能管理是指对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本(TCO)，为企业带来更多的商业利益。
应用性能管理能够对整个企业的IT系统各个层面进行集中的性能监控，并对有可能出现的性能问题进行及时、准确的分析和处理。它能轻松地从一个IT应用系统中找到故障点，并提供有相关解决建议或方法，从而提高整体的系统性能。
2、APM定义
APM发展初期，密切监控两组绩效指标：
第一组性能指标定义了应用程序终端用户所体验的性能。 性能的一个示例是峰值负载下的平均响应时间。 该组的组件包括加载和响应时间。
- 负载是应用程序处理的事务量，例如，每秒事务数（tps），每秒请求数，每秒页数。 在没有被基于计算机的搜索，计算，传输等需求加载的情况下，大多数应用程序都足够快，这就是程序员在开发过程中可能无法捕获性能问题的原因。
- 响应时间是应用程序在此类负载下响应用户操作所需的时间。
第二组性能指标测量应用程序用于负载的计算资源，指示是否有足够的容量来支持负载，以及性能瓶颈的可能位置。 这些数量的测量为应用建立了经验性能基线。 然后可以使用基线来检测性能变化。 性能变化可与外部事件相关联，随后用于预测应用程序性能的未来变化。
2016年，Gartner Research将其定义更新为三个主要功能维度：
- 终端用户体验监控（EUEM）已发展为数字体验监控（DEM）
- 新增一个新的维度：应用程序发现，跟踪和诊断（ADTD）。结合了三个以前独立的维度（应用程序拓扑[运行时架构]发现和可视化，用户定义的事务分析和应用程序组件深入研究），因为这三个维度主要集中在 问题补救方面是相互关联的;
- 应用程序分析（AA）
3、APM框架
应用程序本身变得越来越难以管理，因为它们转向高度分布的，多层，多元素的构造，在许多情况下依赖于应用程序开发框架。APM概念框架旨在帮助优先考虑首先关注的方法，以便快速实施和全面了解五维APM模型。
APM框架
-
终端用户体验
衡量从用户请求到数据再返回的流量传输是捕获最终用户体验（EUE）的一部分。此测量的结果称为实时应用程序监视（又称自顶向下监视），它具有被动和主动两个组件。被动监控 通常是使用网络端口镜像实现的无代理设备。主动监控 由预定义的合成探针和Web机器人组成，用于报告系统可用性和业务事务（即业务方自行埋点）。 -
应用架构映射
应用程序发现和依赖关系映射（ADDM）解决方案用于自动执行将事务和应用程序映射到底层基础架构组件的过程。 -
应用事务的分析
关注用户定义的事务或对业务社区有一定意义的URL页面定义。 -
深度应用诊断
深度应用诊断（DDCM）需要安装代理，通常针对中间件，侧重于Web，应用程序和消息服务器。 -
数据分析
获得一组通用的度量标准以收集和报告每个应用程序非常重要，然后标准化有关数据并呈现应用程序性能数据的常见视图。
4、选型：商用 or 开源 or 自建
笔者工作中开发过一个简单的APM系统，故在此简单说说假如工作中遇到领导要求对APM技术选型时的一些思考的方向。
APM系统的核心是数据收集，包括应用级别数据（包括APP及中间件）和机器级别数据。目前主流的开源APM系统的数据收集主要集中在应用级别的数据收集，典型的如OpenZipkin（当然部分开发人员觉得OpenZipkin或pinpoint等只收集了应用数据，不能算是APM；在此笔者暂将其归为APM），稍微深入一点的，如Cat，加入了JVM监控及简单的告警功能。但他们都远远无法与商用版APM匹配，在此笔者给出个人建议：
- 若公司是技术驱动，有一定规模，且已有完善的运维团队，相对成熟的机器级别监控，只需要 3. APM框架 中的1和3，则使用开源版本已足够；且多数开源项目社区活跃，遇到问题时能够及时得到反馈；
- 若公司为业务、产品驱动的公司，不想在开发运维APM上花费过多精力，则可根据自身情况选择商用版APM；
- 若希望从零开始自研APM系统，笔者的建议是除非公司已发展的足够规模，开源版APM确实无法满足自身需求，再花费力气进行相关开发工作
5、未来畅想
当公司业务有一定访问量后，上APM将会成为必然，那么APM系统未来的发展方向如何呢？在此笔者提出几点个人想法：
- 尽可能多的收集相关数据；
- 结合业务方线上bug，不断完善监控指标；
- 结合业务方使用经验，提供更加直观、高效的图表展示；
- 结合历史经验，指导业务方排查线上问题；
- 基于人工智能，提前发现业务方潜在问题（据说部分商用APM已经实现）；
