正文：
在Linux服务器运维中，日志切割是避免单个日志文件过大、保障系统可维护性的关键操作。传统的按时间切割（如daily/weekly）虽常见，但在高并发或关键服务场景下，可能因切割时机不当导致日志丢失或审计断层。本文将聚焦基于服务状态触发切割的高级配置，通过logrotate实现与业务逻辑联动的智能日志管理。

一、为何需要按服务状态切割？

假设Nginx正在处理高并发请求时触发日志切割：
1. 旧日志被重命名（如access.log → access.log.1）
2. 新请求继续写入已重命名的access.log.1（因Nginx持有原文件描述符）
3. 新建的access.log无数据写入，形成“空窗期”
结果：日志分散在两个文件，分析时需合并，增加故障排查复杂度。

二、解决方案核心：切割后通知服务重建日志

通过postrotate脚本向服务发送信号，强制其重新打开日志文件。以Nginx为例：
bash postrotate # 向Nginx主进程发送USR1信号（平滑重启日志文件） [ -e /run/nginx.pid ] && kill -USR1 $(cat /run/nginx.pid) endscript

三、实战配置：Nginx按服务状态切割

创建配置文件/etc/logrotate.d/nginx：
bash

/var/log/nginx/*.log {  
    daily                  # 每天切割  
    missingok              # 日志不存在时不报错  
    rotate 14              # 保留14份历史日志  
    compress               # 启用压缩  
    delaycompress          # 延迟压缩（前一份不压缩）  
    notifempty             # 空文件不切割  
    sharedscripts          # 所有日志切割后执行一次脚本  
    postrotate  
        # 向Nginx主进程发送USR1信号  
        [ -e /run/nginx.pid ] && kill -USR1 $(cat /run/nginx.pid)  
    endscript  
}

关键参数解析：
- delaycompress：确保前一份日志可用时服务能正常写入
- sharedscripts：避免多个日志文件重复触发信号

四、MySQL：服务重启时自动切割日志

对于数据库类服务，通常需在服务停止后切割日志，避免数据损坏：
bash

/var/log/mysql/mysql.log {  
    monthly                # 每月切割  
    rotate 6  
    compress  
    nodelaycompress       # 立即压缩  
    create 640 mysql adm   # 切割后新建文件并设置权限  
    postrotate  
        # 仅在MySQL运行时重新加载日志  
        if systemctl is-active --quiet mysql; then  
            mysql -e "FLUSH ENGINE LOGS;"  
        fi  
    endscript  
}

五、调试与验证技巧

1. 手动测试配置：
   bash logrotate -d /etc/logrotate.d/nginx # 调试模式（不执行） logrotate -f /etc/logrotate.d/nginx # 强制立即切割
2. 观察日志行为：
   bash lsof -p $(cat /run/nginx.pid) | grep log # 查看Nginx打开的文件描述符

六、进阶场景：按日志大小+服务状态双触发

若需兼顾大小与状态，可组合配置：
bash size 100M # 超过100MB时触发 daily # 每天至少检查一次 olddir /archive # 历史日志存独立目录 copytruncate # 替代创建新文件（部分服务兼容性更好）

注意：copytruncate会复制内容后清空原文件，可能丢失切割瞬间的数据，非高可靠场景慎用。

七、避坑指南

1. 权限问题：确保logrotate进程有权限读取日志和发送信号（通常需加入adm组）
2. 信号冲突：避免使用kill -9（SIGKILL）等可能中断服务的信号
3. 路径陷阱：PID文件路径需与实际匹配（如Systemd服务默认在/run下）

通过将日志切割与服务状态深度绑定，不仅解决了“切割空窗期”问题，更为日志分析、合规审计构建了连贯的数据基础。这种设计模式尤其适用于金融、电商等对日志完整性要求严苛的场景。