Prometheus 报 "Context Deadline Exceeded" 错误怎么办？
Prometheus 查询报 Context Deadline Exceeded 说明查询超时。本文列出四大成因（查询过重、服务高负载、网络问题、资源不足）与对应解法：优化查询、调大 query.timeout、扩容与引入 Thanos 等长期方案。
"Context Deadline Exceeded" 表示 Prometheus 查询在超时时间内没有跑完——本质是查询太重或服务器太忙。按下面的清单逐项排查即可定位。
常见成因
- 查询本身太重：大范围时间聚合、未过滤的高基数指标、多层嵌套子查询，执行时间超过超时阈值；
- Prometheus 高负载：写入速率高、并发查询多，CPU/内存被打满；
- 网络问题：Grafana 等查询端与 Prometheus 之间连通性差；
- 资源不足：CPU/内存配额太小，GC 频繁。
解决办法
优化查询：缩小时间范围、先过滤再聚合、避免 .* 全匹配正则、用录制规则（recording rule）把重查询预计算成新指标。
调大超时：启动参数调整（默认 2 分钟，旧版本默认 60s）：
prometheus --config.file=prometheus.yml --query.timeout=120s
注意 Grafana 侧也有自己的超时设置（数据源的 Timeout 与 Query timeout），两端要一起调。
加资源或扩容：垂直加 CPU/内存；数据量大就上 Thanos、Cortex、Mimir 这类水平扩展方案，把查询与存储拆开。
观测云对照
自建 Prometheus 的超时、容量、分片问题，在观测云里不存在：指标经 DataKit 采集后直接写入观测云的云端时序存储，查询用 DQL，底层容量与性能由平台承担——不需要调 query.timeout，也不需要维护 Thanos 集群。
常见问题（FAQ）
Q：只是偶尔报一次需要处理吗？ 偶发一般是瞬时高负载，观察即可；频繁出现就要按上文排查。
Q：grafana 面板超时但 Prometheus 后台查很快？ 多半是 Grafana 数据源超时设置太短，或面板一次查询的序列过多，减少面板上的查询数量试试。
