共計 2891 個字符，預計需要花費 8 分鐘才能閱讀完成。

這篇文章給大家介紹 ARMS 在怎么 APM 工具選型中實踐的，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

前言

當前的系統在數字化轉型需求以及互聯網架構實施的影響下，越來越普遍地使用了微服務架構，我們在享受微服務帶來的好處（開發效率高，獨立部署，水平擴展，故障與資源隔離等等）外，也帶來測試，事務，應用監控等各方面的困難。

從上圖可以看出，在以分布式為主的互聯網架構下，應用間的調用變得越來越復雜，我們傳統使用的開發工程師主動埋點，運維人員到主機上查日志，組合調用鏈，監控應用的運行情況，顯得越來越力不從心。

為了更好地做到應用層面的監控，包括應用運行環境的基礎設施數據，系統業務調用情況，性能消耗分析，在發生性能，異常與故障問題時，能夠快速定位和解決問題，誕生了很多優秀的 APM（Application Performance Management）工具。

這些 APM 工具都提供了包括指標統計信息與調用鏈路跟蹤信息。

常見的 APM 工具

APM 工具包括指標收集與調用鏈收集。指標收集例如在某一段時間的請求數，異常數，錯誤數，響應時間 RT，IAAS 層的資源使用情況（例如 cpu, memory, IO, load, 網絡），也包括 JVM 的各種運行參數（例如 各內存分區情況，gc 情況）。調用鏈收集包括業務請求中訪問過的各應用，類，方式，在每個運行節點 / 方法上的時間消耗情況。

常見的 APM 工具有：

1、ARMS: 由阿里巴巴自研開發的一款 APM 工具。由于分布式微服務框架以阿里為主體的企業很早就開始探索，阿里集團內很早就有配套的鷹眼系統做相關的應用監控，為適應產品上云輸出，阿里在 2016-08-04 的時間就以 ARMS 的產品形式正式對外提供應用監控服務。
2、開源系的 APM
u Pinpoint：基于 java 編寫的開源 APM 工具，由韓國人開發貢獻，功能完善，發展快，影響了很多其它的 APM 工具實現，在國內外使用比較廣泛。
u Skywalking：支持 open tracing 標準，由我國的吳晟主導開發的分布式追蹤，分析，告警的開源工具，當前是 Apache 旗下的開源項目，發展非常迅速，在各類開源 APM 工具里國內的使用比較廣泛。
u ZipKin：支持 open tracing 標準，由 Twitter 公司開發貢獻，于 2012 年的時候就開始開源發展，是比較成熟的開源 APM 工具。
u Jaeger：支持 open tracing 標準，由 Uber 公司開發貢獻，是比較成熟的開源 APM 工具。

APM 工具原理

盡管這些 APM 工具功能與實現各有不同，但基本上原理都是一樣的，這個原理基于 google dapper 的分布式追蹤技術論文，把 APM 工具實現總體上分為兩大部分：
1、對應用運行節點上進行應用埋點，在業務運行期間進行埋點數據的生成；

在這個調用鏈追蹤技術里，還原調用鏈的功能主要依賴于兩個 ID.

第一個 ID 是 TraceID, 這個代表一個業務調用，就好像在電商系統里發起的一個下單結算；在線教育里的一個選課流程；物流系統里的攬收；這些業務從客戶觸發到獲得響應結果就是一個完整的請求，就是一次業務調用，它每一次的業務請求的都會獲得維一的 TraceID;

第二個 ID 是 RpcID (或者稱為 SpanID), 在一次業務請求中，可能經過的應用會有多過，以一個電商下單業務為例：它需要經過訂單系統創建訂單；支付系統接受支付；庫存系統扣減產品庫存；會員系統給買家進行積分處理；購物車系統會清理購物清單。這樣對于業務流經的每一個應用，都有一個有層次的 RpcID, 這個 RpcID 可以認為是使用目錄層級記錄的，從這個 RpcID 來看，那怕它在同一個業務中被調用了多次，它的每一次進入的 RpcID 都是一樣的。

依賴于 TraceID RpcID, 我們可以很方便地還原整個調用鏈。

6、主動診斷能力
ARMS 提供了主動診斷能力，可以通過選定具體的時間，執行主動診斷，ARMS 會分析這一段時間內的應用運行情況，自動總結這一段時間內的問題，并且結合阿里的經驗，產出具體的報表。我們依據這個報表，可以加速我們的定位與優化。
7、豐富的報警能力
完善報警體系，ARMS 提供了豐富的報警規則，我們可以對相應的規則進行開啟 / 關停，編輯，這樣可以快速搭建報警體系。在報警通道方面，可以直接發對接釘釘 /WebHook/Email/ 短信網關等。

運維能力上的優勢

1、按需監控啟停管理
通過 ARMS 的管理控制臺，我們可以批量在管理應用的啟停，可以一鍵停止所有的 ARMS 監控，也可以一鍵啟動相關應用的監控。非常符合上云的按需要使用觀念。
2、動態采樣率變更
在面對特殊的時間點或者異常出現機率的時候，我們希望動態調整采樣率，例如通過調大采樣率來捕獲這些概率極少的調用鏈，借助 ARMS 的配置管理，我們可以非常方便地把更齊全的調用鏈收集起來；通過調小采樣率來保證存儲空間的合理使用（其它的 APM 工具在做采樣率的變更時，需要應用的重新配置，啟動，這不但處理起來麻煩，并且影響業務的邊續性，在實際操作上很難下定決心去在運行期間中斷業務去做改變采樣率的變更。）
3、綁定參數的開關
雖然很多 APM 工具都可以提供綁定參數的功能。但很多時候，如果對于業務數據敏感的系統，并不希望這類 APM 工具在非必要的時候采集 SQL/API 的運行參數。所以 ARMS 在它的配置管理里提供這么一個功能非常有意義，也就是當需要收集這些運行的業務參數進行問題定位分析的時候，那么只要打開就可以了，使用完畢后，再通過把這些開關關上，那么就可以保護我們的業務數據不外泄漏出去了。
4、接入簡易
可通過更簡易的方式如阿里容器 ACK/EDAS/SAE 等各種非常便捷的接入方式，只需要簡單的 YAML 注解或按鈕即可完成接入。
5、組件穩定免運維
因為 ARMS 是商業化的產品，所以所有的組件都是不需要我們使用方運維的。如果使用開源自建，那么我們就需要對日志收集，計算清洗服務，存儲產品本身進行運維，包括相應的集群規模，清理處理，擴容處理，如果在峰值過后，不進行資源回收，也會產生額外的使用浪費。

成本使用上的優勢

1、ARMS 是按接入節點，接入的小時（時長）計費的，這樣可以充分發揮云上產品的優勢。按需要使用，按需要的應用節點付費。另外 ARMS 單純地按照節點數來計算，并不受采樣率的變動而產生變化，這樣對于大采樣率的應用是有一定的優勢。
2、ARMS 有相應的資源包，可以通過購買資源包的方式進一步節省費用。
3、因為產品的組合因素，ARMS 如果搭配阿里云的容器（ACK）使用，計費會自動 5 折。

備注

1、開源的按照統一統計數據存 15 天，全量明細數據存 3 天計算（ARMS 的數據是全天 24 小時使用，存儲 60 天，在非容器下按年包折下來的月費用。）
2、人力成本以具有開發能力的運維人員月薪 3 萬計算。人力成本，主要參數變動帶來的發布，后端系統的不穩定帶來的效率損失，后端系統的維護操作。中大型的會做一些定制的開發（例如采樣的動態配置化生效）

關于 ARMS 在怎么 APM 工具選型中實踐的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。