全部產品
Search
文件中心

Application Real-Time Monitoring Service:Java應用執行個體監控

更新時間:Nov 20, 2024

為Java應用安裝探針後,ARMS即可開始監控Java應用,您可以在執行個體監控頁面瞭解應用的基礎監控、執行個體GC和JVM記憶體等資訊。

前提條件

重要

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

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

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

查看執行個體監控

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

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

    說明

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

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

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

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

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

  3. 在上方導覽列單擊執行個體監控

頁面說明

執行個體監控頁面會根據應用接入的資訊自動適配展示大盤,並針對ECS環境和容器環境做區別展示。

在容器情境下,如果已經接入Managed Service for Prometheus,則優先以Managed Service for Prometheus資料作為容器資訊的展示。容器環境接入Managed Service for Prometheus的操作,請參見容器可觀測

容器環境如果未接入Managed Service for Prometheus,需要確保應用監控探針版本在4.1.0或以上,對應資料展示容器的基礎資訊。應用監控探針說明,請參見探針(Java Agent)版本說明

ECS環境

image.png

  • 在快捷篩選區域(圖示①),您可以按主機地址對圖表、執行個體列表進行篩選。

  • 在趨勢圖地區(圖示②),您可以查看執行個體的基礎監控、執行個體GC和JVM記憶體的時序曲線。

    • 基礎監控:應用在指定時間範圍內CPU、記憶體和磁碟使用率趨勢圖。通過表徵圖名稱右側的下拉框可以切換展示各使用率的平均值和最大值。

    • 執行個體GC:應用在指定時間範圍內Full GC和Young GC的趨勢圖。通過圖表名稱右側的下拉框可以切換展示GC的次數和平均耗時。

    • JVM記憶體:應用在指定時間範圍內堆記憶體已使用和最大值趨勢圖。通過表徵圖名稱右側的下拉框可以切換展示非堆記憶體已使用和最大值趨勢圖。

      說明

      ARMS應用監控採集的資料來自JMX,其中非堆記憶體所包含的記憶體地區比Java進程中實際的非堆記憶體地區少,因此可能會出現監控中堆記憶體+非堆記憶體總和與通過top命令看到的RES大小存在一定差值,相關細節請參見JVM監控記憶體詳情說明

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

  • 在執行個體列表地區(圖示③),您可以查看執行個體IP、CPU利用率、記憶體利用率、磁碟利用率、負載、Full GC次數、Young GC次數、堆記憶體使用量量、非堆記憶體使用量量、RED三指標(請求數、錯誤數、平均耗時)等資訊。

    在執行個體列表,您可以執行以下操作:

    • 單擊執行個體IP,可以查看執行個體詳情,更多資訊,請參見執行個體詳情

    • 單擊操作列的調用鏈,可以查看該執行個體的鏈路詳情。更多資訊,請參見調用鏈分析

容器環境(Prometheus版)

image

  • 在快捷篩選區域(圖示①),您可以按叢集和主機地址對圖表、執行個體列表進行篩選。

  • 在趨勢圖地區(圖示②),您可以查看執行個體的基礎監控、執行個體GC和JVM記憶體的時序曲線。

    • 基礎監控:應用在指定時間範圍內CPU用量和記憶體用量趨勢圖。

    • 執行個體GC:應用在指定時間範圍內Full GC和Young GC的趨勢圖。通過圖表名稱右側的下拉框可以切換展示GC的次數和平均耗時。

    • JVM記憶體:應用在指定時間範圍內堆記憶體已使用和最大值趨勢圖。通過表徵圖名稱右側的下拉框可以切換展示非堆記憶體已使用和最大值趨勢圖。

      說明

      ARMS應用監控採集的資料來自JMX,其中非堆記憶體所包含的記憶體地區比Java進程中實際的非堆記憶體地區少,因此可能會出現監控中堆記憶體+非堆記憶體總和與通過top命令看到的RES大小存在一定差值,相關細節請參見JVM監控記憶體詳情說明

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

  • 在執行個體列表地區(圖示③),您可以查看執行個體IP、CPU用量、CPU請求、CPU限制、CPU利用率(未設定CPU限制時,此項展示為-)、記憶體用量、記憶體請求、記憶體限制、記憶體利用率(未設定記憶體限制時,此項展示為-)、磁碟用量、磁碟限制、磁碟利用率(未設定磁碟限制時,此項展示為-)、負載、Full GC 次數、Young GC 次數、堆記憶體使用量量、非堆記憶體使用量量、RED三指標(請求數、錯誤數、平均耗時)等。

    在執行個體列表,您可以執行以下操作:

    • 單擊執行個體IP或操作列的詳情,可以查看執行個體詳情,更多資訊,請參見執行個體詳情

    • 單擊操作列的調用鏈,可以查看該執行個體的鏈路詳情。更多資訊,請參見調用鏈分析

