全部產品
Search
文件中心

Application Real-Time Monitoring Service:依賴服務

更新時間:Jun 06, 2025

為應用安裝探針後,ARMS即可開始監控應用,您可以在依賴服務頁面瞭解應用依賴服務的詳情,包括外部調用、資料庫調用和訊息佇列的詳細資料。

前提條件

重要

ARMS應用監控面向已開通新版計費的使用者提供全新的監控詳情頁面,新版計費詳情,請參見產品計費(新版)

對於未開通新版計費的使用者,如需查看新版監控詳情頁面,可在應用列表頁面單擊切換新版

已為應用安裝探針,具體操作,請參見應用監控接入概述

查看應用依賴服務

  1. 登入ARMS控制台,在左側導覽列選擇應用監控 > 應用列表

  2. 應用列表頁面頂部選擇目標地區,然後單擊目標應用程式名稱。

    說明

    語言列的表徵圖含義如下:

    Java表徵圖:接入應用監控的Java應用。

    image:接入應用監控的Golang應用。

    image:接入應用監控的Python應用。

    -:接入Managed Service for OpenTelemetry的應用。

  3. 在上方導覽列單擊依賴服務

    image.png

    • 在快捷篩選區域(圖示①),您可以按請求類型介面名稱主機圖表、服務列表進行篩選過濾。

    • 在趨勢圖地區(圖示②),您可以查看應用在指定時間範圍內對依賴服務發起請求的總數、錯誤數和平均耗時的時序曲線。

      單擊image.png表徵圖,可以在彈出的對話方塊中查看該指標在某個時間段的統計情況或對比不同日期在同一時間段的統計情況,通過選擇image.png表徵圖可以切換柱狀圖、趨勢圖進行展示。

    • 在服務列表地區(圖示③),您可以查看請求的目標、類型、RED三指標(請求數、錯誤數、平均耗時)等資訊。

      在服務列表,您可以執行以下操作:

      • 單擊請求目標或操作列的詳情、SQL分析異常分析,可以查看對應服務的詳細資料,更多資訊,請參見依賴服務詳情

      • 單擊操作列的調用鏈,可以查看該依賴服務調用的鏈路詳情。更多資訊,請參見調用鏈分析

支援的架構

依賴服務詳情

外部調用

概覽

概覽頁簽可以查看目標地址/服務的請求數、錯誤數、平均耗時的統計情況,以及慢調用的時序曲線。

image.png

調用鏈分析

調用鏈分析功能基於已儲存的全量鏈路詳細資料,通過自由組合篩選條件與彙總維度進行即時分析,可以滿足不同情境的自訂診斷需求。更多資訊,請參見調用鏈分析Span資料資訊

訊息發布

說明

Python應用暫不支援查看訊息發布。

概覽

概覽頁簽可以查看目標訊息的請求數、錯誤數、平均耗時的統計情況,以及慢調用的時序曲線。

image

發送統計

發送統計頁簽以訊息發送方視角,列出了Topic的發送情況,包括請求數、錯誤數、耗時。

image

調用鏈分析

調用鏈分析功能基於已儲存的全量鏈路詳細資料,通過自由組合篩選條件與彙總維度進行即時分析,可以滿足不同情境的自訂診斷需求。更多資訊,請參見調用鏈分析Span資料資訊

資料庫調用

說明

Python應用暫不支援查看資料庫調用。

概覽

概覽頁簽可以查看該應用調用目標資料庫執行個體的請求數、錯誤數和平均耗時的統計指標、時序指標與分布,以及慢調用次數分布。

image.png

SQL分析

SQL分析頁簽可以瞭解選中資料庫執行個體的請求趨勢(請求數、慢SQL次數與平均耗時),以及調用SQL層級的統計指標。藉助此頁簽,您可以找出是哪一個SQL造成服務響應過慢。

說明

返回大小指標目前僅支援MySQL 5.X版本,且應用監控探針版本需為2.7.1.3或以上。

單擊SQL右側的調用鏈可以查看SQL執行邏輯所在的完整代碼鏈路。更多資訊,請參見調用鏈分析

