簡介：好的產品總是能給予用戶最輕松的使用體驗，并在實際生產中發揮出巨大的業務價值。我們不妨從現在開始，就將所有微服務應用通過無侵入的方式接入ARMS，構建一體化的全鏈路監控體系，而不是等到真正遇到生產故障的那一天，為了定位問題而費盡周折。

作者：山獵，阿里云解決方案架構師

前言

隨著分布式技術的發展與演進，微服務技術成為了大型分布式IT架構的必然選擇。從本質上來講，微服務是一種架構風格，將一個大型的系統拆分為多個擁有獨立生命周期的應用，應用之間采用輕量級的通信機制進行通信。這些應用都是圍繞具體業務進行構建，可以獨立部署、獨立迭代，也可能根據業務負載獨立的水平擴展。微服務思想以及相關的技術為IT架構的發展帶來了一系列深刻的變革。

微服務技術讓IT系統變得更敏捷、更健壯、更高性能的同時，也給帶來了架構復雜度的提升，給應用監控帶來了前所未有的挑戰。在微服務時代，由于服務的拆分，單個用戶請求會經過多個微服務應用，形成復雜的調用鏈路，使傳統的依賴于單機業務日志的監控手段無從下手，這就需要建立全新的監控機制，幫助開發者全面洞察系統運行狀態，并在系統遇到異常的時候快速的定位和解決問題。

什么是全鏈路監控？

在分布式微服務架構中，系統為了接收并處理一個前端用戶請求，需要讓多個微服務應用協同工作，其中的每一個微服務應用都可以用不同的編程語言構建，由不同的團隊開發，并可以通過多個對等的應用實例實現水平擴展，甚至分布在橫跨多個數據中心的數千臺服務器上。單個用戶請求會引發不同應用之間產生一串順序性的調用關系，鏈路的概念就此誕生。

隨著業務規模的增長，不但來自于前端用戶的請求頻度會增加，鏈路也變得更長，這也代表著應用之間的調用關系變得越來越復雜。為了提升微服務系統在復雜鏈路下的健壯性和穩定性，有3個關鍵訴求需要我們去解決：

1 . 如何梳理整套系統的調用關系，并評判應用上下游依賴的合理性？
2 . 如何了解每一個應用的性能指標，并對系統容量進行合理的規劃？
3 . 當系統出現故障或異常的時候，如何第一時間發現問題、定位問題、解決問題？

這3個關鍵訴求的核心挑戰，都來源于應用之間復雜的鏈路。如果有一套成熟易用的機制，對每一條鏈路的行為進行記錄，并進行深入的分析，提取出有價值的參考數據，就能讓這些難題迎刃而解，這個重要的機制就是全鏈路監控。

標準與規范

十年前，Google成為了分布式系統鏈路追蹤服務的先行者，并通過《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》這篇著名論文闡述了如何在超大規模系統上建設低損耗（low overhead）、應用級透明（application-level transparency）、大范圍部署（ubiquitous deployment）的鏈路追蹤服務。

Dapper闡述了對分布式系統進行鏈路追蹤的技術細節，包括數據表示、埋點、傳遞、收集、存儲與展示等方面，并提出了跟蹤樹、Span、Trace、Annotation等重要概念，為全鏈路監控提供了理論指導。

在Dapper的啟發下，業界誕生了很多用于分布式鏈路追蹤的開源組件，為了保持對鏈路中每一個環節的記錄與匹配，不僅需要在應用內部對跟蹤信息進行傳遞，還需要讓跟蹤信息跨越不同的應用以及不同的分布式組件。這需要制定一套統一的標準，讓微服務體系中的所有應用遵循這套標準來實現跟蹤信息的描述和傳遞，這套標準就是OpenTracing。OpenTracing抽象出一套與編程語言以及業務邏輯無關的接口，對鏈路追蹤領域各類元素的統一管理，從而實現完整的全鏈路監控。
本文不會深入介紹Dapper和OpenTracing的原理以及技術細節。我們只需要知道，優秀的全鏈路監控組件會盡可能的遵循OpenTracing標準，以獲得更好的通用性以及擴展性。

可選方案