容器環境(ARMS自採集版)

image

  • 在快捷篩選區域(圖示①),您可以按主機地址對圖表、執行個體列表進行篩選。

  • 在趨勢圖地區(圖示②),您可以查看執行個體的基礎監控、執行個體GC和JVM記憶體的時序曲線。

    • 基礎監控:應用在指定時間範圍內CPU用量和記憶體用量趨勢圖。

    • 執行個體GC:應用在指定時間範圍內Full GC和Young GC的趨勢圖。通過圖表名稱右側的下拉框可以切換展示GC的次數和平均耗時。

    • JVM記憶體:應用在指定時間範圍內堆記憶體已使用和最大值趨勢圖。通過表徵圖名稱右側的下拉框可以切換展示非堆記憶體已使用和最大值趨勢圖。

      說明

      ARMS應用監控採集的資料來自JMX,其中非堆記憶體所包含的記憶體地區比Java進程中實際的非堆記憶體地區少,因此可能會出現監控中堆記憶體+非堆記憶體總和與通過top命令看到的RES大小存在一定差值,相關細節請參見JVM監控記憶體詳情說明

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

  • 在執行個體列表地區(圖示③),您可以查看執行個體IP、CPU用量、記憶體用量、負載、Full GC 次數、Young GC 次數、堆記憶體使用量量、非堆記憶體使用量量、RED三指標(請求數、錯誤數、平均耗時)等。

    在執行個體列表,您可以執行以下操作:

    • 單擊執行個體IP或操作列的詳情,可以查看執行個體詳情,更多資訊,請參見執行個體詳情

    • 單擊操作列的調用鏈,可以查看該執行個體的鏈路詳情。更多資訊,請參見調用鏈分析

執行個體詳情

概覽

概覽頁簽可以查看目標介面的請求數、錯誤數、平均耗時和慢調用資訊。

image.png

JVM監控

JVM監控頁簽可以查看對應執行個體的GC、記憶體、線程、檔案等資訊。

image.png

池化監控

池化監控頁簽可以查看應用所使用的線程池或串連池的各項指標,包括核心線程數量、當前線程數量、最大線程數量、活躍線程數量、任務隊列容量。

image.png

展開查看池化監控支援的架構。

線程池支援的架構

4.1.x及以上探針版本

支援架構:

  • java.util.ThreadPoolExecutor:一般用於Tomcat8~9.1、Dubbo、HSF、Vertx以及使用者自訂線程池。

  • org.apache.tomcat.util.threads.ThreadPoolExecutor:一般用於Tomcat9.1+。

  • org.eclipse.jetty.util.thread.QueuedThreadPool:一般用於Jetty。

  • org.xnio.XnioWorker:一般用於Undertow。

採集的指標如下:

指標名

支援架構

指標描述

arms_thread_pool_core_pool_size

  • ThreadPoolExecutor(JDK)

  • ThreadPoolExecutor(Tomcat 9.1+)

  • XnioWorke

  • QueuedThreadPool

核心線程數,一般是靜態配置,不會改變。

arms_thread_pool_max_pool_size

  • ThreadPoolExecutor(JDK)

  • ThreadPoolExecutor(Tomcat 9.1+)

  • XnioWorke

  • QueuedThreadPool

最大空閑串連數,一般是靜態配置,不會改變。

arms_thread_pool_active_thread_count

  • ThreadPoolExecutor(JDK)

  • ThreadPoolExecutor(Tomcat 9.1+)

  • XnioWorke

  • QueuedThreadPool

活躍線程數,即當前正在執行任務的線程。

arms_thread_pool_current_thread_count

  • ThreadPoolExecutor(JDK)

  • ThreadPoolExecutor(Tomcat 9.1+)

  • QueuedThreadPool

當前線程數,包含活躍線程數和當前正在等待任務的線程數。

arms_thread_pool_max_thread_count

  • ThreadPoolExecutor(JDK)

  • ThreadPoolExecutor(Tomcat 9.1+)

線程池歷史最大線程數。

arms_thread_pool_scheduled_task_count

  • ThreadPoolExecutor(JDK)

  • ThreadPoolExecutor(Tomcat 9.1+)

線程池調度任務數。

arms_thread_pool_completed_task_count

  • ThreadPoolExecutor(JDK)

  • ThreadPoolExecutor(Tomcat 9.1+)

線程池執行完成任務數。

