应用性能管理与链路追踪的关系

应用性能管理 APM（Application Performance Monitoring）经常和分布式追踪同时出现，但两者却有着明显的差异。APM 由来已久，已经有十几年的历史，自最早的以 WebLogic 为代表的 J2EE 应用出现开始，APM 就逐步受到了各大厂商的重视，并作为商业软件的组成部分被提供出来。

APM 系统为单体式应用和分布式应用提供了全面的可视化展现建议、性能分析建议、性能诊断和优化建议，为开发团队、运维团队提供了常规监控体系之外的保障。随着分布式应用监控难度的增加，应用性能问题的发现和定位变得越来越困难。

在分布式系统中，传统的以日志为主的监控正在越来越多地被用来进行基础设施、网络环境的监控。而在应用层面上，日志监控基本失去了定位问题的能力，尤其是上云之后，网盘逐步成为主流，日志的有效性问题、写入压力和成本问题凸显出来。

这便对 APM 系统提出了越来越高的要求，分布式追踪、非侵入式的语言探针、轻量化、低延迟分析，这些都是对新时代 APM 提出的基本要求，也是对传统 APM 系统的挑战。

• 分布式追踪

分布式追踪能完成日志监控的绝大部分功能，提供更好的使用内存而非文件系统，解决性能定位问题。Google、Twitter 等各大公司都在这个领域投入了极大的精力。

• 非侵入式的语言探针

这一点恰恰和“分布式追踪”的需求矛盾，因为无论是自动探针（Agent）还是手动探针（SDK），本质上都对被监控的目标程序进行了修改，且任何修改都是有一定风险的。而在语言众多，团队小型化、多元化的云原生年代，探针在能力上虽然十分吸引人，但使用成本却很高，所以非侵入式的语言探针，即非语言探针，被提了出来，可以在用户不需要分布式追踪和方法级诊断的情况下完全做到和语言无关。

• 轻量化

传统的 APM 系统使用大量的大数据技术栈，如 Spark、Storm、HBase 等，虽然功能完善，但是运维难度很大。监控系统可能比被监控系统更难运维，这显然不是一个好的设计。大量的中小型公司需要的正是非大数据的 APM 解决方案。只有以 Elasticsearch 或 MySQL 为核心，使用非大数据框架解决方案，才能更好地在新兴的云原生环境下提供服务。

• 低延迟分析

系统的分布式压力变化很快，APM 系统能够做出秒级反应，而不是像使用报表系统一样需要 3 分钟以上才能对数据做出反应。这里需要注意，很多公司把流量分析、经营分析的系统职责加到了 APM 系统上，这样会造成低延迟和轻量化性能的降低。实际上，APM 可以作为流量分析、经营分析的系统数据源，但是应该专注在可观察性、指标分析以及告警上。