全鏈路監控組件如何獲得鏈路相關的信息呢？最簡單的方式是讓開發者在業務代碼中手工埋點，生成符合OpenTracing標準的鏈路信息，并匯入全鏈路監控組件。但手工埋點的方式要求開發者主動配合，并在業務代碼中嵌入大量非業務邏輯。這樣的方式是極為脆弱的，開發者稍有疏忽就會導致鏈路信息丟失，甚至影響到正常的業務邏輯。所以非手工埋點的自動鏈路信息采集，成為了業界的主流，其中包括兩種實現方式：

**1 . SDK方式: 通過引入鏈路追蹤SDK自動生成鏈路數據，并自動上報。對于底層框架沒有公開API的情況，監控邏輯的注入會比較復雜，有可能需要開發者針對具體的底層框架預先做好適配工作。

2 . 探針方式: 探針方式不需要在代碼編譯前引入SDK，而是在應用運行的過程中，通過一個Agent動態的攔截底層框架的行為，從而自動注入監控邏輯**。像Java這樣的編程語言可以通過字節碼增強技術實現探針方式的鏈路信息采集。這是一種最開發者最友好的方式，不需要任何代碼層面的改動，但并不是每一種編程語言都能提供探針機制，因此SDK方式也被很多全鏈路監控組件采用。

不管是SDK方式還是探針方式，非手工埋點形式的鏈路信息采集都依賴于鏈路追蹤組件對于底層框架的識別。這些底層框架包含的領域非常廣，其中包含應用對外提供服務所需要的框架，應用進程內部的通訊框架，應用之間相互訪問所需要的框架，應用訪問外部系統所需要的框架等等。比如在Java體系中，用于提供HTTP服務的Tomcat、Jetty，用于進程內部通訊的RxJava，用于微服務應用之間相互調用的Feign，用于訪問外部系統的MyBatis、MySQL JDBC、HTTPClient，都屬于這個范疇。對于多種編程語言以及種類繁多的底層框架的適配，是一項浩大的工程，一個全鏈路監控方案能夠適配的底層框架越多，它的能力就越強大。

基礎鏈路信息收集上來之后，需要進行統一存儲，并對數據進行清洗與聚合，根據應用響應時間、請求數、錯誤率等指標進行下鉆分析，并按應用、接口、鏈路、事務等多個維度進行展示，這也是一項非常復雜的工作。

因此，全鏈路監控方案的技術門檻是非常高的，在開源的全鏈路監控產品中，真正遵循OpenTracing標準，又夠被廣泛認可和使用的產品非常少，其中通過SDK方式接入的產品以Jaeger為代表，通過探針方式接入的產品以Skywalking為代表。

最輕松的方案

開源的全鏈路監控方案能幫助開發者更深入的理解全鏈路監控的思想、原理以技術細節，但在在生產環境大規模使用開源方案，還是會給開發者帶來很大的挑戰：

1 . 維護工作復雜：除了客戶端的SDK和探針外，一套全鏈路監控方案在服務端有計算組件、存儲組件、展示組件，都需要單獨進行維護。以Jaeger為例，僅在數據存儲方面需要維護一套獨立的Elasticsearch集群，需要投入很大的工作量。

2 . 功能簡單：對主流底層框架的全面支持，豐富的UI界面，完善的診斷機制和報警機制，這些都是一套優秀的全鏈路監控方案所必備的特質。開源方案在這些方面很難做到盡善盡美。

3 . 缺少高可用保障：開源全鏈路監控方案并沒有完整的高可用機制，當某個組件出現故障，比如服務器宕機的時候，無法自動恢復，需要人工介入進行解決，在這個過程中正常的監控會受到影響。

4 . 無法支撐大規模場景：當接入的應用數量達到上千個之后，開源全鏈路監控方案會暴露出各種性能問題，需要開發者修改源代碼進行針對性的優化。

5 . 影響正常業務：如果SDK/探針存在設計上的缺陷，有可能導致應用出現不可預知的故障。這種情況極為罕見，但一旦發生，后果會非常嚴重，這種情況下一般也只能等待開源社區將問題修復后才能恢復使用。

之所以在生產環境使用開源全鏈路監控方案存在這么大挑戰，是因為這些方案本身缺乏大規模實際業務場景的驗證。對于技術實力非常強的互聯網企業，會有專門的技術團隊負責全鏈路監控項目，在使用開源產品的過程中如果遇到任何問題，都可以通過自身的技術實力進行修復和彌補。但對于絕大多數使用者而言，這些挑戰所帶來的都是漫長而痛苦的體驗。

