建設一體化性能監(jiān)控平臺

隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展，企業(yè)的業(yè)務規(guī)模和復雜度也在不斷增加。為了保證業(yè)務的穩(wěn)定性和可靠性，企業(yè)需要對其系統(tǒng)進行全面的性能監(jiān)控。而一體化性能監(jiān)控就是一種集成了多種監(jiān)控工具和技術(shù)的綜合性監(jiān)控方案，可以幫助企業(yè)更加全面、高效地監(jiān)控其系統(tǒng)的性能。

1. 提高監(jiān)控效率：傳統(tǒng)的性能監(jiān)控方案往往需要使用多個不同的監(jiān)控工具，例如網(wǎng)絡監(jiān)控、服務器監(jiān)控、數(shù)據(jù)庫監(jiān)控等。這些工具往往需要單獨配置和管理，而且監(jiān)控數(shù)據(jù)也分散在不同的系統(tǒng)中，導致監(jiān)控效率低下。而一體化性能監(jiān)控則可以將多個監(jiān)控工具集成在一起，通過一個統(tǒng)一的監(jiān)控平臺進行管理和監(jiān)控。這樣可以大大提高監(jiān)控效率，減少監(jiān)控人員的工作量，同時也可以更加全面地監(jiān)控系統(tǒng)的性能。

2. 提高監(jiān)控精度：傳統(tǒng)的性能監(jiān)控方案往往只能監(jiān)控系統(tǒng)的基本指標，例如CPU使用率、內(nèi)存利用率等。而一體化性能監(jiān)控則可以通過集成多種監(jiān)控工具和技術(shù)，監(jiān)控系統(tǒng)的各個方面，例如網(wǎng)絡流量、磁盤IO、數(shù)據(jù)庫響應時間等。這樣可以更加全面地了解系統(tǒng)的性能狀況，及時發(fā)現(xiàn)和解決問題，提高監(jiān)控精度。

3. 提高故障排查效率：當系統(tǒng)或應用出現(xiàn)故障時，傳統(tǒng)的性能監(jiān)控方案通常需要IT運維人員手動分析監(jiān)控數(shù)據(jù)來確定故障原因，這樣會浪費大量的時間和精力。而一體化性能監(jiān)控能夠?qū)Χ喾N關(guān)聯(lián)的監(jiān)控數(shù)據(jù)進行自動分析和處理，幫助IT運維人員快速定位故障原因，從而提高故障排查效率。

4. 提高監(jiān)控可視化程度：一體化性能監(jiān)控可以通過統(tǒng)一可視化界面，綜合展示不同類型的性能監(jiān)控數(shù)據(jù)，使監(jiān)控數(shù)據(jù)更加直觀、易于理解，幫助監(jiān)控人員更快地發(fā)現(xiàn)和解決問題。同時，一體化性能監(jiān)控還可以通過報警機制，及時通知監(jiān)控人員發(fā)現(xiàn)問題，提高監(jiān)控的實時性和響應速度。

因此，一體化性能監(jiān)控是當今企業(yè)信息化建設中不可或缺的一部分。通過將多個性能監(jiān)控工具整合在一起，形成一個統(tǒng)一的監(jiān)控平臺，可以提高監(jiān)控效率、監(jiān)控精度、故障排查效率和可視化程度，從而幫助企業(yè)更好地了解其業(yè)務系統(tǒng)的運行情況，提高業(yè)務系統(tǒng)的穩(wěn)定性和可靠性。

建設一體化性能監(jiān)控平臺步驟

一體化性能監(jiān)控平臺是指將多個性能監(jiān)控工具整合在一起，形成一個統(tǒng)一的平臺，以便更好地監(jiān)控和管理系統(tǒng)的性能。建設一體化性能監(jiān)控平臺通常需要以下步驟：

