本文作者：碧海（蔣星韜）

雲音樂服務監控系統（代號：Pylon APM）為業務提供服務監控，鏈路追蹤，治理分析，問題診斷等能力，本文介紹了平台建設中的一些實踐經驗。

一、背景介紹

雲音樂服務端原有的服務端應用監控體系，存在很多痛點和問題，導致出現線上問題時，定位的效率不太理想。服務端應用監控體系主要存在以下幾個問題：

• Trace鏈路完整性問題：老的trace是通過組件sdk埋點的形式，進行trace的記錄與輸出，導致了trace的完整性依賴埋點邏輯，如果鏈路埋點處理不正確，會出現上下文異步透傳丟失，trace數據衝突混亂的問題。同時，對於異常的非採樣鏈路，在採集時，無法回溯上游來源，經常出現定位信息不足的問題。
• Trace與Metric割裂問題：trace與metric之間缺少數據關聯，metric服務監控數據依賴其他平台，導致慢請求，慢sql之類的問題場景定位時，找不到具體發生問題的trace。線上發生異常錯誤指標報警時，很難找到對應的錯誤鏈路，定位問題效率低下。
• Trace與日誌聯動問題：業務服務產生ERROR日誌時，有追溯異常調用的來源的需求。低採樣率的線上場景，只能找到日誌，而找不到請求的具體鏈路，對問題排查幫助很小。
• 版本升級迭代困難：版本升級依賴業務服務升級sdk，推進困難，功能迭代效率低。

開源項目中Pinpoint和SkyWalking都是目前比較成熟的鏈路追蹤方案，兩者各有優劣，在對比中，我們發現Pinpoint與雲音樂的鏈路模型更加接近，插件開發也更加友好，並且國內有多個基於Pinpoint的商業化落地項目落地，穩定性有保障。

最終我們選擇基於Pinpoint開源方案，進行了深度的自研改造和優化，希望達成以下目標：

• 業務服務解耦：Java Agent形式實現應用監控功能，與服務代碼完全解耦，業務無感知接入，無感知升級。插件化實現，能夠在管控平台通過開關動態控制細粒度功能的開關。
• 保證鏈路完整性：通過異步上下文管理無感知解決了鏈路異步透傳的問題，保證trace透傳的完整性。同時通過TailBased方案，實現了異常錯誤鏈路完整採樣的能力，最大限度的保證鏈路問題定位有效性。
• 集成Metric能力：通過集成prometheus組件，實現了應用服務監控的能力，開發相比哨兵監控項更加簡單。同時實現了Metric監控聯通Trace的能力，對於指定監控指標，能夠根據監控值檢索對應Trace。
• 問題快速診斷：不論是異常日誌，還是錯誤、長耗時調用，都能通過元數據或監控數據關聯到完整的鏈路，在平台快速下鑽，提升問題定位效率。
• 問題診斷工具：提供自動異常現場採集能力，集成白屏化診斷工具，完善問題分析能力。

二、項目思路與方案

2.1 項目整體架構

主要分為Agent和Console兩個部分，Agent主要負責Trace生成與傳遞，Metric記錄與上報，實現了一套字節碼注入工具，以及數據處理框架，再通過插件化的形式，實現不同組件的trace與metric能力。Console主要負責數據的收集與存儲，分析與展示，將Trace，metric，log聯動的數據模型，通過鏈路問題定位能力串聯起來，實現快速的問題診斷。

2.2 基於Pinpoint開發的Java Agent

開源的Pinpoint實現了插件化的Trace能力，並且實現了很多常用的中間件的插件，但是開源Pinpoint Agent依舊存在以下問題：

• Trace模型過於簡單，對於部分Trace使用場景無法很好支持（比如消息隊列多個消費者的場景，消費者之間無法區分），支持的鏈路類型有限，元數據管理不方便。
• 上下文透傳能力支持不足，Trace上下文因為支持透傳，很多時候業務上下文，可以複用這部分能力，不需要重複開發，Pinpoint這塊支持不足。
• 異常鏈路回溯採樣不完整，對於非採樣鏈路，出現異常時，無法回溯採集上游，定位效率會大打折扣。
• 不支持Metric能力，無法關聯監控數據，浪費了切面中的數據與狀態結果。

2.2.1 擴展Trace數據模型

基於Pinpoint Trace-Span-SpanEvent的模型，擴展了部分關聯字段和透傳字段，使得Trace能夠支持多下游關聯，異步下游關聯，異步回調關聯等能力。在上下文透傳上，支持進程內字段透傳，跨進程字段透傳，跨進程字段反向透傳，並提供專門的透傳sdk供接入方使用。

2.2.2 異常鏈路後置採樣

鏈路上發生單點異常時，如果只是把異常點及其下游鏈路採集上來是比較容易的，但是這樣帶來的問題定位收益並不高，很多時候不知道上游來源的話，問題定位無法繼續下去。為了解決異常鏈路完整採樣的問題，我們實現了一套TailBased的異常鏈路採集能力。具體方案示意如下圖：