有沒有一套經歷過大規模實際業務場景驗證，又簡單易用的全鏈路監控產品呢？在云計算時代這個問題的答案是肯定的，阿里云ARMS就能滿足這個要求，代表著業界在全鏈路監控以及應用性能管理領域的最高水平。

應用實時監控服務ARMS（Application Real-Time Monitoring Service）起源于阿里巴巴內部的EagleEye（鷹眼）系統，已經經歷了近10年的沉淀和演進。鷹眼系統同時將基礎設施層、分布式應用層、業務邏輯層與客戶端層進行了全鏈路跟蹤，每天對萬億級別的分布式調用進行分析，對底層的流計算、多維時序指標與事件存儲體系等進行了大量優化，同時引入了時序檢測、根因分析、業務鏈路特征等技術，將問題發現與定位由被動轉為主動。

在ARMS的理念中，對全鏈路監控的理解已經超出了一般意義上APM（應用性能管理的范疇），而是把“可觀測性”作為產品的最重要使命?？捎^測性是一切自動化決策的基礎，求最終目的是為一個復雜分布式系統所發生的一切給出合理解釋。

正是因為經歷了大規模生產環境的長期驗證，才使ARMS能夠在易用性、功能性、穩定性方面做到極致，以開源領域最活躍的全鏈路監控項目Skywalking為例，我們可以從多個維度對兩個產品進行對比：

接入來，我們就通過阿里云ARMS，開啟輕松玩轉全鏈路監控之旅。

應用接入

ARMS采用無代碼侵入探針接入方式，對于應用接入只需要非常簡單的幾個步驟，以Java應用為例：

1 . 開通ARMS服務：登錄阿里云控制臺后，打開ARMS產品主頁，按照提示開通“應用實時監控服務試用版”，開通服務后會獲得15天的免費產品試用。

2 . 下載探針（Agent）：在公網環境以及VPC內，都提供了探針的下載鏈接，可以直接參考ARMS臺的提示進行操作。

3 . 修改應用的啟動命令：通過-javaagent掛載探針，并配置對應的license Key以及應用名。比如我們啟動SpringBoot應用為例，啟動命令為
java -javaagent:/{user.workspace}/ArmsAgent/arms-bootstrap-1.7.0-SNAPSHOT.jar -Darms.licenseKey={LicenseKey} -Darms.appName={AppName} -jar demoApp.jar
其中，-javaagent后面的路徑是探針文件所在的路徑，arms.licenseKey可以從ARMS的控制臺獲得，appName代表應用的名字。在微服務應用中，一個應用可以擁有多個對等的應用實例，這些對等的應用實例接入ARMS的時候，使用同樣的應用名，這樣ARMS可以把這個應用的多個實例放到一個分組中進行統一管理。

修改完應用啟動命令后，對應用進行重啟，就能夠成功接入ARMS。如果在1分鐘后，ARMS控制臺的應用列表能夠看到新的應用，就代表接入成功。

當然，對于Tomcat等通過操作系統腳本啟動的應用，不能直接修改應用啟動命令來掛載ARMS探針，這個時候只要對啟動腳本進行修改即可，以Tomcat為例，我們在setenv.sh中加入如下配置：
JAVA_OPTS="$JAVA_OPTS -javaagent:/{user.workspace}/ArmsAgent/arms-bootstrap-1.7.0-SNAPSHOT.jar -Darms.licenseKey={LicenseKey} -Darms.appName={AppName}"

更多的Jetty等更多通過Web容器啟動的應用可以參考ARMS的幫助文檔。

對于部署在阿里云EDAS或者容器服務Kubernetes的應用，接入工作會更加的簡單，ARMS已經和這些產品進行了集成，使用者都不需要下載ARMS的探針到應用所在的節點，可以直接在控制臺進行一鍵式的批量操作。

特別重要的一點是，ARMS支持混合云模式，所以并不要求接入的應用一定要部署在阿里云，不管應用部署在線下IDC還是其他的云，都可以統一接入ARMS。當然，需要確保在混合云模式下，應用與ARMS服務端之間的網絡是暢通的。

