本篇是《Prometheus 从入门到生产实践》第 18 / 24 篇。配置以文中版本与环境前提为准，实验和故障均为教学场景。完整程序、配置及校验范围见配套实验包。
告警没响、Grafana 没数据、Targets 一片红，表面上都可能叫“Prometheus 不正常”，实际却位于不同层。本篇把前面的知识连成一条故障排查路径，用可观察证据决定下一步，而不是先重启所有组件。
1. 固定一次排查的对象和时间
先记录完整目标、job/instance 标签、发生时间和时区、期望结果、最近变更。确认连接的是哪一套 Prometheus，Grafana 数据源有没有指向另一个环境，查询时间是否覆盖故障时段。
同一个 exporter 若被两个 job 抓取，或同一环境有两个副本，看到的 up、告警和图表可能不是同一对象。每走一层，都保留用于定位的稳定标签，不要在排查中悄悄换对象。
| 层次 | 首先要证明什么 |
|---|---|
| 进程与入口 | 实例可访问，并准备响应查询 |
| 配置与发现 | 配置已生效，目标确实进入发现结果 |
| 抓取 | 最终 URL 能返回合规指标 |
| 查询 | 数据存在且表达式标签、类型与时间正确 |
| 规则 | 规则加载、健康、身份稳定且达到条件 |
| 通知 | Alertmanager 收到、路由命中、接收端接受 |
2. 入口能访问，不等于实例已准备好
对本地实验先做只读探测：
curl --max-time 5 -i http://127.0.0.1:19090/-/healthy
curl --max-time 5 -i http://127.0.0.1:19090/-/ready
healthy 与 ready 是不同检查。ready 用来确认实例已准备服务查询，不能代替业务数据正确性。启动时 WAL 回放等过程可能需要时间，应结合日志判断，不能看到等待就删除数据目录。
入口受 TLS/认证保护时，要使用第 15 篇对应的信任与身份。接口定义见 Management API 文档。
3. 配置修改后，先查加载是否成功
promtool check config prometheus.yml
检查通过，再使用当前部署约定的重载方式；HTTP reload 默认关闭，不能不看启动参数就连续请求。查看实例日志和当前生效配置，确认它读取的是自己刚改的文件。
可查询 prometheus_config_last_reload_successful 等自监控指标，但要以本机版本实际暴露的指标为准。磁盘文件修改时间较新，不等于运行中的配置已更新；失败重载也可能让实例继续保留旧配置。
Operator 环境则回到对象、事件、控制器和生成配置的链路，而不是编辑被管理的容器文件。
4. 目标不存在和目标 down 分开处理
查询活动目标 API，或直接打开 Targets 页面：
curl --max-time 5 'http://127.0.0.1:19090/api/v1/targets?state=active'
目标根本不在列表时，查服务发现、权限、命名空间、标签选择器和 relabel 丢弃条件。目标存在但 up=0 时，读取最近抓取错误和最终 scrape URL。
从 Prometheus 实际运行位置测试 exporter：
curl --connect-timeout 3 --max-time 5 -i \
http://127.0.0.1:19100/metrics
容器中的回环地址不等于宿主机。浏览器所在电脑能访问，也不能证明 Prometheus 的网络路径可达。连接拒绝查监听和端口，超时查路径与响应，404 查路径，401/403 查身份，证书错误查信任和名称，解析错误查正文和 Content-Type。
样本、标签或正文大小限制超出时，也可能让抓取失败。不要只确认 HTTP 200：一个登录页或错误 HTML 同样可以返回 200。
5. up=1，但图表没有数据怎么办
先用最小选择器查询原始指标：
ops_demo_requests_total{job="demo"}
确认指标名、标签和值真实存在，再增加 rate、聚合与筛选。短窗口内点数不够、counter 刚出现、过滤条件过严、标签在重部署后改变，都可能让复杂表达式没有结果。
接着观察：
sum by (code) (rate(ops_demo_requests_total{job="demo"}[5m]))
如果原始指标有值而这个表达式为空，优先检查历史样本和窗口，而不是马上往外加 or vector(0)。如果只在 Grafana 空白，比较数据源、时区、时间范围、变量展开、查询 step 与面板单位。
向量匹配错误、分母为零和没有数据是不同问题。HTTP API 还可能携带 warnings 或 infos，不能只看最外层 HTTP 状态就忽略查询结果的语义。查询接口见 HTTP API 参考。
6. 表达式异常成立，告警仍不 firing
查看 Rules 和 Alerts：规则是否已加载，评估是否报错，当前实例是否 pending，for 是否达到，标签是否每次变化。检查规则组是否因为查询过重而无法按期完成。
用前面提供的单元测试重放固定输入，可以验证表达式与持续时间的预期；如果合成测试通过而线上不成立，应比较实际输入数据，不要只改测试预期。
还要确认没有把不断变化的 $value 放入 labels，导致每次求值都生成新实例。保持标签身份稳定，把当前值放进 annotations，是持续告警能够正常计时的基础。
7. firing 已出现，接收端仍没消息
先在 Alertmanager 查看相同标签集合，或只读查询：
amtool --alertmanager.url=http://127.0.0.1:19093 alert query
实例没到达时，检查 Prometheus 配置的 Alertmanager 地址、网络、认证和通知相关错误。实例已到达时，检查实际命中的路由、静默、抑制、group_wait、group_interval 和接收端返回状态。
webhook 返回 2xx 说明该 HTTP 接收器接受了请求，不一定代表后续聊天平台或手机已收到。真正的验收需要继续追到最终接收端，并核对恢复消息。
8. 所有目标一起异常，先看共同依赖
如果只有一个目标 down，优先沿该目标链路检查；如果大量不相关目标在同一时间异常，应寻找共同变化：采集器所在节点、网络出口、DNS、凭据、配置加载或资源压力。逐台重启被监控应用，往往无法修复位于共同路径上的故障。
但“同一时间”也要以统一时区和实际采样为准。多个目标的抓取周期可能错开，面板的时间聚合也可能让它们看起来同时变化。先确认原始时间与错误类型，再判断是否同一根因。
查询变慢时，不要只增加超时。先缩小时间范围、去掉高基数分组，确认返回序列数和扫描样本规模，再检查存储、压缩及内存压力。规则和交互查询共享资源时，一个昂贵面板也可能影响告警求值，这是需要通过自监控和容量规划看见的关联。
9. 保存能复盘的证据
修复记录至少包含原始错误、受影响对象与标签、变更前后配置差异、实际根因和恢复验证。敏感凭据不进入记录，完整日志也不必无差别复制，只保留与时间和对象对应的必要部分。
恢复还要看持续性。单次采集成功或某次 webhook 返回正常，只说明那一次操作通过；观察数个采集和求值周期，确认队列、规则与错误计数没有继续恶化，才能判断系统回到稳定状态。
最后区分事件恢复与监控改进。业务已经恢复，但缺少数据消失告警、接收端错误无人监测或配置发布没有验证，仍应作为后续行动项。把这些改进交给明确负责人，故障排查才能为下一次减少实际成本。
10. 用一个可控故障完成闭环
只停止自己专用实验的 demo exporter，记录 up 变化、DemoTargetDown 的 pending/firing、Alertmanager 实例和 webhook 时间。恢复 exporter，再记录 up=1、规则解除和恢复通知。
一次只改变一个条件。若同时改端口、规则、路由和接收器，恢复后也很难知道哪项真正起作用。把根因、修改位置、修复证据和缺少的监控补项写进记录，下次值班才有可复用的手册。
上一篇：Prometheus Operator：选择器、ServiceMonitor 与规则管理 · 系列目录 · 下一篇：TSDB 存储与容量：Head、WAL、保留策略和备份恢复