每個服務節點上，對於短時間內的Trace，會先全量輸出到一個全量日誌中，當鏈路上發生異常時，對應服務的Agent會將異常TraceId寫入到中心化緩存中，並在Trace上下文信息中帶上標記。獨立的Tail線程會以一個穩定的延遲（30s~1min），掃描全量日誌中的trace數據，發現存在於緩存中的異常TraceId後，將該TraceId關聯的鏈路數據寫入到最終的採集日誌中，實現完整的鏈路採集。

2.2.3 Prometheus監控集成

我們在Agent端集成Prometheus sdk，用以記錄和輸出監控數據，服務端通過Pull請求定時拉取每台服務上的監控數據，進行數據的預聚合，最終寫入到vm storage存儲中。監控數據在記錄過程中，還會與當前TraceId進行關聯，輸出到關聯日誌中，保證每項監控數據，都有一定的Trace鏈路數據進行關聯定位與分析。關聯示意圖如下所示：

2.2.4 自動Jstack採集

線上服務在發生問題時，經常要面對抓不到現場的情況。我們對於有可能出現服務阻塞的場景，啓動了異步監聽任務。當調用方法執行時間超出設定閾值時，對當前線程執行一次Jstack堆棧採集，將當前的執行現場保存下來，同時關聯TraceId和方法監控指標，便於追溯。流程示意圖如下：

2.3 APM產品設計

開源的Pinpoint自帶了pinpoint-web管控界面並不能滿足我們的需求，我們重新開發了一套APM平台，以應用為中心視角，劃分不同維度的監控指標，再到不同監控視角下，通過Trace，Metric，Log聯動，來幫助快速定位線上問題，APM平台主要具備以下幾個能力。

2.3.1 鏈路詳情診斷

完整的展示從請求入口到下游所有節點的調用拓撲關係，以及請求耗時分佈信息，是鏈路詳情的基本功能。為了定位關鍵透傳字段丟失的情況，驗證鏈路上下文正確與否，平台鏈路詳情中還包含透傳字段以及部分請求參數，使用者可以選擇全局視角或進程視角查看調用棧，狀態參數幫助快速定位到異常節點。

在鏈路詳情頁可以查看關聯的日誌信息，實現與日誌聯動定位問題。

單個調用接口的詳情頁中，除了進程內調用棧，還有監控信息聯動。

2.3.2 應用監控圖表

平台以應用視角為中心，利用Agent集成的監控數據採集，構建了監控圖表大盤，通過不同的元數據分類，平台支持HTTP，RPC，消息，數據庫，緩存等各個獨立視角的監控數據，以大盤曲線結合表格下鑽的形式展現。

大盤圖表在Grafana基礎上，做了二次開發，支持同環比分析，多實例比較等實用的數據分析功能。

2.3.3 異常錯誤長耗時關聯分析

為了解決目前查找異常監控點相關鏈路時，找不到可用鏈路，導致問題定位進展困難的問題。我們平台打通了監控數據與關聯的TraceId，讓使用方能夠快速的找到關聯鏈路，推進問題定位。平台提供了監控大盤圖表，以及相關的下鑽鏈路檢索，用户可以在界面上定向檢索關聯的異常鏈路TraceId，每個TraceId下鑽後，會到達詳細的Trace詳情頁。

2.3.4 耗時請求Jstack追蹤

觸發了自動Jstack採集的方法，在平台上會給出提示文案。每個具體的Jstack採集結果，有詳細的堆棧信息，關聯的Trace上下文信息以及線程池信息。除開自動Jstack採集，平台還支持主動下發Jstack請求，主動抓取現場。

2.3.5 Arthas在線診斷

平台還集成了Jstack，Arthas等使用頻率較高的定位工具。通過Agent連接，用户可以在平台上使用工具直接對服務進行信息採集。採集結果被收集後，平台提供更友好的展示和進一步分析的能力。

三、項目總結

在項目的開發學習過程中，我們積累沉澱了一些線上問題定位的方法論，總結了很多針對服務端問題定位的流程與工具。我們希望能夠將這部分經驗通過產品的形式呈現出來，來幫助面對問題無從下手的同學，通過路徑引導快速得到問題信息。對於有一定問題定位經驗同學，提供更加易用，更加高效定位工具，打通定位流程上的各個環節。最終達到快速定位發現線上問題，快速止血的目標。

當然，線上服務治理不是光靠單一平台就能完全覆蓋的，Pylon大平台下還提供了業務日誌，監控分析，告警治理，場景事件等多個子平台，來幫助我們更好的進行線上服務治理。我們會在後續的文章中，逐一介紹這些平台的建設實踐。

本文發佈自網易雲音樂技術團隊，文章未經授權禁止任何形式的轉載。我們常年招收各類技術崗位，如果你準備換工作，又恰好喜歡雲音樂，那就加入我們
grp.music-fe(at)corp.netease.com！