核心實踐一：了解你的系統

應用接入后，可以通過ARMS獲得哪些重要的信息，從而幫助使用者更好的了解整個系統呢？我們可以從這幾個方面入手：

應用列表和全局拓撲

在應用列表視圖，我們能看到每一個應用的健康度以及最近10分鐘對外服務的響應情況。如果應用的狀態列亮紅燈，代表此應用運行不健康，我們可以繼續點擊紅燈查看ARMS此應用生成的診斷報告，以進一步分析應用不健康的原因。

點擊應用列表右上角的全局拓撲按鈕，能夠通過可視化界面觀察所有接入ARMS應用的拓撲結構，這個界面清晰的展示了所有應用的上下游組件以及相應的調用關系，能夠幫助使用者從全局角度深入理解整個微服務系統。

理想的微服務應用只有不同層級之間的單向依賴，這種依賴的原則是高層應用依賴于低層應用。同層應用之間的相互依賴，或者低層應用依賴于高層應用都是違背這個原則的。假設我們在全局拓撲視圖里面，找到了環狀依賴關系，說明微服務應用之間的依賴關系不清晰，可以考慮對應用的層次結構進行重構。

應用總覽

從應用列表進入應用總覽頁，首先呈現給使用者的是概覽分析視圖，在這個視圖中，我們能夠查詢應用在指定時間的關鍵指標。右上角的時間段是一個非常重要的選項，使用者可以根據需要來修改此應用關鍵指標的采集時間范圍（默認15分鐘）。在ARMS的很多視圖里面，都提供了這個選項，來幫助使用者查看指定時間范圍的監控信息。

應用在選定時間內的總請求量、平均響應時間、錯誤數、實時實例數、FullGC 次數、慢 SQL 次數、異常次數和慢調用次數，以及這些指標和上一天的環比、上周的同比升降幅度等信息，都能夠在這個視圖體現。我們可以重點關注應用應用提供服務和應用依賴服務欄展示的指標曲線，如果在某個時間點發生了突變，可以進行針對性的排查。比如在某一個時間點，一個應用對外服務接口的請求量突然變低，極有可能是其中的一個節點發生了故障，需要特別關注。對于在ARMS展示出來的任何一條以時間維度為橫座標的指標曲線，都可以繼續選擇其中的時間段進行下鉆分析，這也是一個非常便捷的功能。

在拓撲圖頁簽上，可以通過拓撲圖更加直觀地看到應用的上下游組件以及與它們的調用關系。相比全局拓撲圖，單應用拓撲圖能夠展示更多細節信息，幫助使用者分析應用的上下游調用情況，從而更快速地找出性能瓶頸。

應用詳情

在應用詳情視圖中，能夠基于應用整體的維度以及應用內單實例的維度查看更多詳細的信息，包括JVM信息、主機信息、SQL調用分析、異常和錯誤分析等等。

主機監控功能用于監控CPU、內存、Disk（磁盤）、Load（負載）、網絡流量和網絡數據包的各項指標。當我們遇到硬件或網絡故障的時候，這些基礎資源的指標數據將非常有價值。當應用部署在Kubernetes的時候，Pod監控和主機監控能夠分別從pod和宿主機維度分別對指標數據進行展示。

JVM監控功能通過可視化頁面展示應用的GC情況、內存詳情、線程詳情，完全可以代替JStat、JStack等JDK自帶的JVM分析工具。同樣，在以時間為橫坐的曲線圖處，可以繼續選中一個時間段進行下鉆分析。

如果一個應用的多個對等實例中，某一個出現了故障，我們就能夠非常迅速的發現這個實例在應用情況視圖中呈現出來的狀態信息和其他實例存在非常大的區別，這樣有助于我們迅速找到故障實例，并進行相應的處理。

接口調用 & 外部調用

當一個應用對外提供多個服務接口的時候，如何從分析每一個接口的服務質量，以及每一個接口對應的鏈路詳細情況呢？這個時候接口調用視圖就能發揮重要的作用。從這個應用所有提供的接口中，我們可以選中需要分析的單個接口，與這個接口相關的鏈路信息就能夠從多個維度展示出來，其中包括接口的請求數、響應時間、錯誤數、返回狀態碼，以及在接口所對應的鏈路中，應用訪問外部數據庫（包括關系型數據庫，以及Redis等非關系型數據庫）的情況。