1. 確定監(jiān)控需求：首先需要明確監(jiān)控的目標和需求，包括監(jiān)控的對象、監(jiān)控的指標、監(jiān)控的頻率等。這些需求將決定后續(xù)的監(jiān)控工具的選擇和配置。性能監(jiān)控的常見對象包括請求耗時、緩存命中率、FullGC 次數(shù)、數(shù)據(jù)庫連接數(shù)、CPU 使用率等等。幾乎覆蓋了全棧IT設施，比如用戶終端、網(wǎng)關(guān)、微服務應用、數(shù)據(jù)庫、容器或物理機等。

2. 選擇監(jiān)控工具：根據(jù)監(jiān)控需求，選擇適合的監(jiān)控工具。常見的監(jiān)控工具包括Zabbix、Nagios、Grafana等。這些工具可以監(jiān)控服務器、網(wǎng)絡、數(shù)據(jù)庫、應用程序等各個方面的性能指標。

3. 配置監(jiān)控工具：根據(jù)監(jiān)控需求，對所選的監(jiān)控工具進行配置。這包括添加監(jiān)控對象、設置監(jiān)控指標、調(diào)整監(jiān)控頻率等。同時，還需要設置告警規(guī)則，以便在系統(tǒng)出現(xiàn)異常時及時通知管理員。

4. 整合監(jiān)控工具：將多個監(jiān)控工具整合在一起，形成一個統(tǒng)一的監(jiān)控平臺。這可以通過使用開源的監(jiān)控集成工具，如Prometheus、Grafana等來實現(xiàn)。這些工具可以將不同的監(jiān)控數(shù)據(jù)整合在一起，形成一個統(tǒng)一的監(jiān)控視圖。

5. 數(shù)據(jù)可視化：將監(jiān)控數(shù)據(jù)可視化，以便管理員更直觀地了解系統(tǒng)的性能狀況。這可以通過使用Grafana等工具來實現(xiàn)。Grafana可以將監(jiān)控數(shù)據(jù)以圖表、儀表盤等形式展示出來，方便管理員進行分析和決策。

6. 自動化運維：將監(jiān)控平臺與自動化運維工具結(jié)合起來，實現(xiàn)自動化運維。這可以通過使用Ansible、SaltStack等工具來實現(xiàn)。這些工具可以根據(jù)監(jiān)控數(shù)據(jù)自動化地進行故障排除、性能優(yōu)化等操作，提高系統(tǒng)的穩(wěn)定性和性能。

建設一體化性能監(jiān)控平臺需要根據(jù)監(jiān)控需求選擇合適的監(jiān)控工具，進行配置和整合，實現(xiàn)數(shù)據(jù)可視化和自動化運維，以提高系統(tǒng)的穩(wěn)定性和性能。從 0 到 1 自建一套一體化性能監(jiān)控平臺，需要投入巨大的人力研發(fā)、運維和試錯成本。阿里云可觀測團隊面向海量用戶場景，通過多年的自研技術(shù)沉淀，探索出了一套符合開源標準、穩(wěn)定可靠、易擴展的一體化性能監(jiān)控最佳實踐。通過應用實時監(jiān)控服務 ARMS（Application Real-Time Monitoring Service）構(gòu)建的第四代可觀測產(chǎn)品，以應用為中心，向上連接用戶體驗，向下連接基礎(chǔ)設施與云服務，一站式滿足企業(yè)在業(yè)務連續(xù)性、架構(gòu)穩(wěn)定性乃至業(yè)務增長等核心訴求。

實現(xiàn)端到端全鏈路追蹤

鏈路追蹤的價值在于“關(guān)聯(lián)”，終端用戶、后端應用、云端組件（數(shù)據(jù)庫、消息等）共同構(gòu)成了鏈路追蹤的軌跡拓撲大圖。這張拓撲覆蓋的范圍越廣，鏈路追蹤能夠發(fā)揮的價值就越大。而全鏈路追蹤就是覆蓋全部關(guān)聯(lián) IT 系統(tǒng)，能夠完整記錄用戶行為在系統(tǒng)間調(diào)用路徑與狀態(tài)的最佳實踐方案。

完整的全鏈路追蹤可以為業(yè)務帶來三大核心價值：端到端問題診斷，系統(tǒng)間依賴梳理，自定義標記透傳。

