|
|
|
|
@ -23,7 +23,62 @@
|
|
|
|
|
|
|
|
|
|
二、项目核心任务框架
|
|
|
|
|
项目核心任务共分为 4 大类、10 个模块，各模块按 “基础支撑→功能实现→落地保障” 的逻辑分层，具体框架如下：
|
|
|
|
|
任务类别
任务编号
具体任务模块
核心目标
衔接关系
基础环境搭建
1
Hadoop 集群部署与配置
构建项目运行的计算与存储基础集群
为任务 3（日志采集）、任务 4（日志处理）提供 Hadoop 环境支撑
2
分布式数据存储体系构建及持续性维护
搭建 “原始日志归档 + 业务数据管理” 的存储架构
为任务 3（日志存储）、任务 4（数据查询）、任务 7（结果存储）提供数据支撑
应用开发
3
Hadoop 日志实时采集模块开发
实现 Hadoop 集群日志的全量、实时采集
为任务 4（日志处理）提供原始数据输入，依赖任务 1（Hadoop 环境）、任务 2（HDFS 存储）
4
日志传输、处理及与工具的通信接口开发
完成日志结构化处理与跨工具通信
衔接任务 3（日志输入）与任务 6（大模型调用），依赖任务 2（MySQL/Redis 存储）
5
交互式 Web 应用前端开发
实现集群监控、故障管理、结果展示的可视化
依赖任务 4（后端接口数据），为运维人员提供操作入口
核心功能实现
6
基于大模型的故障智能诊断与分析
实现故障类型识别、原因分析、修复方案生成
依赖任务 4（结构化日志输入），为任务 7（修复执行）提供决策依据
7
故障修复指令自动化执行及结果反馈机制
打通 “诊断 - 修复 - 反馈” 闭环
依赖任务 6（修复方案），结果同步至任务 2（MySQL 存储）与任务 5（前端展示）
落地保障
8
全流程系统性测试与迭代优化
验证模块兼容性与系统性能，解决潜在问题
覆盖任务 1-7，为任务 9（部署上线）扫清障碍
9
项目部署上线及全周期运维监控体系搭建
实现从开发环境到生产环境的平稳过渡
依赖任务 8（测试优化结果），保障上线后系统稳定运行
10
处理结果的量化评估与持续改进
量化系统效果，驱动模块迭代优化
基于任务 7（修复结果）、任务 9（运维数据），反哺任务 4（日志处理）、任务 6（大模型）
三、各任务模块详细说明
|
|
|
|
|
任务类别
|
|
|
|
|
任务编号
|
|
|
|
|
具体任务模块
|
|
|
|
|
核心目标
|
|
|
|
|
衔接关系
|
|
|
|
|
基础环境搭建
|
|
|
|
|
1
|
|
|
|
|
Hadoop 集群部署与配置
|
|
|
|
|
构建项目运行的计算与存储基础集群
|
|
|
|
|
为任务 3（日志采集）、任务 4（日志处理）提供 Hadoop 环境支撑
|
|
|
|
|
|
|
|
|
|
2
|
|
|
|
|
分布式数据存储体系构建及持续性维护
|
|
|
|
|
搭建 “原始日志归档 + 业务数据管理” 的存储架构
|
|
|
|
|
为任务 3（日志存储）、任务 4（数据查询）、任务 7（结果存储）提供数据支撑
|
|
|
|
|
应用开发
|
|
|
|
|
3
|
|
|
|
|
Hadoop 日志实时采集模块开发
|
|
|
|
|
实现 Hadoop 集群日志的全量、实时采集
|
|
|
|
|
为任务 4（日志处理）提供原始数据输入，依赖任务 1（Hadoop 环境）、任务 2（HDFS 存储）
|
|
|
|
|
|
|
|
|
|
4
|
|
|
|
|
日志传输、处理及与工具的通信接口开发
|
|
|
|
|
完成日志结构化处理与跨工具通信
|
|
|
|
|
衔接任务 3（日志输入）与任务 6（大模型调用），依赖任务 2（MySQL/Redis 存储）
|
|
|
|
|
|
|
|
|
|
5
|
|
|
|
|
交互式 Web 应用前端开发
|
|
|
|
|
实现集群监控、故障管理、结果展示的可视化
|
|
|
|
|
依赖任务 4（后端接口数据），为运维人员提供操作入口
|
|
|
|
|
核心功能实现
|
|
|
|
|
6
|
|
|
|
|
基于大模型的故障智能诊断与分析
|
|
|
|
|
实现故障类型识别、原因分析、修复方案生成
|
|
|
|
|
依赖任务 4（结构化日志输入），为任务 7（修复执行）提供决策依据
|
|
|
|
|
|
|
|
|
|
7
|
|
|
|
|
故障修复指令自动化执行及结果反馈机制
|
|
|
|
|
打通 “诊断 - 修复 - 反馈” 闭环
|
|
|
|
|
依赖任务 6（修复方案），结果同步至任务 2（MySQL 存储）与任务 5（前端展示）
|
|
|
|
|
落地保障
|
|
|
|
|
8
|
|
|
|
|
全流程系统性测试与迭代优化
|
|
|
|
|
验证模块兼容性与系统性能，解决潜在问题
|
|
|
|
|
覆盖任务 1-7，为任务 9（部署上线）扫清障碍
|
|
|
|
|
|
|
|
|
|
9
|
|
|
|
|
项目部署上线及全周期运维监控体系搭建
|
|
|
|
|
实现从开发环境到生产环境的平稳过渡
|
|
|
|
|
依赖任务 8（测试优化结果），保障上线后系统稳定运行
|
|
|
|
|
|
|
|
|
|
10
|
|
|
|
|
处理结果的量化评估与持续改进
|
|
|
|
|
量化系统效果，驱动模块迭代优化
|
|
|
|
|
基于任务 7（修复结果）、任务 9（运维数据），反哺任务 4（日志处理）、任务 6（大模型）
|
|
|
|
|
三、各任务模块详细说明
|
|
|
|
|
（一）基础环境搭建类
|
|
|
|
|
任务 1：Hadoop 集群部署与配置
|
|
|
|
|
? 任务定位：项目运行的基础计算支撑，提供 HDFS（存储日志）、YARN（资源调度）、MapReduce（可选批量处理）核心组件。
|
|
|
|
|
@ -42,16 +97,24 @@ c.
|
|
|
|
|
d. HDFS 存储配置：
|
|
|
|
|
? 创建日志归档目录：hdfs dfs -mkdir -p /user/hadoop/log_archive，设置权限（hdfs dfs -chmod 755 /user/hadoop/log_archive），仅允许 Flume、后端服务写入；
|
|
|
|
|
? 配置副本策略：hdfs-site.xml中设置dfs.replication=3，确保日志数据高可用，避免单点丢失。
|
|
|
|
|
e. MySQL+Redis 部署与配置：
|
|
|
|
|
? MySQL：安装 MySQL 8.0+，创建数据库hadoop_fault_db，设计核心数据表（如下）：
|
|
|
|
|
e. PostgreSQL+Redis 部署与配置：
|
|
|
|
|
? PostgreSQL：安装 PostgreSQL 14+，创建数据库hadoop_fault_db，按项目脚本初始化表结构（参见 doc/project/数据库建表脚本_postgres.sql）：
|
|
|
|
|
|
|
|
|
|
表名
核心字段
cluster_node
节点 ID、IP 地址、角色（NameNode/DataNode）、磁盘阈值、状态（在线 / 离线）
fault_record
故障 ID、类型、发生时间、诊断结果、修复脚本、修复状态、执行日志
operation_log
操作 ID、用户名、操作时间、操作内容、结果（成功 / 失败）
? Redis：安装 Redis 6.0+，配置缓存策略（集群状态数据缓存 10 分钟，故障列表数据缓存 5 分钟），避免高频查询穿透 MySQL。
|
|
|
|
|
表名
|
|
|
|
|
核心字段
|
|
|
|
|
cluster_node
|
|
|
|
|
节点 ID、IP 地址、角色（NameNode/DataNode）、磁盘阈值、状态（在线 / 离线）
|
|
|
|
|
fault_record
|
|
|
|
|
故障 ID、类型、发生时间、诊断结果、修复脚本、修复状态、执行日志
|
|
|
|
|
operation_log
|
|
|
|
|
操作 ID、用户名、操作时间、操作内容、结果（成功 / 失败）
|
|
|
|
|
? Redis：安装 Redis 6.0+，配置缓存策略（集群状态数据缓存 10 分钟，故障列表数据缓存 5 分钟），避免高频查询穿透 PostgreSQL。
|
|
|
|
|
f. 存储维护：
|
|
|
|
|
? HDFS：每周执行hdfs fsck /检查文件完整性，每月将 3 个月前的日志归档至冷存储（如低成本云存储）；
|
|
|
|
|
? MySQL：配置每日增量备份（mysqldump -u root -p hadoop_fault_db > backup_$(date +%Y%m%d).sql），保留 30 天备份文件；
|
|
|
|
|
? 权限管控：MySQL 仅允许后端服务 IP 访问，Redis 设置密码认证，避免数据泄露。
|
|
|
|
|
? 实施要点：用 Navicat 等工具管理 MySQL，记录数据库账号密码与备份路径，定期验证备份文件可用性。
|
|
|
|
|
? 必要性：HDFS 解决 TB 级原始日志存储问题，MySQL 解决业务数据高效查询问题，缺少任一存储均会导致系统功能断裂（如前端无法加载故障列表、日志无法归档）。
|
|
|
|
|
? PostgreSQL：配置每日增量备份（pg_dump -U postgres -d hadoop_fault_db > backup_$(date +%Y%m%d).sql），保留 30 天备份文件；
|
|
|
|
|
? 权限管控：PostgreSQL 仅允许后端服务 IP 访问，Redis 设置密码认证，避免数据泄露。
|
|
|
|
|
? 实施要点：用 pgAdmin 等工具管理 PostgreSQL，记录数据库账号密码与备份路径，定期验证备份文件可用性。
|
|
|
|
|
? 必要性：HDFS 解决 TB 级原始日志存储问题，PostgreSQL 解决业务数据高效查询问题，缺少任一存储均会导致系统功能断裂（如前端无法加载故障列表、日志无法归档）。
|
|
|
|
|
（二）应用开发类
|
|
|
|
|
任务 3：Hadoop 日志实时采集模块开发
|
|
|
|
|
? 任务定位：实现 Hadoop 集群日志的 “全量、实时” 采集，为后续日志处理提供原始数据来源。
|
|
|
|
|
@ -67,10 +130,10 @@ i.
|
|
|
|
|
? 实施要点：避免 Flume 进程占用过多 CPU / 内存，定期清理 Flume 日志（/var/log/flume-ng/），防止磁盘满。
|
|
|
|
|
? 必要性：无日志采集则后续日志处理、大模型诊断均无数据输入，系统无法感知集群故障。
|
|
|
|
|
任务 4：日志传输、处理及与工具的通信接口开发
|
|
|
|
|
? 任务定位：作为系统 “数据中枢”，完成日志结构化处理、跨工具（Flume / 大模型 / MySQL）通信，衔接 “采集” 与 “诊断” 环节。
|
|
|
|
|
? 任务定位：作为系统 “数据中枢”，完成日志结构化处理、跨工具（Flume / 大模型 / PostgreSQL）通信，衔接 “采集” 与 “诊断” 环节。
|
|
|
|
|
? 核心内容：
|
|
|
|
|
j. 后端服务搭建（基于 FastAPI）：
|
|
|
|
|
? 项目初始化：pip install fastapi uvicorn mysql-connector-python redis requests，创建主程序main.py；
|
|
|
|
|
? 项目初始化：pip install fastapi uvicorn sqlalchemy asyncpg redis requests pydantic，创建主程序main.py；
|
|
|
|
|
? 接口开发：
|
|
|
|
|
? 日志接收接口（POST /api/log/auto-upload）：接收 Flume 推送的日志，调用preprocess_log函数提取时间戳、日志级别、组件名（结构化）；
|
|
|
|
|
? 集群状态接口（GET /api/cluster/status）：调用 Hadoop API（hdfs dfsadmin -report）获取节点状态，缓存至 Redis；
|
|
|
|
|
@ -78,7 +141,7 @@ j.
|
|
|
|
|
k. 日志结构化处理：编写preprocess_log函数，用正则匹配 Hadoop 日志格式（(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) (\w+) (\w+): (.*)），输出结构化字典（含timestamp、log_level、component、content字段）。
|
|
|
|
|
l. 工具通信适配：
|
|
|
|
|
? 与 Hadoop 通信：用subprocess调用 Hadoop 命令（如hdfs dfs -du -h /），或通过 PyHive 连接 Hive 获取任务日志；
|
|
|
|
|
? 与 MySQL/Redis 通信：封装数据读写函数（save_fault_to_mysql、get_cluster_status_from_redis），确保数据一致性。
|
|
|
|
|
? 与 PostgreSQL/Redis 通信：封装数据读写函数（save_fault_to_pg、get_cluster_status_from_redis），确保数据一致性。
|
|
|
|
|
? 实施要点：用uvicorn启动服务时配置--workers 4提高并发能力，接口添加参数校验（如用 Pydantic 定义LogModel），避免非法数据输入。
|
|
|
|
|
? 必要性：原始日志格式杂乱，缺少结构化处理则大模型无法精准诊断；无通信接口则各工具无法协同，系统呈 “碎片化”。
|
|
|
|
|
任务 5：交互式 Web 应用前端开发
|
|
|
|
|
@ -94,10 +157,11 @@ o.
|
|
|
|
|
? 实施要点：用axios拦截器处理 Token 过期（自动跳转登录页），图表采用懒加载减少首屏加载时间。
|
|
|
|
|
? 必要性：无前端则运维人员无法直观查看集群状态与故障信息，系统缺少 “人机交互” 入口，实用性大幅降低。
|
|
|
|
|
（三）核心功能实现类
|
|
|
|
|
任务 6：基于大模型的故障智能诊断与分析
|
|
|
|
|
任务 6：基于大模型与多智能体的故障智能诊断与分析
|
|
|
|
|
? 任务定位：系统 “决策核心”，通过大模型分析结构化日志，实现故障类型识别、原因定位、修复方案生成。
|
|
|
|
|
? 核心内容：
|
|
|
|
|
p. 大模型选型与 API 配置：选择支持工具调用的大模型（如通义千问 Qwen-Max、Scholar ICP），申请 API 密钥，配置调用参数（temperature=0.3，降低随机性）。
|
|
|
|
|
p. 大模型选型与 API 配置：选择支持工具调用的大模型（如通义千问 Qwen-Max、文心一言），申请 API 密钥，配置调用参数（temperature=0.3，降低随机性）。
|
|
|
|
|
? 多智能体架构：采用 Agent Orchestrator（如 LangGraph/Ray/Celery）编排 DiagnosisAgent（诊断）、LogParserAgent（解析）、PolicyAgent（风险与审批策略）。
|
|
|
|
|
q. Prompt 工程设计：构造结构化 Prompt，强制大模型输出可执行修复指令，示例：
|
|
|
|
|
|
|
|
|
|
你是Hadoop运维专家，需基于以下结构化日志输出：
|
|
|
|
|
@ -106,7 +170,8 @@ q. Prompt
|
|
|
|
|
3. fix_script（可执行Shell/Hadoop命令，无多余解释）；
|
|
|
|
|
4. risk_level（风险等级：low/medium/high）。
|
|
|
|
|
输出格式为JSON，不含其他文字！
|
|
|
|
|
日志：{结构化日志列表}
r. 诊断逻辑开发：在 FastAPI 中编写call_llm_diagnose函数，传递结构化日志至大模型 API，解析返回结果（用 Pydantic 定义FixCommand类校验格式），过滤危险指令（如rm -rf /*）。
|
|
|
|
|
日志：{结构化日志列表}
|
|
|
|
|
r. 诊断逻辑开发：在 FastAPI 中编写call_llm_diagnose函数，传递结构化日志至大模型 API，解析返回结果（用 Pydantic 定义FixCommand类校验格式），过滤危险指令（如rm -rf /*）。
|
|
|
|
|
s. 诊断验证：模拟 “磁盘满” 故障（dd if=/dev/zero of=/tmp/test bs=1G count=5），查看大模型是否正确输出 “清理临时文件” 的修复脚本。
|
|
|
|
|
? 实施要点：添加大模型调用重试机制（失败后重试 2 次，间隔 5 秒），记录调用日志（含输入 / 输出），便于问题排查。
|
|
|
|
|
? 必要性：无大模型诊断则需人工分析日志，无法实现 “自动化故障识别”，违背项目核心目标。
|
|
|
|
|
@ -118,10 +183,10 @@ t.
|
|
|
|
|
? clean_temp.sh：ssh datanode-ip "rm -rf /tmp/hadoop-* && hdfs dfsadmin -refreshNodes"；
|
|
|
|
|
? kill_timeout_job.sh：yarn application -kill <appId>（需动态传入 appId）。
|
|
|
|
|
u. 风险控制逻辑：
|
|
|
|
|
? 风险分级：low（如清理临时文件）→ 自动执行；medium（如重启 DataNode）→ 前端弹窗确认后执行；high（如格式化 HDFS）→ 钉钉告警 + 人工审批；
|
|
|
|
|
? 风险分级：low（如清理临时文件）→ RepairAgent 自动执行；medium（如重启 DataNode）→ 前端弹窗确认后执行；high（如格式化 HDFS）→ 钉钉告警 + 人工审批（由 PolicyAgent 协同）；
|
|
|
|
|
? 权限控制：修复脚本仅允许后端服务用户（如hadoop）执行，禁止 root 权限。
|
|
|
|
|
v. 结果反馈：
|
|
|
|
|
? 执行日志记录：用subprocess捕获脚本输出（stdout/stderr），存入 MySQLfault_record表的exec_log字段；
|
|
|
|
|
? 执行日志记录：用subprocess捕获脚本输出（stdout/stderr），存入 PostgreSQL 的 exec_logs 表；
|
|
|
|
|
? 前端同步：修复完成后，通过 WebSocket 实时更新前端故障状态（如 “未修复”→“已修复”），弹窗提示结果。
|
|
|
|
|
? 实施要点：脚本添加参数校验（如clean_temp.sh检查/tmp/hadoop-*是否存在），避免空执行；执行前备份关键配置文件（如hdfs-site.xml）。
|
|
|
|
|
? 必要性：缺少自动修复则系统仅能 “发现故障”，无法 “解决故障”，运维效率无实质提升，项目价值大打折扣。
|
|
|
|
|
@ -134,7 +199,19 @@ w. ģ
|
|
|
|
|
? 功能测试：后端接口（用 Postman 测试参数合法性、返回格式）、前端页面（测试筛选 / 分页 / 按钮点击功能）。
|
|
|
|
|
x. 场景测试：模拟 3 类核心故障，验证全流程通顺性：
|
|
|
|
|
|
|
|
|
|
故障类型
模拟方式
预期结果
DataNode 磁盘满
dd if=/dev/zero of=/tmp/test bs=1G count=5
日志采集→大模型诊断 “磁盘满”→输出clean_temp.sh→执行后磁盘使用率下降
任务超时
提交sleep 3600的 MapReduce 任务
日志采集→大模型诊断 “任务超时”→输出kill_timeout_job.sh→任务被成功终止
DataNode 宕机
sudo systemctl stop hadoop-hdfs-datanode
日志采集→大模型诊断 “DataNode 离线”→输出restart_datanode.sh→节点重启成功
y. 性能优化：
|
|
|
|
|
故障类型
|
|
|
|
|
模拟方式
|
|
|
|
|
预期结果
|
|
|
|
|
DataNode 磁盘满
|
|
|
|
|
dd if=/dev/zero of=/tmp/test bs=1G count=5
|
|
|
|
|
日志采集→大模型诊断 “磁盘满”→输出clean_temp.sh→执行后磁盘使用率下降
|
|
|
|
|
任务超时
|
|
|
|
|
提交sleep 3600的 MapReduce 任务
|
|
|
|
|
日志采集→大模型诊断 “任务超时”→输出kill_timeout_job.sh→任务被成功终止
|
|
|
|
|
DataNode 宕机
|
|
|
|
|
sudo systemctl stop hadoop-hdfs-datanode
|
|
|
|
|
日志采集→大模型诊断 “DataNode 离线”→输出restart_datanode.sh→节点重启成功
|
|
|
|
|
y. 性能优化：
|
|
|
|
|
? 前端：优化图表加载（懒加载非首屏图表），接口请求合并（减少重复调用）；
|
|
|
|
|
? 后端：给高频接口（/api/cluster/status）加 Redis 缓存，优化大模型调用超时时间（设为 30 秒）。
|
|
|
|
|
? 实施要点：记录测试用例与缺陷（用 Excel 或 Jira），优先修复 “阻断性缺陷”（如日志采集丢数据、修复脚本执行失败）。
|
|
|
|
|
@ -146,10 +223,10 @@ z.
|
|
|
|
|
? 编写 Dockerfile：
|
|
|
|
|
? 前端：基于 Nginx 镜像，复制dist目录至/usr/share/nginx/html；
|
|
|
|
|
? 后端：基于 Python 3.9 镜像，安装依赖，暴露 8000 端口；
|
|
|
|
|
? 编写docker-compose.yml：定义前端、后端、MySQL、Redis 服务，配置端口映射（如前端 80→容器 80，后端 8000→容器 8000）。
|
|
|
|
|
? 编写docker-compose.yml：定义前端、后端、PostgreSQL、Redis 服务，配置端口映射（如前端 80→容器 80，后端 8000→容器 8000）。
|
|
|
|
|
aa. 生产环境配置：
|
|
|
|
|
? Hadoop 集群：在生产节点部署 Flume Agent，配置生产级大模型 API 密钥（替换测试密钥）；
|
|
|
|
|
? 安全配置：设置防火墙规则（仅允许运维 IP 访问前端 80 端口、后端 8000 端口），MySQL/Redis 开启密码认证。
|
|
|
|
|
? 安全配置：设置防火墙规则（仅允许运维 IP 访问前端 80 端口、后端 8000 端口），PostgreSQL/Redis 开启密码认证。
|
|
|
|
|
bb. 运维监控：
|
|
|
|
|
? 系统监控面板：开发监控页面（基于 ECharts），展示 Flume 采集量、大模型调用成功率、修复执行成功率；
|
|
|
|
|
? 异常告警：配置钉钉机器人，触发告警条件（如 Flume 5 分钟无日志采集、大模型调用失败率 > 5%）时自动推送消息。
|
|
|
|
|
@ -163,7 +240,7 @@ cc.
|
|
|
|
|
? 时效性：从日志产生到修复完成的平均耗时，目标≤5 分钟；
|
|
|
|
|
? 有效性：修复后故障复发率（复发次数 / 总修复次数），目标≤5%。
|
|
|
|
|
dd. 评估实施：
|
|
|
|
|
? 数据采集：从 MySQLfault_record表提取每日诊断 / 修复数据，用 Excel 或 Python（Pandas）统计；
|
|
|
|
|
? 数据采集：从 PostgreSQL 的 fault_records 与 exec_logs 表提取每日诊断 / 修复数据，用 Excel 或 Python（Pandas）统计；
|
|
|
|
|
? 报告生成：每周输出《系统运行评估报告》，包含 3 个维度指标、环比变化、异常案例（如诊断错误的故障日志）。
|
|
|
|
|
ee. 优化迭代：
|
|
|
|
|
? 若准确性低：优化大模型 Prompt（增加故障示例）、过滤无效日志（减少干扰数据）；
|
|
|
|
|
@ -174,11 +251,41 @@ ee.
|
|
|
|
|
四、任务衔接与实施顺序建议
|
|
|
|
|
1. 实施顺序（按阶段划分）
|
|
|
|
|
|
|
|
|
|
阶段
持续时间
核心任务（按优先级）
阶段目标
基础搭建阶段
2 周
任务 1（Hadoop 部署）→ 任务 2（存储体系）
完成硬件与存储基础，可产生日志数据
应用开发阶段
3 周
任务 3（日志采集）→ 任务 4（后端接口）→ 任务 5（前端开发）
完成 “采集 - 处理 - 展示” 链路，可查看集群状态
核心落地阶段
2 周
任务 6（大模型诊断）→ 任务 7（自动修复）
实现 “诊断 - 修复” 闭环，系统具备核心功能
保障优化阶段
1 周
任务 8（测试优化）→ 任务 9（部署上线）→ 任务 10（评估改进）
系统上线运行，建立长期优化机制
2. 关键衔接点
|
|
|
|
|
阶段
|
|
|
|
|
持续时间
|
|
|
|
|
核心任务（按优先级）
|
|
|
|
|
阶段目标
|
|
|
|
|
基础搭建阶段
|
|
|
|
|
2 周
|
|
|
|
|
任务 1（Hadoop 部署）→ 任务 2（存储体系）
|
|
|
|
|
完成硬件与存储基础，可产生日志数据
|
|
|
|
|
应用开发阶段
|
|
|
|
|
3 周
|
|
|
|
|
任务 3（日志采集）→ 任务 4（后端接口）→ 任务 5（前端开发）
|
|
|
|
|
完成 “采集 - 处理 - 展示” 链路，可查看集群状态
|
|
|
|
|
核心落地阶段
|
|
|
|
|
2 周
|
|
|
|
|
任务 6（大模型诊断）→ 任务 7（自动修复）
|
|
|
|
|
实现 “诊断 - 修复” 闭环，系统具备核心功能
|
|
|
|
|
保障优化阶段
|
|
|
|
|
1 周
|
|
|
|
|
任务 8（测试优化）→ 任务 9（部署上线）→ 任务 10（评估改进）
|
|
|
|
|
系统上线运行，建立长期优化机制
|
|
|
|
|
2. 关键衔接点
|
|
|
|
|
? 任务 1→任务 3：Hadoop 集群部署完成后，才能在节点部署 Flume Agent；
|
|
|
|
|
? 任务 2→任务 4：MySQL/Redis 部署完成后，后端接口才能实现数据存储与缓存；
|
|
|
|
|
? 任务 2→任务 4：PostgreSQL/Redis 部署完成后，后端接口才能实现数据存储与缓存；
|
|
|
|
|
? 任务 4→任务 6：后端完成日志结构化后，大模型才能接收有效输入；
|
|
|
|
|
? 任务 8→任务 9：测试修复所有阻断性缺陷后，才能启动生产环境部署。
|
|
|
|
|
五、风险提示与应对建议
|
|
|
|
|
|
|
|
|
|
潜在风险
应对建议
Hadoop 集群部署失败
提前准备集群部署文档（参考 Apache 官方指南），预留 1 个备用节点，失败后快速重建
大模型 API 不稳定
申请 2 个备用大模型 API（如通义千问 + 百度文心一言），代码中添加 API 切换逻辑
修复脚本执行导致集群异常
执行前备份关键数据（如 HDFS 目录），高风险脚本先在测试集群验证效果
生产环境磁盘满
定期清理日志（Flume / 后端 / 容器日志），配置磁盘使用率告警（阈值 85%）
（注：文档部分内容可能由 AI 生成）
|
|
|
|
|
潜在风险
|
|
|
|
|
应对建议
|
|
|
|
|
Hadoop 集群部署失败
|
|
|
|
|
提前准备集群部署文档（参考 Apache 官方指南），预留 1 个备用节点，失败后快速重建
|
|
|
|
|
大模型 API 不稳定
|
|
|
|
|
申请 2 个备用大模型 API（如通义千问 + 百度文心一言），代码中添加 API 切换逻辑
|
|
|
|
|
修复脚本执行导致集群异常
|
|
|
|
|
执行前备份关键数据（如 HDFS 目录），高风险脚本先在测试集群验证效果
|
|
|
|
|
生产环境磁盘满
|
|
|
|
|
定期清理日志（Flume / 后端 / 容器日志），配置磁盘使用率告警（阈值 85%）
|
|
|
|
|
（注：文档部分内容可能由 AI 生成）
|
|
|
|
|
|
