SuperBizAgent-java/knowledge_base/troubleshooting/aiops-alert-runbook.md

title, keywords, summary, category

title	keywords	summary	category
AIOps 告警排障 Runbook	AIOps 告警 HighCPUUsage SlowResponse payment-service system-metrics application-logs	面向 AIOps 告警诊断的排障步骤，覆盖 Prometheus 活动告警、CLS 日志主题和处理建议。	troubleshooting

AIOps 告警排障 Runbook

1. 告警输入处理原则

AIOps 诊断入口有两种触发方式：

• 有告警 payload：将 payload 视为已触发告警，围绕 alertName、service、severity、timeRange 查询指标、日志和知识库。
• 无告警 payload：先调用 queryPrometheusAlerts 获取当前 firing 告警，再选择 P0/P1 或持续时间最长的告警进入诊断。

最终报告必须基于工具证据，不得凭空编造指标、日志或处理结果。

2. Mock 告警与日志主题映射

告警名	典型服务	优先日志主题	推荐查询
HighCPUUsage	payment-service	system-metrics	cpu_usage:>80 AND service:payment-service
HighMemoryUsage	order-service	system-metrics, system-events	memory_usage:>85
SlowResponse	user-service	application-logs, database-slow-query	duration:>3000 OR slow request
ServiceUnavailable	任意核心服务	application-logs, system-events	level:ERROR OR container crash

3. HighCPUUsage / payment-service 排障步骤

3.1 现象确认

先确认 Prometheus 活动告警中是否存在：

• alert_name = HighCPUUsage
• service = payment-service
• CPU 使用率超过 80%
• 状态为 firing

如果 payload 已经提供该告警，也仍需通过指标或日志工具验证。

3.2 指标与日志取证

推荐工具调用顺序：

1. queryPrometheusAlerts：确认当前活动告警。
2. queryLogs(region=ap-guangzhou, logTopic=system-metrics, query=cpu_usage:>80 AND service:payment-service)：确认 CPU 使用率、实例和持续时间。
3. 如报告中提到 Redis、数据库或下游依赖，再查询 application-logs 或对应主题交叉验证。

3.3 根因判断

可接受的根因结论必须至少满足一项：

• system-metrics 显示 payment-service 实例 CPU 使用率持续高于阈值。
• application-logs 显示与 CPU 飙高同时出现的慢请求、线程池耗尽或依赖超时。
• 告警持续时间与日志时间线一致。

如果只有活动告警，没有日志或指标明细，应输出低置信结论并建议人工确认。

4. 处理建议

临时止血

• 对 payment-service 做水平扩容，优先扩容受影响实例所在 Deployment。
• 对高耗时接口开启限流或降级非核心功能。
• 如果近期有发布，检查变更窗口并准备回滚。

根因修复

• 分析 CPU 热点线程、慢请求接口和依赖调用耗时。
• 检查连接池、线程池、缓存穿透和批量任务是否导致 CPU 飙高。
• 补充针对 payment-service 的 CPU、P95/P99 延迟、错误率和依赖超时联动告警。

5. 报告要求

告警分析报告至少包含：

• 活跃告警清单。
• 告警根因分析。
• 使用过的工具证据：Prometheus 告警、system-metrics 日志、application-logs 或知识库。
• 已执行或建议执行的处理方案。
• 置信度说明：哪些结论有直接证据，哪些需要人工进一步确认。