php - 仅记录 Docker 容器中来自 PHP-FPM 的真正 fatal error

Question

我在单独的 Docker 容器中使用 NGINX 和 PHP-FPM。我只想将错误发送到 stderr，以便我可以在集中式日志服务器上收集它们。问题是:我正在使用 WP，似乎有一些写得不好的插件。它们可以工作，但会导致如下警告:

2017/06/17 01:16:08 [error] 7#7: *1 FastCGI sent in stderr: "PHP message: PHP Warning: Parameter 1 to wp_default_scripts() expected to be a reference, value given in /www/wp-includes/plugin.php on line 601

用于测试的示例脚本，这应该在 stderr 中给我一个 fatal error :

<?php
not_existing_func();

PHP-FPM 配置为将错误记录到 stderr，如下所示:

[global]
log_level = error
error_log = /proc/self/fd/2

我想知道这在上面的脚本中没有给我任何东西。就在我将 log_level 切换到至少 notice 后，我在 docker 容器的控制台上收到了异常:

[17-Jun-2017 01:45:35] WARNING: [pool www] child 8 said into stderr: "NOTICE: PHP message: PHP Fatal error: Uncaught Error: Call to undefined function not_existing_func() in /www/x.php:2"

为什么这是一个通知？对我来说，我们这里显然有一个 fatal error ，如消息所示，导致脚本无法继续(当然，我们在浏览器中收到 500 错误)。我必须将 log_level 设置为 notice 以便我不会错过被标记为警告的 fatal error ，这是不可能的。同时，我的日志中充满了来自 WordPress 主题、插件等的垃圾警告，这些警告是我尚未开发的，并且由于更新原因我不想修复......

我尝试了一下，发现 php.ini 中的 log_errors 对于 PHP-FPM 获取任何信息至关重要。但来自 error_reporting 的日志级别似乎也是有线的。出于测试目的，我使用了以下配置:

display_errors = Off
log_errors = On
error_log = /proc/self/fd/2
;error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR
error_reporting = 0

结果:我收到通知，但没有关于我的 fatal error 的信息...

Answer 1

首先，我发现我错了:Wordpress 是此问题的根本原因，而不是直接 PHP。众所周知，WP 在启用调试时会操纵 error_reporting，因此我尝试在配置中将 WP_DEBUG 定义为 false；但即使有这套，documentation says

[...]Except for 'error_reporting', WordPress will set this to 4983 if WP_DEBUG is defined as false.[...]

所以我对 php.ini 的设置是正确且足够的。当错误被重定向到 php.ini 文件中的 stdout 时，我什至不需要 php-fpm 设置。

如何防止 WordPress 操纵错误报告？

这也不是那么容易的。尽管 WordPress 文档表示，wp-config.php 是设置全局范围设置(例如错误报告)的好地方，they got overwritten later to 4983 。我不知道在哪里；也许它甚至不是 WordPress 的核心，而是一些开发不佳的插件或主题。

我们可以通过将 error_reporting 添加到禁用的函数来处理此问题:

disable_functions = error_reporting

现在不可能覆盖我们的error_reporting。我认为这是确保我们不会因插件或主题的外部影响而收到任何其他错误报告的最佳解决方案。同样在未来，由于PHP允许出现这种困惑，我们需要考虑这些事情。

基本上，我们可以批评这会阻止我们通过将 WP_DEBUG 设置为 true 来获取更多日志，这是正确的，但由于我们在生产系统上，所以对我来说进行故障排除似乎是错误的以这样的方式在那里。我们不应该在应用程序基础上执行此操作，尤其是在没有 display_errors 的情况下!相反，查找问题的工作流程应该是查看错误日志。

应始终记录并定期检查 fatal error 。如果这还不够，可以在更高级别上设置 error_reporting 以获取有关可能出现的问题(例如警告)的信息。