腾讯云可观测平台附件

附件是以文件形式提供的异常现场数据，包含了两种类型的数据：平台默认采集的数据和业务自定义采集的数据。
功能简介
在平台的个例详情中，附件 Tab 展示当前异常个例所有的附件，用户单击即可在线查看附件内容。用户也可以通过单击打包下载，下载当前个例的所有附件。
﻿
批量导出
支持批量导出个例附件的功能。单击左侧的下载图标 > 导出附件，选择需下载的附件，然后单击确定，如下图所示：
﻿
搜索附件
用户可以通过附件的筛选项，搜索出包含指定附件的个例。当选择多个附件时，表示或关系，过滤出包含以下附件中任意一种附件的异常个例。
﻿
上传自定义附件
Android
iOS
业务可以通过 SDK 开放的自定义附件上传接口，以附件的形式，补充更多业务现场。
Android SDK 4.3.0.3 版本开始支持自定义附件。
使用该接口需要同时初始化 SDK 性能和 SDK 质量模块，详细请参见 SDK 接入指引。
自定义文件压缩之后的大小限制为10 MB。如果超过该大小，会直接删除，不会上传。
该接口可以调用多次，之后的调用会覆盖前面设置的值。
CrashReport.setAdditionalAttachmentPaths(String[] files);  
自定义文件都在二次启动的时候才会上传。
SDK 默认禁止该功能，开启需要在 Portal 端新添加如下配置。
﻿
第二次启动之后可以通过 “sub_type: custom_log” 关键字日志来确认是否有自定义文件上传。
12-07 20:42:26.673 15758 15862 I RMonitor_report_File: url: https://rmonitor.qq.com/v1/2ff6123857/custom/upload-file?sign=22efd184a95c12d7faaecb8e8edc3266&timestamp=1670416946671&nonce=ee48217de804345e1634d0adf58e8825, sub_type: custom_log
iOS SDK 2.7.51版本开始支持自定义附件。
参考以下代码设置自定义附件的路径，在异常发生后，会在相应目录下，打包附件上传。
/**
 * 设置自定义文件的决定路径的集合。
 * 文件压缩后的大小不大于10M，二次启动时上报。
 */
