Ubuntu PHP日志轮转机制是什么

Ubuntu PHP日志轮转机制

在Ubuntu系统中，PHP日志的轮转管理，其实是由一个“幕后管家”统一负责的。这个管家就是系统自带的logrotate工具。换句话说，PHP本身并不负责切割和归档日志，而是将这项工作全权交给了系统机制。无论是PHP-FPM的运行日志，还是php.ini中error_log指定的错误日志，它们的“生老病死”都遵循着logrotate制定的规则。

这套机制的核心流程很清晰：按日（或者按文件大小）自动切割当前日志，将旧日志压缩归档，并清理掉过期的历史文件。最关键的一步在于，它还会通过信号或命令通知PHP相关进程：“嘿，日志文件换新的了，请重新打开文件句柄。” 这就确保了日志写入总能指向正确的、最新的文件，避免了进程持续向一个已被重命名或压缩的旧文件句柄里“灌”数据。

核心机制

简单总结一下：在 Ubuntu 上，PHP 的日志轮转通常由系统自带的 logrotate 统一管理，而不是 PHP 内核自带的功能。PHP-FPM 和业务应用常见日志路径包括 /var/log/php-fpm/*.log 以及 php.ini 中 error_log 指定的文件。logrotate 按日（或按大小）切割日志、压缩归档、删除过期文件，并通过通知机制让进程重新打开日志文件，避免继续写入旧文件句柄。

触发与执行方式

那么，这个“管家”什么时候工作，我们又该如何手动干预呢？

• 定时触发：这是默认且最主要的方式。系统通过 /etc/cron.daily/logrotate 这个每日任务，由 cron 定时调用执行。这意味着你无需单独启动任何服务，轮转是自动在后台进行的。当然，你也可以随时按需手动执行。
• 手动触发与调试：在调整配置或排查问题时，手动操作就派上用场了。
  • 语法检查与模拟运行：执行 sudo logrotate -d /etc/logrotate.conf。这个-d（debug）参数非常有用，它能让你预先看到轮转会做什么，但不会实际执行，是检查配置语法和匹配规则是否正确的首选步骤。
  • 强制执行一次：当你确认配置无误后，可以运行 sudo logrotate -f /etc/logrotate.d/php-fpm（以具体配置文件为例）。这个-f（force）参数会立即触发一次轮转，让你验证整个流程——包括切割、压缩、通知进程——是否都按预期工作。

典型配置示例

光说不练假把式，来看两个典型的配置例子，它们通常位于/etc/logrotate.d/目录下。

首先是针对PHP-FPM日志的配置（文件：/etc/logrotate.d/php-fpm）：

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

其次是针对独立PHP错误日志的配置（文件：/etc/logrotate.d/php-errors）：

/var/log/php_errors.log {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
}

这两个配置对比，能看出一个关键区别：进程通知。FPM的配置里包含了postrotate脚本，通过向主进程发送USR2信号，通知其重新打开日志文件。而第二个配置没有这个脚本，通常意味着对应的日志文件由其他方式管理，或者进程本身支持基于文件的重新打开。话说回来，如果PHP是作为Apache模块运行的，那么在postrotate里，你可能需要执行的是invoke-rc.d apache2 reload或类似的命令来触发Apache重载，从而达到相同目的。

关键参数与动作

理解了示例，我们来拆解一下这些配置指令的具体含义，它们正是实现精细化控制的关键。

• 常用指令
  • daily/weekly/monthly：轮转的时间频率，按天、周或月执行。
  • rotate N：指定保留多少个归档后的历史日志文件，超出的会被删除。
  • compress/delaycompress：使用gzip压缩归档日志。delaycompress通常与compress联用，表示延迟压缩上一次轮转的日志，方便你查看最近一份归档。
  • missingok/notifempty：前者表示如果日志文件不存在，不报错跳过；后者表示如果日志文件为空，则不进行轮转。
  • create MODE OWNER GROUP：轮转后，新建一个全新的空日志文件，并设置其文件权限、所有者和所属组。这是确保服务能继续写入的关键。
  • sharedscripts：如果一组配置匹配了多个日志文件（如*.log），这个指令能确保postrotate脚本在所有日志轮转完成后，只执行一次，而不是每个文件轮转都执行一次。
  • postrotate/endscript：这对指令包裹的脚本，会在日志轮转动作完成后执行，通常就是在这里发送信号或重载服务，通知进程刷新日志句柄。
• 进程通知动作
  • PHP-FPM：发送USR2信号，这是FPM设计用来重新打开日志文件的专用信号。
  • Apache：执行服务reload操作，这会优雅地重载Apache，使其PHP模块（如mod_php）重新打开配置的日志文件句柄。

排错与最佳实践

配置好了，但效果不如预期？别急，按照下面这几步来排查和优化，能帮你省去不少麻烦。

• 先确认日志路径：这是所有问题的起点。务必检查php.ini中的error_log、PHP-FPM配置中的access.log和error.log，以及应用程序自身定义的日志目录。确保logrotate配置里匹配的路径，与实际写入日志的路径完全一致。
• 先用模拟再上线：修改配置后，切忌直接生效。务必先用logrotate -d进行模拟运行，检查语法和匹配规则。确认无误后，再用-f参数强制执行一次，验证归档文件是否生成、权限是否正确、进程通知是否成功。
• 权限与属主：create指令设置的权限和属主至关重要。例如create 0640 www-data adm，要确保运行PHP的工作进程用户（如www-data）对新创建的日志文件拥有写入权限，否则会导致日志写入失败。
• 信号与重载：务必用对通知方式。FPM认USR2信号，Apache认reload。用错了，进程就不会去重新打开新日志文件，导致日志持续写入旧的、已被轮转的文件中，使得轮转失去意义。
• 控制日志量：除了轮转，源头控制也很重要。根据业务需要，合理设置PHP的error_reporting级别，避免将大量不必要的通知（NOTICE）或警告（WARNING）写入日志。这能有效控制日志文件的增长速度，减轻磁盘压力。