我在分离的Docker容器中使用带有PHP-FPM的NGINX。我想只将错误传递给stderr，以便我可以在集中式日志服务器上收集它们。问题是：我使用WP并且似乎有一些写得不好的插件。他们工作但引起这样的警告：
2017/06/17 01:16:08 [错误] 7＃7：* 1在stderr发送的FastCGI：＆＃34; PHP 消息：PHP警告：参数1到wp_default_scripts（）期望 作为参考，在第601行/www/wp-includes/plugin.php中给出的值
用于测试的示例脚本，它应该在stderr中给我一个致命的错误：
<?php
not_existing_func();
PHP-FPM配置为将错误记录到stderr，如下所示：
[global]
log_level = error
error_log = /proc/self/fd/2
我想知道这在上面的剧本中没有给我任何帮助。在我将log_level切换到至少notice之后，我在docker容器的控制台上得到了异常：
[2017年6月17日01:45:35]警告：[池www]孩子8对stderr说： ＆＃34;注意：PHP消息：PHP致命错误：未捕获错误：致电 /www/x.php:2"中的未定义函数not_existing_func（）;
为什么这是通知？对于我来说，我们在这里显然是一个致命的错误，如消息所示，因为脚本无法继续（当然，我们在浏览器中得到500错误）。我必须将log_level设置为notice，以便我不会错过任何被视为警告的致命错误，这是不对的。同时，我的日志充满了来自wordpress主题，插件等的垃圾警告，我还没有开发出来，而且我不想修复更新原因......
我尝试了一下，发现log_errors中的php.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
结果：我收到通知，但没有关于我致命错误的信息......
答案 0 :(得分：1)
首先，我了解到我错了：Wordpress是导致此问题的根本原因，而不是直接使用PHP。众所周知，当启用调试时，WP会操纵error_reporting，所以我检查了在我的配置中将WP_DEBUG定义为false。即使有这个设置，documentation says
[...] 除'error_reporting'外，如果将WP_DEBUG定义为false，WordPress会将此值设置为4983。 [...]
所以我对php.ini的设置是正确和充分的。当错误被重定向到php.ini文件中的stdout时，我甚至不需要php-fpm设置。
这也不是那么容易。虽然WordPress文档说，wp-config.php是设置全局广泛设置（如错误报告）的好地方，但他们会在以后覆盖到4983。我不知道在哪里。也许它甚至不是wordpress的核心，而是一些糟糕的插件或主题。
我们可以通过将error_reporting添加到已禁用的功能来处理此问题：
disable_functions = error_reporting
现在无法覆盖我们的error_reporting。我认为这是确保我们不会通过插件或主题的外部影响报告任何其他错误的最佳解决方案。也是在将来。由于PHP允许这样的混乱，我们需要考虑这些事情。
基本上，我们可以批评，这可以通过将WP_DEBUG设置为true来防止我们获取更多日志。那就对了。但是，由于我们处于一个高效的系统中，我似乎不应该以这种方式进行故障排除。我们不应该在应用程序基础上执行此操作，尤其是在没有display_errors的情况下！相反，查找问题的工作流程应该是查看错误日志。
应始终记录致命错误并定期检查。如果这还不够，可以在更高级别设置error_reporting以获取有关警告等可能问题的信息。