arms_thread_pool_rejected_task_count

  • ThreadPoolExecutor(JDK)

  • ThreadPoolExecutor(Tomcat 9.1+)

  • QueuedThreadPool

線程池拒絕任務數。

arms_thread_pool_queue_size

  • ThreadPoolExecutor(JDK)

  • ThreadPoolExecutor(Tomcat 9.1+)

  • XnioWorke

  • QueuedThreadPool

線程池任務隊列大小。

4.1.x以下探針版本

線程池監控支援Tomcat、HSF、Dubbo、Vert.x和Undertow架構,其中,3.1.x及以下版本探針支援Undertow1.x~Undertow2.0.x版本線程池監控,3.2.x及以上版本探針支援Undertow所有版本線程池監控。

採集的指標如下:

指標名稱

指標

線程池核心線程數

arms_threadpool_core_size

線程池最大線程數

arms_threadpool_max_size

線程池活躍線程數

arms_threadpool_active_size

線程池隊列大小

arms_threadpool_queue_size

線程池當前大小

arms_threadpool_current_size

線程池監控支援SchedulerX架構,採集的指標如下:

指標名稱

指標

線程池活躍線程數

arms_threadpool_active_size

串連池支援的架構

4.1.x及以上探針版本

支援架構:DBCP(>2.0)、Vibur DBCP(>11.0)、c3p0(>0.9.2)、Druid、HikariCP(>3.0)、Jedis(>3.0)、Lettuce(>5.0)、Redisson(>3.0)。

採集的指標如下:

指標名

支援架構

指標描述

arms_connection_pool_connection_count

DBCP、c3p0、Vibur DBCP、Druid、Hikaricp、Jedis、Lettuce、Redisson

串連數,可通過State區分Active和Idle串連數。

arms_connection_pool_connection_min_idle_count

DBCP、Jedis、Druid、HikariCP、Lettuce

最小空閑串連數,一般是靜態配置,不會改變。

arms_connection_pool_connection_max_idle_count

DBCP、Jedis、Druid、Lettuce、

最大空閑串連數,一般是靜態配置,不會改變。

arms_connection_pool_connection_max_count

DBCP、Druid、Vibur DBCP、HikariCP

最大串連數,一般是靜態配置,不會改變。

arms_connection_pool_pending_request_count

c3p0、HikariCP、Jedis

阻塞的串連請求數。

4.1.x以下探針版本

串連池監控支援okHttp2、okHttp3架構,採集的指標如下:

指標名稱

指標

串連池活躍串連數

arms_threadpool_active_size

串連池當前串連數

arms_threadpool_current_size

串連池監控支援Apache HTTPClient架構,採集的指標如下:

指標名稱

指標

串連池當前串連數

arms_threadpool_current_size

串連池最大串連數

arms_threadpool_max_size

串連池等待隊列數

arms_threadpool_queue_size

串連池監控支援Druid架構,採集的指標如下:

指標名稱

指標

串連池活躍串連數

arms_threadpool_active_size

串連池最大串連數

arms_threadpool_max_size

串連池監控支援Hikaricp架構,採集的指標如下:

指標名稱

指標

串連池活躍串連數

arms_threadpool_active_size

串連池最大串連數

arms_threadpool_max_size

主機監控

主機監控頁簽可以查看CPU、記憶體、Disk(磁碟)、Load(負載)、網路流量和網路資料包的各項指標。

image.png

容器監控

容器環境(Prometheus版)

接入可觀測監控 Prometheus 版的操作請參見Prometheus執行個體 for Container Service

容器監控頁簽可以查看容器視角的CPU、記憶體、Disk(磁碟)、Load(負載)、網路流量和網路資料包的各項指標。

image.png

容器環境(ARMS自採集版)

未接入可觀測監控 Prometheus 版的情況下,需要確保ARMS探針版本在4.1.0或以上。探針版本說明請參見探針(Java Agent)版本說明

容器監控頁簽可以查看容器視角的CPU、記憶體、網路流量的時序曲線。

image

調用鏈分析

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

相關文檔

應用監控詳細的指標資訊,請參見應用監控指標說明

常見問題

應用層級的資料與單機的資料是什麼關係

  • RED(請求數、錯誤數、延遲)指標:

    • 請求數、慢調用次數、HTTP狀態代碼次數:應用層級的資料是單機層級資料的匯總。

    • 回應時間:應用層級的資料是單機層級資料的平均值。

  • JVM指標:

    • GC次數、GC耗時:應用層級的資料是單機層級資料的匯總。

    • 堆記憶體資料、線程數:應用層級的資料是單機層級資料取最大值。

  • 線程池/串連池指標

    所有指標:應用層級的資料是單機層級資料的平均值。

  • 系統指標

    所有指標:應用層級的資料是單機層級資料取最大值。

  • SQL/NSQL調用:同RED指標,對於次數類指標,應用層級的資料是單機層級資料的匯總;對於其餘指標,應用層級的資料是單機層級資料的平均值。

  • 異常指標:應用層級的資料是單機層級資料的匯總。

