这两天迁移了一个过去的Web服务到另外一个服务器,本来按照提前设定的步骤,操作结果都很顺利。但是谁想,迁移完成内部测试,“咣”,HTTP ERROR 500。

这是一个基于Linux + Nginx + PHP框架的系统。根据我的经验,这种错误基本上都是后端的PHP脚本问题导致的。它报错之后,出于安全防护考虑,PHP-FPM直接返回了500 error,就是报告内部服务器错误给Nginx,浏览器就看到了提示。

这种问题,要排查出来,首要的一个步骤就是尽可能的在减少安全隐患的情况下,搜集错误信息。Web系统因为安全原因,线上的错误提示都是关闭的。但是也有办法单独的给出现问题的系统打开。软件问题错综复杂,影响因素很多,必须尽快隔离错误、定位问题原因。

对于PHP系统,有好多处会影响错误日志的输出。有个建议是:对于修改的配置,先做个备份。使用日志文件,记录你刚才修改了什么文件,然后找到问题后,根据自己的修改还原回去。这样避免定位问题时,改了一大堆,却忘记还原回去。这样会留下很大的问题。

下面是可以输出日志的配置点及其工具,后面有想到的内容会继续补充。

1、php.ini配置文件

生产环境配置是:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

display_errors = Off

display_startup_errors = Off

如果着急排查问题,可以复制一份php.ini备份,先把选项打开,排查完恢复配置

error_reporting = E_ALL

display_errors = On

display_startup_errors = On

对php.ini的修改,需要重启php-fpm服务。对它的直接修改会影响全局,如果必要可以不改php.ini,修改PHP框架入口。现在开发系统都用框架,入口文件就一个,修改很方便,一般都是index.php。

在入口文件开头,加入:

error_reporting(-1); // reports all errors
ini_set(“display_errors”, “1”); // shows all errors
ini_set(“log_errors”, 1);
ini_set(“error_log”, “/tmp/php-error.log”);

这样就覆盖了php.ini的配置。

此外,还有一个注意事项,PHP如果打开了OPcache,它是有刷新时间的。比如默认设置成60秒刷新,意味着你对PHP文件的修改,不会立刻生效。在一些时刻可能会误导你,以为修改没有产生任何作用。

2、Nginx的配置

Nginx系统的配置文件很灵活。错误输出可以全局配置,也可以单独根据需要配置。全局文件一般在安装目录的conf/nginx.conf

具体语法这里不讲,可以去查询。这个日志指令可以放在开始的地方:

error_log /home/wwwlogs/error_nginx.log crit;

把crit改成error。不过不建议在这里更改。nginx有配置文件的include功能,建议单独在需要打开日志的server配置中添加这行指令,改成error。

3、使用xdebug和strace

xdebug是非常强大的调试工具。我喜欢用PHP,估计有一半原因是因为有它,断点调试易如反掌。

使用指令:pecl install xdebug 即可自动下载编译安装。但是需要修改php.ini,添加xdebug模块后,还要重启php-fpm服务。

如果还找不到问题根源,就要拿起重量级武器了:strace,这是一个强大的调试工具,它可以追踪程序的系统调用、文件读写,对于追查问题很有帮助。

使用如下指令打开对php-fpm执行过程的追踪:

strace $(pidof “php-fpm” | sed ‘s/\([0-9]*\)/-p \1/g’) -o phpstrace

不过追踪时间不能长,因为输出的日志量可能非常大,不利于分析。建议只追踪一次出问题的调用,就关闭,然后打开phpstrace日志文件分析。

 

经过分析,发现是一个模块的代码,语法出错了。可是,此代码从未修改过,前面也运行的十分正常。马上想起来,此服务器的PHP运行环境是7.0,前面的服务器环境是7.1,所以语法出现兼容性问题。百密一疏。把PHP运行环境升级到7.1最新版本,解决问题。

 

苹果妙控键盘Apple Magic keyboard大小写切换按键不灵,咋回事呢?