1、APM简介
1.1需求背景
在微服务大行其道的今天，一个大型系统可能包含上百个服务（甚至更多），随着服务数量的增多，遇到问题后定位和分析的时间成本也相应增加。例如遇到系统故障或者性能问题，在传统三层架构中，仅仅需要分析有限的几个组件，如web服务器，应用服务器和数据库。但是，如果问题发生在微服务架构中，就需要调查大量的组件和服务器。此外，仅仅分析单个组件很难看到全局，当在微服务架构中发生一个低可见度的问题时，采用传统分析方式解决问题所需的时间也会成倍增加。
面对以上情况， 我们就需要一些可以帮助运维开发人员快速理解系统、定位问题、监控系统性能的工具，这就是所谓的APM（Application Performance Monitoring，应用性能管理）。
什么是APM？
用最简单的术语来说，APM是从业人员用来确保应用程序的一致可用性、性能和响应时间的工具。网站、移动应用程序和业务应用程序是监控的典型用例。
APM区别于其他监控系统的核心技术之一是分布式调用链追踪，借助于这一功能，我们能在监控页面上看到一个请求从前端到底层服务的每一次调用，以及对应的服务器地址，接口名，响应时间，是否成功等信息。借助这一功能，当一个请求出现问题时，就可以快速发现产生问题的根源。
APM的功能远不止于此，在当今高度连接的数字世界中，APM的监控范围已经扩展到服务、流程、主机、日志、网络，当然还有访问这些应用程序的最终用户。
1.2 理论基础—调用链追踪的实现原理
Google的Dapper是最早的APM系统，Google利用Dapper系统帮助运维人员快速定位问题。相关论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》[1]发表后，很多公司和组织基于调用链追踪的原理，设计出了各种优秀的APM系统。这些APM系统不只包括调用链追踪，还集成了性能监控、日志收集、告警等功能，可以作为一个独立的运维监控系统来使用。
在《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》中，阐述了Dapper对整个调用过程的追踪过程：
① 请求到来生成一个全局TraceID，通过TraceID可以串联起整个调用链，一个TraceID代表一次请求。
② 除了TraceID外，还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id，通过他们可以组织一次完整调用链的父子关系。
③ 一个没有parent id的span成为root span，可以看成调用链入口。
④ 所有这些ID可用全局唯一的64位整数表示；
⑤ 整个调用过程中每个请求都要透传TraceID和SpanID。
⑥ 每个服务将该次请求附带的TraceID和附带的SpanID作为parent id记录下，并且将自己生成的SpanID也记录下。
⑦ 要查看某次完整的调用则只要根据TraceID查出所有调用记录，然后通过parent id和span id组织起整个调用父子关系。
1.3 统一规范—opentracing
当代分布式跟踪系统（例如，Zipkin, Dapper, HTrace, X-Trace等）的实现方式各异，他们使用不兼容的API来实现各自的应用需求。OpenTracing通过提供平台无关、厂商无关的API，使得开发人员能够方便的添加或修改追踪系统的实现。OpenTracing[2]提供了用于运营支撑系统的和针对特定平台的辅助程序库。
OpenTracing是一个规范，它不是一个数据结构，能提供的是语义和概念。OpenTracing要涵盖的是中间的一层，它是要实现的是一套API的套件。你需要按照OpenTracing的规范向用户提供API，实现把数据下送到API的探针或者Tracer的探针。OpenTracing的主旨是在做手动埋点，程序的开发者要主动调用Tracing的API。
实现了OpenTracing规范的APM包括Zipkin，Pinpoint，Skywalking，Jaeger等。
2、开源APM比较
比较知名的开源APM包括：Zipkin[3]，Pinpoint[4]，Jaeger[5]，Skywalking[6]等。以下是这些开源APM的横向比较[7]。
图1 开源APM横向比较
综合以上分析，Skywalking对代码无侵入，集成成本低，支持trace查询，监控，告警等功能，最重要的是，对应用吞吐量的影响最小，与我们所在项目的需求契合度最高，因此，我们选择Skywalking进行部署和使用。
3、Skywalking简介
Skywalking是一款国内开源的应用性能监控工具，支持对分布式系统的监控、跟踪和诊断。以下是SkyWalking的一些主要功能和组件:
① 分布式跟踪：SkyWalking跟踪流经多个服务的请求，提供对事务路径的端到端可见性。它捕获关于每个调用的详细信息，包括延迟、错误和依赖关系。
② 指标分析：SkyWalking收集和分析应用指标，如CPU使用率、内存消耗和网络流量。它提供了这些指标的实时监控和可视化，帮助识别性能瓶颈和资源使用模式。
③ 服务网格支持： SkyWalking集成了流行的服务网格框架，如Istio和Envoy，允许用户监控和管理部署在服务网格环境中的微服务。
④ 告警和诊断：SkyWalking可以根据预定义的阈值或收集数据中检测到的异常产生告警。它还提供了强大的诊断工具来帮助解决性能问题并分析根本原因。
⑤ 插件生态系统：SkyWalking提供了一个基于插件的架构，允许用户扩展其功能并与不同的技术集成，可支持多种各种数据库、消息代理和中间件系统。
⑥ 可视化展示：SkyWalking提供了一个用户友好的基于web的界面，用于可视化性能数据、生成报告和探索跟踪细节。它提供了一套全面的指示板和图表来帮助使用者理解系统行为。
⑦ 可扩展性和兼容性：SkyWalking设计用于处理大规模分布式系统。它支持水平可伸缩性，可以跨多个节点以分布式方式部署。它与云原生环境和容器编排平台（如Kubernetes）兼容。
Skywalking 总体可以分为四部分（图2）：
① Skywalking Agent：使用Javaagent做字节码植入，无侵入式的收集，并通过HTTP或者gRPC方式发送数据到Skywalking Collector。
② Skywalking Collector ：链路数据收集器，对agent传过来的数据进行整合分析处理并落入相关的数据存储中。
③ Storage：Skywalking的存储，时间更迭，sw已经开发迭代到了6.x版本，在6.x版本中支持以ElasticSearch、Mysql、TiDB、H2、作为存储介质进行数据存储。
④ UI：Web可视化平台，用来展示落地的数据。
图2 skywalking整体架构
通过在应用程序中集成 SkyWalking Agent，就可以对接口、服务、数据库、MQ等进行追踪，将追踪结果通过 HTTP 或 gRPC协议 发送到 SkyWalking Collecter，SkyWalking Collecter 经过分析和聚合，将结果存储到 Elasticsearch 或 H2等数据库中，SkyWalking同时提供了一个 SkyWalking UI 的可视化界面，UI 以 GraphQL + HTTP 方式获取存储数据进行展示。
如果只是为了学习体验SkyWalking，不必单独安装每一个组件，最新版本的Skywalking服务端支持AllInOne的安装方式。只需要需要将安装包解压然后启动，数据库，Collector，UI等服务端组件就已经安装好了，可以直接登录UI进行体验，此时使用的是H2内存数据库，Skywalking重启后数据会清空。被监控的应用需要集成skywalking agent，修改agent配置后重启，以便将采集信息上报给服务端。
此外，skywaling的官方网站https://skywalking.apache.org/
还提供了在线体验入口，打开网站，在页面上点击“Live demo”->“Go to native UI”，即可进入skywalking监控页面，查看当前监控的应用和日志信息。
目前使用Skywalking的公司包括华为，当当，小米等不下数十家公司。
4、Skywalking使用示例
面基于我们自己部署的Skywalking（9.4.0版本），介绍一下Skywalking的主要功能。
4.1 服务监控
进入Skywalking首页，点击Service面板，呈现如下页面。
图3 Skywalking服务监控-1
在页面中可以看到，当前系统中有3个应用组件被纳入监控，分别是ops，business，user。页面中展示了每种应用的负载，请求成功率，时延，和应用性能指数（Apdex）。
点击某个服务，可以看到该服务的各种指标的趋势图以及告警信息，如下图所示。
图4 Skywalking服务监控-2
Skywalking的告警规则可在配置文件中进行设置。
4.2 拓扑展示
Topology页面中，可以看到Skywalking根据当前时间窗口的请求数据绘制的系统拓扑图。如果在监控时间段内某个应用没有请求，则拓扑图中不会显示该应用和其他应用之间的调用关系。
图5 Skywalking拓扑展示
在Topology页面中，不仅显示了被监控的服务，还显示了与这些服务发生直接调用关系的对象或组件，例如User，agent::ui，服务器10.100.201.73:61616等。
4.3 调用链路追踪
在Trace页面中，可以根据traceid查看一次请求的完整调用过程。如下图所示，在“追踪ID”输入框中输入想要查询的traceid并点击搜索，侧栏中会显示出该traceid关联的所有请求。点击其中的一个请求，会在右侧显示请求从前端直到到存储层的所有调用步骤、时延等。进一步地，还可以通过点击具体的路径，查看当前调用关联的实例名，ip，端口，业务日志等信息。
图6 Skywalking调用链追踪
4.4 日志监控
Skywalking支持通过log4j和logback配置将业务日志上报Skywalking到服务端，以便在UI中展示，配置方式参考文档[8][9][10]。配置完成后，可在UI的Log页面中看到业务日志。如下图所示，
我们的Java程序通常使用logback或log4j框架打印业务日志，如果能够将这些标识与skywalking的traceid进行关联，在某条告警日志出现时，就可以根据其中的traceid找到相应的调用链。为此，Skywalking提供了低侵入的集成方式，让我们可以在业务日志中打印traceid。
以log4j框架为例，首先在程序中添加apm-toolkit-log4j-1.x依赖
<dependency>
<groupId>org.apache.skywalking</groupId>
<artifactId>apm-toolkit-log4j-1.x</artifactId>
<version>{project.release.version}</version>
</dependency>然后修改layout配置
log4j.appender.CONSOLE.layout=org.apache.skywalking.apm.toolkit.log.log4j.v1.x.TraceIdPatternLayout最后修改日志打印格式
log4j.appender.CONSOLE.layout.Cnotallow=%d [%T] %-5p %c{1}:%L - %m%n其中%T即表示在日志中增加traceid字段。
logback的配置方法类似，具体可以参考Skywalking文档[8][9][10]。
4.5 更多功能
Skywalking提供的功能远不止上面演示的这些，想要了解更多功能，请参考官方文档https://skywalking.apache.org/docs，以及在线演示系统http://demo.skywalking.apache.org/general
5、如何选择适合自己的APM？
哪一款APM最适合自己？需要根据自己项目的实际情况进行选择，以下是选型时需要考虑的一些因素：
（1）特性和功能
评估每个开源APM提供的特性和功能。例如，调用链追踪的粒度、监控指标、告警功能是否满足自己的需求；
（2）性能与可扩展性
考虑每个APM的可扩展性和性能，是否具有水平可伸缩性，是否具有高效的数据存储和检索机制，当业务增长时APM的负载能力是否满足需求，等等。
（3）支持的技术
检查APM是否支持项目中使用的编程语言、框架和技术。
（4）与现有监控系统的集成
了解APM与现有监控和日志系统的集成方式，优先选择可以实现平滑数据对接，与当前系统兼容性好的平台。
（5）安装和使用的便利性
评估每个APM的安装、配置和使用的便利性，用户界面是否满足需求，学习曲线是否合理，利用现有文档和资源是否能够快速入手。
（6）社区活跃度
一个活跃的社区可以为平台提供支持、指导和定期更新。
