云原生监控插件负载OOM处理
在集群运行过程中,很多情况下云原生监控插件都可能会发生OOM(Out of Memory)问题,本文为您介绍如何有效地解决该问题。
云原生监控插件的组件出现OOM时,可参考以下解决方案:
- prometheus-lightweight负载出现OOM
- prometheus-server负载出现OOM
- thanos-query和thanos-sidecar负载出现OOM
- kube-state-metrics负载出现OOM
处理前准备
请先确保负载所在节点内存充足,排除由于节点内存不足导致的OOM。
prometheus-lightweight负载出现OOM

prometheus-lightweight负载仅在本地存储关闭的场景下存在。
prometheus-lightweight负载为轻量化采集组件,一般不会出现OOM。若发生OOM,可能是由于远端存储(AOM或三方存储)异常导致的,建议查看prometheus-lightweight负载的日志及仪表盘。
prometheus-server负载出现OOM

prometheus-server负载仅在本地存储开启的场景下存在。
prometheus-server负载会内存中存储近2小时的指标供快速查询,因此随着指标规模的增加,内存也会相应增加。
prometheus-server一旦OOM后,大概率会持续OOM,因为每次启动后都要从WAL中加载近2小时的全量指标至内存,此过程中通常会消耗比常态运行更多的内存。
建议通过插件页面,将prometheus-server负载的内存Limits扩大50%~100%,然后持续观察即可(启动可能耗时5~30分钟,由指标总量和磁盘性能决定)。
thanos-query和thanos-sidecar负载出现OOM

Thanos负载仅在本地存储开启、且高可用开启的场景下存在,用于高可用查询去重。
执行大规模长时间线的查询,或者查询并发较多时,Thanos组件存在OOM风险。
此时通过插件页面,扩大Thanos负载的CPU和内存Limits即可,建议扩大100%。
kube-state-metrics负载出现OOM
kube-state-metrics负载用于暴露集群的Kubernetes指标,和集群规模正相关。
建议按照大规模集群中的云原生监控插件配置最佳实践对kube-state-metrics负载的分片和资源进行调整。