2020-05-27

由java程序引起的一次系统崩溃

由java程序引起的一次系统崩溃


问题来源

2020年5月3日星期天。晚上7点39分,正是结账的高峰期,然而就是在这个时候系统崩溃了。牵扯到钱的事没一件事小事,可以定性此为重大事故。

造成的后果:

有人必须要背锅了,先恢复再找问题源头,再找谁的问题(这种锅绝大多数是开发的问题)。

问题处理


常见思路:回滚、重启大法!!! 先恢复再查原因
f12 访问看问题到底在哪里?

502服务端错误,可以肯定与代码健壮性有关。
重启回滚能解决百分之80的问题,但这里的路径多了一个/,路由是不是有问题,看日志,或看相关服务的连接。nginx就做了一个反向代理,我觉得还是跟请求的代码有关,让他们抓包看看流量到哪了,先看看解析有没有问题,然后直接用ip能不能到ng,解析没问题的话,确定一下域名访问能到ng不,后端直接在ng上用curl测试下正常不,代码问题直接回滚,不二话,域名问题看看是不是被劫持了。

GC了,....网关,开发自己写的...
其实最开始出现问题,后面会出现有的可以访问,有的不行,我们的gatway是设置弹性伸缩的,刚才确实伸缩了,但是有些流量还是转到了旧的pod上,因为GC了,所以不能访问gatway。
OOM是不会影响端口 端口只有是否被开放 或者服务是否正确启动才会有端口的问题,OOM是内存的问题和你服务端口无关,Pod中查询OOM的问题:java应用出现内存溢出老正常了。最好加上监控(监控Pod的IO之类的),重启也行,加入注册中心,服务不可用 剔除。

善后工作

  1. 监控日志,报警出来
  2. 做探针?
    探针没用,因为服务端口都在,pod状态也是running。所以就是要api,检测可用性的api。端口不能代表可用性,应该让开发在网关加一个健康检查端口。通过curl 健康检查端口判断业务是否正常
  3. prestop
    钩子,有问题,就杀掉,然后剔除注册中心,滚动更新的时候加上prestop,然后通过curl 注册中心,将这个pod强制下线

    具体参数得问开发
    越是重大问题你处理了,越是体现价值,处理好了,应该的,处理不好,背锅。真现实。

No comments:

Post a Comment