不同執行個體之間流量不均勻

在3.x版本探針中,如果開啟了記憶體最佳化開關,可能會導致部分指標統計丟失。該問題已在4.x版本探針中修複。

Undertow一次請求被統計成了兩次

3.2.x版本之前探針埋點方法在使用DeferredResult情境下一次調用中會被執行兩次。該問題已在3.2.x及以上版本中修複。

容器監控中CPU/記憶體配額與Pod實際設定不一致

請檢查您的Pod中是否定義了多個Container,該指標會統計所有Container加起來的總配額。

系統指標部分缺失、不準或者CPU使用率展示為100%

4.x之前版本探針不支援Windows環境下系統指標採集,4.x及以後版本探針已經修複。

為什麼應用剛啟動會FullGC

一般是因為使用者沒有配置元空間大小,預設的元空間大小約為20 MB,應用在剛啟動的時候可能會進行元空間的擴容從而觸發FullGC,可通過-XX:MetaspaceSize參數和XX:MaxMetaspaceSize參數設定初始元空間和最大元空間大小。

VM Stack指標是如何計算的

該指標是通過線程數×1 MB得到的,其中1 MB是線程堆棧預設大小。如果通過-Xss參數重新指定了線程堆棧大小,則該資料與實際情況會有差異。

JVM指標擷取原理

ARMS展示的JVM指標均是通過標準的JDK介面擷取的,對應介面如下:

記憶體相關指標:

  • ManagementFactory.getMemoryPoolMXBeans

  • java.lang.management.MemoryPoolMXBean#getUsage

GC相關指標:

  • ManagementFactory.getGarbageCollectorMXBeans

  • java.lang.management.GarbageCollectorMXBean#getCollectionCount

  • java.lang.management.GarbageCollectorMXBean#getCollectionTime

為什麼JVM最大堆記憶體值為-1

-1代表未設定最大堆記憶體大小。

為什麼JVM堆記憶體使用量總量不等於設定的堆記憶體最大值

根據JVM記憶體配置機制,-Xms參數指定初始堆記憶體配置,當空餘堆記憶體不足後擴容,直到達到-Xmx參數設定的最大值,總量與最大量不一致說明還沒觸發擴容,使用量是當前實際用量。

JVM GC的頻率逐漸加快

可能是使用了JDK 8預設的GC演算法ParallelGC,該演算法預設開啟了-XX:+UseAdaptiveSizePolicy,其作用是自動調整堆的大小,包括新生代大小、SurvivorRatio等參數,為了滿足GC的停頓時間,當YounGC比較頻繁時,可能會動態縮小Survivor區的大小,這時候Survivor區的對象很容易晉陞到Old區,導致Old區空間漲幅過快,從而觸發Full GC的頻率也加快。更多資訊,請參見Java官方文檔

線程池、串連池監控沒有資料

  1. 自訂配置頁面的進階設定地區確認是否已經開啟線程池、串連池監控開關。

  2. 檢查架構是否在支援的範圍內,具體內容,請參見線程池和串連池監控

HikariCP串連池擷取的最大串連數與實際不符

3.2.x版本之前的探針擷取最大串連數代碼有誤,3.2.x及以上版本已經修複。

池化監控指標展示數值是小數

探針每隔15s採集一次,因此一分鐘會採集4個點的資料,控制台會根據採集資訊展示一個時間段的平均值。例如:一分鐘採集的4個資料點為0、 0、 1、 0,理論上平均值為0.25。

線程池/串連池明明被打滿了,但為什麼監控上沒有體現出來

如果您的日誌或其他記錄中確實看到線程池/串連池被打滿,但是ARMS控制台卻看不到相關指標的增長,有可能是由於指標採樣時間點與打滿的時間點錯開導致的。目前ARMS自動採集線程池/串連池狀態指標的時間間隔為15s,發生在這個時間段內的瞬時沖高可能不會被採集到。

線程池監控最大線程數不符合預期或者最大線程數為21億

ARMS最大線程池是直接調用線程池對象的擷取最大線程數方法得到的,一般不會出錯。如果不符合使用者預期可能是使用者佈建的最大線程數未生效。

如果最大線程數為21億一般是調度線程池,在調度線程池中,預設設定的最大線程數是Integer.MAX_VALUE,如下圖所示。

image