如果訪問這個接口的上游應用也接入了ARMS，還能從鏈路上游頁簽查看每一個上游應用訪問這個接口的請求數、響應時間和錯誤數。同樣，如果這個接口對應的鏈路在離開這個應用后，還會繼續訪問接入了ARMS的下游應用，我們也能從鏈路下游頁簽查看到針對每一個下游應用的請求情況。

我們需要記住，接口調用基于單個應用接口的維度，對鏈路信息進行提取并展示。當一個應用的某個接口存在問題的時候，我們能迅速通過這個功能定位這個有問題的接口。

在外部調用視圖中，會把下游應用每一個實例以IP+端口的形式進行呈現，我們可以通過這個視圖快速定位下游應用是否有某個實例存在故障。

核心實踐二：快速定位故障源和性能瓶頸

通過核心實踐一介紹的功能，相信大家已經可以對整個微服務系統形成全面而深入的了解。接下來，我們需要在系統遇到故障或系統問題的時候，通過ARMS來迅速定位故障源和性能瓶頸。

我們以某個業務功能出現卡頓現象為例，來說明如何通過ARMS一步一步的進行排查。這種情況發生的時候，往往來自于前端用戶的反饋，直觀的表現是前端用戶在進行操作的時候，返回時間比較長，或者收到系統異常相關的提示。

核查應用的整體健康狀態

首先，我們從自身對于整個系統架構以及業務架構的了解，能夠知道當問題發生的時候，前端用戶的請求在經過安全系統、負載均衡組件以網關后，最先發往哪一個微服務應用。站在微服務鏈路的角度，這個應用負責接收并處理最終用戶的請求，是鏈路的發起點，可以簡稱為入口應用。

通過全局拓撲和應用拓撲視圖，我們能夠知道這個應用依賴于哪一些下游應用，這樣就確定了與這次問題有可能發生關聯的應用名單。

回到應用列表視圖，我們能查看到這些應用的整理健康狀態，最先應該關注的是應用的狀態列，如果亮紅燈，說明系統已經診斷到某個應用存在明顯的健康問題，這個時候我們可以點擊紅燈圖標，讓ARMS生成一份應用診斷報告。通過應用診斷報告，能很快的知道這個應用在哪一個時間點發生了故障。比如ARMS判斷故障是由應用的某一個實例導致的情況下，會把可疑實例在報告中報出，讓使用者點擊實例鏈接就能進入單實例的詳情頁面，從錯誤率、硬件資源、JVM等維度對故障進行排查。

如果在應用列表視圖，并沒有發現亮紅燈的應用，我們可以從健康度百分比、請求數、錯誤數、異常數、最近10分鐘響應時間等數據中，快速判斷一下有沒有比較明顯的與實際情況存在出入的應用。比如在最近10分鐘內，有一個應用從某一個時間點開始，響應時間明顯變長，我們就可以把這類應用列入需要進一步進行分析的名單。

分析應用統計信息

通過前一個步驟，找到的可疑應用名單后，我們逐個點擊應用名，進行應用總覽視圖，分析應用的關鍵指標。ARMS會收集和展示選定時間內應用的總請求量、平均響應時間、錯誤數、實時實例數、FullGC次數、慢SQL次數、異常次數和慢調用次數，以及這些指標和上一天的環比、上周的同比升降幅度。我們主要關注這一些信息的環比以及同比升降情況，還可以修改右面右上角的時間段，來調整統計時間范圍。
這些展示的數據中，如果我們發現有明顯的可疑現象，可以點擊數字上的鏈接，進入更詳細的分析視圖。例如：我們發現某個應用今天的錯誤數相比昨天存在400%的漲幅，但總請求量變化不大，就可以判斷出這個應用非常值得懷疑。接下來，我們可以直接進入錯誤分析視圖，來觀察具體哪一個時間段的哪一些接口存在問題。

