某业务间接性获取不到数据

引言

问题往往出现在意想不到的地方;问题分析时,我们需要更多的数据作为支撑。

问题现象

某天晚上用户反馈业务经过高防产品后间接性的无法获取到数据;判断是高* Z 2 | W防的问题导致的,由于是线上业务需要我们紧急处理。

1 f ! x ~ k m D v一优4 A S B K N先级恢复业务

用户反馈由于源站证书问题,无法进行域名解析回源的。当时萌了,还有这种操作;随后的排查:
1、请用户处理源站证书,全部处理正确;随后全部域名解析回源。
2、{ K y分析高防4层&7层日志 是否有拦截情况

分析高防日志

在高防的4层和7层日志上,没有任何的异常返回码以及拦截记录。即高防没有啥问题

源站处理

用户将源站证书处理正常;将域名全部解析回源,但是依然发现有问题。
反馈的业务架构为:Client->cms..cn(slb-ECS)->content.x.cn
其中b.com是在高防上的。但是均已经解析回源负载均衡了依然有问题,苦于联 q t B _ =系不到用户的开发同学;与客户达成共识暂定白天继续分析。

深入分析

业务恢A . p _
白天开发操作,由原来的请求访问b.com 修改为内网负载均衡之后,问题现象消失。需要我们配合查询原因,同时不认可是应用问题Y T C;判断的依据是真正的通信域名一直在高防上

Rev_ ~ g c e t eiew业务结构

针对这个情况; J 6 C ` ; a T拉上用户的运维,开发,我们的同学与用户对齐信息;了解到如下信息
用户的运维和开发是2个部门,操作完全是分开N @ $的。晚上操作的b.com回源其实没有效果,因为当时cmsj E # ^ 4 (.x.cn(slb-ECS)访问的域名是content.x.com;content.x.com这个域名一直解析在高防上没有解析走过。
Review分析过程
根据用户的数据
cms.x.cn(sL U Rlb-ECS)这5个ECS的公网地址是需要大量的访问 content.x.com 这个域名的。

分析高防7层日志

分析过程中发现共5台ECS的公网Ia { B v % t NP,但是在高防的7层日志里只有3台的数据量是正常的;其他1台没有日志,1台~ k # B c w | G非常少。这个数据是符K d ~ 1 l x Y合间接性的失败的情况。
某业务间接性获取不到数据

分析高防4层日志

分析过程中发现用户的5台ECS的公网IP,在4层日志都是有的,且量] # m = * L z / R还不小。

分析初步结论

开始认为可能为高防的VIP到7层代理之间,或者7层代理的问题。但是经过与开发同学的讨论
1、LB 的日志是正常的。所以当时的网络以及Tengine不太可能有f f F t @ N问题。
2、用户是走的hd A @ Lttps协议,那么三次握手完成之后,应该是要进行ssl握手。
最终判断比较大的可能是由m D t D于当时ssl握手的时候,出现了问题。

验证问题

将其中一台请求基本没有的ECS的链接地址修改为高防/SLB,然后在该ECS上进行抓包分析。看到的抓包如下,肯定完成三次握手后,没有进行ssl握手的动作直接断开了链接;这个行为是不符合预期的。
某业务间接性获取不到数据

随后用户对比正常与不正常的服务配置。
定位到v [ ^ i h @ U是由于php的配置文件中,没有开启模块extension=php_opej . ( w z M v F :nssl.d- W 4 ? ? # S L `ll ;开启后问题现象消失。