某业务间接性获取不到数据-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

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

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

引言

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

问题现象

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

第一优先级恢复业务

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

分析高防日志

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

源站处理

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

深入分析

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

Review业务结构

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

分析高防7层日志

分析过程中发现共5台ECS的公网IP,但是在高防的7层日志里只有3台的数据量是正常的;其他1台没有日志,1台非常少。这个数据是符合间接性的失败的情况。
image.png

分析高防4层日志

分析过程中发现用户的5台ECS的公网IP,在4层日志都是有的,且量还不小。

分析初步结论

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

验证问题

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

随后用户对比正常与不正常的服务配置。
定位到是由于php的配置文件中,没有开启模块extension=php_openssl.dll ;开启后问题现象消失。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章