• 端到端問題診斷：VIP 客戶下單失敗，內(nèi)測用戶請求超時，許多終端用戶的體驗問題，追根溯源就是由于后端應用或云端組件異常導致的。而全鏈路追蹤是解決端到端問題的首選方案。

• 系統(tǒng)間依賴梳理：新業(yè)務上線，老業(yè)務裁撤，機房搬遷/架構(gòu)升級，IT 系統(tǒng)間的依賴關(guān)系錯綜復雜，已經(jīng)超出了人工梳理的能力范疇，基于全鏈路追蹤的拓撲發(fā)現(xiàn)，使得上述場景決策更加敏捷、可信。

• 自定義標記透傳：全鏈路壓測，用戶級灰度，訂單追溯，流量隔離。基于自定義標記的分級處理&數(shù)據(jù)關(guān)聯(lián)，已經(jīng)衍生出了一個繁榮的全鏈路生態(tài)。然而，一旦發(fā)生數(shù)據(jù)斷鏈、標記丟失，也將引發(fā)不可預知的邏輯災難。

全鏈路追蹤的挑戰(zhàn)

全鏈路追蹤的價值與覆蓋的范圍成正比，它的挑戰(zhàn)也同樣如此。為了最大程度地確保鏈路完整性，無論是前端應用還是云端組件，無論是 Java 語言還是 Go 語言，無論是公有云還是自建機房，都需要遵循同一套鏈路規(guī)范，并實現(xiàn)數(shù)據(jù)互聯(lián)互通。多語言協(xié)議棧統(tǒng)一、前/后/云（多）端聯(lián)動、跨云數(shù)據(jù)融合是實現(xiàn)全鏈路追蹤的三大挑戰(zhàn)，如下圖所示。

多語言協(xié)議棧統(tǒng)一

在云原生時代，多語言應用架構(gòu)越來越普遍，利用不同語言特性實現(xiàn)最佳的性能和研發(fā)體驗，已經(jīng)成為一種趨勢。但是，不同語言的成熟度差異，使得全鏈路追蹤無法做到完全的能力一致。目前業(yè)界的主流做法是，先保證遠程調(diào)用協(xié)議層格式統(tǒng)一，多語言應用內(nèi)部自行實現(xiàn)調(diào)用攔截與上下文透傳，這樣可以確保基礎(chǔ)的鏈路數(shù)據(jù)完整。

但是，絕大部分線上問題無法僅通過鏈路追蹤的基礎(chǔ)能力就能夠有效定位并解決，線上系統(tǒng)的復雜性決定了一款優(yōu)秀的 Trace 產(chǎn)品必須提供更加全面、有效的數(shù)據(jù)診斷能力，比如代碼級診斷、內(nèi)存分析、線程池分析、無損統(tǒng)計等等。充分利用不同語言提供的診斷接口，最大化的釋放多語言產(chǎn)品能力是 Trace 能夠不斷向前發(fā)展的基礎(chǔ)。

• 透傳協(xié)議標準化：全鏈路所有應用需要遵循同一套協(xié)議透傳標準，保證鏈路上下文在不同語言應用間能夠完整透傳，不會出現(xiàn)斷鏈或上下文缺失的問題。目前主流的開源透傳協(xié)議包括 W3C、Jaeger、B3、SkyWalking等。

• 最大化釋放多語言產(chǎn)品能力：鏈路追蹤除了最基礎(chǔ)的調(diào)用鏈功能外，逐步衍生出了應用/服務監(jiān)控，方法棧追蹤，性能剖析等高階能力。但是不同語言的成熟度導致產(chǎn)品能力差異較大，比如 Java 探針可以基于 JVMTI 實現(xiàn)很多高階的邊緣側(cè)診斷。優(yōu)秀的全鏈路追蹤方案會最大化的釋放每種語言的差異化技術(shù)紅利，而不是一味的追求趨同平庸。

前后云（多）端聯(lián)動

目前開源的鏈路追蹤實現(xiàn)主要集中于后端業(yè)務應用層，在用戶終端和云端組件（如云數(shù)據(jù)庫）側(cè)缺乏有效的埋點手段。主要原因是后兩者通常由云服務商或三方廠商提供服務，依賴于廠商對于開源的兼容適配性是否友好。而業(yè)務方很難直接介入開發(fā)。

