记一次prometheus监控pod内存使用率错误使用sum函数引发的血案

博客讲述了在Prometheus监控中,由于标签匹配问题导致Pod内存使用率计算错误,进而引发大量Pod误重启的情况。问题源于sum函数在数据重复时导致指标翻倍。根因分析指出,sum函数的使用不当是问题核心。解决方案包括修改计算指标为使用count函数确保数据稳定性,或者改为max函数以最大值为依据。建议在使用Prometheus时注意指标聚合的正确性,避免类似误报问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

prometheus监控pod内存使用率

发生背景

  1. pod内存使用率过高需要自动重启pod防止被kill影响线上业务
  2. 制定计算规则
  • 首先制定的规则:(container_memory_usage_bytes - container_memory_cache) / memory_limit > 90
  • container_memory_usage_bytes和container_memory_cache是Cadvisor中采集的数据,和memory_limit不是一个采集器收集上来的,标签不一致没办法计算,所以有了如下改版进行,标签选择使前后的指标的标签一致
  • 进行标签选择之后的规则sum(container_memory_usage_bytes{container!="", container!="POD"} - container_memory_cache{container!="", container!="POD"}) by(env, namespace, pod, container) / on(pod, container, env, namespace) label_replace(label_replace(memory_limit{status=~"Running.*"}, "pod", "$1", "pod_name", "(.+)"), "container", "$1", "container_name", "(.+)") * 100 != +inf > 90
  • 因为进行env, namespace, pod, container标签筛选之后能够确定只有一条指标,所以算出来的数据判断是没有问题的,该计算指标就上线了

问题伊始

  1. 某天下午突然一个线上环境触发了大量的pod重启,原因是因为pod内存过高导致触发了pod的自动重启,但是排查发现那一时刻的Pod内存使用率没有任何问题的,于是就来排查是否是告警误报导致
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值