码农code之路1. APM？
APM (Application Performance Management) 即应用性能管理（应用性能监控）
APM主要是针对企业 关键业务的IT应用性能和用户体验的监测、优化，提高企业IT应用的可靠性和质量。
旨在确保最终用户获得高质量的体验，降低IT总拥有成本（TCO)
TCO （Total Cost of Ownership ），即总拥有成本，包括产品采购到后期使用、维护的成本。 这是一种公司经常采用的技术评价标准。
2 .简介
目前市面的系统基本都是参考 Google 的 Dapper（大规模分布式系统的跟踪系统）来做的。
跟踪业务请求的处理过程，完成对应用系统在前后端处理、服务端调用的性能消耗跟踪，提供可视化的界面来展示对跟踪数据的分析。
通过汇聚业务系统各处理环节的实时数据，分析业务系统各事务处理的交易路径和处理时间，实现对应用的全链路性能监测。
APM工具与传统的性能监控工具的区别在于，不仅仅提供一些零散的资源监控点和指标，其主要关注在系统内部执行、系统间调用的性能瓶颈分析，这样更有利于定位到问题的具体原因。
APM致力于检测和诊断应用性能问题，从而能提供应用预期的服务水平。
2.1 三大特征
- 多级应用性能监控：覆盖通讯协议1-7层，通过事务处理过程监控、模拟等手段实现端到端应用监测。
- 应用性能故障快速定位：对应用系统各个组件进行监测，迅速定位系统故障，并进行修复或提出修复建议。
- 应用性能全面优化：精确分析各组件占用系统资源的情况，并根据应用系统性能要求给出专家建议。
2.2 发展历程
目前APM的发展主要经历了前面的三个阶段：
第一阶段：以网络监控基础设施为主，主要监控主机 的CPU 使用率、I/O、内存资源、网速等，主要以各类网络管理系统（NMS）和各种系统监控工具为代表。
第二阶段：以监控各种基础组件为主，随着互联网的快速发展，为了降低应用开发难度，各种基础组件（如数据库、中间件等）开始大量涌现，所以这个时期应用性能管理主要是监控和管理各种基础组件的性能。
第三阶段：以监控应用本身的性能为主, IT 运维管理的复杂度开始出现爆炸性的增长，应用性能管理的重点也开始聚焦于应用本身的性能与管理上。
第四节阶段属于正在发展的阶段：
云计算方兴未艾，而DevOps以及微服务的兴起对传统APM产生了很大的冲击，传统厂商也在做一些革新，也做一些微服务方面的尝试和云计算方面的尝试。
随着Machine Learning、AI的技术的兴起，对定位故障、定位问题，也会起到一些帮助，基于大数据的分析的手段也会有一些帮助，目前市场上正在初步尝试阶段。
2016年Gartner对APM的定义分为三个维度
- DEM-Digital experience monitoring：数字体验监控，浏览器及移动设备用户体验监控及利用主动拨测的实现的业务可用性及性能监控。
- ADTD-Application discovery, tracing and diagnostics：应用自动发现、追踪和故障诊断，自动发现应用之间的逻辑关系，自动建模、应用组件的深入监控及性能关联分析。
- AA-Application analytics：应用分析，通过机器学习，进行针对JAVA及.NET等应用的根源分析。
2.3 DevOps
DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。
DevOps可以简洁的理解为“开发团队与运营团队之间更具协作性、更高效的关系”。
是两个相关趋势碰撞中出现的新术语
更多信息见：https://zh.wikipedia.org/wiki/DevOps
2.4 APM 的核心思想
在应用服务各节点相互调用的时候，从中记录并传递一个应用级别的标记，这个标记可以用来关联各个服务节点之间的关系。
比如两个应用服务节点之间使用 HTTP 作为传输协议的话，那么这些标记就会被加入到 HTTP 头中。
可见如何传递这些标记是与应用服务节点之间使用的通讯协议有关的，常用的协议就相对容易加入这些内容，一些按需定制的可能就相对困难些，这一点也直接决定了实现分布式追踪系统的难度。
2.5 为什么要使用APM
随着公司业务的与日俱增，各个系统也越来越复杂，服务间的调用，服务的依赖，以及分析服务的性能问题也越棘手，因此引入服务追踪系统尤为重要。
现有的APM，基本都是参考Google的Dapper的体系来做的。通过跟踪请求的处理过程，来对应用系统在前后端处理、服务端调用的性能消耗进行跟踪（每个请求的完整调用链路，收集调用链路上每个服务的性能数据），方便工程师能够快速定位问题。
2.6 好的APM应满足的条件
总的来说，一个优秀的APM系统应该满足以下五个条件
- 低消耗，高效率：被跟踪的系统为跟踪所付出的系统资源代价要尽量小，现在主流的APM对于系统资源的消耗在2.5%-5%左右，但是这个数值应该越小越好，因为在大规模的分布式系统下，一个单节点的资源是无法把控的，可能是超强配置，也可能是老爷机，只跑几个小服务，但是本身性能已经十分吃紧了，如果这时候跟踪应用再一跑，很可能这个节点就挂掉了，得不偿失。
- 低侵入性，足够透明：作为跟踪系统，侵入性是不可能不存在的，关键这种侵入性要在哪个层面，如何在越底层的层面上侵入，对于开发者的感知和需要配合跟踪系统的工作就越少，如果在代码层面就需要进行侵入，那对于本身业务就比较复杂的应用来说，代码就更加冗余复杂了，也不利于开发者快节奏的开发。
- 灵活的延展性：不能随着微服务和集群规模的扩大而使分布式跟踪系统瘫痪，要能够充分考虑到未来分布式服务的规模，跟踪系统至少要在未来几年内完全吃得消。
- 跟踪数据可视化和迅速反馈：要有可视化的监控界面，从跟踪数据收集、处理到结果的展现尽量做到快速，就可以对系统的异常状况作出快速的反应
- 持续的监控： 要求分布式跟踪系统必须是7×24小时工作的，否则将难以定位到系统偶尔抖动的行为