上述情況的直接影響是前端頁面響應慢，很難直接定位到后端哪個應用或服務導致的，無法明確給出確定性的根因。同理，云端組件的異常也難以直接與業(yè)務應用異常劃等號，特別是多個應用共享同一個數(shù)據(jù)庫實例等場景下，需要更加迂回的手段進行驗證，排查效率十分低下。

為了解決此類問題，首先需要云服務商更好的支持開源鏈路標準，添加核心方法埋點，并支持開源協(xié)議棧透傳與數(shù)據(jù)回流（如應用實時監(jiān)控服務的前端監(jiān)控能力支持 Jaeger 協(xié)議透傳與方法棧追蹤）。

其次，由于不同系統(tǒng)的業(yè)務歸屬等問題，無法完成全鏈路協(xié)議棧統(tǒng)一，為了實現(xiàn)多端聯(lián)動，需要由 Trace 系統(tǒng)提供異構(gòu)協(xié)議棧的打通方案。

為了實現(xiàn)異構(gòu)協(xié)議棧的打通，Trace 系統(tǒng)需要支持兩項能力：

1. 協(xié)議棧轉(zhuǎn)換與動態(tài)配置，比如前端向下透傳了 Jaeger 協(xié)議，新接入的下游外部系統(tǒng)使用的則是 ZipKin B3 協(xié)議。在兩者之間的 Node.js 應用可以接收 Jaeger 協(xié)議并向下透傳 B3 協(xié)議，保證全鏈路標記透傳完整性。

2. 服務端數(shù)據(jù)格式轉(zhuǎn)換，可以將上報的不同數(shù)據(jù)格式轉(zhuǎn)換成統(tǒng)一格式進行存儲，或者在查詢側(cè)進行兼容。前者維護成本相對較小，后者兼容性成本更高，但相對更靈活。

跨云數(shù)據(jù)融合

很多大型企業(yè)，出于穩(wěn)定性或數(shù)據(jù)安全等因素考慮，選擇了多云部署，這種部署架構(gòu)下，由于不同環(huán)境的網(wǎng)絡隔離，以及基礎(chǔ)設施的差異性，為運維人員帶來了巨大的挑戰(zhàn)。

由于云環(huán)境間僅能通過公網(wǎng)通信，為了實現(xiàn)多云部署架構(gòu)下的鏈路完整性，可以采用鏈路數(shù)據(jù)跨云上報、跨云查詢等方式。無論哪種方式，目標都是實現(xiàn)多云數(shù)據(jù)統(tǒng)一可見，通過完整鏈路數(shù)據(jù)快速定位或分析問題。

跨云上報

鏈路數(shù)據(jù)跨云上報的實現(xiàn)難度相對較低，便于維護管理，是目前云廠商采用的主流做法，比如應用實時監(jiān)控服務就是通過跨云數(shù)據(jù)上報實現(xiàn)的多云數(shù)據(jù)融合。

跨云上報的優(yōu)點是部署成本低，一套服務端便于維護；缺點是跨云傳輸會占用公網(wǎng)帶寬，公網(wǎng)流量費用和穩(wěn)定性是重要限制條件。跨云上報比較適合一主多從架構(gòu)，絕大部分節(jié)點部署在一個云環(huán)境內(nèi)，其他云/自建機房僅占少量業(yè)務流量，比如某企業(yè) toC 業(yè)務部署在阿里云，企業(yè)內(nèi)部應用部署在自建機房，就比較適合跨云上報的方式，如下圖所示。

跨云查詢

跨云查詢是指原始鏈路數(shù)據(jù)保存在當前云網(wǎng)絡內(nèi)，將一次用戶查詢分別下發(fā)，再將查詢結(jié)果聚合進行統(tǒng)一處理，減少公網(wǎng)傳輸成本。

