作者：山獵，阿裡雲解決方案架構師
前言
随着分布式技術的發展與演進，微服務技術成為了大型分布式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，建構一體化的全鍊路監控體系，而不是等到真正遇到生産故障的那一天，為了定位問題而費盡周折。
【更多精彩】
1.Serverless應用引擎(SAE)限時優惠，還有阿裡巴巴十年最佳實踐深度解密，點選馬上了解：
https://www.aliyun.com/activity/daily/commercial?spm=5176.20960838.0.0.6a54305etoEn4D2.【填問卷領淘公仔】點選馬上填寫問卷：
https://survey.aliyun.com/apps/zhiliao/YmW95Gk8bU3.【加入行業實戰交流釘釘群】阿裡雲專門成立了“網際網路架構更新實戰課”釘釘群，每周邀請一位阿裡雲專家在群内進行行業最佳實踐直播，每天分享行業前沿幹貨，釘釘掃碼馬上加入。