+ (void)setAdditionalAttachmentPaths:(NSArray<NSString *>*)pathArray;
﻿
使用示例：
[RumPro setAdditionalAttachmentPaths:[NSArray arrayWithObject:filePath]];
自定义文件都在二次启动的时候才会上传。
SDK 默认禁止该功能，开启需要在 Portal 端新添加如下配置。
在崩溃发生时调用此接口无法生效，因此需要业务提前设置路径。
如果在当前配置中没有看到自定义文件这一项，单击最后一个配置项的最右边的加号 icon ，添加自定义文件的配置项。
﻿
Android
以下内容主要介绍 Android 上报个例详情中附件 Tab 中每个文件记录的信息以及各个信息的含义。
附件概述
分类/Tab
来源
出错堆栈
来自 crash 详情接口，导出在附件「crash.log」
tombstone
来自附件 tomb.zip
现场数据/基础信息
来自 crash 详情接口，导出在附件「detail_data.JSON」
现场数据/自定义字段
来自附件 valueMapOthers.txt
现场数据/页面跟踪
来自附件 martianlog.txt
日志
来自附件 log.txt
FD 信息
来自附件 crashInfos.txt
进程信息
来自附件 state_file.zip
通过回调接口 getCrashExtraData 补充的信息
来自附件 extraMessage.txt
通过回调接口 getCrashExtraMessage 补充的信息
导出在附件「user_datas.log」中
通过 CrashReport.putUserData 和 setUserSceneTag 设置的内容
导出在附件「valueMapOthers.txt」中
ANR_INFO
来自附件 anrMessage.txt
ANR_Trace
来自附件 trace.zip
crash.log
存放出错堆栈信息，包含当前异常线程的堆栈，以及其他线程的堆栈，跟出错堆栈 Tab 展示的内容一致。
﻿
为什么崩溃的线程有两个堆栈，而且前面的进程号还不一样？
1. 对于 Native 异常，捕获异常堆栈是同时捕获 Native 堆栈和 Java 堆栈，而且是在 Native 层进行捕获，获取的是 Native 层的进程号。
2. 其他线程的堆栈作为附加信息，是在 Java 层处理的，获取的是 JVM 堆栈，进程号也是 JVM 中描述的进程号。
3. 当前其他线程堆栈其实是包含异常发生时，当前应用所有的 JVM 线程堆栈，也可能包含当前崩溃的线程，但是没有包含 Native 层创建的线程。
tomb.zip
对应系统的「tombstone」文件，在应用程序或系统进程崩溃时生成。这个文件包含了崩溃时的一些关键信息，如堆栈跟踪、内存映射、寄存器状态等。这个文件是平台参考系统的「tombstone」文件格式而生成的。
tombstone 包含以下几部分信息：
异常摘要
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Crash type: 'Native'
Start time: '2023-12-22T15:55:39.381+0800'
Crash time: '2023-12-22T15:58:30.119+0800'
App version: '4.4.0-beta.3'RumPro
Rooted: 'No'
API level: '30'
Build fingerprint: 'vivo/PD1824/PD1824:11/RP1A.200720.012/compiler03061748:user/release-keys'
ABI: 'arm64'
pid: 26730, tid: 26730, name: .example.sdkapp  >>> com.example.sdkapp <<<
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: 'JNI DETECTED ERROR IN AppLICATION: jarray was NULL     in call to GetObjectArrayElement     from void com.tencent.RumPro.crashreport.crash.jni.NativeCrashHandler.testCrash()'
寄存器信息
    x0  0000000000000000  x1  000000000000686a  x2  0000000000000006  x3  0000007fdab30cc0
    x4  00000077f497b000  x5  00000077f497b000  x6  00000077f497b000  x7  000000000042906e
    x8  00000000000000f0  x9  b8ae21afa5964f35  x10 0000000000000000  x11 ffffffc0fffffbdf
    x12 0000000000000001  x13 00000000658541a6  x14 0005e9acbf980fa7  x15 000077c18d549120
    x16 00000077f138b948  x17 00000077f1368630  x18 00000077f3d3a000  x19 000000000000686a
    x20 000000000000686a  x21 00000000ffffffff  x22 000000000000000b  x23 000000000000000b
    x24 000000776caa41c5  x25 0000000000000001  x26 000000776cabb177  x27 000000776d072000
    x28 b4000077f3452340  x29 0000007fdab30d40
    sp  0000007fdab30ca0  lr  00000077f1317d24  pc  00000077f1317d50
异常堆栈
backtrace:
    #00 pc 000000000008cd50  /apex/com.android.runtime/lib64/bionic/libc.SO (abort+164)
    #01 pc 00000000005320a0  /apex/com.android.art/lib64/libart.SO (_ZN3art7Runtime5AbortEPKc+2340)
    #02 pc 000000000001394c  /system/lib64/libbase.SO (_ZZN7android4base10SetAborterEONSt3__18functionIFvPKcEEEEN3$_38__invokeES4_+76)
    #03 pc 00000000000130cc  /system/lib64/libbase.SO (_ZN7android4base10LogMessageD1Ev+312)
    #04 pc 0000000000369b00  /apex/com.android.art/lib64/libart.SO (_ZN3art9JavaVMExt8JniAbortEPKcS2_+2596)
    #05 pc 0000000000369b78  /apex/com.android.art/lib64/libart.SO (_ZN3art9JavaVMExt9JniAbortVEPKcS2_St9__va_list+108)
    #06 pc 000000000035b7c4  /apex/com.android.art/lib64/libart.SO (_ZN3art12_GLOBAL__N_111ScopedCheck6AbortFEPKcz+144)
    ...
    #81 pc 0000000000088188  /apex/com.android.runtime/lib64/bionic/libc.SO (__libc_init+108)
