持續剖析日誌中的報錯如何解決 - Application Real-Time Monitoring Service

本文介紹持續剖析使用過程中的常見問題。

開啟持續剖析後頁面沒有資料

檢查相關配置是否正確，設定的網段是否包含了應用執行個體對應的IP地址。
若使用了3.1.4之前版本的探針，由於Alpine基礎鏡像的相容性問題可能導致剖析引擎失效（該問題在3.1.4版本中已修複）。為確保功能穩定性及資料完整性，建議升級探針至3.1.4及以上版本探針。
說明
驗證是否使用了Apline Linux基礎鏡像的操作，請參見其他動作。
持續剖析基於開源Async Profiler增強後對應用進行資料擷取，當前暫不支援多Async Profiler同時掛載。如果應用同時使用了Pyroscope探針提供的持續剖析功能可能會出現啟動失敗。
將持續剖析頁面的查詢時間向後調整8小時，查看是否存在資料，如果有資料，可能是應用所在時區為0時區，所以資料寫入時間比東八區（UTC+8）晚了8小時。
解決方案：為應用添加環境變數將時區調整到UTC+8。
說明
建議先在持續剖析頁面使用當前Pod的名稱進行過濾，避免因過去8小時容器重啟過多，導致看錯資訊。
```
Key：JAVA_TOOL_OPTIONS，Value：-Duser.timezone=GMT+8
```
該問題已經在 4.1.10 版本修複，如果確認是該問題，您也可以直接升級探針至4.1.10及以上版本。
應用自身是否有掛載其他Async Profiler動態庫，檢查方式如下：
1. 執行以下命令，其中[pid]需換成業務進程的pid資訊。
```
lsof -p [pid] | grep libasync
```
2. 如果結果中有類似如下非阿里雲的動態庫，則是應用自身使用了Async Profiler動態庫導致跟ARMS不相容，此時需要移除自身動態庫後才可以繼續使用ARMS相關功能。
```
/home/admin/xxx/.default/temp/libasyncProfiler1309163652530490111.so
```

新版持久性能剖析資料計算儲存費用變化原因

導致上報量變化的主要原因：

持久性能剖析是全新的產品能力，無縫相容原有持續剖析能力，支援多執行個體彙總查詢，線程層級的分析，引入Copilot智能化火焰圖分析解讀等能力。
儲存結構變化，為了滿足使用者對剖析資料的二次消費需求，剖析資料的儲存介質將從原來內建的OSS中遷移至使用者名稱下的SLS中（SLS Project：proj-xtrace-<encode>-<region-id>，SLS Logstore：logstore-profiling），這將導致剖析資料量有一定變化。

資料查詢支援的時間跨度

持久性能剖析資料支援儲存7天，您可以查詢7天內的剖析資料。

堆記憶體監控的記憶體佔比和持續剖析中記憶體熱點單位時間檢測到的記憶體佔比資料不一樣，是否正常？

持續剖析只記錄指定時段內的堆記憶體申請情況，並不是當前進程實際包含的總量。

CPU診斷有資料但記憶體診斷無資料

該問題一般出現在3.1.4及以後版本的探針中。

記憶體診斷功能無資料，一般都是由於使用了 Alpine 基礎鏡像導致的，Alpine 基礎鏡像為了控制體積而去除了 JDK 偵錯符號（debug symbols），進而影響了持續剖析能力的正常使用，建議在使用者鏡像中為 JDK 安裝調試符（部分 JDK 版本缺乏對應的調試符包，會導致無法安裝）或使用非 Alpine 的基礎鏡像。

說明

驗證所在環境是否存在調試符資訊的操作，請參見檢查所在環境JDK是否包含調試符資訊。

代碼熱點無資料或資料不符合預期

