主机监控：故障排查与值班交接

状态、入口与接班条件

状态：PENDING（待目标环境验证）。本篇是故障处置方案，没有已运行平台、通知演练或恢复成绩。实施方完成部署配置后，需补齐组件版本、资产范围、值班负责人和独立通知渠道。下面只读示例不构成重启或改配置授权，占位符必须先替换并核验。

接到“主机失联”时先记录告警首次出现时间、最后正常样本、影响资产及最近变更。通过独立业务检查判断是否真的影响服务；监控自身不可用时，不应继续用同一套看板证明业务正常。

第一轮只读取证

在获准的 Prometheus 查询入口检查以下请求，不访问管理接口。targets 可能包含内部资产信息，输出只保留相关目标，脱敏后入事件记录。

GET /api/v1/targets?state=any
GET /api/v1/rules?type=alert
GET /api/v1/alerts

从 targets 记录 discoveredLabels、最终 labels、lastError、lastScrape 与抓取耗时，规则记录健康状态和实际表达式。字段含义见 Prometheus 查询 API。同一时段的比较必须固定时区，不能拼接不同时间截图得出链路结论。

分支一：目标消失还是抓取失败

• 资产应存在却不在 active targets：查发现源是否返回资产，再比较 dropped targets 和最近 relabel 配置。被过滤目标的保留数量可能受限，“未找到 dropped 记录”也不是未被过滤的证明。
• active targets 存在但 up=0：按最近错误区分 DNS、连接、TLS、认证和超时；证书错误交给证书责任人，不关闭校验。多台同网段同时失败时先检查公共路径，不逐台重启。
• up=1 但挂载点缺失：比较 exporter 的宿主机视角、采集器配置与挂载过滤；抓取成功只证明一次请求成功，不能证明指标齐全。

在已获准主机上可检查实际服务单元和挂载状态；服务名须以资产记录为准。

systemctl status '<EXPORTER_UNIT>' --no-pager
df -hT
df -i

分支二：规则触发却没有通知

先区分规则未加载、表达式无结果、pending 和 firing。只有确认 firing，才进入 Alertmanager 的接收、路由、分组、静默及抑制检查。用相同标签追踪，避免把名称相似的另一条告警当作证据。

若接收器已发送成功但人未收到，交给通知渠道负责人核对拒收、群成员和投递回执；不要反复制造真实故障催通知。维护静默须核对对象和到期时间，分组等待会影响首条通知时延，参见 Alertmanager 通知机制。

分支三：看板空白或数值突变

Prometheus 原始查询有数据而 Grafana 无数据时，依次比较数据源、时间范围、变量最终值、单位与查询步长。若重标记改变了 instance，旧变量可能只查询旧序列；若 exporter 重启导致计数器归零，不能直接将累计值差额当业务突降。只有原始样本也异常，才回到采集和主机证据，不把改看板作为消除真实异常的方法。

风险动作与恢复验收

规则恢复、目标回退、服务重启、静默创建和保留期调整都需记录审批人、范围、预期影响及恢复点。优先撤回已确认有问题的一批配置；不清空时序数据，也不把全局静默当降噪。触及业务资源阈值或影响面扩散时，停止新增接入并升级。

恢复后按事先约定窗口连续核对目标覆盖、抓取时间、关键指标和规则状态，再由接收人确认带测试标签的触发与恢复通知。验收应涵盖公共故障路径中的代表资产，不能只挑已恢复的一台。未通过项保持 PENDING，按运行维护持续观察。

值班交接模板

状态：PENDING / 排查中 / 观察中 / 已验收（须附证据）
事件编号、接班人、交接时间及时区：待填写
受影响资产、业务影响、最后正常时间：待填写
诊断分支与支持/反对证据：待填写
最近配置版本、已执行动作及批准人：待填写
遗留静默、临时权限及到期负责人：待填写
验收窗口、未恢复目标、下一检查时间：待填写
证据位置、升级联系人、停止条件：待填写

接班人应独立打开一条目标和对应规则，复述剩余风险；“无新增告警”不能替代签收。告警治理细节见分级与降噪实践。