告警出现时，最容易浪费时间的做法是同时改配置、翻日志和猜测原因。先回答三个问题：用户是否受影响、影响从哪个版本或依赖开始、哪条路径需要先恢复。
本文讨论已有基础日志和监控后，如何处理一次告警。若你正在搭建第一套日志、指标和追踪，先读《可观测性起步：为关键用户路径接入日志、指标与追踪》。复核日期为 2026-09-05。
先确认影响和优先恢复的路径
从用户能感知的结果开始，而不是从 CPU 利用率开始。例如：登录后能读取核心数据、支付回调能被处理、创建任务后最终状态可见。为每条路径确定一个隔离、可重复、不会写入真实业务数据的检查方法。
健康检查可以分层：存活检查回答进程是否响应；就绪检查回答是否应接收流量；业务检查回答用户的关键动作是否成立。不要把支付、发邮件或创建真实订单塞进高频探针。检查失败时，应保留时间、版本、环境和失败阶段，供后续排查。
用现有信号缩小范围
OpenTelemetry 将 traces、metrics 和 logs 作为已支持的遥测信号：追踪记录请求经过的路径，指标记录运行时测量，日志记录事件。它们不是必须同时接入的套餐，而是回答不同问题的证据。详见 OpenTelemetry：遥测信号。
| 需要回答的问题 | 优先信号 | 起步做法 |
|---|---|---|
| 服务或关键路径是否异常？ | 指标与合成检查 | 记录成功/失败、延迟和版本；按路径和环境分组。 |
| 一次失败发生了什么？ | 结构化日志 | 记录请求或任务 ID、操作、结果、耗时和安全的错误分类。 |
| 请求在哪个依赖环节变慢或失败？ | 追踪 | 让跨服务调用共享 trace ID，并为外部调用标注时长与结果。 |
日志不要只写一句“失败了”。使用稳定字段名，保留关联 ID，但避免记录密码、访问令牌、完整支付信息或不必要的个人数据。OpenTelemetry 建议生产环境使用结构化日志，便于验证、解析与关联，详见 日志信号文档。
把告警写成可执行的动作
每条告警都应能回答：谁接收、在什么时间段响应、先执行什么检查、什么情况下升级或停止。若无人能在收到后行动，它更适合日报或仪表盘，而不是即时通知。
告警条件应来自自身的正常基线与用户影响，不应从模板复制固定百分比。先为“关键路径持续失败”“错误突然增多”“任务长时间不完成”等少量情形建立告警，观察误报和遗漏后再调整。让恢复条件与触发条件同样清楚，避免事故已经结束却持续叫醒人。
一次告警的处理顺序
- 确认告警是否影响真实用户路径，并标记开始时间和当前版本；
- 限制影响：暂停有风险的任务、关闭新入口、回退配置或流量；
- 使用请求 ID、结构化日志和追踪缩小故障范围；
- 恢复后记录触发证据、动作、影响、恢复验证和待办。
不要在同一事件中同时重构、换监控系统和修改多个基础设施配置。先恢复路径，再把本次缺失的证据或检查补进系统。发布阶段怎样定义停止条件和恢复方式，可参考《发布与回滚：先设计停止条件，再改生产环境》。
事件结束后补齐什么
- 有一条隔离的关键路径检查，失败时能识别版本与环境。
- 应用日志为结构化格式，含关联 ID、操作、耗时、结果和已脱敏的错误信息。
- 外部请求、队列任务和数据库操作在需要时能关联到同一次请求。
- 即时告警数量有限，且每条都有明确的接收者与处理动作。
- 备份、恢复与监控本身的失效方式被定期演练。
每次事件都应留下一个改动：补一条检查、补一个字段、改一条告警，或写清一个恢复步骤。这样下一次告警会更容易处理。
参考资料
- OpenTelemetry：遥测信号（复核于 2026-09-03）
- OpenTelemetry：日志（复核于 2026-09-03）
- OpenTelemetry：可观测性概述（复核于 2026-09-03）