暫不支援對使用了JDK（包括 Alibaba Dragonwell JDK）中虛擬線程或類似技術的相關應用進行熱點剖析。
SkyWalking協議暫不支援使用代碼熱點功能。您可以在調用鏈的Span詳情中的確認協議類型。
代碼熱點要求的最低探針版本為3.1.4，之前版本不支援代碼熱點功能。
低於4.2.1的探針版本，僅支援同步調用情境，並有一定機率可能採集不全，非同步呼叫可能會出現沒有資料（如使用Spring Cloud Gateway或者Undertow、Lettuce等，都會出現非同步線程切換導致資料擷取不準問題），4.2.1及以上版本探針對相關問題進行了最佳化，建議優先升級探針到相關版本進行使用。
僅按固定採樣率採樣的調用鏈支援代碼熱點功能，通過非固定採樣率採集調用鏈時會引發較大的效能開銷，如在調用鏈執行結束後才觸發的錯採樣s9和慢採樣s10（可以檢查Span的attribute中的sample.reason欄位進行判斷），暫不支援代碼熱點功能。
非固定採樣率採集的調用鏈，建議在調用鏈分析頁面通過僅含代碼熱點的Trace參數篩選包含代碼熱點的調用鏈，進行問題診斷。
如果使用4.2.1及以上探針版本，但採集的耗時比外層Span統計的耗時低很多，這種情況需要檢查一下應用是否使用了非同步非阻塞NIO的架構（如Spring Cloud Gateway），這類架構在接收上遊請求或發送請求到下遊時，如果上遊或下遊資料沒有準備好，不會阻塞線程，而是立即返回，讓線程可以去做其他事情，從而提高線程的利用率。由於無線程實際執行，耗時瓶頸不是出現在本應用中，這種情況下代碼熱點採集耗時可能會比Span低很多，此時您可以重點排查上下遊應用請求處理或者網路是否存在瓶頸。

持續剖析效能開銷是多少

持續剖析功能經效能測試，在500 TPS情境下，在一般的Spring Web應用所有功能效果全部開啟時， CPU開銷增加5%左右，堆外記憶體開銷增加50 M左右，GC以及請求延遲增加不明顯。
極端情況下，由於當前記憶體熱點剖析沒有做限流，如果應用申請記憶體非常頻繁，可能會導致相關事件非常多，例如1分鐘達到數萬，可能會對P99延時造成影響。您可以先關閉記憶體剖析解決。
該問題已經在 4.1.10 版本中修複，您可以直接升級探針至4.1.10及以上版本。

應用中有JFR相關線程

持續剖析功能會產生JFR線程，主要在4.1.10以下版本會存在JFR線程，4.1.10及以上版本不會再主動引入JFR相關線程。
相關線程不會對應用產生效能瓶頸。
動態關閉持續剖析開關後，該線程不會立即銷毀，需要應用重啟以後才會消失。

持續剖析影響應用啟動時間

所有接入了ARMS 持續剖析的應用，如果沒有JDK偵錯符號，且Classloader載入的類的方法較多，都可能影響啟動速度（顯著變慢）。但在應用啟動完成後，對應用運行效能沒有影響。

該問題已經在 4.2.1 版本修複，不會影響應用啟動，您可以升級探針到相關版本。

火焰圖中總記憶體超過實際配置的記憶體上限

持續剖析中展示的資料跟機器沒有必然關係，該資料是分析的一段時間內，堆記憶體配置的記憶體空間大小，因為有記憶體回收，所以比實際機器實際配置的記憶體大是符合預期的。

OpenJ9 JDK接入失敗

ARMS 持續剖析暫不支援IBM OpenJ9，使用相關JDK可能會出現接入失敗並報錯，建議更換到OpenJDK或者Oracle JDK。

Span中的代碼熱點資料不全

代碼熱點是根據一定時間間隔對調用鏈中的線程進行方法棧採集，對代碼熱點火焰圖中缺失的方法，請檢查其耗時是否小於500ms，如果小於500ms，可能有一定機率採集不到，這種情況不影響相關慢調用鏈診斷，因為耗時短的方法不會是耗時瓶頸。

火焰圖中為什麼存在.GC_active的棧

.GC_active 代表火焰圖採集資料時，受到GC的Stop the World（即GC過程暫停所有Java業務線程的執行）過程影響，導致相關業務線程被暫停。如果在代碼熱點中出現，表示該次請求的耗時一部分是由於GC暫停導致的。

火焰圖中為什麼存在unknown項

Alpine上JDK無偵錯符號，類載入器中方法較多時，載入持續剖析可能會導致應用變慢甚至逾時，因此，目前從在4.2.1版本探針開始，會檢測載入耗時，預設150ms，超過會停止一些耗時步驟載入，導致出現部分方法符號資訊未正常被解析出現unknown。可以通過比如export AP_JMID_TIME_LIMIT=500（單位毫秒）參數進行閾值調整緩解現象。