Build ID
Build ID 是一个在编译过程中生成的唯一标识符，用于标识特定的二进制文件。Build ID 的主要用途是在调试过程中，帮助开发者确定正在运行的二进制文件的确切版本。在 Linux 系统中，Build ID 通常是通过编译器或链接器在编译过程中生成的，它通常是源代码、编译选项等信息的哈希值。如果两个 ELF 文件具有相同的 Build ID，则它们是相同版本的库。
build id:
    /apex/com.android.runtime/lib64/bionic/libc.SO (BuildId: 4995223f2954ed2746d96c2f1c7939a1. FileSize: 1314184. LastModified: 2009-01-01T08:00:00.000+0800. MD5: 0eabd0f3735afdc6317062180a4369ec)
    ...
    /system/bin/app_process64 (BuildId: c8e30518cdd6709068b3a08e6bfe4a76. FileSize: 33832. LastModified: 2009-01-01T08:00:00.000+0800. MD5: 68ed3a8e223ff95392828c5b5dd451f3)
在 Mac 中，可以直接通过 readelf 工具读取一个 SO 的 Build ID。
> readelf -n libNative.SO 
﻿
Displaying notes found in: .note.gnu.build-id
  Owner                Data size    Description
  GNU                  0x00000014   NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: dae1f4c9f93715c9de15c86161a1af37b5cce24a
栈内存
stack:
         0000007fdab30c20  00000077f3814000  [anon:stack_and_tls:main]
         0000007fdab30c28  0000000000000002
         0000007fdab30c30  0000007fdab30d58  [stack]
         0000007fdab30c38  0000000000000000
         0000007fdab30c40  000000776cac3c9e  /apex/com.android.art/lib64/libart.SO
         0000007fdab30c48  00000077f12d0c84  /apex/com.android.runtime/lib64/bionic/libc.SO (malloc+44)
         0000007fdab30c50  00000076f4d262c0  [anon:libc_malloc]
         0000007fdab30c58  b8ae21afa5964f35
         0000007fdab30c60  0000007fdab30d40  [stack]
         0000007fdab30c68  00000077f1317ce8  /apex/com.android.runtime/lib64/bionic/libc.SO (abort+60)
         0000007fdab30c70  000000000000000b
         0000007fdab30c78  000000776cac3c9e  /apex/com.android.art/lib64/libart.SO
         0000007fdab30c80  000000000000000b
         0000007fdab30c88  00000076fd2b9a00  [anon:libc_malloc]
         0000007fdab30c90  00000077f4a797f0  [anon:.bss]
         0000007fdab30c98  00000076f4c6e080  [anon:libc_malloc]
    #00  0000007fdab30ca0  0000000000000001
    ...
    ........  ........
    #81  0000007fdab35f80  0000007fdab35fd0  [stack]
         0000007fdab35f88  0000005e8de33048  /system/bin/app_process64 (main)
         0000007fdab35f90  0000000000000000
         0000007fdab35f98  0000000000000000
         0000007fdab35fa0  0000000000000000
         0000007fdab35fa8  0000000000000000
         0000007fdab35fb0  0000000000000000
         0000007fdab35fb8  0000005e8de37000  /system/bin/app_process64
         0000007fdab35fc0  0000005e8de37010  /system/bin/app_process64
         0000007fdab35fc8  0000005e8de37028  /system/bin/app_process64
         0000007fdab35fd0  0000000000000000
         0000007fdab35fd8  00000077f49caa68  /apex/com.android.runtime/bin/linker64 (__dl__start+8)
         0000007fdab35fe0  0000000000000006
         0000007fdab35fe8  0000007fdab36290  [stack]
         0000007fdab35ff0  0000007fdab362aa  [stack]
         0000007fdab35ff8  0000007fdab362b3  [stack]