image.png

異常分析

異常分析頁簽可以查看該應用在指定時間範圍內調用目標資料庫時拋出該異常的次數,以及異常詳情。更多資訊,請參見異常分析

image.png

調用來源

調用來源頁簽可以查看該應用調用目標資料庫來源介面的回應時間、請求數和錯誤數的時序曲線。

image.png

調用鏈分析

調用鏈分析功能基於已儲存的全量鏈路詳細資料,通過自由組合篩選條件與彙總維度進行即時分析,可以滿足不同情境的自訂診斷需求。更多資訊,請參見調用鏈分析Span資料資訊

常見問題

資料庫相關

資料庫調用無資料

可能原因:

  • 資料庫不在ARMS支援的資料庫列表中,支援的資料庫請參見ARMS應用監控支援的Java組件和架構

  • 4.x之前版本的探針不支援通過非同步方式或者是通過無入口的方式調用的資料庫。

ARMS控制台看到資料庫有慢調用,但是資料庫服務端看不到慢調用

ARMS從用戶端視角出發進行監控,包括在應用內部發起請求,通過網路傳輸給服務端,在服務端處理完之後,將響應發回用戶端等一系列過程,因此ARMS統計到的資料庫指標會受到GC、網路傳輸的影響,數值會比服務端更大。此外,ARMS判斷是否有慢調用是按照自訂配置頁面配置的慢SQL閾值判斷,閾值預設值為500 ms,和服務端的配置不同。

image

ARMS控制台看到資料庫調用量和資料庫服務端監控看到的調用量不同

一個資料庫可能被多個應用訪問,ARMS控制台只能看到當前應用的訪問量,無法看到其他應用訪問資料庫的調用量。

部分外部調用未被記錄

在3.x探針中,可以原因如下:

  • 無入口外部調用。

    3.x探針預設只會採集HTTP介面、RPC介面、定時任務、消費訊息的處理流程中執行的外部調用。例如訪問DB、發送HTTP請求等。直接通過線程池定時執行的一些外部調用會被忽略採集。

  • 有入口的外部調用,但是在執行實際外部調用時進行了線程切換。

    因為3.x探針不支援非同步上下文自動傳遞,線程切換後沒有Trace上下文,這種情況也會忽略採集。

上述情況都可以通過升級探針至4.x解決。

外部調用有undefined資料

探針3.1.x及之前版本對於Dubbo埋點有缺陷,導致擷取對端IP地址時失敗,該問題已在3.2.x版本修複。

Redis調用記錄的key亂碼

Lettuce架構埋點問題導致key取值錯誤,使用者可忽略亂碼部分,其他部分是有效值。

SQL語句跳轉到調用鏈分析頁面無資料

問題原因:ARMS探針為了避免極端情境下大量資料上報的成本和效能開銷,預設開啟Span壓縮功能,當一個ParentSpan的多個子Span的SpanName相同時,只會記錄一個子Span,並在該子Span的Attributes中記錄相同子Span的數量、耗時總和、最大耗時以及最小耗時。出現這種情況會導致被壓縮Span的資訊丟失,同樣被壓縮Span中的SQL語句也無法直接在調用鏈分析頁面查詢。

image.png

解決方案:關閉調用鏈壓縮

說明

關閉後,當應用的一個介面大量訪問資料庫、Redis等組件操作時,會造成資料上報量上升,且ARMS的錯慢採樣邏輯會失效。

訊息發布相關

訊息訂閱/訊息發佈頁面的資料和 MQ 執行個體自監控面板資料有什麼區別?

訊息訂閱/訊息發佈頁面展示的內容為選定應用作為消費者/生產者時的各種效能指標,是用戶端視角的監控資料。MQ 執行個體的監控面板資料是 Topic 相關的效能指標,是服務端視角的監控資料。

訊息發送與接收對應的 SpanName 格式是什嗎?

訊息類型

4.x 之前版本探針

4.X 及之後版本探針

RocketMQ/Ons 訊息發送

不會建立 Span,僅記錄方法棧。

