网站和接口监测：能打开，不代表关键任务已经完成

先问用户依赖哪一个结果

假设团队每天早上需要查看昨日报表。网站能打开、接口返回 HTTP 200，并不能证明报表已更新。监测应读取约定的报表期间或任务产出时间，再判断它是否满足当天使用需要。HTTP 状态表达请求结果，业务是否正确还要按应用约定核对。

检查范围从少数关键页面和任务开始。探测尽量使用确认为只读的接口或隔离的测试路径，不通过反复提交真实询价、订单或付款来验证系统。

告警条件应避免一次抖动触发一串消息

可以配置“连续三次失败后创建事件，连续两次成功后标记恢复”作为初始测试规则。这个数字是示例，实际频率和阈值需按业务容忍度、访问成本及来源限制确定，不能据此承诺可用性。

同一个检查项持续失败时，更新同一事件的持续时间和最近结果；状态显著变化或超过约定时间再升级提醒。恢复通知关联原事件，说明恢复时间及验证结果。这样负责人看到的是一次故障的进展，而不是几十条无法对应的失败消息。

监测本身也会失败

应区分目标服务失败、探测器无法执行、通知发送失败。探测器自己的网络中断不能直接证明所有目标宕机；通知发送失败也不能让系统把事件误标为已通知。事件页保留最后一次实际探测时间，超过约定间隔时显示监测状态未知。

处理人收到通知后可以登记接手、判断、临时措施和下一次检查。自动监测提供证据，是否重启、回退或更改配置由有权限的人员决定；第一版不必把故障发现与自动修复绑在一起。

日志要够定位，但不要塞进整份业务数据

记录检查编号、发生时间、目标标识、耗时、状态、请求关联编号和必要的错误摘要。OWASP 的日志指南强调保留事件定位信息，并避免直接记录访问令牌、密码等敏感内容。对于客户资料，用受控记录编号关联，通常比复制完整请求正文更合适。

若响应中含密钥或个人信息，告警摘要应先去除这些内容。详细日志的查看权限和保留周期单独设置，公开状态页只展示适合公开的信息。

验收一次完整的“失败到恢复”

1. 用测试路径制造超时，确认按阈值生成单一事件。
2. 让接口返回正常状态但缺少必要字段，确认内容检查失败。
3. 保持页面在线但使用过期报表，确认新鲜度告警。
4. 模拟通知失败，检查是否保留待通知状态。
5. 恢复后确认事件闭合，日志中没有令牌和客户正文。