為應用安裝探針後，ARMS即可開始監控應用，您可以在提供服務頁面瞭解應用提供的服務詳情，包括介面調用、訊息訂閱和定時任務的詳細資料。
前提條件
ARMS應用監控面向已開通新版計費的使用者提供全新的監控詳情頁面，新版計費詳情，請參見產品計費（新版）。
對於未開通新版計費的使用者，如需查看新版監控詳情頁面，可在應用列表頁面單擊切換新版。
已為應用安裝探針，具體操作，請參見應用監控接入概述。
查看應用提供服務
登入ARMS控制台，在左側導覽列選擇。
在應用列表頁面頂部選擇目標地區，然後單擊目標應用程式名稱。
說明語言列的表徵圖含義如下：
：接入應用監控的Java應用。
：接入應用監控的Golang應用。
：接入應用監控的Python應用。-：接入Managed Service for OpenTelemetry的應用。
在上方導覽列單擊提供服務。
在快捷篩選區域（圖示①），您可以按請求類型、介面名稱、主機對圖表、服務列表進行篩選過濾。
在趨勢圖地區（圖示②），您可以查看服務的請求數、錯誤數和平均耗時的時序曲線。
單擊
表徵圖，可以在彈出的對話方塊中查看該指標在某個時間段的統計情況或對比不同日期在同一時間段的統計情況，通過選擇
表徵圖可以切換柱狀圖、趨勢圖進行展示。在服務列表地區（圖示③），您可以查看介面的名稱、請求類型、RED三指標（請求數、錯誤數、平均耗時）等資訊。
在服務列表，您可以執行以下操作：
支援的架構
介面詳情
介面調用
概覽
在概覽頁簽可以查看目標介面的請求數、錯誤數、平均耗時，以及HTTP-狀態代碼統計、慢調用的時序曲線。
SQL和NoSQL分析
在SQL分析和NoSQL分析頁簽可以查看左側選中介面發起的SQL和NoSQL請求列表，同時可以通過主機列表進行主機過濾。藉助此頁簽，您可以找出是哪一個SQL或NoSQL造成某個服務過慢。
單擊SQL或NoSQL的資料庫名稱可以查看該資料庫的詳情；單擊SQL或NoSQL右側的調用鏈可以查看SQL或NoSQL執行邏輯所在的完整代碼鏈路。更多資訊，請參見調用鏈分析。
鏈路上下遊的介面調用情況
鏈路上遊和鏈路下遊頁簽分別列出了應用上遊（調用應用的一方）和應用下遊（被應用調用的一方）的介面及其調用效能指標，包括請求數、錯誤數和耗時資訊。
調用鏈分析
調用鏈分析功能基於已儲存的全量鏈路詳細資料，通過自由組合篩選條件與彙總維度進行即時分析，可以滿足不同情境的自訂診斷需求。更多資訊，請參見調用鏈分析。
訊息訂閱
Python應用暫不支援查看訊息訂閱。
概覽
在概覽頁簽可以查看目標介面的請求數、錯誤數、平均耗時，以及消費延遲（目前僅支援RocketMQ 4.8.0+）。
SQL和NoSQL分析
在SQL分析和NoSQL分析頁簽可以查看左側選中介面發起的SQL和NoSQL請求列表，同時可以通過主機列表進行主機過濾。藉助此頁簽，您可以找出是哪一個SQL或NoSQL造成某個服務過慢。
單擊SQL或NoSQL的資料庫名稱可以查看該資料庫的詳情；單擊SQL或NoSQL右側的調用鏈可以查看SQL或NoSQL執行邏輯所在的完整代碼鏈路。更多資訊，請參見調用鏈分析。
消費統計
消費統計頁簽以訊息消費方視角，列出了Topic的消費情況，包括請求數、錯誤數和耗時。
調用鏈分析
調用鏈分析功能基於已儲存的全量鏈路詳細資料，通過自由組合篩選條件與彙總維度進行即時分析，可以滿足不同情境的自訂診斷需求。更多資訊，請參見調用鏈分析。
定時任務
目前僅Java應用支援查看定時任務。
概覽
在概覽頁簽可以查看目標介面的請求數、錯誤數、平均耗時，以及調度延遲時間的時序曲線。
SQL和NoSQL分析
在SQL分析和NoSQL分析頁簽可以查看左側選中介面發起的SQL和NoSQL請求列表，同時可以通過主機列表進行主機過濾。藉助此頁簽，您可以找出是哪一個SQL或NoSQL造成某個服務過慢。
單擊SQL或NoSQL的資料庫名稱可以查看該資料庫的詳情；單擊SQL或NoSQL右側的調用鏈可以查看SQL或NoSQL執行邏輯所在的完整代碼鏈路。更多資訊，請參見調用鏈分析。
鏈路下遊的介面調用情況
鏈路下遊頁簽列出了應用下遊（被應用調用的一方）的介面及其調用效能指標，包括請求數、錯誤數和耗時資訊。
調用鏈分析
調用鏈分析功能基於已儲存的全量鏈路詳細資料，通過自由組合篩選條件與彙總維度進行即時分析，可以滿足不同情境的自訂診斷需求。更多資訊，請參見調用鏈分析。
常見問題
介面調用相關
介面調用的鏈路上遊是什麼
指上遊應用調用該應用的次數，當上遊應用接入了ARMS探針，就會有記錄；當上遊應用沒有接入ARMS探針，就不會有。如果應用自己調用自己，也會作為上遊應用展示。
部分介面缺失鏈路上遊
如果該介面確實存在上遊調用，但上遊調用沒有接入ARMS探針，則上遊調用不會被展示出來。
鏈路上下遊混亂
如果當前鏈路中有使用SkyWalking組件，則預設整條鏈路中的Tracing協議為SkyWalking協議。在4.2.x版本之前，ARMS對SkyWalking協議的支援存在問題，會導致上下遊識別失敗。您可以升級到4.2.x或以上版本，或者在自訂配置頁面的調用鏈透傳通訊協定設定中強制使用其他非SkyWalking協議進行Trace上下文透傳。具體操作，請參見Trace上下文傳播通訊協定設定。
Dubbo介面錯誤數不為0，但是搜不到調用鏈
探針3.2.x版本之前，Dubbo調用鏈未正確選項組碼，導致搜不到錯誤調用鏈，3.2.x及以上版本已經修複。
介面調用中異常次數不為0，但在調用鏈中無法搜尋到異常調用鏈
在4.1.x版本之前，探針僅記錄錯、慢調用，所以當介面調用中僅有異常時，不一定被採樣；在4.1.x版本之後，探針記錄錯、慢、異常採樣，當介面調用中存在異常時就會被採樣。
為什麼介面流量下跌了
首先需要排除是否確實下跌了，可以通過查看下跌時間點前後的CPU水位，網路IO等指標是否有同步變化來判斷：
如果有，一般是實際流量下跌。
如果沒有，可能是ARMS服務端出現問題，此時建議提交工單諮詢。
Spring Cloud Gateway監控的流量不準
4.x版本以前對於Spring Cloud Gateway的埋點存在缺陷，在某些情境下會導致流量統計丟失，建議升級到4.x版本探針。
是否能查看一個介面中有哪些慢SQL
可以，查詢頁面如下：
新版控制台
在監控詳情頁面單擊目標介面名稱，然後在SQL分析頁面查看。
舊版控制台
在目標應用的頁面查看。
舊版控制台中介面前面的黃點是什麼意思
將滑鼠移到圓點上，可以查看相應提示。
黃點代錶慢調用，預設一次請求耗時大於500 ms會被標識為慢調用，您可在自訂配置頁面的介面調用配置地區調整該閾值。
紅點代表錯誤。
部分5xx資料未被採集到
根據RFC7231說明，502、504等狀態代碼為Gateway拋出的錯誤狀態代碼，這些狀態代碼是Gateway產生的，和Gateway調用服務實際的響應碼可能並無關係。如果Gateway沒有接入ARMS監控，只是Gateway對接的服務方接入了ARMS，這種情境下拋出的5xx響應是不會被統計上來的。
NetWork And Dubbo Response Decode是什麼
是一個Span，用於統計Dubbo傳輸層還原序列化的耗時。
介面中為什麼包含*或者ARMS關鍵字的一些字元
這種情況是因為介面名比較發散，ARMS對介面進行了收斂，將相似介面中差異的部分進行了替換，詳情請參見ARMS收斂機制說明。
外部調用介面耗時與下遊服務實際耗時不同
服務端耗時是請求到介面之後，介面處理請求的耗時；調用端耗時是發起請求之後統計的耗時，還會包含建連、網路等耗時。其中，ARMS控制台會分別展示服務端介面的處理請求耗時，與調用方發起請求的完整耗時，但是其中網路相關的耗時無法確定。
介面正常返回，但單次異常次數不為0
這個是符合預期的，這些異常是某些架構（如OkHttp3架構）內部拋出的，這些異常在外部被架構catch住了，因此業務是正常的，但是ARMS監控的時候因為針對這個架構進行了埋點，所以也會對這些異常資訊進行記錄，但不代表業務真的有異常，這些資訊業務方可以自行判斷是否需要進行治理。這個異常在統計時忽略了異常的Message資訊，如果想要看具體異常的Message資訊，可以通過單擊異常對應的一條調用鏈 ，然後單擊介面右側的
表徵圖，查看方法棧裡面的異常資訊。
HTTP介面名為/error、/404、/*、/**等
這種情況通常是存在一些非預期的請求，ARMS無法為這些請求找到匹配的路由，一般存在以下幾種情況：
請求了一個不存在的URL。
要求標頭非法導致請求校正失敗報錯，例如Header包含非法字元。
使用了一些無路由機制的HTTP Server，例如裸用Netty。
介面調用中請求次數和調用鏈分析中介面次數不一致
調用鏈分析是基於Trace資料計算的，受採樣率影響。
介面詳情裡的分位元耗時和調用鏈分析裡的不一樣
介面詳情中分位元是單機基於分桶演算法計算得到的，調用鏈中是基於採樣後該介面相關Span的耗時計算的，所以二者不一致，詳情請參見ARMS分位元指標計算原理。
介面調用量突然增量2倍左右
這種情況一般是由於在升級探針的過程中誤操作，同時掛載了3.x和4.x版本的探針導致。您可以前往頁面選擇任一探針，單擊查看詳情查看JVM參數。
如下圖所示，存在兩個-javaagent參數就是同時掛載了3.x和4.x探針。
ARMS控制台看到的調用量和其他途徑統計的調用量不一致
造成調用量不一致的情況比較多，下面舉例說明兩種常見情境：
ARMS看到應用的介面調用量為500次/分鐘，Nginx看到介面的調用量為200/分鐘。一般造成這種原因很有可能是有流量繞過Nginx直接存取應用。
ARMS上看到應用訪問DB的次數是400次/分鐘，DB服務端監控看到資料庫執行次數是1000/分鐘。一般造成這種情況是該DB被多個應用訪問，ARMS控制台僅能看到特定應用的訪問量。
ARMS當前對於webflux情境的支援情況
4.x之前的探針只支援使用原生的Spring Webflux和spring-cloud-gateway。對於使用自訂WebHandler修改過的Webflux相關外掛程式（如apache shenyu）暫時不支援。
為什麼在鏈路上遊中存在不屬於我的應用程式，並且無法跳轉到對應應用查看詳細資料
如果該應用對外部提供了服務則屬於正常情況。該鏈路上遊為另一個使用者下的應用，即跨使用者間存在調用關係，在這種情況下，ARMS會統計上遊應用的應用程式名稱和對該介面的調用次數，但受限於使用者間資訊隔離，您無法查看另一位使用者的應用詳情。
在應用之間明確有上下遊調用關係時，無法通過介面上下遊看到預期資料
ARMS會先隨機查看使用者的調用鏈路，關注LocalRootSpan中記錄的trace.protocol.type欄位。如果欄位值為Jager則會因為大小寫轉換問題導致上下遊識別失敗，出現該問題請切換為其他協議或提交工單處理。
訊息訂閱相關
訊息訂閱/訊息發佈頁面的資料和 MQ 執行個體自監控面板資料有什麼區別？
訊息訂閱/訊息發佈頁面展示的內容為選定應用作為消費者/生產者時的各種效能指標，是用戶端視角的監控資料。MQ 執行個體的監控面板資料是 Topic 相關的效能指標，是服務端視角的監控資料。
訊息發送與接收對應的 SpanName 格式是什嗎？
訊息類型 | 4.x 之前版本探針 | 4.X 及之後版本探針 |
RocketMQ/Ons 訊息發送 | 不會建立 Span，僅記錄方法棧。 |
|
RocketMQ/Ons 訊息接收 |
|
|
Kafka 訊息發送 | 不會建立 Span，僅記錄方法棧。 |
|
Kafka 訊息接收 |
|
|
RabbitMQ 訊息發送 | 不會建立 Span，僅記錄方法棧。 |
|
RabbitMQ 訊息接收 |
|
|
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？
請檢查您的 Producer 和 Consumer 應用使用的訊息佇列 Client SDK 是否在ARMS支援範圍內，支援的組件請參見ARMS應用監控支援的Java組件和架構。
請檢查您的 Producer 和 Consumer 應用是否都接入了 ARMS 應用監控或Managed Service for OpenTelemetry，正常開啟了探針開關和外掛程式開關，並上報到了同一地區。發送訊息的 Span 在 Producer 中產生，接受訊息的 Span 在 Consumer 中產生，如果有應用沒有正確接入則會缺失對應 Span。
如果無法看到發送訊息的 Span，請檢查 Producer 應用探針版本是否大於等於 4.x。在低於 4.x 版本的探針中，發送訊息不會作為一個單獨的 Span 被統計，而是會統計在父 Span 的方法棧中，您可以單擊父 Span 右側的
表徵圖查看實際的調用方法棧。
如果無法看到接收訊息的 Span，您可以在對應 Consumer 應用自訂配置頁面的介面調用配置地區檢查是否配置了無效介面過濾。無效介面過濾會過濾掉您不關心的 Span。
為什麼4.x和4.x以下版本探針對應的Kafka回應時間差距較大
問題現象：回應時間從幾秒變成了0.x毫秒。
問題原因：
3.x 及之前探針在處理 BatchMessageListener 時，一批訊息會視為一次調用，所有的耗時會被統計在一起。
4.x 及之後的探針會把這些邏輯分開，每條訊息算作一次調用。因此出現從 3.x 升級到 4.x 探針後，單次調用耗時大幅下跌，調用次數大幅上升，這是符合預期的。
3.x 版本的統計方式不合理，4.x 版本進行了最佳化。
消費訂閱中為什麼鏈路中的 Kafka 消費過程發生重複？
如果您使用了 spring-kafka 提供的 batchMessageListener，這批訊息中每個訊息的處理過程都會記錄在同一個 kafka 消費邏輯中。spring-kafka 的 batchMessageListener 實現的方式包括：
在消費方法上添加
@KafkaListener(topics = "my-topic", batch = true)註解。消費方法類實現
BatchMessageListener介面。Kafka Message Listener Container 的屬性中開啟 batch 消費模式：
containerProperties.setBatchListener(true)。
定時任務相關
為什麼無效介面無法過濾定時任務的介面
請檢查您應用的探針版本，對於版本低於 3.2.0 或介於 4.0.0 及 4.2.0 之間的探針，可能存在無效介面過濾不生效的情況，建議升級探針到 3.2.10 版本或高於 4.2.0 版本。
為什麼定時任務中存在外部調用，但 trace 中看不到外部調用的記錄
排查方式：
如果定時任務調用記錄也不存在，請先檢查ARMS應用監控支援的Java組件和架構，並檢查探針開關設定。
如果僅缺少外部調用的記錄，且探針版本低於 4.0.0 版本，可能是由於非同步情境下鏈路上下文透傳失敗，請升級探針到 4.0.0 及以上版本，或者使用進階設定功能配置上下文自動透傳。
為什麼缺少 xxl-job 架構的資料
版本低於 3.1.0 的探針不支援 xxl-job 架構，請升級探針到更高版本。
如果您對 xxl-job 代碼有過定製，例如對某些關鍵類的全類名進行了修改（包括類名和包名），則探針埋點無法生效，這種情況下建議您通過OpenTelemetry Java SDK為調用鏈增加自訂埋點。