導讀：微服務技術讓 IT 系統變得更敏捷、更健壯、更高效能的同時，也給帶來了架構複雜度的提升，給應用監控帶來了前所未有的挑戰。
作者｜山獵
前言隨著分散式技術的發展與演進，微服務技術成為了大型分散式 IT 架構的必然選擇。從本質上來講，微服務是一種架構風格，將一個大型的系統拆分為多個擁有獨立生命週期的應用，應用之間採用輕量級的通訊機制進行通訊。這些應用都是圍繞具體業務進行構建，可以獨立部署、獨立迭代，也可能根據業務負載獨立的水平擴充套件。微服務思想以及相關的技術為 IT 架構的發展帶來了一系列深刻的變革。
微服務技術讓 IT 系統變得更敏捷、更健壯、更高效能的同時，也給帶來了架構複雜度的提升，給應用監控帶來了前所未有的挑戰。在微服務時代，由於服務的拆分，單個使用者請求會經過多個微服務應用，形成複雜的呼叫鏈路，使傳統的依賴於單機業務日誌的監控手段無從下手，這就需要建立全新的監控機制，幫助開發者全面洞察系統執行狀態，並在系統遇到異常的時候快速的定位和解決問題。
什麼是全鏈路監控？在分散式微服務架構中，系統為了接收並處理一個前端使用者請求，需要讓多個微服務應用協同工作，其中的每一個微服務應用都可以用不同的程式語言構建，由不同的團隊開發，並可以透過多個對等的應用例項實現水平擴充套件，甚至分佈在橫跨多個數據中心的數千臺伺服器上。單個使用者請求會引發不同應用之間產生一串順序性的呼叫關係，鏈路的概念就此誕生。
微服務鏈路
隨著業務規模的增長，不但來自於前端使用者的請求頻度會增加，鏈路也變得更長，這也代表著應用之間的呼叫關係變得越來越複雜。為了提升微服務系統在複雜鏈路下的健壯性和穩定性，有 3 個關鍵訴求需要我們去解決：
1. 如何梳理整套系統的呼叫關係，並評判應用上下游依賴的合理性？
2. 如何瞭解每一個應用的效能指標，並對系統容量進行合理的規劃？
3. 當系統出現故障或異常的時候，如何第一時間發現問題、定位問題、解決問題？
標準與規範十年前，Google 成為了分散式系統鏈路追蹤服務的先行者，並透過《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》這篇著名論文闡述瞭如何在超大規模系統上建設低損耗（low overhead）、應用級透明（application-leveltransparency）、大範圍部署（ubiquitous deployment）的鏈路追蹤服務。
一個鏈路完整的資料流轉
Dapper 闡述了對分散式系統進行鏈路追蹤的技術細節，包括資料表示、埋點、傳遞、收集、儲存與展示等方面，並提出了跟蹤樹、Span、Trace、Annotation 等重要概念，為全鏈路監控提供了理論指導。
一個跟蹤樹裡面 5 個 Span 的實時關係
在 Dapper 的啟發下，業界誕生了很多用於分散式鏈路追蹤的開源元件，為了保持對鏈路中每一個環節的記錄與匹配，不僅需要在應用內部對跟蹤資訊進行傳遞，還需要讓跟蹤資訊跨越不同的應用以及不同的分散式元件。這需要制定一套統一的標準，讓微服務體系中的所有應用遵循這套標準來實現跟蹤資訊的描述和傳遞，這套標準就是 OpenTracing。OpenTracing 抽象出一套與程式語言以及業務邏輯無關的介面，對鏈路追蹤領域各類元素的統一管理，從而實現完整的全鏈路監控。
本文不會深入介紹 Dapper 和 OpenTracing 的原理以及技術細節。我們只需要知道，優秀的全鏈路監控元件會盡可能的遵循 OpenTracing 標準，以獲得更好的通用性以及擴充套件性。
可選方案全鏈路監控元件如何獲得鏈路相關的資訊呢？最簡單的方式是讓開發者在業務程式碼中手工埋點，生成符合 OpenTracing 標準的鏈路資訊，並匯入全鏈路監控元件。但手工埋點的方式要求開發者主動配合，並在業務程式碼中嵌入大量非業務邏輯。這樣的方式是極為脆弱的，開發者稍有疏忽就會導致鏈路資訊丟失，甚至影響到正常的業務邏輯。所以非手工埋點的自動鏈路資訊採集，成為了業界的主流，其中包括兩種實現方式：
SDK 方式：透過引入鏈路追蹤 SDK 自動生成鏈路資料，並自動上報。對於底層框架沒有公開API的情況，監控邏輯的注入會比較複雜，有可能需要開發者針對具體的底層框架預先做好適配工作。
探針方式：探針方式不需要在程式碼編譯前引入 SDK ，而是在應用執行的過程中，透過一個 Agent 動態的攔截底層框架的行為，從而自動注入監控邏輯。像 Java 這樣的程式語言可以透過位元組碼增強技術實現探針方式的鏈路資訊採集。這是一種最開發者最友好的方式，不需要任何程式碼層面的改動，但並不是每一種程式語言都能提供探針機制，因此 SDK 方式也被很多全鏈路監控元件採用。
不管是 SDK 方式還是探針方式，非手工埋點形式的鏈路資訊採集都依賴於鏈路追蹤元件對於底層框架的識別。這些底層框架包含的領域非常廣，其中包含應用對外提供服務所需要的框架，應用程序內部的通訊框架，應用之間相互訪問所需要的框架，應用訪問外部系統所需要的框架等等。比如在 Java 體系中，用於提供 HTTP 服務的 Tomcat、Jetty，用於程序內部通訊的 RxJava，用於微服務應用之間相互呼叫的Feign，用於訪問外部系統的 MyBatis、MySQL JDBC、HTTPClient，都屬於這個範疇。對於多種程式語言以及種類繁多的底層框架的適配，是一項浩大的工程，一個全鏈路監控方案能夠適配的底層框架越多，它的能力就越強大。
Java 應用需要支援的基本元件和框架
基礎鏈路資訊收集上來之後，需要進行統一儲存，並對資料進行清洗與聚合，根據應用響應時間、請求數、錯誤率等指標進行下鑽分析，並按應用、介面、鏈路、事務等多個維度進行展示，這也是一項非常複雜的工作。
因此，全鏈路監控方案的技術門檻是非常高的，在開源的全鏈路監控產品中，真正遵循 OpenTracing 標準，又夠被廣泛認可和使用的產品非常少，其中透過 SDK 方式接入的產品以 Jaeger 為代表，透過探針方式接入的產品以 Skywalking 為代表。
Jaeger 技術架構
最輕鬆的方案開源的全鏈路監控方案能幫助開發者更深入的理解全鏈路監控的思想、原理以技術細節，但在在生產環境大規模使用開源方案，還是會給開發者帶來很大的挑戰：
維護工作複雜：除了客戶端的 SDK 和探針外，一套全鏈路監控方案在服務端有計算元件、儲存元件、展示元件，都需要單獨進行維護。以 Jaeger 為例，僅在資料儲存方面需要維護一套獨立的 Elasticsearch 叢集，需要投入很大的工作量。
功能簡單：對主流底層框架的全面支援，豐富的 UI 介面，完善的診斷機制和報警機制，這些都是一套優秀的全鏈路監控方案所必備的特質。開源方案在這些方面很難做到盡善盡美。
缺少高可用保障：開源全鏈路監控方案並沒有完整的高可用機制，當某個元件出現故障，比如伺服器宕機的時候，無法自動恢復，需要人工介入進行解決，在這個過程中正常的監控會受到影響。
無法支撐大規模場景：當接入的應用數量達到上千個之後，開源全鏈路監控方案會暴露出各種效能問題，需要開發者修改原始碼進行針對性的最佳化。
影響正常業務：如果 SDK/探針存在設計上的缺陷，有可能導致應用出現不可預知的故障。這種情況極為罕見，但一旦發生，後果會非常嚴重，這種情況下一般也只能等待開源社群將問題修復後才能恢復使用。
之所以在生產環境使用開源全鏈路監控方案存在這麼大挑戰，是因為這些方案本身缺乏大規模實際業務場景的驗證。對於技術實力非常強的網際網路企業，會有專門的技術團隊負責全鏈路監控專案，在使用開源產品的過程中如果遇到任何問題，都可以透過自身的技術實力進行修復和彌補。但對於絕大多數使用者而言，這些挑戰所帶來的都是漫長而痛苦的體驗。
有沒有一套經歷過大規模實際業務場景驗證，又簡單易用的全鏈路監控產品呢？在雲計算時代這個問題的答案是肯定的，阿里雲 ARMS 就能滿足這個要求，代表著業界在全鏈路監控以及應用效能管理領域的最高水平。
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 此應用生成的診斷報告，以進一步分析應用不健康的原因。
應用列表檢視
全域性拓撲結構
理想的微服務應用只有不同層級之間的單向依賴，這種依賴的原則是高層應用依賴於低層應用。同層應用之間的相互依賴，或者低層應用依賴於高層應用都是違背這個原則的。假設我們在全域性拓撲視圖裡面，找到了環狀依賴關係，說明微服務應用之間的依賴關係不清晰，可以考慮對應用的層次結構進行重構。
應用總覽從應用列表進入應用總覽頁，首先呈現給使用者的是概覽分析檢視，在這個檢視中，我們能夠查詢應用在指定時間的關鍵指標。右上角的時間段是一個非常重要的選項，使用者可以根據需要來修改此應用關鍵指標的採集時間範圍（預設 15 分鐘）。在 ARMS 的很多視圖裡面，都提供了這個選項，來幫助使用者檢視指定時間範圍的監控資訊。
應用關鍵指標
應用在選定時間內的總請求量、平均響應時間、錯誤數、實時例項數、FullGC 次數、慢 SQL 次數、異常次數和慢呼叫次數，以及這些指標和上一天的環比、上週的同比升降幅度等資訊，都能夠在這個檢視體現。我們可以重點關注應用應用提供服務和應用依賴服務欄展示的指標曲線，如果在某個時間點發生了突變，可以進行針對性的排查。比如在某一個時間點，一個應用對外服務介面的請求量突然變低，極有可能是其中的一個節點發生了故障，需要特別關注。對於在 ARMS 展示出來的任何一條以時間維度為橫座標的指標曲線，都可以繼續選擇其中的時間段進行下鑽分析，這也是一個非常便捷的功能。
在指標曲線上選擇時間段進行下鑽分析
應用拓撲
應用詳情在應用詳情檢視中，能夠基於應用整體的維度以及應用內單例項的維度檢視更多詳細的資訊，包括 JVM 資訊、主機資訊、SQL 呼叫分析、異常和錯誤分析等等。
主機、控功能用於監控 CPU、記憶體、Disk（磁碟）、Load（負載）、網路流量和網路資料包的各項指標。當我們遇到硬體或網路故障的時候，這些基礎資源的指標資料將非常有價值。當應用部署在 Kubernetes 的時候，Pod 監控和主機監控能夠分別從 pod 和宿主機維度分別對指標資料進行展示。
JVM 監控功能透過視覺化頁面展示應用的 GC 情況、記憶體詳情、執行緒詳情，完全可以代替 JStat、JStack 等 JDK 自帶的 JVM 分析工具。同樣，在以時間為橫坐的曲線圖處，可以繼續選中一個時間段進行下鑽分析。
應用情況——JVM 監控
如果一個應用的多個對等例項中，某一個出現了故障，我們就能夠非常迅速的發現這個例項在應用情況檢視中呈現出來的狀態資訊和其他例項存在非常大的區別，這樣有助於我們迅速找到故障例項，並進行相應的處理。
介面呼叫 & 外部呼叫當一個應用對外提供多個服務介面的時候，如何從分析每一個介面的服務質量，以及每一個介面對應的鏈路詳細情況呢？這個時候介面呼叫檢視就能發揮重要的作用。從這個應用所有提供的介面中，我們可以選中需要分析的單個介面，與這個介面相關的鏈路資訊就能夠從多個維度展示出來，其中包括介面的請求數、響應時間、錯誤數、返回狀態碼，以及在介面所對應的鏈路中，應用訪問外部資料庫（包括關係型資料庫，以及 Redis 等非關係型資料庫）的情況。如果訪問這個介面的上游應用也接入了 ARMS，還能從鏈路上游頁籤檢視每一個上游應用訪問這個介面的請求數、響應時間和錯誤數。同樣，如果這個介面對應的鏈路在離開這個應用後，還會繼續訪問接入了 ARMS 的下游應用，我們也能從鏈路下游頁籤檢視到針對每一個下游應用的請求情況。
介面呼叫
我們需要記住，介面呼叫基於單個應用介面的維度，對鏈路資訊進行提取並展示。當一個應用的某個介面存在問題的時候，我們能迅速透過這個功能定位這個有問題的介面。
在外部呼叫檢視中，會把下游應用每一個例項以 IP+埠的形式進行呈現，我們可以透過這個檢視快速定位下游應用是否有某個例項存在故障。
核心實踐二：快速定位故障源和效能瓶頸透過核心實踐一介紹的功能，相信大家已經可以對整個微服務系統形成全面而深入的瞭解。接下來，我們需要在系統遇到故障或系統問題的時候，透過 ARMS 來迅速定位故障源和效能瓶頸。
我們以某個業務功能出現卡頓現象為例，來說明如何透過 ARMS 一步一步的進行排查。這種情況發生的時候，往往來自於前端使用者的反饋，直觀的表現是前端使用者在進行操作的時候，返回時間比較長，或者收到系統異常相關的提示。
核查應用的整體健康狀態首先，我們從自身對於整個系統架構以及業務架構的瞭解，能夠知道當問題發生的時候，前端使用者的請求在經過安全系統、負載均衡元件以閘道器後，最先發往哪一個微服務應用。站在微服務鏈路的角度，這個應用負責接收並處理終端使用者的請求，是鏈路的發起點，可以簡稱為入口應用。
透過全域性拓撲和應用拓撲檢視，我們能夠知道這個應用依賴於哪一些下游應用，這樣就確定了與這次問題有可能發生關聯的應用名單。
回到應用列表檢視，我們能檢視到這些應用的整理健康狀態，最先應該關注的是應用的狀態列，如果亮紅燈，說明系統已經診斷到某個應用存在明顯的健康問題，這個時候我們可以點選紅燈圖示，讓 ARMS 生成一份應用診斷報告。透過應用診斷報告，能很快的知道這個應用在哪一個時間點發生了故障。比如 ARMS 判斷故障是由應用的某一個例項導致的情況下，會把可疑例項在報告中報出，讓使用者點選例項連結就能進入單例項的詳情頁面，從錯誤率、硬體資源、JVM 等維度對故障進行排查。
診斷報告
如果在應用列表檢視，並沒有發現亮紅燈的應用，我們可以從健康度百分比、請求數、錯誤數、異常數、最近 10 分鐘響應時間等資料中，快速判斷一下有沒有比較明顯的與實際情況存在出入的應用。比如在最近 10 分鐘內，有一個應用從某一個時間點開始，響應時間明顯變長，我們就可以把這類應用列入需要進一步進行分析的名單。
分析應用統計資訊透過前一個步驟，找到的可疑應用名單後，我們逐個點選應用名，進行應用總覽檢視，分析應用的關鍵指標。ARMS 會收集和展示選定時間內應用的總請求量、平均響應時間、錯誤數、實時例項數、FullGC 次數、慢 SQL 次數、異常次數和慢呼叫次數，以及這些指標和上一天的環比、上週的同比升降幅度。我們主要關注這一些資訊的環比以及同比升降情況，還可以修改右面右上角的時間段，來調整統計時間範圍。
錯誤分析檢視
在應用總覽展示的資料中，最應該值得關注的是慢 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，對於記憶體快照的分析是必不可少的工作。
記憶體分析報告
核心實踐三：提前預知風險構建一個健壯穩定的微服務體系，不能總是等著有問題和故障暴露出來之後，再進行排查和最佳化，只有建立一個可以提前預知風險機制，才能幫助我們儘可能的避免問題發生。報警機制是實現風險提前預知的核心，ARMS 可以制定針對特定監控物件的報警規則，當規則被觸發時，會透過預先指定的報警方式向報警聯絡人分組傳送報警資訊，以提醒使用者採取必要的問題解決措施。
建立聯絡人報警規則被觸發時會向指定的聯絡人分組傳送通知，而在建立聯絡人分組之前必須先建立聯絡人。所以在建立報警規則前，我們需要預先確定報警的接收者，配置好聯絡人和聯絡人分組。
我可以在報警管理 → 聯絡人管理頁面建立聯絡人，指定聯絡人用於接收通知的手機號碼和郵箱地址，也可以提供用於自動傳送報警通知的釘釘機器人地址。
建立報警在 ARMS 控制檯可以制定針對特定監控物件的報警，當報警規則被觸發時，系統會以指定的報警方式向報警聯絡人分組傳送報警資訊，以提醒使用者採取必要的問題解決措施。
報警覆蓋了 JVM 監控、異常介面監控、呼叫型別統計、主機監控、資料庫指標等多種型別，每一種型別都預定義了一系列的可選規則，允許使用者在一個報警中新增一條或多條規則。每一條規則都包含一條時間引數，代表報警基於最近多少分鐘之內的統計結果，而多條規則之間可以是“與“或者”或“的關係。
以資料庫指標這種型別為例，我們可以定義一條這樣的規則：“最近 60 分鐘之內，如果應用的多個例項在訪問資料庫的時候，平均響應時間大於 2000 毫秒，便觸發系統報警”。
資料庫指標報警規則示例
為新上線的應用自動建立報警我們還可以定義多條報警模板，批次建立報警，提高配置報警規則的效率，具體的操作和建立報警類似。
ARMS 已經為我們預設定義了 5 條報警模板，以方便我們使用，在預設情況下，每一個新接入 ARMS 的應用都會被自動追加如下 5 條報警：
資料庫異常報警模板：資料庫響應時間長或資料庫調用出錯場景的報警異常呼叫報警模板：存在超時呼叫或錯誤呼叫場景的報警主機監控報警模板：CPU 水位過高或磁碟空間不足場景的報警程序異常報警模板：程序存活場景的報警GC 異常報警模板：有過多的 FullGC、FullGC 耗時長或 YoungGC 耗時長場景的報警這 5 條預設的報警模板很有用，代表著 ARMS 對於最通用的一些報警場景的抽象，我們保留這幾個模板，只在細節方面做出少許調整，用最少的配置提升風險預知的能力。
構建多語言全鏈路監控體系除了 Java 語言外，ARMS 還提供了 PHP 探針，PHP 應用接入 ARMS 後，能夠擁有和 Java 應用同樣的全鏈路監控體驗。除了 Java 和 PHP 之外，ARMS 還對主流的程式語言提供了支援，我們可以選擇開源的探針/SDK 接入 ARMS。受益於統一的全鏈路監控模型，如果一個微服務體系中存在多種語言之間的相互呼叫，只要把對應的應用都接入 ARMS，就能夠跨越多語言對呼叫鏈路進行統一的管理和分析。
ARMS 支援的程式語言
各種主流語言的接入方式
總結受限制於篇幅的原因，本文只能介紹全鏈路監控最核心的一些實踐，作為全鏈路監控以及應用效能管理領域的標杆產品，ARMS 還有更多的功能特性等待著我們去挖掘，我們可以對照幫助文件逐步學習。好的產品總是能給予使用者最輕鬆的使用體驗，並在實際生產中發揮出巨大的業務價值。我們不妨從現在開始，就將所有微服務應用透過無侵入的方式接入 ARMS，構建一體化的全鏈路監控體系，而不是等到真正遇到生產故障的那一天，為了定位問題而費盡周折。