Ubuntu PHP日志清理策略

Ubuntu PHP日志清理策略

一 定位日志来源与路径

清理日志的第一步，也是最关键的一步，就是搞清楚日志到底从哪儿来。如果搞错了源头，要么误删了重要文件，要么漏掉了真正占空间的“元凶”。通常，日志主要来自三个地方：PHP引擎本身、Web服务器（比如Apache或Nginx），以及你使用的应用框架（如Lara vel）。

下面这张表帮你快速定位常见的日志文件和查看方法：

至于如何确认PHP自己的日志路径，方法也很直接：去对应的配置文件里找。打开 /etc/php/版本号/apache2/php.ini 或 /etc/php/版本号/fpm/php.ini，搜索 error_log 指令，就能看到它指向的具体文件了。

二 推荐的清理策略

明确了日志在哪，接下来就是怎么管。一套好的策略，应该兼顾自动化、安全性和资源效率。

• 使用 logrotate 做按日轮转、压缩与保留（首选方案）
  • 为什么首选它？原因很实在：安全、自动化程度高、支持压缩节省空间，还能保留指定天数的历史日志以备排查。更重要的是，它能配合信号通知进程重新打开日志文件，避免日志写入中断。
  • 通常的建议策略是：按天轮转、保留7到14天的日志、对旧日志进行压缩、空文件不轮转，并且在轮转后通知相关服务。
• 降低日志噪声
  • 有时候日志暴涨，不是因为错误多了，而是记录得太“细”了。可以调整 php.ini 中的 error_reporting 级别，减少像 E_NOTICE、E_WARNING 这类非关键信息的输出。
  • 同样，对于Lara vel、Symfony这类框架，在生产环境中，也建议将日志级别设置为 warning 或 error，过滤掉大量调试信息。
• 清理应用自定义日志
  • 应用自己生成的日志（比如Lara vel的 storage/logs 目录）也需要规范管理。最好的做法是统一日志目录，然后同样交给 logrotate 或者一个定时脚本，定期清理超过N天的旧日志。
• 监控与告警
  • 被动清理不如主动预防。对 /var/log 或核心日志目录设置磁盘使用率监控和阈值告警（比如达到80%就报警），能在日志异常增长导致磁盘爆满之前，就发现问题。

三 落地配置示例

理论说完了，咱们来看具体怎么配。这才是真正能落地的东西。

• PHP-FPM 日志轮转（/etc/logrotate.d/php-fpm）
  • 这个配置适用于像 /var/log/php-fpm.log 或 /var/log/php/7.4/fpm/error.log 这样的路径。
  • 它的核心要点是：按天轮转、保留7天、压缩旧文件、空文件不处理，并且在轮转后向PHP-FPM主进程发送USR2信号，让它重新打开日志文件，确保服务不间断。

/var/log/php*.log /var/log/php/*/fpm*.log {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        # 按实际版本和进程名调整
        for pid in /run/php/php*.pid; do
            if [ -f "$pid" ]; then
                kill -USR2 "$(cat "$pid")"
            fi
        done
    endscript
}

• 应用自定义 PHP 日志（/etc/logrotate.d/php-app）
  • 这个配置用来管理应用框架的日志，比如Lara vel的 /var/www/app/storage/logs/lara vel.log。
  • 配置逻辑类似：按天轮转、保留14天、压缩。这里使用了 copytruncate 方式，更适合那些不支持接收重载信号的应用。

/var/www/*/storage/logs/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0644 www-data www-data
    copytruncate
}

• 测试与生效
  • 配置好了别急着走，先测试一下。用 sudo logrotate -d /etc/logrotate.conf 可以检查语法和执行计划（干跑模式）。
  • 确认无误后，可以手动强制执行一次特定配置来验证：sudo logrotate -f /etc/logrotate.d/php-fpm。
  • 顺便提一句，大多数Ubuntu系统已经预装了logrotate。如果确实没有，一条命令就能搞定：sudo apt-get install logrotate。

四 安全清理与应急操作

虽然自动化工具是首选，但总会遇到需要手动干预的紧急情况，比如磁盘突然被日志塞满。这时候，操作的安全性就至关重要。

• 记住一个原则：优先使用 logrotate 而不是直接删除或清空正在写入的日志文件。如果情况紧急必须立即释放空间，正确的做法是“清空”而非“删除”：
  • 清空文件内容：sudo truncate -s 0 /var/log/php-fpm.log
  • 如果非要删除并重建（需确保相关进程已停止或不再持有该文件句柄），步骤是：删除原文件、创建新文件、并正确设置所有者和权限。
• 无论进行何种操作，事前备份关键日志总是一个好习惯。另外，谨慎使用 rm -rf 这种破坏性命令。最后，修改了 php.ini 或 PHP-FPM 池配置后，别忘了重启或重载服务，让新的 error_log 设置生效。

五 监控与容量规划

把日志管理好，不是一个一次性的任务，而是一个持续的过程。

• 建立基础的监控告警，比如对日志目录设置容量阈值（例如80%），一旦超过就触发告警，让你能提前应对。
• 对历史归档日志实施生命周期管理。例如，明确策略：保留7到14天的压缩归档，超过这个时间的就自动批量清理。
• 当监控发现日志异常增长时，这本身就是一个信号。需要联动排查：是不是错误级别配置太低了？有没有出现新的异常堆栈？第三方组件的日志开关是否被意外打开？最近是否有部署变更？从日志增长的趋势里，往往能提前发现系统潜在的问题。