Android日志能力之持久化转储及回传的闭环方案(下)

编程入门 行业动态 更新时间:2024-10-11 01:16:22

Android日志能力之持久化转储及回传的<a href=https://www.elefans.com/category/jswz/34/1759781.html style=闭环方案(下)"/>

Android日志能力之持久化转储及回传的闭环方案(下)

Android日志能力之持久化转储及回传的闭环方案(下)

上帝反馈后

在碰到一些奇奇怪怪的系统问题时,如视频无法播放、网络异常、触摸无响应等等疑难杂症单单靠应用级别的异常信息怕是不能正常分析的,如果没有相应的日志获取能力,那面对用户的应该就是一块板砖,而面对我们的可能就是来自上帝的批判,因此如何在上帝反馈问题后第一时间能够获取到有用的信息并给予用户正向的反馈是及其重要的。

因此,在系统层面设计了一种持久化转储日志信息的三把刀方案:logdump、kdump、xdump。

logdump

logdump最初的设计初衷是为了持久化存储Android log,能够在用户机器出现问题时提供给研发端更多的信息便于分析定位。起初在设计时V1.0版本时只能保存最大两次开机后的日志信息,并且没有增加时间戳区别,回传的日志文件比较不清晰,在进行二次重构时,充分考虑了时间因素,增加了时间戳,能更明显的辨别日志记录的起始位置,由于持久化记录日志会对emmc有损耗,因此,结合公司的物联服务做了下发开关的操作,使得能够进行按需操作:

#!/system/bin/shLOG_PATH="/data/logdump"
LOG_DIR_MAX_COUNT=5if [ ! -d "$LOG_PATH" ]; thenmkdir -p $LOG_PATH
fi# remove files not in correct directory.
REMOVE_FILES=`ls -F $LOG_PATH | grep -v /$`
for r_file in $REMOVE_FILES
dorm -f $LOG_PATH/$r_file
doneCUR_LOG_DIR_COUNT=`ls -F $LOG_PATH | grep /$ | wc -l`if [ "$CUR_LOG_DIR_COUNT" -ge "$LOG_DIR_MAX_COUNT" ]; thenREMOVE_DIR_COUNT=`expr $CUR_LOG_DIR_COUNT - $LOG_DIR_MAX_COUNT + 1`REMOVE_DIRS=`ls -F $LOG_PATH | grep /$ | head -$REMOVE_DIR_COUNT`for r_dir in $REMOVE_DIRSdorm -rf $LOG_PATH/$r_dirdone
fiif [ "$CUR_LOG_DIR_COUNT" -gt "0" ]; thenCOPY_DIR=`ls -F $LOG_PATH | grep /$ | tail -1`cp -rf /sys/fs/pstore/ $LOG_PATH/$COPY_DIR
fiCUR_LOG_DIR_WITH_TIMESTAMP=`date +%Y-%m-%d_%H%M%S`
mkdir -p $LOG_PATH/$CUR_LOG_DIR_WITH_TIMESTAMPlogcat -G 16m
logcat -v threadtime -r8192 -n6 -f $LOG_PATH/$CUR_LOG_DIR_WITH_TIMESTAMP/log.txt &

在boot阶段logcat的服务已经启动并开始记录日志,因此在init.rc配置中增加了如下属性检测,当检测到persist.sys.logdump=true时则启动logdump的service。

service logdump /system/bin/logdumpclass mainuser rootgroup root lodump systemseclabel u:r:logdump:s0oneshoton boot && property:persist.sys.logdump=truestart logdump

而persist.sys.logdump的开关控制则由物联平台进行管理下发,实现了远程按需配置的功能。

kdump

通常在userdebug中获取kernel的日志时都是通过dmesg获取,但是dmesg仅仅只能将目前内核日志缓冲区打印出来,而内核日志缓冲区大小是有限的,往往我们在发现问题时再去获取内核日志时打印的dmesg已经不是现场了,对与内核相关问题的调试成为业务很大痛点。并且userdebug我们还能使用adb进行打印,但是出货的user版本我们根本无法获取现场的内核信息,若出现内核相关问题,只能换机调回来调式,因此非常有必要集成一个持续获取内核日志的工具服务。

采用从init起一个服务的方法,专门用于往/data/kdump/中记录kernel log,最大保存5次开机以来的kernel log,每次存储的日志元数据单文件最大支持20M,采用gzip流压缩方式,将占用空间大小尽可能缩减,避免更多的EMMC占用,采用shell编写了一个覆盖算法将新日志保存,实现旧日志清除。

