Shell中处理大容量日志：日志轮转与切割的最佳方案

关键在于“切得稳、留得住、不丢日志”，应以logrotate为主管理轮转，辅以自定义脚本处理业务特需动作；配置需含压缩、保留、信号通知等，并配合大小、时间、数量三重保留策略及磁盘监控。

处理大容量日志，关键不是“切得快”，而是“切得稳、留得住、不丢日志”。Shell环境下最可靠的做法是结合 logrotate 工具 与 轻量级自定义脚本 各司其职：logrotate 负责通用轮转逻辑（压缩、保留、归档），脚本负责业务特需动作（如通知服务重开句柄、适配非标准路径或权限）。

优先用 logrotate 管理核心轮转

它不是可选项，而是 Linux 日志管理的事实标准。系统每日通过 /etc/cron.daily/logrotate 自动触发，稳定、低开销、状态可追溯。

• 配置文件放在 /etc/logrotate.d/ 下，例如 /etc/logrotate.d/myapp
• 典型配置示例：

  /var/log/myapp/*.log {    daily    missingok    rotate 30    compress    delaycompress    notifempty    create 0644 root root    sharedscripts    postrotate        /bin/kill -USR1 `cat /var/run/myapp.pid 2>/dev/null` 2>/dev/null || true    endscript}

• postrotate 块里发信号（如 USR1 或 HUP）通知应用重新打开日志，避免重启服务
• 用 logrotate -d /etc/logrotate.d/myapp 先调试，-f 强制执行验证效果

按周或按业务周期切割：用 shell 脚本补位

logrotate 默认不直接支持“按周”或“按业务周期”（如结算日、报表日），这时写一个简单脚本更清晰可控。

• 核心逻辑：用 date +%Y_%V 获取当前年+ISO周数（如 2026_24），判断是否变更
• 只在周初（如周一凌晨）执行一次归档，避免重复操作
• 移动日志后，用 kill -HUP $PID 或 echo > $LOG_FILE 清空句柄（取决于应用是否支持重载）
• 配合 crontab：0 2 * * 1 /opt/scripts/rotate_weekly.sh

持续写入场景下必须处理的细节

日志被进程持续打开时，单纯 mv 不会释放原文件占用空间——旧文件仍被持有，磁盘不会释放。

• 确认应用支持信号重载（Nginx 用 kill -HUP，rsyslog 用 kill -USR1，Java 应用需自行实现）
• 若不支持信号，可用 cp /dev/null $LOG_FILE 清空内容（保持 inode 不变，不中断写入）
• 避免直接 rm 正在写入的日志文件，否则可能丢失数据或引发应用异常

保留策略与空间兜底机制

光切割不够，还要防爆盘。建议组合使用时间 + 大小 + 数量三重控制。

• logrotate 中设 maxsize 100M，当日志超限时立即轮转（适合高流量服务）
• 脚本中用 find /var/log/archive -name "*.log" -mtime +90 -delete 定期清理过期归档
• 加一行监控检查：df -h /var | awk 'NR==2 {print $5}' | sed 's/%//' | [[ $(cat) -gt 85 ]] && echo "WARN: /var usage > 85%" | logger -t logwatch