轻松玩转全链路监控
作者：山獵，阿里云解決方案架構(gòu)師
前言
隨著分布式技術(shù)的發(fā)展與演進，微服務(wù)技術(shù)成為了大型分布式IT架構(gòu)的必然選擇。從本質(zhì)上來講，微服務(wù)是一種架構(gòu)風(fēng)格，將一個大型的系統(tǒng)拆分為多個擁有獨立生命周期的應(yīng)用，應(yīng)用之間采用輕量級的通信機制進行通信。這些應(yīng)用都是圍繞具體業(yè)務(wù)進行構(gòu)建，可以獨立部署、獨立迭代，也可能根據(jù)業(yè)務(wù)負載獨立的水平擴展。微服務(wù)思想以及相關(guān)的技術(shù)為IT架構(gòu)的發(fā)展帶來了一系列深刻的變革。
微服務(wù)技術(shù)讓IT系統(tǒng)變得更敏捷、更健壯、更高性能的同時，也給帶來了架構(gòu)復(fù)雜度的提升，給應(yīng)用監(jiān)控帶來了前所未有的挑戰(zhàn)。在微服務(wù)時代，由于服務(wù)的拆分，單個用戶請求會經(jīng)過多個微服務(wù)應(yīng)用，形成復(fù)雜的調(diào)用鏈路，使傳統(tǒng)的依賴于單機業(yè)務(wù)日志的監(jiān)控手段無從下手，這就需要建立全新的監(jiān)控機制，幫助開發(fā)者全面洞察系統(tǒng)運行狀態(tài)，并在系統(tǒng)遇到異常的時候快速的定位和解決問題。
什么是全鏈路監(jiān)控？
在分布式微服務(wù)架構(gòu)中，系統(tǒng)為了接收并處理一個前端用戶請求，需要讓多個微服務(wù)應(yīng)用協(xié)同工作，其中的每一個微服務(wù)應(yīng)用都可以用不同的編程語言構(gòu)建，由不同的團隊開發(fā)，并可以通過多個對等的應(yīng)用實例實現(xiàn)水平擴展，甚至分布在橫跨多個數(shù)據(jù)中心的數(shù)千臺服務(wù)器上。單個用戶請求會引發(fā)不同應(yīng)用之間產(chǎn)生一串順序性的調(diào)用關(guān)系，鏈路的概念就此誕生。
隨著業(yè)務(wù)規(guī)模的增長，不但來自于前端用戶的請求頻度會增加，鏈路也變得更長，這也代表著應(yīng)用之間的調(diào)用關(guān)系變得越來越復(fù)雜。為了提升微服務(wù)系統(tǒng)在復(fù)雜鏈路下的健壯性和穩(wěn)定性，有3個關(guān)鍵訴求需要我們?nèi)ソ鉀Q：
1 . 如何梳理整套系統(tǒng)的調(diào)用關(guān)系，并評判應(yīng)用上下游依賴的合理性？
2 . 如何了解每一個應(yīng)用的性能指標，并對系統(tǒng)容量進行合理的規(guī)劃？
3 . 當系統(tǒng)出現(xiàn)故障或異常的時候，如何第一時間發(fā)現(xiàn)問題、定位問題、解決問題？
這3個關(guān)鍵訴求的核心挑戰(zhàn)，都來源于應(yīng)用之間復(fù)雜的鏈路。如果有一套成熟易用的機制，對每一條鏈路的行為進行記錄，并進行深入的分析，提取出有價值的參考數(shù)據(jù)，就能讓這些難題迎刃而解，這個重要的機制就是全鏈路監(jiān)控。
標準與規(guī)范
十年前，Google成為了分布式系統(tǒng)鏈路追蹤服務(wù)的先行者，并通過《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》這篇著名論文闡述了如何在超大規(guī)模系統(tǒng)上建設(shè)低損耗（low overhead）、應(yīng)用級透明（application-level transparency）、大范圍部署（ubiquitous deployment）的鏈路追蹤服務(wù)。
Dapper闡述了對分布式系統(tǒng)進行鏈路追蹤的技術(shù)細節(jié)，包括數(shù)據(jù)表示、埋點、傳遞、收集、存儲與展示等方面，并提出了跟蹤樹、Span、Trace、Annotation等重要概念，為全鏈路監(jiān)控提供了理論指導(dǎo)。
在Dapper的啟發(fā)下，業(yè)界誕生了很多用于分布式鏈路追蹤的開源組件，為了保持對鏈路中每一個環(huán)節(jié)的記錄與匹配，不僅需要在應(yīng)用內(nèi)部對跟蹤信息進行傳遞，還需要讓跟蹤信息跨越不同的應(yīng)用以及不同的分布式組件。這需要制定一套統(tǒng)一的標準，讓微服務(wù)體系中的所有應(yīng)用遵循這套標準來實現(xiàn)跟蹤信息的描述和傳遞，這套標準就是OpenTracing。OpenTracing抽象出一套與編程語言以及業(yè)務(wù)邏輯無關(guān)的接口，對鏈路追蹤領(lǐng)域各類元素的統(tǒng)一管理，從而實現(xiàn)完整的全鏈路監(jiān)控。
本文不會深入介紹Dapper和OpenTracing的原理以及技術(shù)細節(jié)。我們只需要知道，優(yōu)秀的全鏈路監(jiān)控組件會盡可能的遵循OpenTracing標準，以獲得更好的通用性以及擴展性。
可選方案
全鏈路監(jiān)控組件如何獲得鏈路相關(guān)的信息呢？最簡單的方式是讓開發(fā)者在業(yè)務(wù)代碼中手工埋點，生成符合OpenTracing標準的鏈路信息，并匯入全鏈路監(jiān)控組件。但手工埋點的方式要求開發(fā)者主動配合，并在業(yè)務(wù)代碼中嵌入大量非業(yè)務(wù)邏輯。這樣的方式是極為脆弱的，開發(fā)者稍有疏忽就會導(dǎo)致鏈路信息丟失，甚至影響到正常的業(yè)務(wù)邏輯。所以非手工埋點的自動鏈路信息采集，成為了業(yè)界的主流，其中包括兩種實現(xiàn)方式：
**1 . SDK方式: 通過引入鏈路追蹤SDK自動生成鏈路數(shù)據(jù)，并自動上報。對于底層框架沒有公開API的情況，監(jiān)控邏輯的注入會比較復(fù)雜，有可能需要開發(fā)者針對具體的底層框架預(yù)先做好適配工作。
2 . 探針方式: 探針方式不需要在代碼編譯前引入SDK，而是在應(yīng)用運行的過程中，通過一個Agent動態(tài)的攔截底層框架的行為，從而自動注入監(jiān)控邏輯**。像Java這樣的編程語言可以通過字節(jié)碼增強技術(shù)實現(xiàn)探針方式的鏈路信息采集。這是一種最開發(fā)者最友好的方式，不需要任何代碼層面的改動，但并不是每一種編程語言都能提供探針機制，因此SDK方式也被很多全鏈路監(jiān)控組件采用。
不管是SDK方式還是探針方式，非手工埋點形式的鏈路信息采集都依賴于鏈路追蹤組件對于底層框架的識別。這些底層框架包含的領(lǐng)域非常廣，其中包含應(yīng)用對外提供服務(wù)所需要的框架，應(yīng)用進程內(nèi)部的通訊框架，應(yīng)用之間相互訪問所需要的框架，應(yīng)用訪問外部系統(tǒng)所需要的框架等等。比如在Java體系中，用于提供HTTP服務(wù)的Tomcat、Jetty，用于進程內(nèi)部通訊的RxJava，用于微服務(wù)應(yīng)用之間相互調(diào)用的Feign，用于訪問外部系統(tǒng)的MyBatis、MySQL JDBC、HTTPClient，都屬于這個范疇。對于多種編程語言以及種類繁多的底層框架的適配，是一項浩大的工程，一個全鏈路監(jiān)控方案能夠適配的底層框架越多，它的能力就越強大。
基礎(chǔ)鏈路信息收集上來之后，需要進行統(tǒng)一存儲，并對數(shù)據(jù)進行清洗與聚合，根據(jù)應(yīng)用響應(yīng)時間、請求數(shù)、錯誤率等指標進行下鉆分析，并按應(yīng)用、接口、鏈路、事務(wù)等多個維度進行展示，這也是一項非常復(fù)雜的工作。
因此，全鏈路監(jiān)控方案的技術(shù)門檻是非常高的，在開源的全鏈路監(jiān)控產(chǎn)品中，真正遵循OpenTracing標準，又夠被廣泛認可和使用的產(chǎn)品非常少，其中通過SDK方式接入的產(chǎn)品以Jaeger為代表，通過探針方式接入的產(chǎn)品以Skywalking為代表。
最輕松的方案
開源的全鏈路監(jiān)控方案能幫助開發(fā)者更深入的理解全鏈路監(jiān)控的思想、原理以技術(shù)細節(jié)，但在在生產(chǎn)環(huán)境大規(guī)模使用開源方案，還是會給開發(fā)者帶來很大的挑戰(zhàn)：
1 . 維護工作復(fù)雜：除了客戶端的SDK和探針外，一套全鏈路監(jiān)控方案在服務(wù)端有計算組件、存儲組件、展示組件，都需要單獨進行維護。以Jaeger為例，僅在數(shù)據(jù)存儲方面需要維護一套獨立的Elasticsearch集群，需要投入很大的工作量。
2 . 功能簡單：對主流底層框架的全面支持，豐富的UI界面，完善的診斷機制和報警機制，這些都是一套優(yōu)秀的全鏈路監(jiān)控方案所必備的特質(zhì)。開源方案在這些方面很難做到盡善盡美。
3 . 缺少高可用保障：開源全鏈路監(jiān)控方案并沒有完整的高可用機制，當某個組件出現(xiàn)故障，比如服務(wù)器宕機的時候，無法自動恢復(fù)，需要人工介入進行解決，在這個過程中正常的監(jiān)控會受到影響。
4 . 無法支撐大規(guī)模場景：當接入的應(yīng)用數(shù)量達到上千個之后，開源全鏈路監(jiān)控方案會暴露出各種性能問題，需要開發(fā)者修改源代碼進行針對性的優(yōu)化。
5 . 影響正常業(yè)務(wù)：如果SDK/探針存在設(shè)計上的缺陷，有可能導(dǎo)致應(yīng)用出現(xiàn)不可預(yù)知的故障。這種情況極為罕見，但一旦發(fā)生，后果會非常嚴重，這種情況下一般也只能等待開源社區(qū)將問題修復(fù)后才能恢復(fù)使用。
之所以在生產(chǎn)環(huán)境使用開源全鏈路監(jiān)控方案存在這么大挑戰(zhàn)，是因為這些方案本身缺乏大規(guī)模實際業(yè)務(wù)場景的驗證。對于技術(shù)實力非常強的互聯(lián)網(wǎng)企業(yè)，會有專門的技術(shù)團隊負責(zé)全鏈路監(jiān)控項目，在使用開源產(chǎn)品的過程中如果遇到任何問題，都可以通過自身的技術(shù)實力進行修復(fù)和彌補。但對于絕大多數(shù)使用者而言，這些挑戰(zhàn)所帶來的都是漫長而痛苦的體驗。
有沒有一套經(jīng)歷過大規(guī)模實際業(yè)務(wù)場景驗證，又簡單易用的全鏈路監(jiān)控產(chǎn)品呢？在云計算時代這個問題的答案是肯定的，阿里云ARMS就能滿足這個要求，代表著業(yè)界在全鏈路監(jiān)控以及應(yīng)用性能管理領(lǐng)域的最高水平。
應(yīng)用實時監(jiān)控服務(wù)ARMS（Application Real-Time Monitoring Service）起源于阿里巴巴內(nèi)部的EagleEye（鷹眼）系統(tǒng)，已經(jīng)經(jīng)歷了近10年的沉淀和演進。鷹眼系統(tǒng)同時將基礎(chǔ)設(shè)施層、分布式應(yīng)用層、業(yè)務(wù)邏輯層與客戶端層進行了全鏈路跟蹤，每天對萬億級別的分布式調(diào)用進行分析，對底層的流計算、多維時序指標與事件存儲體系等進行了大量優(yōu)化，同時引入了時序檢測、根因分析、業(yè)務(wù)鏈路特征等技術(shù)，將問題發(fā)現(xiàn)與定位由被動轉(zhuǎn)為主動。
在ARMS的理念中，對全鏈路監(jiān)控的理解已經(jīng)超出了一般意義上APM（應(yīng)用性能管理的范疇），而是把“可觀測性”作為產(chǎn)品的最重要使命。可觀測性是一切自動化決策的基礎(chǔ)，求最終目的是為一個復(fù)雜分布式系統(tǒng)所發(fā)生的一切給出合理解釋。
正是因為經(jīng)歷了大規(guī)模生產(chǎn)環(huán)境的長期驗證，才使ARMS能夠在易用性、功能性、穩(wěn)定性方面做到極致，以開源領(lǐng)域最活躍的全鏈路監(jiān)控項目Skywalking為例，我們可以從多個維度對兩個產(chǎn)品進行對比：
接入來，我們就通過阿里云ARMS，開啟輕松玩轉(zhuǎn)全鏈路監(jiān)控之旅。
應(yīng)用接入
ARMS采用無代碼侵入探針接入方式，對于應(yīng)用接入只需要非常簡單的幾個步驟，以Java應(yīng)用為例：
1 . 開通ARMS服務(wù)：登錄阿里云控制臺后，打開ARMS產(chǎn)品主頁，按照提示開通“應(yīng)用實時監(jiān)控服務(wù)試用版”，開通服務(wù)后會獲得15天的免費產(chǎn)品試用。
2 . 下載探針（Agent）：在公網(wǎng)環(huán)境以及VPC內(nèi)，都提供了探針的下載鏈接，可以直接參考ARMS臺的提示進行操作。
3 . 修改應(yīng)用的啟動命令：通過-javaagent掛載探針，并配置對應(yīng)的license Key以及應(yīng)用名。比如我們啟動SpringBoot應(yīng)用為例，啟動命令為
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代表應(yīng)用的名字。在微服務(wù)應(yīng)用中，一個應(yīng)用可以擁有多個對等的應(yīng)用實例，這些對等的應(yīng)用實例接入ARMS的時候，使用同樣的應(yīng)用名，這樣ARMS可以把這個應(yīng)用的多個實例放到一個分組中進行統(tǒng)一管理。
修改完應(yīng)用啟動命令后，對應(yīng)用進行重啟，就能夠成功接入ARMS。如果在1分鐘后，ARMS控制臺的應(yīng)用列表能夠看到新的應(yīng)用，就代表接入成功。
當然，對于Tomcat等通過操作系統(tǒng)腳本啟動的應(yīng)用，不能直接修改應(yīng)用啟動命令來掛載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容器啟動的應(yīng)用可以參考ARMS的幫助文檔。
對于部署在阿里云EDAS或者容器服務(wù)Kubernetes的應(yīng)用，接入工作會更加的簡單，ARMS已經(jīng)和這些產(chǎn)品進行了集成，使用者都不需要下載ARMS的探針到應(yīng)用所在的節(jié)點，可以直接在控制臺進行一鍵式的批量操作。
特別重要的一點是，ARMS支持混合云模式，所以并不要求接入的應(yīng)用一定要部署在阿里云，不管應(yīng)用部署在線下IDC還是其他的云，都可以統(tǒng)一接入ARMS。當然，需要確保在混合云模式下，應(yīng)用與ARMS服務(wù)端之間的網(wǎng)絡(luò)是暢通的。
核心實踐一：了解你的系統(tǒng)
應(yīng)用接入后，可以通過ARMS獲得哪些重要的信息，從而幫助使用者更好的了解整個系統(tǒng)呢？我們可以從這幾個方面入手：
應(yīng)用列表和全局拓撲
在應(yīng)用列表視圖，我們能看到每一個應(yīng)用的健康度以及最近10分鐘對外服務(wù)的響應(yīng)情況。如果應(yīng)用的狀態(tài)列亮紅燈，代表此應(yīng)用運行不健康，我們可以繼續(xù)點擊紅燈查看ARMS此應(yīng)用生成的診斷報告，以進一步分析應(yīng)用不健康的原因。
點擊應(yīng)用列表右上角的全局拓撲按鈕，能夠通過可視化界面觀察所有接入ARMS應(yīng)用的拓撲結(jié)構(gòu)，這個界面清晰的展示了所有應(yīng)用的上下游組件以及相應(yīng)的調(diào)用關(guān)系，能夠幫助使用者從全局角度深入理解整個微服務(wù)系統(tǒng)。
理想的微服務(wù)應(yīng)用只有不同層級之間的單向依賴，這種依賴的原則是高層應(yīng)用依賴于低層應(yīng)用。同層應(yīng)用之間的相互依賴，或者低層應(yīng)用依賴于高層應(yīng)用都是違背這個原則的。假設(shè)我們在全局拓撲視圖里面，找到了環(huán)狀依賴關(guān)系，說明微服務(wù)應(yīng)用之間的依賴關(guān)系不清晰，可以考慮對應(yīng)用的層次結(jié)構(gòu)進行重構(gòu)。
應(yīng)用總覽
從應(yīng)用列表進入應(yīng)用總覽頁，首先呈現(xiàn)給使用者的是概覽分析視圖，在這個視圖中，我們能夠查詢應(yīng)用在指定時間的關(guān)鍵指標。右上角的時間段是一個非常重要的選項，使用者可以根據(jù)需要來修改此應(yīng)用關(guān)鍵指標的采集時間范圍（默認15分鐘）。在ARMS的很多視圖里面，都提供了這個選項，來幫助使用者查看指定時間范圍的監(jiān)控信息。
應(yīng)用在選定時間內(nèi)的總請求量、平均響應(yīng)時間、錯誤數(shù)、實時實例數(shù)、FullGC 次數(shù)、慢 SQL 次數(shù)、異常次數(shù)和慢調(diào)用次數(shù)，以及這些指標和上一天的環(huán)比、上周的同比升降幅度等信息，都能夠在這個視圖體現(xiàn)。我們可以重點關(guān)注應(yīng)用應(yīng)用提供服務(wù)和應(yīng)用依賴服務(wù)欄展示的指標曲線，如果在某個時間點發(fā)生了突變，可以進行針對性的排查。比如在某一個時間點，一個應(yīng)用對外服務(wù)接口的請求量突然變低，極有可能是其中的一個節(jié)點發(fā)生了故障，需要特別關(guān)注。對于在ARMS展示出來的任何一條以時間維度為橫座標的指標曲線，都可以繼續(xù)選擇其中的時間段進行下鉆分析，這也是一個非常便捷的功能。
在拓撲圖頁簽上，可以通過拓撲圖更加直觀地看到應(yīng)用的上下游組件以及與它們的調(diào)用關(guān)系。相比全局拓撲圖，單應(yīng)用拓撲圖能夠展示更多細節(jié)信息，幫助使用者分析應(yīng)用的上下游調(diào)用情況，從而更快速地找出性能瓶頸。
應(yīng)用詳情
在應(yīng)用詳情視圖中，能夠基于應(yīng)用整體的維度以及應(yīng)用內(nèi)單實例的維度查看更多詳細的信息，包括JVM信息、主機信息、SQL調(diào)用分析、異常和錯誤分析等等。
主機監(jiān)控功能用于監(jiān)控CPU、內(nèi)存、Disk（磁盤）、Load（負載）、網(wǎng)絡(luò)流量和網(wǎng)絡(luò)數(shù)據(jù)包的各項指標。當我們遇到硬件或網(wǎng)絡(luò)故障的時候，這些基礎(chǔ)資源的指標數(shù)據(jù)將非常有價值。當應(yīng)用部署在Kubernetes的時候，Pod監(jiān)控和主機監(jiān)控能夠分別從pod和宿主機維度分別對指標數(shù)據(jù)進行展示。
JVM監(jiān)控功能通過可視化頁面展示應(yīng)用的GC情況、內(nèi)存詳情、線程詳情，完全可以代替JStat、JStack等JDK自帶的JVM分析工具。同樣，在以時間為橫坐的曲線圖處，可以繼續(xù)選中一個時間段進行下鉆分析。
如果一個應(yīng)用的多個對等實例中，某一個出現(xiàn)了故障，我們就能夠非常迅速的發(fā)現(xiàn)這個實例在應(yīng)用情況視圖中呈現(xiàn)出來的狀態(tài)信息和其他實例存在非常大的區(qū)別，這樣有助于我們迅速找到故障實例，并進行相應(yīng)的處理。
接口調(diào)用 & 外部調(diào)用
當一個應(yīng)用對外提供多個服務(wù)接口的時候，如何從分析每一個接口的服務(wù)質(zhì)量，以及每一個接口對應(yīng)的鏈路詳細情況呢？這個時候接口調(diào)用視圖就能發(fā)揮重要的作用。從這個應(yīng)用所有提供的接口中，我們可以選中需要分析的單個接口，與這個接口相關(guān)的鏈路信息就能夠從多個維度展示出來，其中包括接口的請求數(shù)、響應(yīng)時間、錯誤數(shù)、返回狀態(tài)碼，以及在接口所對應(yīng)的鏈路中，應(yīng)用訪問外部數(shù)據(jù)庫（包括關(guān)系型數(shù)據(jù)庫，以及Redis等非關(guān)系型數(shù)據(jù)庫）的情況。
如果訪問這個接口的上游應(yīng)用也接入了ARMS，還能從鏈路上游頁簽查看每一個上游應(yīng)用訪問這個接口的請求數(shù)、響應(yīng)時間和錯誤數(shù)。同樣，如果這個接口對應(yīng)的鏈路在離開這個應(yīng)用后，還會繼續(xù)訪問接入了ARMS的下游應(yīng)用，我們也能從鏈路下游頁簽查看到針對每一個下游應(yīng)用的請求情況。
我們需要記住，接口調(diào)用基于單個應(yīng)用接口的維度，對鏈路信息進行提取并展示。當一個應(yīng)用的某個接口存在問題的時候，我們能迅速通過這個功能定位這個有問題的接口。
在外部調(diào)用視圖中，會把下游應(yīng)用每一個實例以IP+端口的形式進行呈現(xiàn)，我們可以通過這個視圖快速定位下游應(yīng)用是否有某個實例存在故障。
核心實踐二：快速定位故障源和性能瓶頸
通過核心實踐一介紹的功能，相信大家已經(jīng)可以對整個微服務(wù)系統(tǒng)形成全面而深入的了解。接下來，我們需要在系統(tǒng)遇到故障或系統(tǒng)問題的時候，通過ARMS來迅速定位故障源和性能瓶頸。
我們以某個業(yè)務(wù)功能出現(xiàn)卡頓現(xiàn)象為例，來說明如何通過ARMS一步一步的進行排查。這種情況發(fā)生的時候，往往來自于前端用戶的反饋，直觀的表現(xiàn)是前端用戶在進行操作的時候，返回時間比較長，或者收到系統(tǒng)異常相關(guān)的提示。
核查應(yīng)用的整體健康狀態(tài)
首先，我們從自身對于整個系統(tǒng)架構(gòu)以及業(yè)務(wù)架構(gòu)的了解，能夠知道當問題發(fā)生的時候，前端用戶的請求在經(jīng)過安全系統(tǒng)、負載均衡組件以網(wǎng)關(guān)后，最先發(fā)往哪一個微服務(wù)應(yīng)用。站在微服務(wù)鏈路的角度，這個應(yīng)用負責(zé)接收并處理最終用戶的請求，是鏈路的發(fā)起點，可以簡稱為入口應(yīng)用。
通過全局拓撲和應(yīng)用拓撲視圖，我們能夠知道這個應(yīng)用依賴于哪一些下游應(yīng)用，這樣就確定了與這次問題有可能發(fā)生關(guān)聯(lián)的應(yīng)用名單。
回到應(yīng)用列表視圖，我們能查看到這些應(yīng)用的整理健康狀態(tài)，最先應(yīng)該關(guān)注的是應(yīng)用的狀態(tài)列，如果亮紅燈，說明系統(tǒng)已經(jīng)診斷到某個應(yīng)用存在明顯的健康問題，這個時候我們可以點擊紅燈圖標，讓ARMS生成一份應(yīng)用診斷報告。通過應(yīng)用診斷報告，能很快的知道這個應(yīng)用在哪一個時間點發(fā)生了故障。比如ARMS判斷故障是由應(yīng)用的某一個實例導(dǎo)致的情況下，會把可疑實例在報告中報出，讓使用者點擊實例鏈接就能進入單實例的詳情頁面，從錯誤率、硬件資源、JVM等維度對故障進行排查。
如果在應(yīng)用列表視圖，并沒有發(fā)現(xiàn)亮紅燈的應(yīng)用，我們可以從健康度百分比、請求數(shù)、錯誤數(shù)、異常數(shù)、最近10分鐘響應(yīng)時間等數(shù)據(jù)中，快速判斷一下有沒有比較明顯的與實際情況存在出入的應(yīng)用。比如在最近10分鐘內(nèi)，有一個應(yīng)用從某一個時間點開始，響應(yīng)時間明顯變長，我們就可以把這類應(yīng)用列入需要進一步進行分析的名單。
分析應(yīng)用統(tǒng)計信息
通過前一個步驟，找到的可疑應(yīng)用名單后，我們逐個點擊應(yīng)用名，進行應(yīng)用總覽視圖，分析應(yīng)用的關(guān)鍵指標。ARMS會收集和展示選定時間內(nèi)應(yīng)用的總請求量、平均響應(yīng)時間、錯誤數(shù)、實時實例數(shù)、FullGC次數(shù)、慢SQL次數(shù)、異常次數(shù)和慢調(diào)用次數(shù)，以及這些指標和上一天的環(huán)比、上周的同比升降幅度。我們主要關(guān)注這一些信息的環(huán)比以及同比升降情況，還可以修改右面右上角的時間段，來調(diào)整統(tǒng)計時間范圍。
這些展示的數(shù)據(jù)中，如果我們發(fā)現(xiàn)有明顯的可疑現(xiàn)象，可以點擊數(shù)字上的鏈接，進入更詳細的分析視圖。例如：我們發(fā)現(xiàn)某個應(yīng)用今天的錯誤數(shù)相比昨天存在400%的漲幅，但總請求量變化不大，就可以判斷出這個應(yīng)用非常值得懷疑。接下來，我們可以直接進入錯誤分析視圖，來觀察具體哪一個時間段的哪一些接口存在問題。
在應(yīng)用總覽展示的數(shù)據(jù)中，最應(yīng)該值得關(guān)注的是慢SQL數(shù)據(jù)。ARMS會記錄應(yīng)用訪問數(shù)據(jù)庫的情況，當發(fā)現(xiàn)應(yīng)用存在大量慢SQL的時候，就可以直接給出判斷：該應(yīng)用在訪問數(shù)據(jù)庫的環(huán)節(jié)存在問題。我們可以從慢SQL分析視圖找到到底是哪一條SQL存在問題，從而針對性的進行優(yōu)化。對于慢SQL的定義，可以通過應(yīng)用的自定義配置進行修改（默認執(zhí)行時間超過500ms會標記為慢SQL）
通過調(diào)用鏈鎖定問題應(yīng)用
如果通過前兩個步驟還沒有找到問題的根源，就需要借助ARMS的核心能力—全鏈路排查了。
我們先進入入口應(yīng)用的接口調(diào)用視圖，結(jié)束實際業(yè)場景，我們能夠快速找到哪一個接口存在響應(yīng)時間過長的情況。接下來，我們進入接口快照視圖，在這個視圖中，ARMS記錄了每一次具體接口調(diào)用的情況，包括耗時、狀態(tài)、以及對應(yīng)的TraceId。按照耗時從大到小的順序，對列表進行排序，就能夠找到指定時間內(nèi)耗時最長的調(diào)用。
接下來就需要重點分析接口調(diào)用耗時過長的問題了。我們知道，接口調(diào)用耗時是應(yīng)用自身的處理速度，加上下游所有環(huán)節(jié)處理速度，以及所有網(wǎng)絡(luò)時延的總和。當應(yīng)用存在下游依賴的時候，整個調(diào)用鏈路的任何一個環(huán)節(jié)耗時過高，都會影響到接口的整體耗時。在這種情況下，我們需要利用TraceId提取出調(diào)用鏈路上的所有環(huán)節(jié)，進行統(tǒng)一的排查。點擊TraceId所代表的鏈接，呈現(xiàn)出來的調(diào)用鏈路視圖，就能幫助我們快速鎖定真正存在性能瓶頸的應(yīng)用。
在調(diào)用鏈路視圖中，可以查看到整個調(diào)用鏈路中，所經(jīng)歷的每一個應(yīng)用的調(diào)用類型、服務(wù)名、IP地址，以及耗時。通過右側(cè)的時間軸，能一步定位到哪一個應(yīng)用存在性能瓶頸。
鎖定有問題的代碼
找到有問題的應(yīng)用后，接下來可以通過對方法棧的剖析，排查出真正存在問題的代碼片段。點擊放大鏡圖標，彈出的窗口中展示了這個應(yīng)用為了處理接口請求所經(jīng)過的方法列表。同樣，通過右側(cè)的時間軸能夠迅速定位哪一個方法執(zhí)行的速度與預(yù)期不符。至此，我們已經(jīng)能夠確定慢調(diào)用的源頭，從而有效的進行下一步的代碼優(yōu)化工作。
線程分析 & 內(nèi)存快照
找到有問題的代碼片斷之后，慢調(diào)用的根本原因是什么呢？ARMS能夠?qū)?yīng)用的線程以及內(nèi)存快照做進一步的分析，為使用者優(yōu)化代碼提供思路。
線程分析功能提供線程粒度的CPU耗時和每類線程數(shù)量的統(tǒng)計，并且每5分鐘記錄一次線程的方法棧并聚合，可真實還原代碼執(zhí)行過程。如果我們發(fā)現(xiàn)導(dǎo)致慢調(diào)用的關(guān)鍵應(yīng)用存在CPU占用率高的問題，可以通過線程分析功能找到消耗CPU最多的線程。選中某一異常線程后，能夠通過右側(cè)的CPU耗時和線程數(shù)曲線圖分析CPU耗時與線程數(shù)變化。此外，還可以單擊異常線程的方法棧，查看指定時間內(nèi)的此線程的方法執(zhí)行情況，例如查看處于BLOCKED狀態(tài)的線程對應(yīng)的方法，從而優(yōu)化指定代碼段，以便降低CPU使用率。
JVM監(jiān)控可以直觀展示指定時間段內(nèi)的多項內(nèi)存指標，雖然圖表能體現(xiàn)出內(nèi)存使用量過大的情況，但無法顯示具體信息，因此如果需要進一步排查問題產(chǎn)生的原因，可以創(chuàng)建內(nèi)存快照，通過詳細的日志查看內(nèi)存占用的詳細信息，方便排查內(nèi)存泄漏和內(nèi)存浪費等內(nèi)存問題。點擊JVM監(jiān)控頁面的創(chuàng)建內(nèi)存快照按鈕，可以讓ARMS在線為應(yīng)用生成內(nèi)存快照，并通過控制臺在線對內(nèi)存快照進行分析，從而避免將大體積快照文件回傳到開發(fā)者的本地環(huán)境進行分析。如果我們發(fā)現(xiàn)在慢調(diào)用比較嚴重的時間點，GC頻繁或者出現(xiàn)了耗時長的FullGC，對于內(nèi)存快照的分析是必不可少的工作。
內(nèi)存快照創(chuàng)建后，點擊分析結(jié)果，就能夠進入內(nèi)存快照在線分析頁，這個頁面集成了MAT(Eclipse Memory Analyzer)內(nèi)存分析工具的所有功能，具體的用法和實踐可以參考MAT手冊。
核心實踐三：提前預(yù)知風(fēng)險
構(gòu)建一個健壯穩(wěn)定的微服務(wù)體系，不能總是等著有問題和故障暴露出來之后，再進行排查和優(yōu)化，只有建立一個可以提前預(yù)知風(fēng)險機制，才能幫助我們盡可能的避免問題發(fā)生。報警機制是實現(xiàn)風(fēng)險提前預(yù)知的核心，ARMS可以制定針對特定監(jiān)控對象的報警規(guī)則，當規(guī)則被觸發(fā)時，會通過預(yù)先指定的報警方式向報警聯(lián)系人分組發(fā)送報警信息，以提醒用戶采取必要的問題解決措施。
創(chuàng)建聯(lián)系人
報警規(guī)則被觸發(fā)時會向指定的聯(lián)系人分組發(fā)送通知，而在創(chuàng)建聯(lián)系人分組之前必須先創(chuàng)建聯(lián)系人。所以在創(chuàng)建報警規(guī)則前，我們需要預(yù)先確定報警的接收者，配置好聯(lián)系人和聯(lián)系人分組。
我可以在報警管理 > 聯(lián)系人管理頁面創(chuàng)建聯(lián)系人，指定聯(lián)系人用于接收通知的手機號碼和郵箱地址，也可以提供用于自動發(fā)送報警通知的釘釘機器人地址。
創(chuàng)建報警
在ARMS控制臺可以制定針對特定監(jiān)控對象的報警，當報警規(guī)則被觸發(fā)時，系統(tǒng)會以指定的報警方式向報警聯(lián)系人分組發(fā)送報警信息，以提醒用戶采取必要的問題解決措施。
報警覆蓋了JVM監(jiān)控、異常接口監(jiān)控、調(diào)用類型統(tǒng)計、主機監(jiān)控、數(shù)據(jù)庫指標等多種類型，每一種類型都預(yù)定義了一系列的可選規(guī)則，允許使用者在一個報警中添加一條或多條規(guī)則。每一條規(guī)則都包含一條時間參數(shù)，代表報警基于最近多少分鐘之內(nèi)的統(tǒng)計結(jié)果，而多條規(guī)則之間可以是“與“或者”或“的關(guān)系。
以數(shù)據(jù)庫指標這種類型為例，我們可以定義一條這樣的規(guī)則：”最近60分鐘之內(nèi)，如果應(yīng)用的多個實例在訪問數(shù)據(jù)庫的時候，平均響應(yīng)時間大于2000毫秒，便觸發(fā)系統(tǒng)報警”。
為新上線的應(yīng)用自動創(chuàng)建報警
我們還可以定義多條報警模板，批量創(chuàng)建報警，提高配置報警規(guī)則的效率，具體的操作和創(chuàng)建報警類似。
ARMS已經(jīng)為我們默認定義了5條報警模板，以方便我們使用，在默認情況下，每一個新接入ARMS的應(yīng)用都會被自動追加如下5條報警：
1、數(shù)據(jù)庫異常報警模板：數(shù)據(jù)庫響應(yīng)時間長或數(shù)據(jù)庫調(diào)用出錯場景的報警
2、異常調(diào)用報警模板：存在超時調(diào)用或錯誤調(diào)用場景的報警
3、主機監(jiān)控報警模板：CPU 水位過高或磁盤空間不足場景的報警
4、進程異常報警模板：進程存活場景的報警
5、GC異常報警模板：有過多的 FullGC、FullGC 耗時長或 YoungGC 耗時長場景的報警
這5條默認的報警模板很有用，代表著ARMS對于最通用的一些報警場景的抽象，我們保留這幾個模板，只在細節(jié)方面做出少許調(diào)整，用最少的配置提升風(fēng)險預(yù)知的能力。
構(gòu)建多語言全鏈路監(jiān)控體系
除了Java語言外，ARMS還提供了PHP探針，PHP應(yīng)用接入ARMS后，能夠擁有和Java應(yīng)用同樣的全鏈路監(jiān)控體驗。除了Java和PHP之外 ，ARMS還對主流的編程語言提供了支持，我們可以選擇開源的探針/SDK接入ARMS。受益于統(tǒng)一的全鏈路監(jiān)控模型，如果一個微服務(wù)體系中存在多種語言之間的相互調(diào)用，只要把對應(yīng)的應(yīng)用都接入ARMS，就能夠跨越多語言對調(diào)用鏈路進行統(tǒng)一的管理和分析。
當然，開源探針/SDK在功能方面和ARMS探針還存在不小的差距，ARMS針對更多語言的探針正在陸續(xù)發(fā)布中，希望能夠盡快覆蓋所有的主流編程語言。目前階段，我們可以參考以下表格，選擇最合適的接入方式。
總結(jié)
受限制于篇幅的原因，本文只能介紹全鏈路監(jiān)控最核心的一些實踐，作為全鏈路監(jiān)控以及應(yīng)用性能管理領(lǐng)域的標桿產(chǎn)品，ARMS還有更多的功能特性等待著我們?nèi)ネ诰?#xff0c;我們可以對照幫助文檔逐步學(xué)習(xí)。好的產(chǎn)品總是能給予用戶最輕松的使用體驗，并在實際生產(chǎn)中發(fā)揮出巨大的業(yè)務(wù)價值。我們不妨從現(xiàn)在開始，就將所有微服務(wù)應(yīng)用通過無侵入的方式接入ARMS，構(gòu)建一體化的全鏈路監(jiān)控體系，而不是等到真正遇到生產(chǎn)故障的那一天，為了定位問題而費盡周折。
# 加入客戶交流釘釘群
阿里云專門成立了“互聯(lián)網(wǎng)架構(gòu)升級實戰(zhàn)課”釘釘群，每周邀請一位阿里云專家在群內(nèi)進行行業(yè)最佳實踐直播，每天分享行業(yè)前沿干貨，歡迎掃碼或釘釘搜索群號加入：35712134。
*更多客戶案例，實戰(zhàn)經(jīng)驗，請點擊了解：
https://www.aliyun.com/activity/daily/commercial
原文鏈接：https://developer.aliyun.com/article/778727?
版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。總結(jié)
- 上一篇： PG奥斯卡！云数据库专属集群MyBase
- 下一篇： 阿里云 Serverless 事件总线