#!/system/bin/shLOG_ROOT_DIR="/data/kdump"
KMSG_DIR_MAX_COUNT=5
KMSG_FILE_MAX_COUNT=10# Create kmsg root directory if not exist.
if [ ! -f "$LOG_ROOT_DIR" ]; thenmkdir -p $LOG_ROOT_DIR
fi# Remove files which're not in correct directory.
REMOVE_FILES=`ls -F $LOG_ROOT_DIR | grep -v /$`
for r_file in $REMOVE_FILES
dorm -f $LOG_ROOT_DIR/$r_file
done# Remove more than $KMSG_DIR_MAX_COUNT kmsg storage directories.
CUR_LOG_DIR_COUNT=`ls -F $LOG_ROOT_DIR | grep /$ | wc -l`if [ "$CUR_LOG_DIR_COUNT" -ge "$KMSG_DIR_MAX_COUNT" ]; thenREMOVE_DIR_COUNT=`expr $CUR_LOG_DIR_COUNT - $KMSG_DIR_MAX_COUNT + 1`REMOVE_DIRS=`ls -F $LOG_ROOT_DIR | grep /$ | head -$REMOVE_DIR_COUNT`for r_dir in $REMOVE_DIRSdorm -rf $LOG_ROOT_DIR/$r_dirdone
fi# Create new kmsg storage directory with named timestamp.
CUR_LOG_DIR_WITH_TIMESTAMP=`date +%Y-%m-%d_%H%M%S`
mkdir -p $LOG_ROOT_DIR/$CUR_LOG_DIR_WITH_TIMESTAMP
echo "Create $LOG_ROOT_DIR/$CUR_LOG_DIR_WITH_TIMESTAMP"do_kmsg_dump(){while :dofor i in $(seq 1 $KMSG_FILE_MAX_COUNT)dof_index=$(expr $KMSG_FILE_MAX_COUNT - $i)# Move new kmsg to overlay old.if [ -f "$LOG_ROOT_DIR/$CUR_LOG_DIR_WITH_TIMESTAMP/kernel_msg_$(expr $f_index - 1)".gz ]; thenmv $LOG_ROOT_DIR/$CUR_LOG_DIR_WITH_TIMESTAMP/kernel_msg_$(expr $f_index - 1).gz \$LOG_ROOT_DIR/$CUR_LOG_DIR_WITH_TIMESTAMP/kernel_msg_$f_index.gz -ffidone# Save up to 40MB kmsg metadata in every dump file, use gzip to compress it.dd if=/proc/kmsg bs=1k count=40960 | gzip > $LOG_ROOT_DIR/$CUR_LOG_DIR_WITH_TIMESTAMP/kernel_msg_0.gzdone
}do_kmsg_dump

在设置单文件元数据大小时发现dd的流采集大小设置为20M时实际最多采集8MB大小原始kmsg,因此调整数据流大小最大40MB,压缩后的gzip包最大不超过2MB,日志目录保存最大10个文件,单目录最大20MBEMMC损耗,全系统最大20*5=100MBEMMC空间损耗,对用户来说整体空间损耗可忽略不计。

xdump

前两个dump功能是日志转储的话,xdump则是进行日志收集功能,将所有的有用信息进行可选择性的收集及上报操作。

在设计时采用了getopt进行参数解析,使得容错性更强,采用主从分离架构,使得单个脚本能够单独使用,由xdump作为总执行脚本放在/system/xbin/xdump下,其余脚本放在/system/etc/xdumps/script下,分别有:android_base_dump、data_data_dump、kernel_base_dump、android_apk_dump:

xdump v2.00 (2021-08-31) log catcher tool.usage: xdump [COMMAND] [ARGS]-a: dump all logs-b [args]: dump android base logsall : dump all android base logsystem : dump system core info message.media : dump media [video|aduio] info : dump network info.graphic : dump graphic [activity|screen|window] info.log : dump system log [anr|dropbox|logdump] info.-d [args|<package name>]: dump /data/data packages files.all : dump all packages data filesthirdpart : dump all thirdpart packages data filescompany : dump all company packages data files<package name> : dump specific packages data files,each package split with ':'.-k: dump kernel base logs-s [all|<package name>]: dump company apk xlog files.all : dump all packages data files<package name> : dump specific packages data files,each package split with ':'.-P <path>: dump files path.-z : pack xdump files with gzip.-h: show this message.
#!/bin/sh############################################
# @Description: xdump log tool
# @Version: V2.0 2021-08-31
############################################DEFAULT_XDUMP_ROOT_PATH=/sdcard
xdump_log_root_path=$DEFAULT_XDUMP_ROOT_PATHXDUMP_SCRIPT_PATH=/system/etc/xdumps/script
XDUMP_LOG_ROOT_NAME=$(getprop ro.serialno)
XDUMP_PACK_FILE_NAME=`date +%Y-%m-%d_%H%M%S`......#Help
do_help()
{......
}do_start()
{echo "------------------start xdump------------------"start_time=$(date +%s)
}do_finish()
{end_time=$(date +%s)delta_time=$(expr ${end_time} - ${start_time})echo "-----finish xdump. spend: ${delta_time} s------"if [ $XDUMP_PACK_FLAG -eq 1 ]; thenecho "Log file path: $xdump_file_path/${XDUMP_PACK_FILE_NAME}.tgz"elseecho "Log file path: $xdump_file_path/${XDUMP_LOG_ROOT_NAME}"fi
}create_xdump_log_dir()
{xdump_file_path=$xdump_log_root_path/xdumpsecho "create xdump log dir: $xdump_file_path"create_dir_success=`mkdir -p $xdump_file_path 2>&1 > /dev/null ; echo $?`if [ $create_dir_success -ne 0 ]; thenecho "Failed to create $xdump_file_path, please check path."exit 1fi
}parse_android_base_params()
{
......
}parse_data_data_params()
{
......
}parse_android_apk_params()
{
......
}parse_arguments()
{XDUMP_PACK_FLAG=0ALL_DUMP_FLAG=0ANDROID_BASE_DUMP_FLAG=0KERNEL_DUMP_FLAG=0DATA_DUMP_FLAG=0ANDROID_APK_DUMP_FLAG=0if [ $# -le 0 ]; thenALL_DUMP_FLAG=1XDUMP_PACK_FLAG=1returnfiwhile getopts 

更多推荐

Android日志能力之持久化转储及回传的闭环方案(下)

本文发布于:2024-02-07 08:23:20,感谢您对本站的认可!
本文链接:https://www.elefans.com/category/jswz/34/1754982.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
本文标签:闭环   持久   回传   能力   方案

发布评论

评论列表 (有 0 条评论)
草根站长

>www.elefans.com

编程频道|电子爱好者 - 技术资讯及电子产品介绍!