运维诊断智能体设计文档
智能体名称: 运维诊断智能体 (Ops Diagnosis Agent) 优先级: ⭐⭐⭐ (中高优先级) 技术栈: Python 3.11 + LangGraph + Claude 3.5 Sonnet + ELK + Prometheus 文档版本: v1.0 最后更新: 2025-10-28
一、功能概述
基于LangGraph的多智能体协作系统,通过分析日志、监控指标和调用链路,实现故障的智能诊断和根因分析,提供可执行的解决方案和预防措施。
核心价值
- 快速定位: MTTR从45分钟降至10分钟,缩短78%
- 准确诊断: 根因定位准确率>85%
- 主动预防: 基于历史故障预测潜在问题
- 经验积累: 建立故障知识库,持续学习
二、LangGraph工作流设计
2.1 多智能体架构
主诊断智能体 (Coordinator Agent)
- 协调其他子智能体的工作
- 汇总分析结果
- 进行根因推理
- 生成诊断报告和解决方案
子智能体列表:
- 日志分析智能体 - 从ELK分析应用日志和错误日志
- 指标分析智能体 - 从Prometheus分析监控指标
- 链路追踪智能体 - 从SkyWalking分析调用链路
- 知识库检索智能体 - 从Milvus检索相似历史故障
2.2 工作流状态定义
输入状态:
- alert_message: 告警信息
- service_name: 服务名称
- timestamp: 故障时间
- alert_level: 告警级别
中间状态:
- logs: 相关日志数据
- metrics: 监控指标数据
- traces: 调用链路数据
- similar_incidents: 相似历史故障
- log_analysis: 日志分析结果
- metric_analysis: 指标分析结果
- trace_analysis: 链路分析结果
输出状态:
- root_cause: 根本原因
- impact_assessment: 影响评估
- fix_suggestions: 解决方案列表
- prevention_measures: 预防措施
- confidence_score: 诊断置信度
2.3 工作流流程
告警触发
↓
主诊断智能体启动
↓
并行执行子智能体:
├─ [日志分析智能体] → 分析错误日志和堆栈
├─ [指标分析智能体] → 分析CPU/内存/网络
├─ [链路追踪智能体] → 分析调用关系
└─ [知识库检索智能体] → 检索相似故障
↓ 汇总
主诊断智能体:
├─ 综合分析所有数据
├─ 推理根本原因
├─ 评估影响范围
└─ 生成解决方案
↓
输出诊断报告
↓
保存到知识库
↓
结束
三、子智能体设计
3.1 日志分析智能体
功能:
- 从ELK获取指定时间范围的日志
- 识别错误日志和异常堆栈
- 分析错误模式和频率
- 提取关键错误信息
输入: 服务名、时间范围 输出: 日志分析结果(错误类型、堆栈信息、错误频率)
实现要点:
- 使用Elasticsearch Query DSL查询日志
- 支持日志格式解析(JSON、Plain Text)
- 识别常见错误模式(OOM、NPE、超时等)
- 聚合相似错误,避免重复
Prompt模板:
分析以下日志,找出异常模式和错误原因:
## 日志数据
{logs}
## 分析要求
1. 识别所有ERROR和FATAL级别日志
2. 提取异常堆栈信息
3. 识别错误模式(如重复出现的错误)
4. 分析错误发生时间分布
5. 提取关键错误关键词
## 输出格式
返回JSON格式:
- error_type: 错误类型
- stack_trace: 堆栈信息
- frequency: 错误频率
- key_keywords: 关键词列表
- possible_causes: 可能原因
3.2 指标分析智能体
功能:
- 从Prometheus查询监控指标
- 分析指标异常(突增、突降、阈值超限)
- 识别指标关联关系
- 判断性能瓶颈
输入: 服务名、时间范围 输出: 指标分析结果(异常指标、趋势、关联关系)
关键指标:
- CPU使用率
- 内存使用率
- 请求量(QPS)
- 错误率
- 响应时间(P50/P95/P99)
- 数据库连接数
- 线程池使用率
Prompt模板:
分析以下监控指标,找出异常和性能瓶颈:
## 指标数据
CPU使用率: {cpu_usage}
内存使用率: {memory_usage}
请求量: {request_count}
错误率: {error_rate}
响应时间P99: {response_time_p99}
## 历史基线
正常CPU使用率: 20-40%
正常内存使用率: 50-70%
正常错误率: <1%
正常响应时间: <200ms
## 分析要求
1. 识别异常指标(超过基线)
2. 分析指标之间的关联关系
3. 判断是否存在性能瓶颈
4. 评估资源使用是否合理
## 输出格式
返回JSON格式:
- abnormal_metrics: 异常指标列表
- correlations: 指标关联关系
- bottleneck: 性能瓶颈
- resource_status: 资源状态评估
3.3 链路追踪智能体
功能:
- 从SkyWalking获取调用链路
- 识别慢请求和失败请求
- 分析服务依赖关系
- 定位问题服务节点
输入: Trace ID、时间范围 输出: 链路分析结果(慢服务、失败节点、调用关系)
Prompt模板:
分析以下调用链路,找出性能瓶颈和失败节点:
## 链路数据
{traces}
## 分析要求
1. 识别耗时最长的服务调用
2. 识别失败的调用节点
3. 分析服务依赖关系
4. 判断是否存在级联失败
## 输出格式
返回JSON格式:
- slow_services: 慢服务列表
- failed_nodes: 失败节点
- dependencies: 依赖关系图
- cascade_failure: 是否级联失败
3.4 知识库检索智能体
功能:
- 向量化当前故障描述
- 从Milvus检索相似历史故障
- 提取历史故障的解决方案
- 评估相似度和适用性
输入: 故障描述、错误信息 输出: 相似故障列表及其解决方案
检索策略:
- 使用Claude生成故障描述的Embedding
- Top-K检索(K=5)
- 相似度阈值>0.8
- 按时间倒序排列(优先最近的故障)
四、主诊断智能体
4.1 根因推理Prompt
基于以下信息,诊断故障根本原因:
## 故障信息
- 服务名称: {service_name}
- 故障时间: {timestamp}
- 告警信息: {alert_message}
## 日志分析
{log_analysis}
## 指标分析
{metric_analysis}
## 链路分析
{trace_analysis}
## 相似历史故障
{similar_incidents}
## 分析要求
1. 综合所有信息推理根本原因
2. 评估根因推理的置信度(0-100%)
3. 分析故障影响范围和严重程度
4. 提供3个解决方案,按优先级排序
5. 提出预防措施
## 输出格式
返回JSON格式:
{
"root_cause": "根本原因描述",
"confidence": 85,
"impact": {
"severity": "HIGH",
"affected_services": ["service1", "service2"],
"user_impact": "影响描述"
},
"solutions": [
{
"priority": 1,
"description": "解决方案描述",
"steps": ["步骤1", "步骤2"],
"estimated_time": "预计时间",
"risk": "风险评估"
}
],
"prevention": ["预防措施1", "预防措施2"]
}
4.2 诊断报告格式
# 🚨 故障诊断报告
**故障编号**: #INCIDENT-20251028-001
**诊断时间**: 2025-10-28 15:30:00
**诊断耗时**: 2分15秒
---
## 📊 故障概览
- **服务名称**: maiban-payment-service
- **故障时间**: 2025-10-28 15:15:00
- **告警级别**: CRITICAL
- **影响范围**: 支付功能完全不可用
- **影响用户**: 约500用户
---
## 🔍 根因分析
**根本原因**: 数据库连接池耗尽导致服务阻塞
**置信度**: 95%
**详细分析**:
1. 日志显示大量"Connection timeout"错误
2. 数据库连接数达到最大限制(200)
3. 慢SQL导致连接长时间占用
4. 未及时释放连接,连接泄漏
**证据链**:
- 日志: 15:15:00开始出现Connection timeout
- 指标: DB连接数在15:14:30达到200并保持
- 链路: 支付订单查询接口耗时从200ms暴涨至30s
---
## 💡 解决方案
### 方案1: 重启服务释放连接 (推荐)
**优先级**: 🔴 最高
**预计时间**: 5分钟
**风险**: 低
**执行步骤**:
1. 滚动重启payment-service实例
2. 监控服务恢复状态
3. 验证支付功能正常
### 方案2: 调整数据库连接池配置
**优先级**: 🟡 中等
**预计时间**: 10分钟
**风险**: 中(需重启服务)
**执行步骤**:
1. 增大连接池最大连接数: 200 → 300
2. 调整连接超时时间: 30s → 60s
3. 重启服务使配置生效
### 方案3: 优化慢SQL
**优先级**: 🟢 低(长期优化)
**预计时间**: 1小时
**风险**: 低
**执行步骤**:
1. 分析慢查询日志
2. 添加缺失索引
3. 优化查询语句
---
## 🛡️ 预防措施
1. **监控增强**: 添加数据库连接数告警(阈值180)
2. **代码审查**: 检查是否正确释放数据库连接
3. **压测验证**: 模拟高并发场景验证连接池配置
4. **自动扩容**: 配置HPA根据连接数自动扩容
---
## 📈 相似历史故障
**故障#INCIDENT-20251015-003** (相似度: 92%)
- 时间: 2025-10-15
- 原因: 连接池耗尽
- 解决方案: 优化慢SQL,增大连接池
- 效果: 故障未再复现
---
## 🤖 AI诊断说明
- 数据来源: ELK日志、Prometheus指标、SkyWalking链路
- 分析模型: Claude 3.5 Sonnet
- 置信度评估: 基于证据链完整性和历史案例匹配度
💡 **建议**: 立即执行方案1恢复服务,后续执行方案2和方案3进行优化
五、触发方式
5.1 Prometheus告警触发
AlertManager配置:
receivers:
- name: 'ai-ops-webhook'
webhook_configs:
- url: 'https://ai-agents.maiban.com/api/v1/alerts/prometheus'
send_resolved: true
route:
group_by: ['alertname', 'service']
receiver: 'ai-ops-webhook'
routes:
- match:
severity: critical
receiver: 'ai-ops-webhook'
continue: true
告警规则示例:
- alert: HighErrorRate
expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
for: 2m
labels:
severity: critical
ai_diagnosis: enabled
annotations:
summary: "服务错误率过高"
description: "{{ $labels.service }}错误率超过5%"
5.2 主动巡检
定时任务:
- 每小时检查关键服务健康状况
- 每天生成服务健康报告
- 发现异常主动触发诊断
六、数据来源集成
6.1 ELK集成
Elasticsearch查询:
query = {
"bool": {
"must": [
{"match": {"service": service_name}},
{"range": {"@timestamp": {"gte": start_time, "lte": end_time}}},
{"terms": {"level": ["ERROR", "FATAL"]}}
]
}
}
6.2 Prometheus集成
查询示例:
# CPU使用率
query = f'rate(process_cpu_seconds_total{{service="{service}"}}[5m])'
# 内存使用率
query = f'process_resident_memory_bytes{{service="{service}"}}'
# 请求错误率
query = f'rate(http_requests_total{{status=~"5..",service="{service}"}}[5m])'
6.3 SkyWalking集成
GraphQL查询:
query {
queryBasicTraces(condition: {
serviceId: "payment-service"
traceState: ERROR
queryDuration: {
start: "2025-10-28 1500"
end: "2025-10-28 1530"
}
}) {
traces {
traceId
duration
isError
endpointNames
}
}
}
七、成本控制
成本目标: <$10/次诊断
优化策略:
- 故障数据预处理(聚合、过滤)减少Token消耗
- 日志只分析ERROR和FATAL级别
- 指标只查询关键指标(CPU、内存、错误率)
- 知识库命中直接复用解决方案
- 使用Claude Sonnet,复杂推理使用Opus
八、效果评估
诊断效率:
- 平均诊断耗时: <5分钟
- 根因定位准确率: >85%
- MTTR: 从45分钟降至10分钟
知识积累:
- 故障案例库: 持续增长
- 解决方案复用率: >60%
- 新故障学习周期: <24小时
文档维护者: AI团队 技术负责人: 待定 创建日期: 2025-10-28 最后更新: 2025-10-28
