Ubuntu PHP日志管理技巧

Ubuntu PHP日志管理实用技巧

一 日志位置与快速查看

管理日志的第一步，自然是得知道它们藏在哪儿。不同的服务组件，日志的存放路径和用途也各不相同。下面这张清单，能帮你快速定位：

• Apache：访问日志通常在 /var/log/apache2/access.log；错误日志则在 /var/log/apache2/error.log。需要注意的是，PHP运行时产生的错误，默认也会输出到Apache的错误日志里。
• Nginx：访问日志是 /var/log/nginx/access.log，错误日志是 /var/log/nginx/error.log。当PHP以FastCGI模式运行时，其错误或上游PHP-FPM的异常信息，往往也会出现在这里。
• PHP-FPM：常见的日志文件包括 /var/log/php-fpm/error.log 和 /var/log/php-fpm/access.log。不过，部分发行版或特定版本可能会使用单一文件，比如 /var/log/php7.x-fpm.log。具体路径，还是要以实际配置为准。

找到日志文件后，查看起来就方便了。几个高效的命令可以记一下：

• 实时追踪：想盯着日志的动态更新？用 sudo tail -f /var/log/nginx/error.log。
• 分页浏览：对于内容较多的日志文件，less +F /var/log/php-fpm/error.log 既能分页查看，也能进入实时追踪模式。

如果实在不确定日志路径，最可靠的方法是直接查看对应服务的配置文件，寻找像Nginx里的 error_log，或者PHP-FPM池配置中的 access.log、error.log 这类指令。

二 配置 PHP 错误日志与输出策略

默认配置未必符合生产环境的要求，主动配置PHP的错误日志行为至关重要。操作的核心是编辑对应SAPI（如Apache、FPM或CLI）的 php.ini 文件，路径通常是 /etc/php/{version}/{apache2|fpm|cli}/php.ini。

需要关注并调整以下几个关键参数：

• 开启日志记录：确保 log_errors = On。
• 指定日志文件：设置 error_log = /var/log/php_errors.log，将所有PHP错误集中记录到指定文件。
• 调整错误报告级别：生产环境建议使用 error_reporting = E_ALL & ~E_NOTICE & ~E_WARNING & ~E_DEPRECATED。这样既能捕获严重错误，又避免了大量无关紧要的通知和警告信息淹没日志。
• 禁止页面显示错误：务必设置 display_errors = Off，防止敏感信息泄露给终端用户。

修改完成后，别忘了重启对应的Web或PHP-FPM服务（例如 systemctl restart apache2 或 systemctl restart php{version}-fpm）使配置生效。

还有一个最佳实践：建议将应用程序或框架自身产生的日志，统一输出到独立的应用程序日志目录。这样做的好处是能将业务日志与系统、服务日志分离，便于后续进行独立的日志轮转和更精细的权限控制。

三 使用 Monolog 进行结构化与应用级日志

对于现代PHP应用来说，仅仅依赖PHP或Web服务器的原生日志功能是不够的。Monolog库几乎是PHP生态中进行结构化、应用级日志记录的事实标准。

安装非常简单，通过Composer即可：composer require monolog/monolog。

其基本用法非常直观，以下是一个将警告及以上级别日志写入文件的示例：

• 代码示例：
  • use Monolog\Logger;
  • use Monolog\Handler\StreamHandler;
  • $log = new Logger(‘app’);
  • $log->pushHandler(new StreamHandler(‘/var/log/myapp.log’, Logger::WARNING));
  • $log->warning(‘Disk space low’);

Monolog的强大之处在于其灵活性。你可以根据环境（开发或生产）轻松调整日志级别：开发环境可以设为 debug 以便调试，生产环境则建议设为 warning 或 error。同时，它支持添加多个处理器（Handler），例如，可以配置成同时将日志写入本地文件和发送到远程Syslog服务器，实现日志的集中管理。

四 日志轮转与保留策略

日志文件如果放任不管，很快就会膨胀到占满磁盘空间。这时，日志轮转工具就派上用场了。Ubuntu系统默认集成了 logrotate，它会按日或按周自动执行轮转任务。

以PHP-FPM日志为例，我们可以在 /etc/logrotate.d/php-fpm 创建或修改其轮转配置，核心要点包括：

• 指定路径：/var/log/php-fpm/*.log
• 轮转策略：daily（按天）、rotate 7（保留7份）、compress（压缩旧日志）、delaycompress（延迟压缩）、notifempty（空文件不轮转）、create 640 www-data adm（轮转后创建新文件并设置权限）。
• 关键步骤：通过 postrotate 脚本，在轮转后通知PHP-FPM重新打开日志文件，确保日志记录不中断：kill -USR2 $(cat /var/run/php-fpm.pid)。

配置好后，可以使用 sudo logrotate -d /etc/logrotate.d/php-fpm 进行调试和语法检查，用 sudo logrotate -f /etc/logrotate.d/php-fpm 来强制执行一次轮转，测试配置是否正确。

对于应用日志，除了依赖系统级的 logrotate，还可以在应用层实现双重保障。Monolog提供了 RotatingFileHandler，例如 new RotatingFileHandler(‘/var/log/myapp.log’, 7)，就能实现按文件大小自动滚动，最多保留7个历史文件。

同样地，对于通过 php.ini 配置的通用PHP错误日志，也可以为其创建独立的轮转配置（如 /etc/logrotate.d/php-errors），一个简单的配置示例如下：

• /var/log/php_errors.log { daily; missingok; rotate 7; compress; notifempty; create 640 root adm }。

五 定位日志膨胀与建立监控告警

当磁盘空间告急，怀疑是日志文件过大时，如何快速定位和解决？

第一步，快速定位膨胀源：

• 检查 php.ini 中 error_log 指向的文件。
• 核对Nginx/Apache配置中的 access_log 和 error_log 路径。
• 在项目目录下搜索所有日志文件：find . -name “*.log” | grep -i php。

第二步，主动控制日志量：

• 适当降低 error_reporting 级别，关闭生产环境中非关键的 E_NOTICE 或 E_DEPRECATED。
• 审查所用框架的日志配置。例如在Lara vel中，调整 config/logging.php 中的日志级别为 warning 或 error。

第三步，建立清理与监控机制：

• 定期清理过期归档日志，例如：find /var/log -name “php_*.log.*” -mtime +30 -delete（删除30天前的PHP日志归档）。
• 对日志目录建立磁盘使用率监控，并设置阈值告警。这可以通过Prometheus + Node Exporter、Zabbix等监控系统来实现，防患于未然。

最后，别忘了安全与权限：

• 确保日志目录和文件仅对必要的用户（如 www-data）或用户组（如 adm）开放读写权限，防止敏感信息泄露。
• 在磁盘规划时，可以考虑将日志目录挂载到独立的分区，避免日志写满导致系统核心服务受影响。