跨云查詢的優(yōu)點就是跨網(wǎng)傳輸數(shù)據(jù)量小，特別是鏈路數(shù)據(jù)的實際查詢量通常不到原始數(shù)據(jù)量的萬分之一，可以極大地節(jié)省公網(wǎng)帶寬。缺點是需要部署多個數(shù)據(jù)處理終端，不支持分位數(shù)、全局 TopN 等復雜計算。比較適合多主架構(gòu)，簡單的鏈路拼接、max/min/avg 統(tǒng)計都可以支持。

跨云查詢實現(xiàn)有兩種模式，一種是在云網(wǎng)絡內(nèi)部搭建一套集中式的數(shù)據(jù)處理終端，并通過內(nèi)網(wǎng)專線打通用戶網(wǎng)絡，可以同時處理多個用戶的數(shù)據(jù)；另一種是為每個用戶單獨搭建一套 VPC 內(nèi)的數(shù)據(jù)處理終端。前者維護成本低，容量彈性更大；后者數(shù)據(jù)隔離性更好。

其他方式

除了上述兩種方案，在實際應用中還可以采用混合模式或僅透傳模式。

混合模式是指將統(tǒng)計數(shù)據(jù)通過公網(wǎng)統(tǒng)一上報，進行集中處理（數(shù)據(jù)量小，精度要求高），而鏈路數(shù)據(jù)采用跨云查詢方式進行檢索（數(shù)據(jù)量大，查詢頻率低）。

僅透傳模式是指每個云環(huán)境之間僅保證鏈路上下文能夠完整透傳，鏈路數(shù)據(jù)的存儲與查詢獨立實現(xiàn)。這種模式的好處就是實現(xiàn)成本極低，每朵云之間僅需要遵循同一套透傳協(xié)議，具體的實現(xiàn)方案可以完全獨立。通過同一個 TraceId 或應用名進行人工串聯(lián)，比較適合存量系統(tǒng)的快速融合，改造成本最小。

阿里云全鏈路追蹤最佳實踐

阿里云環(huán)境下，可以基于可觀測鏈路 OpenTelemetry 版，從 0 到 1 快速構(gòu)建一套貫穿前端、網(wǎng)關(guān)、服務端、容器和云組件的全鏈路追蹤體系。

• Header 透傳格式：全鏈路統(tǒng)一采用一種透傳協(xié)議，可以是 W3C TraceContext、B3 或 Jaeger 等格式。

• 前端接入：可以采用 CDN（Script 注入）或 NPM 兩種低代碼接入方式，支持 Web/H5、小程序等場景。

• 后端接入：

  • Java 應用推薦優(yōu)先使用 ARMS Agent，無侵入式埋點無需代碼改造，支持邊緣診斷、無損統(tǒng)計、精準采樣等高階功能。用戶自定義方法可以通過 OpenTelemetry SDK 主動埋點。

  • 非 Java 應用推薦接入可觀測鏈路 OpenTelemetry 版，將數(shù)據(jù)上報至對應接入點，實現(xiàn)多語言應用間的鏈路透傳與展示。

全鏈路追蹤僅僅只是開始，遠遠不是結(jié)束。基于全鏈路追蹤生態(tài)，關(guān)聯(lián)更多的指標、日志、事件、Profiling 等數(shù)據(jù)或工具，提升問題診斷或業(yè)務分析效率，才能更好的發(fā)揮全鏈路追蹤的價值。

結(jié)合阿里云用戶實踐，一個典型的鏈路篩選與診斷過程，主要分為以下幾步：

1. 根據(jù) TraceId、應用名、接口名、耗時、狀態(tài)碼、自定義標簽等任意條件組合過濾出目標調(diào)用鏈。

2. 從滿足過濾條件的調(diào)用鏈列表中選中一條鏈路查詢詳情。

3. 結(jié)合請求調(diào)用軌跡，本地方法棧，主動/自動關(guān)聯(lián)數(shù)據(jù)（如SQL、業(yè)務日志）綜合分析調(diào)用鏈。

4. 如果上述信息仍無法定位根因，需要結(jié)合內(nèi)存快照、Arthas 在線診斷等工具進行二次分析。