启用remote_write后Prometheus CPU占用异常飙升问题咨询

你好，这种从30m跳到2700m的CPU涨幅绝对是不正常的——正常开启remote_write后，CPU开销通常只会有10%-30%的小幅上涨，最多翻倍，绝不会到这种量级。我来给你梳理几个排查方向，帮你定位问题：

一、先检查remote_write的配置细节 #

• 看看是不是remote_write的queue_config参数配置不合理？比如max_shards设得过高，导致Prometheus启动了大量并发写入线程，疯狂消耗CPU；或者capacity（队列容量）太大，积压样本后触发大量并发处理逻辑。
• 有没有开启send_exemplars？如果你的监控数据里关联了大量Tempo的trace ID（exemplars），开启这个选项后会额外增加样本序列化和传输的开销，可能直接把CPU拉满。
• 检查write_relabel_configs是不是写了复杂的正则规则或者大量过滤逻辑？每一条样本都要经过这些规则的计算，规则太复杂的话，CPU很容易被吃满。

二、排查目标端（Tempo）的响应情况 #

• 看看Tempo的写入接收端是不是处理缓慢？如果Tempo本身压力大、响应延迟高，Prometheus的remote_write队列会快速积压，为了处理重试、队列调度等逻辑，Prometheus会占用大量CPU。你可以通过Prometheus自身的metrics来验证：比如prometheus_remote_write_sends_total（成功发送次数）、prometheus_remote_write_send_duration_seconds_sum（发送总耗时），如果发现有大量超时、失败的请求，或者发送耗时暴增，那大概率是Tempo那边的问题。
• 有没有把remote_timeout设得太长？如果目标端长时间不响应，Prometheus会挂着连接等待，导致线程占用CPU不释放，进而引发连锁反应。

三、检查版本与Chart的兼容性 #

• 你用的kube-prometheus-stack是40.1.2版本，对应的Prometheus版本大概是2.37.x，这个版本的remote_write有没有已知的性能bug？比如某些场景下的循环逻辑、内存泄漏导致CPU飙升？可以查一下该版本的release notes，看看有没有相关的性能修复记录。
• 有没有在Chart里同时开启了其他高开销特性？比如大量的recording_rules（记录规则），规则生成的样本量本身就很大，再加上remote_write的双重压力，直接把CPU压垮。

四、验证样本量的变化 #

• 开启remote_write后，Prometheus抓取的样本量是不是突然暴增了？比如有没有因为配置变更，导致抓取的target数量翻倍，或者每个target的指标数大幅增加？你可以看prometheus_tsdb_head_samples_appended_total这个指标，对比开启remote_write前后的样本增量，确认是不是样本量本身的增长加上remote_write的开销，才导致CPU飙升。

五、临时验证方法 #

你可以先简化remote_write配置：只保留最基础的目标地址配置，关掉send_exemplars、write_relabel_configs，调整queue_config到保守值（比如max_shards: 2、capacity: 2500），看看CPU是不是能降下来。如果降了，再逐个加回之前的配置项，就能定位到是哪个选项导致的问题。

备注：内容来源于stack exchange，提问作者Antonio Soldo