在 Docker 容器中仅记录来自 PHP-FPM 的真正致命错误

Question

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

2017/06/17 01:16:08 [error] 7#7: *1 FastCGI 在 stderr 中发送：“PHP 消息：PHP 警告：wp_default_scripts() 的参数 1 应为参考，值在 /www/wp 中给出-includes/plugin.php 第 601 行

用于测试的示例脚本，它应该在 stderr 中给我一个致命错误：

<?php
not_existing_func();

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

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

我想知道这在上面的脚本中没有给我任何内容。就在我切换log_level到 at least 之后notice，我在 docker 容器的控制台上得到了异常：

[17-Jun-2017 01:45:35] 警告：[pool www] child 8 对 stderr 说：“注意：PHP 消息：PHP 致命错误：未捕获错误：调用 /www/x 中未定义的函数 not_existing_func()。 php:2"

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

我尝试了一下，发现log_errorsinphp.ini对于 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

结果：我收到通知，但没有关于我的致命错误的信息...

Answer 1

首先，我知道我错了：Wordpress 是这个问题的根本原因，而不是 PHP 直接原因。众所周知，WP 会error_reporting在启用调试时进行操作，因此我尝试在我的配置中定义WP_DEBUG为false；但即使有这个设置，文档说

[...] 除了 'error_reporting'，如果 WP_DEBUG 定义为 false，WordPress 会将其设置为 4983。[...]

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

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

这也不是那么容易。尽管 WordPress 文档说这wp-config.php是设置错误报告等全局设置的好地方，但它们后来被覆盖到4983. 我不知道在哪里；也许它甚至不是 Wordpress 的核心，而是一些开发不佳的插件或主题。

我们可以通过添加error_reporting到禁用的功能来解决这个问题：

disable_functions = error_reporting

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

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

应始终定期记录和检查致命错误。如果这还不够，error_reporting可以将其设置在更高级别以获取有关警告等可能问题的信息。