跳到主要内容

异常告警

1. 定义与边界​

异常告警是对 Agent 生产系统中影响用户、成本、安全或业务状态的异常进行自动通知和处置。它不同于日志搜索；告警必须有明确影响、阈值、负责人和处理动作。

2. 为什么重要​

Agent 问题可能迅速扩大：工具循环导致费用飙升，提示注入导致数据外泄，模型延迟导致用户排队，权限策略误配导致大量任务失败。告警的目标是及时发现对用户和业务有影响的问题。

3. 核心机制​

告警按信号分类：

类型示例
可用性错误率、超时率、任务失败率
质量成功率下降、人工接管率上升、负反馈上升
成本token 暴涨、单位成功成本超预算
安全越权工具调用、注入命中、数据外泄风险
依赖工具服务 5xx、检索服务不可用、模型 API 429

4. 工程实现​

告警规则示例：

alerts:
  - name: agent_high_risk_tool_denied_spike
    query: rate(tool_call_denied{risk="high"}[5m]) > 0.05
    severity: page
    runbook: "runbooks/high-risk-tool-denied.md"
  - name: cost_per_success_spike
    query: p95(unit_success_cost_usd[15m]) > 2 * baseline
    severity: ticket
  - name: unsafe_action_detected
    query: count(unsafe_action[1m]) > 0
    severity: page

5. 生产实践​

  • 告警应基于用户影响和 SLO，而不是所有内部异常都 page。
  • 设置 burn rate 或多窗口告警，兼顾快速事故和慢性退化。
  • 每条告警必须有 runbook：怎么看、找谁、如何降级、如何回滚。
  • 安全告警优先级高于普通质量告警。

6. 常见反模式​

  • 告警太多，团队开始忽略。
  • 没有区分 page、ticket、dashboard。
  • 告警只说“失败了”，不带 trace 示例和切片。
  • 只监控系统错误，不监控质量和安全退化。

7. 评测方法​

指标解释
Alert Precision告警中真正需要处理的比例
Mean Time to Detect平均发现时间
Mean Time to Mitigate平均缓解时间
False Positive Rate误报比例
Runbook Coverage告警是否有处理手册

8. 安全与治理​

高风险动作、权限变更、外部发送、敏感数据访问要有更严格告警。告警通知本身不能泄漏敏感数据，消息中应放摘要和安全链接。

9. 权威资料​

16. 主控验收清单​

  • 是否区分 page、ticket、dashboard 三类告警。
  • 是否每条 page 告警都有 runbook。
  • 是否告警表达式基于用户影响或安全影响。
  • 是否设置 SLO burn rate 告警。
  • 是否安全 critical 事件一票 page。
  • 是否有成本预算告警。
  • 是否有 trace/log drop 告警。
  • 是否有 DLQ 和队列 oldest age 告警。
  • 是否告警消息不包含敏感数据。
  • 是否有自动回滚或禁用工具的止血动作。
  • 是否定期复盘误报和漏报。
  • 是否记录 MTTD、MTTR 和告警噪声。
  • 是否有升级路径和备用联系人。
  • 是否在维护窗口设置明确抑制规则。
  • 是否避免全局静默安全告警。
  • 是否将事故样本回流到回归测试。
  • 是否按租户和版本分片看告警。
  • 是否对告警阈值有变更审计。
  • 是否验证告警在预发环境可触发。
  • 是否每季度演练关键告警 runbook。
  • 是否记录每次告警的处理结论。
  • 是否把重复告警合并为一个 incident。
  • 是否为供应商故障准备降级告警。
  • 是否为模型质量突然下降准备业务指标告警。
  • 是否为人工审批积压准备 SLA 告警。
  • 是否为成本熔断触发准备用户体验监控。
  • 是否为安全拦截率异常下降准备漏报告警。
  • 是否为用户负反馈突增准备质量告警。
  • 是否为回放失败准备评测基础设施告警。
  • 是否为数据延迟准备仪表盘可信度提示。
  • 是否为 webhook 失败准备补偿任务告警。
  • 是否对告警权限和通知群组做定期复核。
  • 是否要求告警关闭时填写根因或处置摘要。
  • 是否把关键告警纳入新员工值班演练。
  • 是否对告警规则进行版本管理。
  • 是否在发布期间提高相关指标敏感度。
  • 是否对告警风暴有降噪但不断安全事件的策略。

10. 二次精修：Agent 告警分层​

Agent 告警要区分用户体验、业务正确性、安全、成本和平台可靠性。不要只盯 HTTP 500。

告警类示例指标处理优先级
SLOTSR 下降、P95 延迟升高高
Safetyforbidden tool、数据泄露最高
Costcost per success 飙升高
Tool工具超时、下游 5xx中高
Queueoldest message age、DLQ中高
Observabilitytrace drop、日志丢失中

11. 告警规则示例​

alerts:
  - name: "UnsafeActionDetected"
    expr: "sum(rate(agent_unsafe_action_total[5m])) > 0"
    severity: "critical"
    runbook: "ops/runbooks/unsafe-action.md"
  - name: "TaskSuccessDrop"
    expr: "task_success_rate_30m < baseline_task_success_rate * 0.95"
    severity: "page"
    runbook: "ops/runbooks/task-success-drop.md"
  - name: "QueueOldestMessageHigh"
    expr: "queue_oldest_message_age_seconds > 300"
    severity: "warning"
    runbook: "ops/runbooks/queue-lag.md"

12. 告警处理流程​

13. SLO 与告警原则​

  • 告警应基于用户影响和 SLO burn rate，避免每个 500 都 page。
  • 安全类告警可以不等 SLO，critical 样本一票触发。
  • 告警通知只放摘要和安全链接，不放敏感 prompt、工具参数或用户数据。
  • 每条 page 级告警必须有 owner、runbook、升级路径和回滚动作。
  • 抑制规则要谨慎，不能把安全事件压掉。

14. 告警质量指标​

指标说明
Precision触发后确实需要处理的比例
Recall真实事故被告警覆盖的比例
MTTD平均发现时间
MTTR平均恢复时间
Noise Rate无效告警比例
Runbook Coverage有处置手册的告警比例

15. 补充权威资料​