问题描述
最近市场的同学通过一系列活动激活了很多用户,日活用户激增,导致服务器不稳定.
根据以往经验一一排查,下面是排查问题的过程.
- 1.一般都是数据库的瓶颈,查看数据库的
cpu使用率和cpu负载都正常,加了一个只读库,情况大大好转. - 2.然后排查服务器的
cpu使用率和cpu负载,也是正常. - 3.排查容器服务节点的资源消耗,应用服务容器节点
cpu使用率在正常的情况. - 4.怀疑
自定义路由 proxy服务的问题,遂查看服务容器节点的资源消耗,发现cpu使用率有时候会超过100%,决定增加proxy的容器数量.增加proxy容器数量需要新加集群节点,所以决定新增服务器. - 5.新增服务器后情况得到缓解,但是还有服务不稳定的情况.这个时候
ecs的cpu使用率和cpu负载都很低了,proxy的资源消耗有部分节点cpu使用率超过100%,但是大部分已经是正常的了.这个时候一直找不到原因,但是用户那边一直反馈服务还是不稳定.一直认为是proxy的问题,所以提交了工单,询问阿里云工程师怎样提高proxy服务的cpu资源,阿里云工程师建议使用scale,增加proxy容器的数量.
因为重新调度proxy会导致服务停止30s左右,为了不影响用户,也不确定是否能解决问题,所以决定等晚上再操作,继续增加容器节点,提高proxy容器节点. - 6.增加服务器后,情况并没有得到缓解,还是会出现该问题.同时,同事查看了负载均衡的监控数据,发现负载均衡出现丢弃连接数,正常情况1个丢弃连接数都不应该出现的,查看负载均衡配置,只支持 5000 并发连接数,遂升级负载均衡配置,后续持续观察,服务变得稳定.
中间插曲
- 1.新增容器节点服务部署失败,拉取不了镜像.新增的节点没有绑定公网
ip,不能访问公网,需要绑定公网ip或者使用vpc的NAT网关. - 2.新增容器节点连不上
redis,最开始没有设置redis连接白名单,后来设置之后还是连不上,提交阿里云工单咨询工程师,白名单添加无效,经阿里云修复后解决.将redis也加到安全组中. - 3.对阿里云容器服务编排模板自定义便签
cpu_shares: 50 #0.5核和mem_limit: 536870912 #512MB的认知有歧义,在不确定意思的情况下进行了操作.查询docker文档后 容器资源限制docker默认对容器不做限制.
问题再次出现预防手段
确定问题排查步骤
服务架构
排查步骤
增加服务报警
- 并发丢弃报警
总结
经过这次事件,总结如下:
- 1、需要对整个流程都清晰
- 2、不清楚的操作一定要在了解清楚后在操作，不要拿用户去冒险
- 3、犯的错误需要记录下来，转变成文字