记录一次lnmp故障报告

业务架构图：



nginx 状态监控图：



本次故障的表现为：前端php页面无法打开，空白页或者502错误。

nginx中php配置如下：

location ~ \.php$ {
root                /xxx/xxx;
fastcgi_pass        unix:/dev/shm/php-cgi.sock;
fastcgi_index       index.php;
include             fastcgi.conf;
access_log          logs/fastcgi.log ngx_Web_log;
}

首先查看 logs/fastcgi.log 如下：

统计nginx和php交互状态码如下：

总数    状态码
233694    499
55891    200
34029    302
100    500

可以发现日志里大量的出现了499的状态码，百度说明：

nginx源码：

/*
* HTTP does notdefine the code for the case when a client closed
* the connectionwhile we are processing its request so we introduce
* own code to logsuch situation when a client has closed the connection
* before we even tryto send the HTTP header to it
*/
#define NGX_HTTP_CLIENT_CLOSED_REQUEST 499

这是nginx定义的一个状态码，用于表示这样的错误：服务器返回http头之前，客户端就提前关闭了http连接

简单来说，由于后端服务处理时间过长而导致前端nginx等待超时断开。

查看nginx状态监控图发现active在这个时间段，活动连接一直保持在3000左右，根据经验，日常活动连接数一般在900左右，这次突然上了3000，有可能是攻击所致。

1. 查看网络连接数：netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
2. 过滤fastcgi.log访问连接ip数量，通过nginx deny禁止掉可疑ip。

经过上面的处理后，活动连接数的变化不是很明显。于是在程序中添加info.php来测试php响应情况。

测试结果：
重启php-fpm 大概10秒后，就无法再次访问info.php ，大致估计是因为php accept queue 被占满所致。查看一下内核参数是否正常：

# ulimit -n     # 文件最大描述符

# sysctl -a | egrep "tw|backlog|cookies|synack|soconnmax"

net.core.netdev_max_backlog = 262144         # 程序accept queue队列长度
net.ipv4.tcp_max_syn_backlog = 262144         # syn queue 队列长度
net.ipv4.tcp_max_tw_buckets = 6000             # 保持 TIME_WAIT 最大值
net.ipv4.tcp_synack_retries = 1             # 服务端发送syn + ack 包次数限制
net.ipv4.tcp_syncookies = 1                 # 启用syn cookies，当syn等待队列出现溢出时，启用cookies来处理，可以防范少量的syn攻击
net.ipv4.tcp_tw_recycle = 1                 # TIME_WAIT 状态快速回收
net.ipv4.tcp_tw_reuse = 1                     # TIME_WAIT 状态快速重用

一些常用的内核参数都是没有问题的。

问题总汇下：
1. nginx fastcgi.log 大量返回499
2. nginx 活动连接数远远高于正常业务并发
3. php 重启很快就失去响应。

这时候发现问题排查起来有点困难了，于是和开发、数据库沟通下。

沟通下来的结果就是：
早上数据库被DBA调整过。出现过停止服务的状态，而开发人员通过java开发的api是要去连接数据库的。
请求从nginx进来，通过php去调用java接口，而java接口无法连接上数据库无法将数据返回给php，所以nginx等待超时返回499

沟通后思路清晰了，早上DBA动MySQL没有通知到大家，造成了这一系列连锁反应。可见，通知和沟通是很重要的。

重启java程序，php正常返回结果，业务恢复正常。

最后，做技术不能只是关注技术本身，熟悉业务流程和沟通也是作为运维人员必备的技能。