麦瓣健康麦瓣健康
首页
  • APP产品开发方案
  • 商业调查报告
  • 后端技术架构
  • Docker Compose部署指南
  • 技师端-功能模块与微服务对应关系
  • 数据库设计
  • 分布式事务一致性
  • 日志管理与配置
  • Netdata监控系统
  • 系统总览
  • 文档导航
  • 代码审计智能体
  • 测试生成智能体
  • 运维诊断智能体
  • APP测试智能体
  • API自动化测试多智能体协作系统
  • 项目规划
  • 开发工作手册
  • 开发周期管理
  • 任务看板总览
  • Week 3任务看板
  • Week 3周例会
  • Week 4任务看板
  • Week 5任务看板
  • Week 6任务看板
  • APP测试设备采购清单
  • 用户端APP
  • 用户端APP功能脑图
  • 技师端APP
  • 技师端APP功能脑图
  • 后台管理
  • 大数据屏幕
  • 技师端-账户系统需求明细
原型图(Demo)
GitHub
首页
  • APP产品开发方案
  • 商业调查报告
  • 后端技术架构
  • Docker Compose部署指南
  • 技师端-功能模块与微服务对应关系
  • 数据库设计
  • 分布式事务一致性
  • 日志管理与配置
  • Netdata监控系统
  • 系统总览
  • 文档导航
  • 代码审计智能体
  • 测试生成智能体
  • 运维诊断智能体
  • APP测试智能体
  • API自动化测试多智能体协作系统
  • 项目规划
  • 开发工作手册
  • 开发周期管理
  • 任务看板总览
  • Week 3任务看板
  • Week 3周例会
  • Week 4任务看板
  • Week 5任务看板
  • Week 6任务看板
  • APP测试设备采购清单
  • 用户端APP
  • 用户端APP功能脑图
  • 技师端APP
  • 技师端APP功能脑图
  • 后台管理
  • 大数据屏幕
  • 技师端-账户系统需求明细
原型图(Demo)
GitHub
  • AI智能体系统

    • /技术架构/AI智能体系统/README.html
    • AI智能体系统 - 文档导航
    • 代码审计智能体设计文档
    • 测试生成智能体设计文档
    • 运维诊断智能体设计文档
    • APP测试智能体设计文档
    • /技术架构/AI智能体系统/API自动化测试多智能体协作系统架构方案.html

运维诊断智能体设计文档

智能体名称: 运维诊断智能体 (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)

  • 协调其他子智能体的工作
  • 汇总分析结果
  • 进行根因推理
  • 生成诊断报告和解决方案

子智能体列表:

  1. 日志分析智能体 - 从ELK分析应用日志和错误日志
  2. 指标分析智能体 - 从Prometheus分析监控指标
  3. 链路追踪智能体 - 从SkyWalking分析调用链路
  4. 知识库检索智能体 - 从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/次诊断

优化策略:

  1. 故障数据预处理(聚合、过滤)减少Token消耗
  2. 日志只分析ERROR和FATAL级别
  3. 指标只查询关键指标(CPU、内存、错误率)
  4. 知识库命中直接复用解决方案
  5. 使用Claude Sonnet,复杂推理使用Opus

八、效果评估

诊断效率:

  • 平均诊断耗时: <5分钟
  • 根因定位准确率: >85%
  • MTTR: 从45分钟降至10分钟

知识积累:

  • 故障案例库: 持续增长
  • 解决方案复用率: >60%
  • 新故障学习周期: <24小时

文档维护者: AI团队 技术负责人: 待定 创建日期: 2025-10-28 最后更新: 2025-10-28

在 GitHub 上编辑此页
最后更新: 2025/11/10 10:53
贡献者: David, Claude Code
Prev
测试生成智能体设计文档
Next
APP测试智能体设计文档