Prometheus 抓取超时与下游慢查询互相放大：scrape 间隔、超时与样本堆积怎么拆开调

监控看起来「红了」，业务也变慢——两边值班互相甩锅。一类高频根因是 Prometheus 抓取超时、重试与下游慢查询/锁等待形成正反馈：scrape 打满应用线程或把慢SQL再放大一轮。本帖按「先确认是抓取侧还是目标侧 → 再拆开间隔/超时/并发 → 最后才动业务SQL」整理排查顺序。

一、先钉死是谁在放大谁
1. 看 Prometheus 自身：`scrape_duration_seconds`、`scrape_samples_scraped`、`up` 翻车是否与目标P99同相位；目标健康时 scrape 仍超时，优先查网络、服务发现抖动、过大的metric体量。
2. 看目标侧：同一时刻线程池/DB连接是否被 `/metrics` 或导出器同步查询占满；很多「监控接口」实际会触发聚合SQL或遍历大表。
3. 只在高峰互相放大：把 scrape 临时降并发/拉长间隔做对照，若业务P99立刻回落，基本坐实耦合，而不是「业务自己慢」。

二、间隔、超时、体量三件套
1. 超时必须小于间隔，并留网络与GC抖动余量；超时≥间隔时，上一轮未完成下一轮又叠上来，目标会被抓取打成拒绝服务。
2. 高基数/大直方图：先减label、减bucket、改用recording rule，而不是把 scrape timeout 一味加长。
3. 短间隔只留给真正要告警的SLO信号；大盘展览类指标可以更疏，避免所有job一刀切15s。
4. 联邦/远程写：本地已超时的序列不要再对同一目标叠加第二套高频抓取。

三、导出器与应用暴露方式
1. 同步锁：`/metrics` 里拿着业务锁做聚合是经典事故；改为后台采样、无锁近似或独立导出进程。
2. 多进程/多副本：每个副本都被抓时，下游若是共享DB，要把「监控查询」预算计入容量，而不是只算用户QPS。
3. 服务发现抖动：频繁up/down会触发额外重试；先稳SD与健康检查，再谈调参。

四、调参与验收
1. 一次只改一个旋钮：先降并发或拉长间隔，观察目标线程与DB；再单独调整timeout。
2. 记录改前改后的 scrape_duration、目标P99、DB活跃会话，避免「看起来不超时了但漏了告警」。
3. 对关键作业设独立的 sample limit / body size 防护，防止单作业拖垮整机。

五、常见误区
- 一超时就全局加大 scrape timeout。
- 把业务慢查询优化和监控抓取混成一次变更，无法归因。
- 用关掉监控当高峰应急常态。

欢迎补充你们在 Kubernetes 服务发现、Java client、以及远程写入场景下的 scrape 与慢查询解耦经验。

scrape 超时和下游慢查询正反馈这套分流很清楚。车队/边缘侧也常见：把力传感器或安全诊断指标和业务指标绑在同一个高频 job 上，一高峰监控自己先把节点打满。我们的做法是关键安全/力控信号走短间隔小基数 job，展览类大直方图另开疏间隔，并给 /metrics 单独连接预算，避免和业务 SQL 抢池。

拆开调的关键是先把监控流量和业务流量在容量上分开算。/metrics 走独立的轻量导出进程或后台采样，不要让它直接触发聚合 SQL 或持业务锁做计算；Java 客户端的默认直方图 bucket 和高基数 label 最容易把体量撑大，先在客户端侧减 bucket、删不稳定的 label，再用 recording rule 预聚合。scrape 配置上，超时严格小于间隔并留 GC 抖动余量，关键 job 单独设 sample_limit 和 scrape_timeout，慢 job 拉长间隔，SLO 告警信号单独一个短间隔 job。远程写入场景，本地已经超时的序列不要再叠加联邦抓取，先看 scrape_duration_seconds 与目标 P99 是否同相位，再决定是降并发还是优化下游慢查询，一次只改一个参数。