通用寄存器附近的内存和内存信息。
detail_data.JSON
基础数据以及页面跟踪是 SDK 在异常时自动捕获的现场信息，其中基础数据导出在附件「detail_data.JSON」中。
自定义字段中展示的「App 渠道」，来自「detail_data.JSON」的 "appInfo" 。
﻿
valueMapOthers.txt
自定义字段是指业务通过 CrashReport.putUserData 接口设置的 Key/Value , 相关内容导出在附件「valueMapOthers.txt」中。
通过 CrashReport.setUserSceneTag 接口设置的 Tag ，相关内容导出在附件「valueMapOthers.txt」中。
自定义字段中展示的「App 渠道」，来自「detail_data.JSON」的 "appInfo" 。
现场数据的自定义字段部分展示的内容跟附件「valueMapOthers.txt」是一致的。
martianlog.txt
异常发生前一段时间的页面跟踪数据，由 SDK 自动记录。
这部分数据同时展示在现场数据 > 页面跟踪部分。
log.txt
异常现场的日志 Tab 中展示的系统日志，对应附件的「log.txt」。
﻿
crashInfos.txt
异常现场的 FD Tab 中展示的 FD 信息，来自附件「crashInfos.txt」。
除此之外，附件「crashInfos.txt」还包含 System SO info，信息来自「/proc/$pid/maps」文件。
System SO infos:
  707dd000-70a50000 r-xp 00080000 fc:00 171                                /apex/com.android.art/Javalib/arm64/boot.oat
  70a65000-70ab7000 r-xp 00010000 fc:00 165                                /apex/com.android.art/Javalib/arm64/boot-core-libart.oat
  ...
