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

2023-11-23 01:59

本文主要是介绍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.net : 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日志能力之持久化转储及回传的闭环方案(下)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/414501

相关文章

Spring Boot集成/输出/日志级别控制/持久化开发实践

《SpringBoot集成/输出/日志级别控制/持久化开发实践》SpringBoot默认集成Logback,支持灵活日志级别配置(INFO/DEBUG等),输出包含时间戳、级别、类名等信息,并可通过... 目录一、日志概述1.1、Spring Boot日志简介1.2、日志框架与默认配置1.3、日志的核心作用

Redis客户端连接机制的实现方案

《Redis客户端连接机制的实现方案》本文主要介绍了Redis客户端连接机制的实现方案,包括事件驱动模型、非阻塞I/O处理、连接池应用及配置优化,具有一定的参考价值,感兴趣的可以了解一下... 目录1. Redis连接模型概述2. 连接建立过程详解2.1 连php接初始化流程2.2 关键配置参数3. 最大连

Android Paging 分页加载库使用实践

《AndroidPaging分页加载库使用实践》AndroidPaging库是Jetpack组件的一部分,它提供了一套完整的解决方案来处理大型数据集的分页加载,本文将深入探讨Paging库... 目录前言一、Paging 库概述二、Paging 3 核心组件1. PagingSource2. Pager3.

深度解析Nginx日志分析与499状态码问题解决

《深度解析Nginx日志分析与499状态码问题解决》在Web服务器运维和性能优化过程中,Nginx日志是排查问题的重要依据,本文将围绕Nginx日志分析、499状态码的成因、排查方法及解决方案展开讨论... 目录前言1. Nginx日志基础1.1 Nginx日志存放位置1.2 Nginx日志格式2. 499

Java堆转储文件之1.6G大文件处理完整指南

《Java堆转储文件之1.6G大文件处理完整指南》堆转储文件是优化、分析内存消耗的重要工具,:本文主要介绍Java堆转储文件之1.6G大文件处理的相关资料,文中通过代码介绍的非常详细,需要的朋友可... 目录前言文件为什么这么大?如何处理这个文件?分析文件内容(推荐)删除文件(如果不需要)查看错误来源如何避

使用Python构建一个高效的日志处理系统

《使用Python构建一个高效的日志处理系统》这篇文章主要为大家详细讲解了如何使用Python开发一个专业的日志分析工具,能够自动化处理、分析和可视化各类日志文件,大幅提升运维效率,需要的可以了解下... 目录环境准备工具功能概述完整代码实现代码深度解析1. 类设计与初始化2. 日志解析核心逻辑3. 文件处

MySQL 迁移至 Doris 最佳实践方案(最新整理)

《MySQL迁移至Doris最佳实践方案(最新整理)》本文将深入剖析三种经过实践验证的MySQL迁移至Doris的最佳方案,涵盖全量迁移、增量同步、混合迁移以及基于CDC(ChangeData... 目录一、China编程JDBC Catalog 联邦查询方案(适合跨库实时查询)1. 方案概述2. 环境要求3.

SpringBoot3.X 整合 MinIO 存储原生方案

《SpringBoot3.X整合MinIO存储原生方案》本文详细介绍了SpringBoot3.X整合MinIO的原生方案,从环境搭建到核心功能实现,涵盖了文件上传、下载、删除等常用操作,并补充了... 目录SpringBoot3.X整合MinIO存储原生方案:从环境搭建到实战开发一、前言:为什么选择MinI

Android kotlin中 Channel 和 Flow 的区别和选择使用场景分析

《Androidkotlin中Channel和Flow的区别和选择使用场景分析》Kotlin协程中,Flow是冷数据流,按需触发,适合响应式数据处理;Channel是热数据流,持续发送,支持... 目录一、基本概念界定FlowChannel二、核心特性对比数据生产触发条件生产与消费的关系背压处理机制生命周期

Android ClassLoader加载机制详解

《AndroidClassLoader加载机制详解》Android的ClassLoader负责加载.dex文件,基于双亲委派模型,支持热修复和插件化,需注意类冲突、内存泄漏和兼容性问题,本文给大家介... 目录一、ClassLoader概述1.1 类加载的基本概念1.2 android与Java Class