Linux PHP-FPM日志切割策略

Linux PHP-FPM日志切割策略

处理PHP-FPM日志，最怕的就是文件无限膨胀，最终把磁盘空间占满。一套自动化的切割、归档和清理策略，是线上环境稳定运行的基本保障。下面就来聊聊几种主流方案和其中的关键细节。

一 推荐方案 logrotate

说到日志轮转，首推系统自带的logrotate。用它来管理PHP-FPM的access.log和error.log，按日或按大小切割、自动压缩、保留指定份数，整个过程稳定可靠，几乎无需人工干预，维护成本极低。

具体操作上，建议在/etc/logrotate.d/目录下创建一个专属配置文件，比如/etc/logrotate.d/php-fpm。配置文件内容可以这样写：

/var/log/php-fpm/*.log {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    create 640 www-data adm
    sharedscripts
    postrotate
        if [ -f /var/run/php-fpm/php-fpm.pid ]; then
            kill -USR1 $(cat /var/run/php-fpm/php-fpm.pid 2>/dev/null) 2>/dev/null || true
        fi
    endscript
}

别看参数不少，其实各有各的用处，理解清楚才能用得顺手：

• 轮转周期：daily、weekly、monthly控制按时间触发；如果想按文件大小控制，可以用size 100M这样的参数。
• 保留策略：rotate 7表示保留最近7份归档日志，更早的会自动删除。
• 压缩处理：compress会对旧日志进行压缩以节省空间。delaycompress通常和它搭配使用，作用是延迟一次压缩，让最新的一份归档保持未压缩状态，方便随时查看。
• 容错与优化：missingok让日志文件不存在时不报错；notifempty则确保空文件不会被轮转，避免产生无用的空归档。
• 权限控制：create 640 www-data adm至关重要，它指定了轮转后新建的日志文件的权限（640）和属主/属组（www-data:adm）。这里务必根据你服务器上PHP-FPM的实际运行用户来调整。
• 信号通知：sharedscripts和postrotate这段是灵魂。所有匹配的日志文件处理完毕后，会执行一次postrotate里的脚本。向PHP-FPM master进程发送USR1信号，是为了通知它重新打开日志文件。如果不做这一步，进程会继续向已被重命名的旧文件句柄里写日志，导致切割失效。

二 手动或脚本切割方案

当然，有些环境可能不方便使用logrotate，或者你需要实现一些更自定义的逻辑。这时候，一个简单的Shell脚本配合cron定时任务，同样能解决问题。

脚本示例：

#!/usr/bin/env bash
set -e

LOG_DIR="/var/log/php-fpm"
DATE=$(date -d "1 day ago" +"%Y%m%d")
cd "$LOG_DIR" || exit 1

[ -f php-fpm.log ] && mv php-fpm.log "php-fpm.log_${DATE}"
[ -f slow.log ] && mv slow.log "slow.log_${DATE}"

# 通知 PHP-FPM 重新打开日志
if [ -f /var/run/php-fpm/php-fpm.pid ]; then
    kill -USR1 "$(cat /var/run/php-fpm/php-fpm.pid 2>/dev/null)" 2>/dev/null || true
fi

脚本写好了，别忘了给它执行权限，并加入到crontab中，比如设定每天零点执行：

0 0 * * * /usr/local/bin/cut_php_fpm_logs.sh

这里有个核心要点需要反复强调：无论是用logrotate还是自定义脚本，在重命名或移动了日志文件之后，都必须通知PHP-FPM master进程重新打开日志文件。发送USR1信号是标准做法，否则你会发现日志“消失”了，其实全写到了被你移走的那个旧文件里。

三 关键注意事项

方案看似简单，但魔鬼藏在细节里。下面这几个坑，提前避开能省不少事。

• 信号选择：大部分实践指南都推荐使用USR1信号来触发日志重开。不过，确实也有少数资料提到USR2。这两个信号在不同版本或发行版的PHP-FPM中可能都有应用。关键不在于信号本身的名字，而在于它是否能正确触发“重新打开日志文件”这个行为。稳妥起见，建议先在测试环境验证你使用的信号是否有效。
• 路径与权限：确保PHP-FPM配置文件（php-fpm.conf或www.conf）中error_log、access.log的路径，与logrotate配置或脚本中操作的路径完全一致。另外，新建日志文件的属主、属组和权限（即create指令设置的参数）必须与PHP-FPM进程的运行用户匹配，否则会导致进程没有权限写入新文件。
• 触发与测试：
  • 手动测试：配置好后，可以执行logrotate -vf /etc/logrotate.d/php-fpm进行强制轮转测试（-f表示强制执行）。
  • 自动执行：logrotate通常由系统通过/etc/cron.daily/logrotate任务每日自动调用，一般无需额外配置cron。
• 压缩策略：合理使用compress和delaycompress选项，能在节省磁盘空间和保持日志可读性之间取得平衡。通常，压缩除最新一份外的所有旧日志，既保证了磁盘空间，又让排查最近问题时无需先解压文件。

四 日志体量优化建议

切割是“治标”，要想从根本上控制日志体量，还得从源头入手做些优化。

• 调整日志级别：在php.ini或PHP-FPM的www.conf中，合理设置error_reporting和log_errors。在生产环境中，可以考虑减少或关闭NOTICE、DEBUG这类信息量巨大但价值相对较低的日志，只记录WARNING和ERROR级别，能显著降低日志输出量。
• 慎用慢日志：慢请求日志（slowlog）是性能排查的利器，但不宜长期开启。建议仅在需要排查问题时临时启用，并务必设置一个合理的request_slowlog_timeout值（比如5秒），避免记录过多“伪慢请求”，导致日志体积激增。
• 定期审计与清理：再好的策略也离不开监控。结合rotate N的保留策略，并设置磁盘空间监控告警，定期审计日志目录的大小，才能万无一失，避免某天被历史日志“偷袭”，占满磁盘。