1. 场景需求
老项目架构一定会输出service_stdout.log系统日志文件, 无法通过logback.xml控制, 并且由于该日志一直不停输出, 导致文件占用无法手动删除. 针对该日志文件, 设定阈值, 监控文件大小, 若超出阈值, 则按固定长度切割文件.
#!/bin/bash
echo "\"split start!\""
# 被监控的文件名
fileName=xxx.file
# 被监控的文件路径
filePath=./${fileName}
# 文件大小上限 150MB -> 150000000
maxLength=1000000000
# 每份按此大小切割
splitLength=999m
# 当前执行时间
current_date=`date -d "-1 day" "+%Y%m%d"`
if [ -e "${filePath}" ]; then
while (true)
do
fileLength=$(ls -l ${filePath} | awk '{print $5}')
echo "\"文件大小 = ${fileLength}\""
if [ "${fileLength}" -gt "${maxLength}" ]; then
echo "\"文件过大, 准备切割...\""
split -b ${splitLength} -d -a 4 ${filePath} ./${fileName}_split-"${current_date}"
echo "\"切割完成, 准备清空原文件...\""
cat /dev/null > ${filePath}
echo "\"清空完成...\""
echo "\"split success!\""
else
echo "\"文件大小正常, 可直接退出脚本...\""
fi
# 3秒轮询监控文件大小
/bin/sleep 3
done
else
echo "\"当前目录下不存在${fileName}, 请将此脚本移至与${fileName}平级后执行\""
echo "\"split failed!\""
fi
2. 脚本逻辑
此脚本必须与被监控文件在同一级目录下(也可自行修改filePath), 若超出阈值, 原文件将按规则被切割成若干份文件, 并且原文件大小清零. 由于没有删除动作, 所以如果原文件一直有读写操作也不会影响, 例如一直滚动的日志文件, 会在清零后继续重新输出.
3. 隐患
如果阈值设置过大, 例如当文件超过10G时按每份1G切割, 脚本执行时间可能过长. 清空原文件的动作是在切割动作完成之后才执行, 那么以日志文件为例, 切割动作执行的时间内, 新增的日志内容可能会在切割后被一起清空导致丢失, 以上为假设场景, 待验证.
4. 优化
脚本可使用crontab定时执行, 解放人工操作, 但需要交接清楚. 针对第三点隐患的解决方案待验证.