记一次服务内存报警排查过程

曾经终败给现在 2023-07-04 14:02 82阅读 0赞

早上起来，看到群里机器人发的服务报警信息，仔细一看是自己负责的项目在报警，并且持续报警了20分钟左右

{“pod_name”:“xxxxxxx-xxxxxxx”} 最近3分钟求平均 >= 80.0, 当前值81.9331,
报警名称:生产环境_POD内存报警

  1. 可看出是内存报警，而不是CPU报警。所以要先确认一下内存占用情况和内存配置是否合理。

内存报警：比如一个请求上传的数据量太多会直接进到内存，我发上来1G的数据你就撑不住了

  1. 内存资源的配置为512MiB（request和limit一样），当时内存占用为483.62MiB。在这里插入图片描述

  2. 接下来我们要分析为什么会有这样一波请求，确认是正常请求？客户端极端情况重复请求？坏人恶意请求？

    正常请求？，因为这是凌晨3点，所以不应该有用户正常请求。
    客户端极端请求？，和前端沟通了解到，确实在某种极端情况下会有重复请求，但是和这次报警的情况不同。
    坏人恶意请求？，在分析了nginx日志后，可以判断是重客户端发起的请求。

  3. 查看日志中每个请求中的参数特点，继续分析请求的可能性
    由于每个请求参数中都会带设备的唯一性标识，然后我取出所有的标识，去数据库查了标识的合法性。意外的发现这些标识所处的地理位置都是国外！然后恍然大悟。

  4. 得出最终原因

    我们的终端，每天在晚上8点的时候会自动进行数据备份。之前已经用队列处理了北京时间晚上8点的请求。这次的报警恰恰是其他地区时区的终端在当地晚上8点发起的备份请求。由于终端数量不多，但是备份内容较大，导致内存报警。

发表评论

表情：
评论列表 （有 0 条评论，82人围观）

还没有评论，来说两句吧...

相关阅读