火焰圖中為什麼存在.no_Java_frame項

一般是由於使用了Alpine基礎鏡像，Alpine基礎鏡像為了控制體積而去除了JDK偵錯符號（debug symbols），導致JDK裡面的C++線程中的方法棧無法識別出函數名字，只能顯示為no_Java_frame，由於這些方法棧主要是非Java的線程執行資訊，一般常見如VM Thread或者JIT編譯器線程，如果no_Java_frame相關內容佔比不高，可以忽略，重點觀察其他Java方法棧資訊做效能分析，如果no_Java_frame相關內容佔比較高，建議在基礎鏡像中為JDK安裝調試符（部分JDK版本缺乏對應的調試符包，會導致無法安裝）或使用非Alpine基礎鏡像。

火焰圖中為什麼出現other項

問題現象

火焰圖中出現 other 項。

在效能分析類型選擇 Allocated Memory 的分析結果中，記憶體配置排行表顯示 other 項（6.41 MB）以橙色高亮標示，排列在具體 Java 方法（如 AbstractQueuedSynchronizer$ConditionObject.addConditionWaiter() 8.99 MB、java.util.Arrays.copyOfRange(char[], int, int) 8.90 MB）之間，右側火焰圖展示對應調用棧層級結構。

問題原因

火焰圖中出現other項是正常的。火焰圖是一棵樹，當節點數較多時不便於從圖中提取關鍵資訊，因此ARMS通過一些方法對火焰圖中的節點進行收斂，將一些重要性相對較低的節點併入到other項中。

parse lib sigsegv handler installed日誌列印

該日誌是ARMS探針列印的無用日誌，僅在開啟持續剖析功能後才會列印，對應用運行過程無影響，另外ARMS會在將來的新版本中關閉相關日誌列印。

perf_event_open被限制導致的No access to perf events報錯問題

問題現象

Async-Profiler進行CPU Profiler依賴perf_event_open的系統調用，但因為Linux kernel的Syscall安全性原則（seccomp）控制，可能會禁止進程調用特定Syscall。

錯誤提示如下：

[ERROR] Failed to execute 'start,jfr=0,event=cpu,interval=11ms,alloc=512k,file=/tmp/cpc-async-profiler-7729534006755968198.jfr'
[ERROR] Failed to start Continuous Profile Collector
java.lang.RuntimeException: java.lang.IllegalStateException: No access to perf events. Try --fdtransfer or --all-user option or 'sysctl kernel.perf_event_paranoid=1'

解決方案

Docker環境：執行以下命令運行容器。如需配置更精細化的系統調用控制，請參見官方文檔。
```
  docker run --security-opt seccomp=unconfined  XXX
```
Kubernetes環境：配置特權容器參數privileged: true，特權容器始終保持為Unconfined。
如需配置更精細化的系統調用控制，請參見官方文檔。

No AllocTracer symbols found. Are JDK debug symbols installed? 報錯問題

如果Java進程運行在容器環境，出現以上報錯或者該功能無資料，一般都是由於使用了Alpine基礎鏡像導致，Alpine基礎鏡像為了控制體積而去除了JDK偵錯符號（debug symbols），影響持續剖析能力的正常使用，建議參考本文缺少調試符導致記憶體熱點採集失敗的解決辦法進行處理。

perf_event mmap failed...報錯問題

問題現象

此錯誤一般出現在JVM的標準輸出中。持續剖析功能進行CPU熱點採樣時，會同時採集Native（Linux Kernel + JVM + C/C++）以及Java棧，採集Native棧需要對Java中每個線程的perf_event的fd進行MMap，Linux核心中限制了進程perf_event相關的MMap的總記憶體大小（預設516 K Bytes）。當Java中線程數較多時，會觸發限制並在Java標準輸出中列印警告資訊perf_event mmap failed...。出現這個警示資訊，對Java的運行沒有副作用，對業務也沒有影響，實際的影響是火焰圖中看不到Native的棧。一般來說定位CPU熱點問題時，只看Java方法棧就夠了，您可以忽略此警示。

解決方案

如果想消除這個錯誤資訊，可以執行以下步驟：