${topic} + publish

RocketMQ/Ons 訊息接收

Recv Topic@${topic}

Recv Topic@${topic}

Kafka 訊息發送

不會建立 Span,僅記錄方法棧。

${topic} + publish

Kafka 訊息接收

Kafka/topic=${topic}

Kafka/topic=${topic}

RabbitMQ 訊息發送

不會建立 Span,僅記錄方法棧。

${exchange} + publish

RabbitMQ 訊息接收

Recv Exchange@${exchange}

Recv Exchange@${exchange}

Java 探針是否支援 Spring Cloud Alibaba RocketMQ?

4.x 及之後版本的探針中已經支援該架構,如果您探針版本低於 4x,請升級ARMS探針

MQ 監控中的“訊息延遲”指標含義和單位是什嗎?

訊息延遲指該訊息從訊息產生開始到被 Consumer 消費的總耗時,該指標單位是毫秒(ms)。該指標目前僅支援 RocketMQ Client 和 Ons Client 的採集。

為什麼應用中存在消費邏輯,但沒有消費者的鏈路和指標資料?

可能是探針版本低於 4.x,且使用了 lambda 運算式定義 messageListener 中的消費邏輯。

由於2.x/3.x 版本探針對 lambda 運算式的類增強失敗,您可以升級探針到 4.x 版本避免該問題。

為什麼接入 Java 探針後,Kafka Clients 出現了 Magic v1 does not support record headers 的報錯資訊?

Java 探針通過 Kafka Message 的 Header 欄位來傳遞鏈路上下文,而在低於 0.11.0.0 版本的 Kafka 中(無論是 Client 還是 Broker),Kafka 的訊息體不支援 Header 欄位。如果您的 Kafka-broker 或 Kafka-clients 低於這個版本,請儘快遷移到 0.11.0.0 以上版本。 如果您暫時還無法遷移,對於4.x 之前版本的 Java探針,您可以在應用自訂配置頁面的探針開關設定地區關閉 Kafka 組件的增強(kafka-plugin開關);對於 4.x 及之後版本的 Java探針,您可以在啟動服務時添加 -Dotel.instrumentation.kafka.producer-propagation.enabled=false 虛擬機器參數來防止該類問題。

為什麼調用鏈中缺少接收訊息或者發送訊息的 Span?

  1. 請檢查您的 Producer 和 Consumer 應用使用的訊息佇列 Client SDK 是否在ARMS支援範圍內,支援的組件請參見ARMS應用監控支援的Java組件和架構

  2. 請檢查您的 Producer 和 Consumer 應用是否都接入了 ARMS 應用監控或Managed Service for OpenTelemetry,正常開啟了探針開關和外掛程式開關,並上報到了同一地區。發送訊息的 Span 在 Producer 中產生,接受訊息的 Span 在 Consumer 中產生,如果有應用沒有正確接入則會缺失對應 Span。

  3. 如果無法看到發送訊息的 Span,請檢查 Producer 應用探針版本是否大於等於 4.x。在低於 4.x 版本的探針中,發送訊息不會作為一個單獨的 Span 被統計,而是會統計在父 Span 的方法棧中,您可以單擊父 Span 右側的image表徵圖查看實際的調用方法棧。

    2024-12-20_15-23-14

  4. 如果無法看到接收訊息的 Span,您可以在對應 Consumer 應用自訂配置頁面的介面調用配置地區檢查是否配置了無效介面過濾。無效介面過濾會過濾掉您不關心的 Span。

為什麼4.x和4.x以下版本探針對應的Kafka回應時間差距較大

問題現象:回應時間從幾秒變成了0.x毫秒。

問題原因:

3.x 及之前探針在處理 BatchMessageListener 時,一批訊息會視為一次調用,所有的耗時會被統計在一起。

4.x 及之後的探針會把這些邏輯分開,每條訊息算作一次調用。因此出現從 3.x 升級到 4.x 探針後,單次調用耗時大幅下跌,調用次數大幅上升,這是符合預期的。

3.x 版本的統計方式不合理,4.x 版本進行了最佳化。