以第一行举例，这些信息描述了 SO 文件在内存中的位置、访问权限以及在磁盘上的偏移量等相关信息。
"707dd000-70a50000"：这是文件在内存中的地址范围。它表示文件被映射到内存的起始地址是0x707dd000，结束地址是0x70a50000。
"r-xp"：这是文件在内存中的访问权限。其中，"r"表示可读，"x"表示可执行，"p"表示私有。
"00080000"：这是文件在磁盘上的偏移量，表示文件在磁盘中的起始位置距离文件开头的偏移量是0x00080000。
"fc:00"：这是文件的设备号和 inode 号，用于唯一标识文件。
"171"：这是文件的文件描述符，用于在操作系统中标识文件。
tomb.zip 中的 stack 也是根据这些信息，标识出一些地址对应的 SO 文件。
﻿
state_file.zip
异常详情中，进程信息来自附件「state_file.zip」中。
Maps 信息来自「/proc/$pid/maps」文件。
Meminfo 信息表示了用户进程的内存使用情况，可以查看应用当前内存主要被如何分配。
进程状态和线程状态分别表示当前运行进程及其中各线程的状态指标。
﻿
user_datas.log
通过回调接口 getCrashExtraMessage 补充的信息导出在附件「user_datas.log」中。
extraMessage.txt
通过回调接口 getCrashExtraData 补充的信息导出在附件「extraMessage.txt」中。
anrMessage.txt
「anrMessage.txt」的信息展示在「ANR_INFO」中。
ANR_INFO 信息是应用程序在 ANR 发生时生成的一项系统报告，记录了 ANR 发生时所在的 Activity 组件，发生 ANR 的进程 ID，以及发生 ANR 的原因。
其中，Load 表示 ANR 发生时系统在1分钟、5分钟和15分钟的平均负载情况，平均负载的单位是进程数，代表在 ANR 发生时系统中正在运行或等待 CPU资源的进程数的平均值。CPU Usage 代表在 ANR 发生的时间范围内 CPU 的详细占用情况，根据这些信息可以辅助进行 ANR 问题的分析。
﻿
trace.zip
「trace.zip」的信息展示在「ANR Trace」中。
ANR Trace 是一个包含应用程序在 ANR 期间发生的事件和线程堆栈跟踪的日志文件。
第一部分是 ANR 时间和 GC 信息，可以了解当前 ANR 问题发生了多长时间，系统进行了哪些 GC 操作。
第二部分是线程堆栈信息，列出了所有在 ANR 期间运行线程的堆栈跟踪信息。除每个线程除堆栈信息外，还包含线程 ID（tid）、线程优先级（prio）、线程状态（state）、线程调度统计信息（schedstat）、线程使用的CPU时间（utm和stm）等线程的状态信息。结合上述信息，尤其是线程的堆栈跟踪信息，可以快速帮助定位分析造成 ANR 问题的原因。
﻿
iOS
以下内容主要介绍 iOS 上报个例详情中附件 Tab 中每个文件记录的信息以及各个信息的含义。
附件概述
iOS 平台暂不支持日志。
分类/Tab
来源
出错堆栈
来自crash详情接口，导出在附件「crash.log」
现场数据/基础信息
来自crash详情接口，导出在附件「detail_data.JSON」
现场数据/自定义字段
来自附件valueMapOthers.txt
现场数据/页面跟踪
来自附件martianlog.txt
通过接口「setUserValue」补充的信息
导出在附件「user_datas.log」中
通过回调接口「attachmentForException」补充的信息
导出在附件「crash_attach.log」中
内存信息
附件「meminfo.txt」
crash.log
存放出错堆栈信息，包含当前异常线程的堆栈，以及其他线程的堆栈，跟出错堆栈 Tab 展示的内容一致。
不同线程的堆栈通过空行分隔，首行是线程号以及线程名。
包含当前异常线程的寄存器信息。
包含所有模块的信息。
﻿
detail_data.JSON
基础数据以及页面跟踪是 SDK 在异常时自动捕获的现场信息，其中基础数据导出在附件「detail_data.JSON」中。
自定义字段中展示的「App 渠道」，来自「detail_data.JSON」的"appInfo"。
﻿
valueMapOthers.txt
包含业务通过接口 SetUserValue 设置的内容。
现场数据的自定义字段部分展示的内容跟附件「valueMapOthers.txt」是一致的。
﻿
martianlog.txt
异常发生前一段时间的页面跟踪数据，由 SDK 自动记录。
这部分数据同时展示在现场数据 > 页面跟踪部分。
﻿
user_datas.log
包含业务通过接口 SetUserValue 设置的内容。
现场数据的自定义字段部分展示的内容跟附件「user_datas.log」是一致的。
crash_attach.log
业务通过回调接口 attachmentForException 设置的内容。
meminfo.txt
异常时的内存概述信息。
﻿
分类/Tab	来源
出错堆栈	来自 crash 详情接口，导出在附件「crash.log」
tombstone	来自附件 tomb.zip
现场数据/基础信息	来自 crash 详情接口，导出在附件「detail_data.JSON」
现场数据/自定义字段	来自附件 valueMapOthers.txt
现场数据/页面跟踪	来自附件 martianlog.txt
日志	来自附件 log.txt
FD 信息	来自附件 crashInfos.txt
进程信息	来自附件 state_file.zip
通过回调接口 getCrashExtraData 补充的信息	来自附件 extraMessage.txt
通过回调接口 getCrashExtraMessage 补充的信息	导出在附件「user_datas.log」中
通过 CrashReport.putUserData 和 setUserSceneTag 设置的内容	导出在附件「valueMapOthers.txt」中
ANR_INFO	来自附件 anrMessage.txt
ANR_Trace	来自附件 trace.zip
附件

本页目录：

功能简介

批量导出

搜索附件

上传自定义附件

Android

附件概述

crash.log

tomb.zip

detail_data.JSON

valueMapOthers.txt

martianlog.txt

log.txt

crashInfos.txt

state_file.zip

user_datas.log

extraMessage.txt

anrMessage.txt

trace.zip

iOS

附件概述

crash.log

detail_data.JSON

valueMapOthers.txt

martianlog.txt

user_datas.log

crash_attach.log

meminfo.txt