在應用總覽展示的數據中，最應該值得關注的是慢SQL數據。ARMS會記錄應用訪問數據庫的情況，當發現應用存在大量慢SQL的時候，就可以直接給出判斷：該應用在訪問數據庫的環節存在問題。我們可以從慢SQL分析視圖找到到底是哪一條SQL存在問題，從而針對性的進行優化。對于慢SQL的定義，可以通過應用的自定義配置進行修改（默認執行時間超過500ms會標記為慢SQL）

通過調用鏈鎖定問題應用

如果通過前兩個步驟還沒有找到問題的根源，就需要借助ARMS的核心能力—全鏈路排查了。

我們先進入入口應用的接口調用視圖，結束實際業場景，我們能夠快速找到哪一個接口存在響應時間過長的情況。接下來，我們進入接口快照視圖，在這個視圖中，ARMS記錄了每一次具體接口調用的情況，包括耗時、狀態、以及對應的TraceId。按照耗時從大到小的順序，對列表進行排序，就能夠找到指定時間內耗時最長的調用。

接下來就需要重點分析接口調用耗時過長的問題了。我們知道，接口調用耗時是應用自身的處理速度，加上下游所有環節處理速度，以及所有網絡時延的總和。當應用存在下游依賴的時候，整個調用鏈路的任何一個環節耗時過高，都會影響到接口的整體耗時。在這種情況下，我們需要利用TraceId提取出調用鏈路上的所有環節，進行統一的排查。點擊TraceId所代表的鏈接，呈現出來的調用鏈路視圖，就能幫助我們快速鎖定真正存在性能瓶頸的應用。

在調用鏈路視圖中，可以查看到整個調用鏈路中，所經歷的每一個應用的調用類型、服務名、IP地址，以及耗時。通過右側的時間軸，能一步定位到哪一個應用存在性能瓶頸。

鎖定有問題的代碼

找到有問題的應用后，接下來可以通過對方法棧的剖析，排查出真正存在問題的代碼片段。點擊放大鏡圖標，彈出的窗口中展示了這個應用為了處理接口請求所經過的方法列表。同樣，通過右側的時間軸能夠迅速定位哪一個方法執行的速度與預期不符。至此，我們已經能夠確定慢調用的源頭，從而有效的進行下一步的代碼優化工作。

線程分析 & 內存快照

找到有問題的代碼片斷之后，慢調用的根本原因是什么呢？ARMS能夠對應用的線程以及內存快照做進一步的分析，為使用者優化代碼提供思路。

線程分析功能提供線程粒度的CPU耗時和每類線程數量的統計，并且每5分鐘記錄一次線程的方法棧并聚合，可真實還原代碼執行過程。如果我們發現導致慢調用的關鍵應用存在CPU占用率高的問題，可以通過線程分析功能找到消耗CPU最多的線程。選中某一異常線程后，能夠通過右側的CPU耗時和線程數曲線圖分析CPU耗時與線程數變化。此外，還可以單擊異常線程的方法棧，查看指定時間內的此線程的方法執行情況，例如查看處于BLOCKED狀態的線程對應的方法，從而優化指定代碼段，以便降低CPU使用率。

JVM監控可以直觀展示指定時間段內的多項內存指標，雖然圖表能體現出內存使用量過大的情況，但無法顯示具體信息，因此如果需要進一步排查問題產生的原因，可以創建內存快照，通過詳細的日志查看內存占用的詳細信息，方便排查內存泄漏和內存浪費等內存問題。點擊JVM監控頁面的創建內存快照按鈕，可以讓ARMS在線為應用生成內存快照，并通過控制臺在線對內存快照進行分析，從而避免將大體積快照文件回傳到開發者的本地環境進行分析。如果我們發現在慢調用比較嚴重的時間點，GC頻繁或者出現了耗時長的FullGC，對于內存快照的分析是必不可少的工作。

內存快照創建后，點擊分析結果，就能夠進入內存快照在線分析頁，這個頁面集成了MAT(Eclipse Memory Analyzer)內存分析工具的所有功能，具體的用法和實踐可以參考MAT手冊。

核心實踐三：提前預知風險

構建一個健壯穩定的微服務體系，不能總是等著有問題和故障暴露出來之后，再進行排查和優化，只有建立一個可以提前預知風險機制，才能幫助我們盡可能的避免問題發生。報警機制是實現風險提前預知的核心，ARMS可以制定針對特定監控對象的報警規則，當規則被觸發時，會通過預先指定的報警方式向報警聯系人分組發送報警信息，以提醒用戶采取必要的問題解決措施。

