常见问题

1. 检查相关配置是否正确，设置的网段是否包含了应用实例对应的IP地址。

2. 若使用了3.1.4之前版本的探针，由于Alpine基础镜像的兼容性问题可能导致剖析引擎失效（该问题在3.1.4版本中已修复）。为确保功能稳定性及数据完整性，建议升级探针至3.1.4及以上版本探针。

   说明

   验证是否使用了Apline Linux基础镜像的操作，请参见验证是否使用了Apline Linux基础镜像。

3. 持续剖析基于开源Async Profiler增强后对应用进行数据采集，当前暂不支持多Async Profiler同时挂载。如果应用同时使用了Pyroscope探针提供的持续剖析功能可能会出现启动失败。

4. 将持续剖析页面的查询时间向后调整8小时，查看是否存在数据，如果有数据，可能是应用所在时区为0时区，所以数据写入时间比东八区（UTC+8）晚了8小时。

   解决方案：为应用添加环境变量将时区调整到UTC+8。

   说明

   建议先在持续剖析页面使用当前Pod的名称进行过滤，避免因过去8小时容器重启过多，导致看错信息。

   Key：JAVA_TOOL_OPTIONS，Value：-Duser.timezone=GMT+8

   该问题已经在 4.1.10 版本修复，如果确认是该问题，您也可以直接升级探针至4.1.10及以上版本。

5. 应用自身是否有挂载其他Async Profiler动态库，检查方式如下：

   1. 执行以下命令，其中[pid]需换成业务进程的pid信息。

      lsof -p [pid] | grep libasync

   2. 如果结果中有类似如下非阿里云的动态库，则是应用自身使用了Async Profiler动态库导致跟ARMS不兼容，此时需要移除自身动态库后才可以继续使用ARMS相关功能。

      /home/admin/xxx/.default/temp/libasyncProfiler1309163652530490111.so

问题现象

如下图所示火焰图中出现other项。

问题原因

火焰图中出现other项是正常的。火焰图是一棵树，当节点数较多时不便于从图中提取关键信息，因此ARMS通过一些方法对火焰图中的节点进行收敛，将一些重要性相对较低的节点并入到other项中。

该日志是ARMS探针打印的无用日志，仅在开启持续剖析功能后才会打印，对应用运行过程无影响，另外ARMS会在将来的新版本中关闭相关日志打印。

问题现象

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。

  如需配置更精细化的系统调用控制，请参见官方文档。

解决方案

如果Java进程运行在容器环境，出现以上报错或者该功能无数据，一般都是由于使用了Alpine基础镜像导致，Alpine基础镜像为了控制体积而去除了JDK调试符号（debug symbols），影响持续剖析能力正常使用，建议在基础镜像中为JDK安装调试符（部分JDK版本缺乏对应的调试符包，会导致无法安装）或使用非Alpine基础镜像。

如果是CentOS物理机环境部署应用可通过以下步骤安装调试符：

1. 执行以下命令，确认是否已经配置了debuginfo的源。

   yum repolist all | grep -i debug

   通过返回信息确认源配置信息是否如下：

   debuginfo/7/x86_64 CentOS-7 - debuginfo - mirrors.aliyun.com 启用: 8,760

   如果未配置debuginfo的源，则执行步骤2增加配置；如果已经配置，则执行步骤3。

2. 在Yum配置文件中增加debuginfo的配置。

   vi /etc/yum.repos.d/CentOS-Base.repo
   [debuginfo]
   name=CentOS-$releasever - debuginfo - mirrors.aliyun.com
   failovermethod=priority
   baseurl=http://mirrors.aliyun.com/centos-debuginfo/$releasever/$basearch/
   gpgcheck=1
   enabled=1
   gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-Debug-7

   保存后执行如下命令：

   yum clean all
   yum makecache
   yum-config-manager --enable debuginfo

3. 安装JDK版本对应的符号信息。

   JDK 8

   yum list installed|grep openjdk    #查询JDK版本。
   java-1.8.0-openjdk.x86_64          1:1.8.0.332.b09-1.el7_9            @updates
   
   debuginfo-install -y java-1.8.0-openjdk      #安装符号信息。

   JDK 11

   yum list installed|grep openjdk    #查询JDK版本。
   java-11-openjdk.x86_64             1:11.0.15.0.9-2.el7_9              @updates
   
   debuginfo-install -y java-11-openjdk      #安装符号信息。

4. 检查JDK的符号信息是否已经安装成功。

   gdb $JAVA_HOME/lib/server/libjvm.so -ex 'info address UseG1GC'
   gdb /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.332.b09-1.el7_9.x86_64/jre/lib/amd64/server/libjvm.so -ex 'info address UseG1GC'
   GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
   Copyright (C) 2013 Free Software Foundation, Inc.
   License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
   This is free software: you are free to change and redistribute it.
   There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
   and "show warranty" for details.
   This GDB was configured as "x86_64-redhat-linux-gnu".
   For bug reporting instructions, please see:
   <http://www.gnu.org/software/gdb/bugs/>...
   Reading symbols from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.332.b09-1.el7_9.x86_64/jre/lib/amd64/server/libjvm.so...Reading symbols from /usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.332.b09-1.el7_9.x86_64/jre/lib/amd64/server/libjvm.so.debug...done.
   done.

   如果安装正确，返回信息如下：

   Symbol "UseG1GC" is static storage at address 0x107f993.

   如果安装失败，返回信息如下：

   No symbol "UseG1GC" in current context.

问题现象

此错误一般出现在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方法栈就够了，您可以忽略此告警。

解决方案

如果想消除这个错误信息，可以执行以下步骤：

1. 在宿主机上执行以下命令。

   echo 1028 > /proc/sys/kernel/perf_event_mlock_kb

   默认阈值是516，可以逐渐增加，直到不出现告警，该值最好满足8*N + 4，N是自然数。例如516 = 512 + 4, 1028 = 1024 + 4。

2. 重启Docker，即可消除错误。

更换基础镜像

可以在Dockerhub中，通过 openjdk 关键字选择一些著名的JDK发行版（如eclipse-temurin、ibm-semeru-runtimes、amazoncorretto等），然后在其中搜索未基于 Alpine Linux 构建的JDK镜像（如果自身有常用的JDK镜像库，也可以在库中自行查找替换），一般 Alpine Linux 构建的JDK镜像的 tag 中都有 alpine 相关关键字。

非 Apline Linux 基础镜像构建的 JDK 版本示例：

如果更换基础镜像以后，还是没有数据，可以查看本地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