1

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

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

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

<?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

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

4

1 回答 1

5

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

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

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

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

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

我们可以通过添加error_reporting禁用的函数来处理这个问题：

disable_functions = error_reporting

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

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

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

于 2017-06-17T00:35:38.317 回答