創建聯系人

報警規則被觸發時會向指定的聯系人分組發送通知，而在創建聯系人分組之前必須先創建聯系人。所以在創建報警規則前，我們需要預先確定報警的接收者，配置好聯系人和聯系人分組。

我可以在報警管理 > 聯系人管理頁面創建聯系人，指定聯系人用于接收通知的手機號碼和郵箱地址，也可以提供用于自動發送報警通知的釘釘機器人地址。

創建報警

在ARMS控制臺可以制定針對特定監控對象的報警，當報警規則被觸發時，系統會以指定的報警方式向報警聯系人分組發送報警信息，以提醒用戶采取必要的問題解決措施。

報警覆蓋了JVM監控、異常接口監控、調用類型統計、主機監控、數據庫指標等多種類型，每一種類型都預定義了一系列的可選規則，允許使用者在一個報警中添加一條或多條規則。每一條規則都包含一條時間參數，代表報警基于最近多少分鐘之內的統計結果，而多條規則之間可以是“與“或者”或“的關系。

以數據庫指標這種類型為例，我們可以定義一條這樣的規則：”最近60分鐘之內，如果應用的多個實例在訪問數據庫的時候，平均響應時間大于2000毫秒，便觸發系統報警”。

為新上線的應用自動創建報警

我們還可以定義多條報警模板，批量創建報警，提高配置報警規則的效率，具體的操作和創建報警類似。

ARMS已經為我們默認定義了5條報警模板，以方便我們使用，在默認情況下，每一個新接入ARMS的應用都會被自動追加如下5條報警：
1、數據庫異常報警模板：數據庫響應時間長或數據庫調用出錯場景的報警
2、異常調用報警模板：存在超時調用或錯誤調用場景的報警
3、主機監控報警模板：CPU 水位過高或磁盤空間不足場景的報警
4、進程異常報警模板：進程存活場景的報警
5、GC異常報警模板：有過多的 FullGC、FullGC 耗時長或 YoungGC 耗時長場景的報警

這5條默認的報警模板很有用，代表著ARMS對于最通用的一些報警場景的抽象，我們保留這幾個模板，只在細節方面做出少許調整，用最少的配置提升風險預知的能力。

構建多語言全鏈路監控體系

除了Java語言外，ARMS還提供了PHP探針，PHP應用接入ARMS后，能夠擁有和Java應用同樣的全鏈路監控體驗。除了Java和PHP之外 ，ARMS還對主流的編程語言提供了支持，我們可以選擇開源的探針/SDK接入ARMS。受益于統一的全鏈路監控模型，如果一個微服務體系中存在多種語言之間的相互調用，只要把對應的應用都接入ARMS，就能夠跨越多語言對調用鏈路進行統一的管理和分析。

當然，開源探針/SDK在功能方面和ARMS探針還存在不小的差距，ARMS針對更多語言的探針正在陸續發布中，希望能夠盡快覆蓋所有的主流編程語言。目前階段，我們可以參考以下表格，選擇最合適的接入方式。

總結

受限制于篇幅的原因，本文只能介紹全鏈路監控最核心的一些實踐，作為全鏈路監控以及應用性能管理領域的標桿產品，ARMS還有更多的功能特性等待著我們去挖掘，我們可以對照幫助文檔逐步學習。好的產品總是能給予用戶最輕松的使用體驗，并在實際生產中發揮出巨大的業務價值。我們不妨從現在開始，就將所有微服務應用通過無侵入的方式接入ARMS，構建一體化的全鏈路監控體系，而不是等到真正遇到生產故障的那一天，為了定位問題而費盡周折。

# 加入客戶交流釘釘群

阿里云專門成立了“互聯網架構升級實戰課”釘釘群，每周邀請一位阿里云專家在群內進行行業最佳實踐直播，每天分享行業前沿干貨，歡迎掃碼或釘釘搜索群號加入：35712134。

*更多客戶案例，實戰經驗，請點擊了解：
https://www.aliyun.com/activity/daily/commercial

原文鏈接：https://developer.aliyun.com/article/778727?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的轻松玩转全链路监控的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。