php-fpm错误日志怎么分析

服务器又报 502 了？别慌，十有八九是 PHP-FPM 在闹脾气。要搞定它，最快的方法就是去翻它的错误日志。但很多新手拿到日志一脸懵，满屏的英文不知道从哪看起。其实这事没你想的那么玄乎，说白了就七个步骤，今天咱们就捋一遍。

第一步，你得先知道日志藏在哪。PHP-FPM 的默认错误日志通常蹲在 /var/log/php-fpm/ 这个目录下面，名字要么是 error.log，要么是 www-error.log。如果你翻遍了也找不到，那多半是配置文件里改了路径。去 php-fpm.conf 或者 www.conf 里搜一下 error_log 这个指令，路径就在那。

找到日志之后，第二步是确认它的“嗓门”有多大。错误日志级别有 alert、error、warning、notice、debug 这么几档。级别越高，记下来的东西越严重。平时排查问题调成 error 或 warning 就够用了，真要追查一个灵异 Bug，可以临时开到 debug——不过生产环境慎用，那玩意儿刷起日志来比水管还猛。

好，现在日志打开了，满屏的条目怎么读？第三步就是学会看每一条记录的“四要素”：时间戳——告诉你事故发生在几点几分；错误类型——是警告、错误还是直接致命；错误描述——关键所在，会精确告诉你哪个文件的哪一行、调了哪个函数出了问题；调用堆栈——把出问题之前的函数调用顺序给你排出来了。顺着这个链条捋，问题基本就现形了。

接下来是第四步，定位。根据错误描述去猜，是代码写崩了、配置配错了，还是资源不够用。比如常见的 FPM is running 但页面空白，多半是子进程处理超时；再比如 unable to fork，大概率是内存吃紧或者进程数配置太高。

找到根儿了，第五步就是动手修。改代码、调配置、加资源，该干嘛干嘛。具体怎么修得看具体错误，但有一条铁律：改完任何配置都别忘了一步——重启服务。

第六步，重启。命令其实就两行，看你的系统用哪个。

sudo service php-fpm restart

或者

sudo systemctl restart php-fpm

重启之后，别急着关终端。第七步，持续盯一阵子日志。等个几分钟再看看有没有同类型的错误冒出来。如果是偶发性问题，最好把日志监控搞起来，别等用户投诉了才发现。

说到底，分析 PHP-FPM 错误日志就是个“找茬”的活——耐住性子，一条一条看，定位到问题再动手，你的应用自然就越跑越稳了。