Categories
程式開發

线上故障处理实践


一、背景

最近公司一个系统发生线上故障,系统架构为C/S的,客户端是APP;系统的功能有:联系人、短信、通话记录等,每个业务都有备份、恢复的功能,即用户可以在APP内备份自己的联系人、短信、通话记录至服务端,然后可以后续某个时间段恢复数据。

线上故障处理实践 1

第1层Nginx,主要做一些流量清洗、流控等处理;

第2层是应用层,分应用接入层和服务层,应用接入层做一些参数检查和登录检查等,服务层处理业务逻辑,这2层之间通过RPC通信;

该系统经过几次接手,没有人能对系统逻辑理解很清楚;

该系统从去年下半年开始一直偶尔有500的报错,但每次重启就好了,本次发生故障后,重启仍然是大量500;

二、问题分析

先查看接入层日志,发现大量的500错误:

线上故障处理实践 2

发现是连接应用接入层超时,应该是应用接入层压力大,赶紧将接入层扩容,增加了1倍的服务器;

线上故障处理实践 3

应用层扩容后,发现连接Hbase报错超时了(这里就不列日志了,日志很重要~)。

因为Hbase扩容后需要Rebalance,这个过程需要一段时间,为了尽量减少对线上影响,开始在nginx上限流,具体是通过accessbylua_file指令进行限流,代码如下:

local tokenHash

if (token == nil) or (token == "") then
return
end

tokenHash = ngx.crc32_long(token)
if ((tokenHash % 64) == 1 then
else
ngx.exit(505)
end

代码比较简单,先从http头中取出标识,然后hash一下,然后让1/64的流量返回给后端,其余的直接返回505。

经过上述处理后,运维同学反应机房带宽打爆了,通过分析发现流量爆增10倍以上,和客户端的同学确认,如果服务端返回的不是200客户端会马上重试。

怎么办呢,将上面的代码改下,加个sleep:

local headers = ngx.req.get_headers()
local token = headers["xxx"]

local headers = ngx.req.get_headers()
local token = headers["xxx"]
local tokenHash

if (token == nil) or (token == "") then
return
end

tokenHash = ngx.crc32_long(token)
if ((tokenHash % 64) == 1 then
else
ngx.sleep(120)
ngx.exit(505)
end

我们查了资料, ngx.sleep不会阻塞nginx进程,所以才敢放心的用。

这样处理之后,带宽还是满了,问题没有解决,因为所有在线客户端基本上都在重试了;

这时候Hbase扩容完了,我们将接入层、服务层的应用都重启了,现象是有一段时间是200,过会又是500了,通过日志分析发现前后端的超时时间不一致,导致nginx返回给应用是500,实际上后端还在处理;

调整了nginx几个超时时间:

proxyconnecttimeout 60s;

proxysendtimeout 60s;

proxyreadtimeout 60s;

RPC的超时间也改为60秒,这样应用有些缓和,但还是有不少500报错;

再通过分析日志发现后端请求处理的请求是几分钟前的日志:

线上故障处理实践 4

Nginx日志如下:

线上故障处理实践 5

再分析下代码,原因是 因为RPC框架设计的不合理,此框架线程池参考的是Dubbo设计的,有threads和queues的配置,只不过框架中queues参数不能改,默认是threads*100,即如果线程数设置为500,则等待队列是50000,并且一直要处理等待队列才能处理新请求,所以造成新请求一直在nginx层报超时,但后端服务层还在处理很早以前的请求,即做一些无用功。

此时修改框架已经来不及,为了解决问题,我们再次进行限流,不过限流策略有些调整,即让每个客户端都有时间处理:

--入口函数
function run()
local headers = ngx.req.get_headers()
local token = headers["XXX"]
local tokenHash
local curTimeSec
local minute
local baseNum

if (token == nil) or (token == "") then
return
end

--current time
curTimeSec = os.time()
minute = math.floor(curTimeSec / 60)
baseNum = 10

tokenHash = ngx.crc32_long(token)
if ((tokenHash % baseNum) == (minute % baseNum)) then
else
ngx.sleep(20)
ngx.exit(505)
end
end

--启动
run()

三、写在最后

整体来说,系统问题就是RPC框架设计不合理, queues参数写死并且还不能调整,做为一个中间件,面对的场景较多,需要一些参数来让使用者平衡具体场景的差异;

此次排查主要的手段有:

1、限流,主要是通过lua进行实现;

2、仔细分析日志发现应用是否正常,特别是系统异常日志的打印很重要;

3、从接入层到底层存储调和的超时时间对应上,从上往下可以逐渐小些,但不能下层比上层的大;

Redis稳定性实践

扩展Redis:增加Redis命令

如何做好稳定性

从一次线上故障来看redis删除机制

一次线上Mysql死锁分析

线上故障处理实践 6