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）社區活躍度

一個活躍的社區可以為平臺提供支持、指導和定期更新。