免备案网站怎么收录,电子商务seo是指什么意思,百度seo排名360,微信端网站开发流程概述 在3月2日晚上#xff0c;大概8点左右#xff0c;本想打道回府#xff0c;回家休息#xff0c;突然被人在bug群了一下#xff0c;说是管理后台#xff0c;访问不了#xff0c;界面上出现了:
503 service temporarily unavailable我赶紧尝试访问了一下#xff0c;确…概述 在3月2日晚上大概8点左右本想打道回府回家休息突然被人在bug群了一下说是管理后台访问不了界面上出现了:
503 service temporarily unavailable我赶紧尝试访问了一下确实如此但不是每次都不行而是偶发503的错误提示。当时我是没有立刻动手去定位问题而是先拉了一个临时处理群这样做的原因是
先将线上出故障了这件事情同步出去要让相关的人知道像运维、测试、你的上级、产品等一定是先止损优先【线下去处理故障】而不是【直接在线上处理故障】
群拉完后我简单同步现象后就开始分析了首先想的第一点就是 是不是因为做了线上变更导致的比如有发版之类的。 从这个点切入去想的原因是源于自己处理线上故障的经验大部分都是发版导致的能回滚的优先回滚第一时间降低影响。因此我打开了发版日历技术团队是有维护一个发版日历的记录了每次发版或者变更的内容发现3月2号当天在线上做了如下两件事情
部分服务接入了阿里云WAF这个是因为安全原因需要接入管理后台对应的前后端服务确实也发版了
火速电话公司的安全专家先临时关闭WAF但关闭后没有用访问管理后台还是一直出现503提示没办法了得立刻回滚当天上线的内容正当运维要操作回滚的时候我反而制止了它。因为 管理后台突然又能访问了。 跟产品和业务方确认了一下他们也反馈系统恢复了。好吧这个也算一个好消息毕竟可以给技术团队多一些时间去定位问题。
系统临时性恢复后我这边也就没那么大的压力和紧迫感了静下心来开始着手仔细分析找出根因。 分析过程 是否有突增的流量过来
使用阿里云的SLS日志平台写了个简单的脚本执行后发现流量一直很平滑。虽然是管理后台的服务但是还是要先看看流量的因为有可能有一些定时任务或者重量级业务操作导致疯狂的调用管理后台服务。
是否是发版导致的?
由于发版的内容还不少很难一下子分析出是哪些代码导致的只能利用阿里的日志平台以及监控平台从故障发生的时间范围里寻找一些蛛丝马迹。
首先是查看故障时间内对应的后端服务有无返回状态码非200的可以使用阿里的SLS日志平台写个简单命令查询一下即可
xxxx_app_id:yyyy not statusCode: 200上面的一些查询字段是可以在SLS上自己定义的。最终发现返回的状态码都是200的这个就有点奇怪但还是继续看一下有无异常日志。
xxxx_app_id:yyyy and logLevel: ERROR 发现也没有初步判断不是后端代码上线导致的便转而开始用阿里云的监控平台观察后端服务pod节点的运行情况但也没有什么收获pod既无重启的情况内存、CPU usage也都正常也没有什么慢的请求。
当时就有点摸不着北了由于那会也比较晚了后台管理系统也暂时没有出现问题了我就先回家了。而隔天又有其他重要紧急的事情要处理我就忘记去跟这个事情了一直到3月6号早上又开始出现503问题了持续时间是两分钟然后就又自己恢复了。
这次我就把手头上的事情先全部放下全力跟进这个问题。经过3月2号晚上的分析感觉跟后端服务没有关系那会不会是前端的node服务有问题呢? 当然平时如果线上出故障我很少认为会是前端问题都是先从后端服务定位起。
但这次没办法死马当活马医于是便到阿里云上去看一下前端pod节点的运行情况发现有重启的情况我感觉发现新大陆了马上去确定pod重启时间但是很遗憾我没权限看就临时去看一下这个pod的内存波动情况一般来说pod有重启的话内存会短暂释放果然在故障期间前端的pod的内存占用有下降的趋势然后故障后的几秒内存占用又恢复了日常水平。
于是便火急火燎的跑去找了一下运维 把前端的xxx pod有重启的情况我怀疑管理后台503问题是这个原因导致的你能不能把这个pod重启前的日志发我一下。 当时运维回复说重启前的日志找不到了哦。当然这句话我是不信的。就让运维去查一下或者找阿里云的售后看看怎么拿到pod重启前的日志。果然可以使用kubectl命令找到日志 kubectl describe pod xxxx-pro-vyyyyyyyy | grep State: ’ -A 5 日志里有几个信息
一个是pod重启前的代码报错日志一个是pod具体的重启时间一个是Exit Code这个code等于1说明pod重启是服务自身的报错导致的。
报错日志如下 TypeError [ERR_HTTP_INVALID_HEADER_VALUE]: Invalid value “undefined” for header “Content-Length” 到此基本就清楚了请求先经过阿里WAF和阿里nginx-ingress后由nginx-ingress转发给前端的service进而进入到pod但是由于pod同一时间都在重启暂时无法提供服务service这一层就不知道pod的状态nginx-ingress自然也就无法知道service的状态于是便返回了503。等重启完毕后就又正常提供服务之所以偶发的出问题原因就在这里。 于是便找了前端的开发leader去定位原因最后他回复说要改一个底层文件兼容一下Content-Length为空的情况改完后简单在在测试环境和预发布环境测试一下过一下核心主流程没问题后就上线了。
从3月9日上线到现在暂时没有发现503问题了。
那灵魂一问来了这个底层文件从2021年来一直都没有改动过也没出过啥事为啥最近才开始出问题呢? 答案是 比较难查不知道是哪些请求会没有Content-Length但肯定是发版导致的。