在宿主機上執行以下命令。
```
echo 1028 > /proc/sys/kernel/perf_event_mlock_kb
```
預設閾值是516，可以逐漸增加，直到不出現警示，該值最好滿足8*N + 4，N是自然數。例如516 = 512 + 4, 1028 = 1024 + 4。
重啟Docker，即可消除錯誤。

其他動作

檢查所在環境JDK是否包含調試符資訊

缺少調試符資訊將會導致記憶體熱點開啟失敗，從而無法採集到記憶體熱點資料。

通過探針相關日誌判斷是否缺少調試符資訊。
在探針安裝目錄下的logs目錄中檢查是否有cpc.log記錄檔（部分老版本探針在logs目錄下，部分版本探針在logs/arms_log目錄下），如果日誌中包含關鍵字No AllocTracer symbols found. Are JDK debug symbols installed? ，則表示缺少調試符。
```
2023-03-08 11:32:00 [continuous Profile collector] [INFO]
Some or all engines success, details below
CPU:true
Alloc:false:No AllocTracer symbols found. Are JDK debug symbols installed?
Wall:true
Other:false
Lock:false
```

通過命令檢查環境是否缺少調試符資訊。

進入JDK安裝路徑。
可通過which java命令或echo$JAVA_HOME找到所在環境的JDK安裝路徑。
在JDK安裝路徑最外層執行以下命令找到libjvm.so檔案所在路徑。
```
find ./ -name "*libjvm.so*"
```

執行以下命令檢查外掛程式是否被剝離調試符，/path/to/需替換成實際路徑。

file /path/to/libjvm.so

如果返回not stripped，表示所在環境JDK包含調試符；如果返回stripped，表示不包含調試符。

[root@iZj6cbirlzrhmgljxdfxw9Z jdk-directory]# cd jdk8u412-b08
[root@iZj6cbirlzrhmgljxdfxw9Z jdk8u412-b08]# ls
ASSEMBLY_EXCEPTION  LICENSE  NOTICE  THIRD_PARTY_README  bin  include  jre  lib  man  release  sample  src.zip
[root@iZj6cbirlzrhmgljxdfxw9Z jdk8u412-b08]# find ./ -name "*libjvm.so*"
./jre/lib/amd64/server/libjvm.so
[root@iZj6cbirlzrhmgljxdfxw9Z jdk8u412-b08]# file ./jre/lib/amd64/server/libjvm.so
./jre/lib/amd64/server/libjvm.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, not stripped

缺少調試符導致記憶體熱點採集失敗的解決辦法

方法一：將JDK升級到JDK 11+

JDK 11+相關實現有調整，不再依賴於調試符資訊。

方法二：更換基礎鏡像

可以在Dockerhub中，通過 openjdk 關鍵字選擇一些著名的JDK發行版（如eclipse-temurin、ibm-semeru-runtimes、amazoncorretto等），然後在其中搜尋未基於 Alpine Linux 構建的JDK鏡像（如果自身有常用的JDK鏡像庫，也可以在庫中自行尋找替換），一般 Alpine Linux 構建的JDK鏡像的 tag 中都有 alpine 相關關鍵字。

例如，eclipse-temurin:8u382-b05-jdk-alpine 鏡像的 tag 中包含 alpine 關鍵字，表示該鏡像基於 Alpine Linux 構建，需要避免使用。

非 Apline Linux 基礎鏡像構建的 JDK 版本樣本：

例如 Docker Hub 上的 eclipse-temurin:8u392-b08-jdk 鏡像，其 tag 中不含 alpine 關鍵字，屬於非 Alpine Linux 基礎鏡像構建的 JDK 版本，支援 linux/amd64、linux/arm/v7、linux/arm64/v8、linux/ppc64le 及 windows/amd64 等多種架構。

如果更換基礎鏡像以後，還是沒有資料，可以查看本地cpc.log記錄檔，檢查其中是否包含No AllocTracer symbols found .Are JDK debug symbols installed?報錯資訊，該資訊表示環境中仍然沒有調試符，請更換其他基礎鏡像或者方法三：使用標準的Alpine Linux和JDK。

方法三：使用標準的Alpine Linux和JDK

使用3.2.8及以上版本的ARMS探針，並在Dockerfile中聲明Alpine Linux和JDK。

from Alpine:3.9
RUN apk add openjdk8