↑↑↑点击关注，分享IT技术|职场晋升技巧|AI工具
研究AIOps已有1年，目前手里有不少可落地的方案了，而且目前我们已经有了自研的AIOps平台，欢迎关注并与我链接（看底下留言）。
前阵子有个同学提了个需求，他想针对几百台主机做巡检同时做故障排查。我第一时间想到的是Dify + Ansible，在我看来这已经是非常简单的解决方案了。但这个同学问还有没有更便捷的方案，我想了想，觉得完全可以通过Shell脚本+Python脚本来搞定。
01 | 整体架构
几百台主机│├─ 本地巡检脚本 check.sh│ └─ 生成巡检结果文件：hostname_时间.txt│└─ 定时上传 / 被中心机拉取│▼中心分析机│├─ 汇总所有巡检文件├─ 调用 LLM 分析├─ 输出问题清单└─ 对异常主机执行二次排查脚本
02 | 主机侧：放一个巡检脚本
每台机器放一个巡检脚本，例如：
!/bin/bashHOST=$(hostname)TIME=$(date "+%Y%m%d%H%M%S")OUT="/tmp/${HOST}${TIME}_check.txt"{echo "===== 基本信息 ====="echo "hostname: $HOST"dateuptimeuname -aechoecho "===== CPU / Load ====="top -bn1 | head -20echoecho "===== 内存 ====="free -hechoecho "===== 磁盘 ====="df -hdf -iechoecho "===== 网络 ====="ip addrss -antp | head -50echoecho "===== 关键进程 ====="ps -eo pid,ppid,cmd,%mem,%cpu –sort=-%cpu | head -30echoecho "===== 系统错误日志 ====="journalctl -p err -n 100 –no-pager 2>/dev/nullechoecho "===== dmesg 异常 ====="dmesg | egrep -i "error|fail|oom|killed|reset|timeout" | tail -100} > "$OUT"echo "$OUT"
说明：该脚本仅仅是一个参考，具体你要巡检什么，在脚本里增加相关步骤即可。
准备好脚本后，用cron每 5 分钟或 10 分钟跑一次：
*/10 * * * * /opt/check.sh
03 | 结果收集方式
最简单有两种，建议先选一种。
方案 A：主机主动上传
每台机器巡检后上传到中心机：
scp "$OUT" ops@10.0.0.10:/data/host-check-results/
优点：简单直接。
缺点：每台机器要配置 SSH key。
方案 B：中心机统一拉取
中心机定时用 Ansible 或 SSH 拉取：
ansible all -m shell -a "/opt/check.sh"ansible all -m fetch -a "src=/tmp/latest_check.txt dest=/data/host-check-results/ flat=yes"
优点：中心化管理。
缺点：需要维护主机清单。
如果要“非常简单”，我建议用：中心机 + Ansible + Shell 脚本 + 文件目录
暂时不需要数据库、不需要消息队列、不需要复杂平台。
04 | 中心机调用 LLM 分析
中心机上写一个简单 Python 脚本，核心目标是调用大模型（比如DeepSeek）来分析巡检结果：
from pathlib import Pathfrom openai import OpenAIimport datetime# ==========================# DeepSeek API配置# ==========================client = OpenAI(apikey="你的DEEPSEEKAPIKEY",baseurl="https://api.deepseek.com")# ==========================# 巡检结果目录# ==========================CHECKDIR = "/data/host-check-results"REPORTFILE = (f"/data/report/"f"hostcheckreport{datetime.datetime.now().strftime('%Y%m%d%H%M%S')}.md")# ==========================# 构造分析提示词# ==========================def buildprompt(hostcheck):prompt = f"""你是一名资深Linux运维专家。请分析下面的服务器巡检结果。请按照以下格式输出：# 服务器健康分析## 1. 整体状态正常 / 警告 / 严重## 2. 发现的问题列出异常指标。## 3. 判断依据引用巡检数据。## 4. 可能原因分析根因。## 5. 下一步排查建议给出具体Linux命令。## 6. 是否需要人工介入是/否，并说明原因。服务器巡检数据：—————-{hostcheck}—————-"""return prompt# ==========================# 调用DeepSeek# ==========================def calldeepseek(prompt):response = client.chat.completions.create(model="deepseek-chat",messages=[{"role": "system","content":"你是企业级Linux故障诊断专家，""擅长服务器异常分析。"},{"role": "user","content": prompt}],temperature=0.2)return response.choices[0].message.content# ==========================# 主程序# ==========================def main():allreport = []files = Path(CHECKDIR).glob("*.txt")for file in files:print(f"正在分析: {file.name}")content = file.readtext(encoding="utf-8",errors="ignore")prompt = buildprompt(content)result = calldeepseek(prompt)hostreport = f"""================================# 主机:{file.name}{result}"""allreport.append(hostreport)# 汇总报告Path("/data/report").mkdir(existok=True)with open(REPORTFILE,"w",encoding="utf-8") as f:f.write("n".join(allreport))print("分析完成:",REPORTFILE)if name == "main":main()LLM 输出建议统一成这种格式：主机：app-01状态：严重问题：- 磁盘 /data 使用率 96%- 系统日志中出现大量 IO error依据：- df -h 显示 /data 96%- dmesg 中存在 blkupdate_request I/O error可能原因：- 磁盘空间不足- 磁盘或存储链路异常建议排查：- df -h- du -sh /data/*- dmesg -T | tail -200- smartctl -a /dev/sda是否人工介入：是
05 | 二次故障排查
不要让 LLM 直接随便执行命令。
建议做成：
LLM 只判断问题类型中心机根据问题类型调用固定排查脚本
例如：
磁盘问题 → rundiskcheck.shCPU问题 → runcpucheck.sh内存问题 → runmemcheck.sh网络问题 → runnetcheck.sh进程异常 → runprocesscheck.sh
示例：
!/bin/bash# rundiskcheck.shecho "===== df -h ====="df -hecho "===== inode ====="df -iecho "===== 大目录 ====="du -sh /* 2>/dev/null | sort -h | tail -20echo "===== dmesg 磁盘错误 ====="dmesg | egrep -i "error|fail|io|disk|scsi|blk" | tail -100
流程就是：
第一次巡检 → LLM发现磁盘异常 → 执行磁盘排查脚本 → 再把结果交给 LLM → 输出最终建议
06 | 最小可用版本
可以先这样落地：
每台主机部署 /opt/check.sh2. 中心机准备 /data/host-check-results/3. 用 cron 或 Ansible 每 10 分钟收集一次4. 中心机每天或每小时调用 LLM 分析所有结果5. 生成 report.md6. 对“严重”主机执行二次排查脚本7. 最终输出异常主机清单
07 | 最终输出报告格式
主机巡检分析报告## 总览- 巡检主机数：320- 正常：285- 警告：27- 严重：8## 严重问题主机| 主机 | 问题 | 依据 | 建议 ||—|—|—|—|| app-01 | /data 磁盘 96% | df -h | 清理日志或扩容 || db-02 | OOM | dmesg 有 killed process | 检查内存和业务进程 || cache-03 | 网络连接异常 | 大量 TIME_WAIT | 检查连接池配置 |## 建议优先处理1. db-02：存在 OOM，可能影响业务稳定性2. app-01：磁盘即将写满3. cache-03：连接数异常，需要排查应用连接池
08 | 核心原则
这个方案里，LLM 不负责执行危险操作，只负责：
看巡检结果 → 判断异常 → 总结原因 → 给排查建议 → 生成报告
真正执行的命令只来自我们提前写好的白名单脚本。这样简单、安全，也容易逐步扩展。
·············· END ··············哈喽，我是阿铭，《跟阿铭学Linux》作者，曾就职于腾讯，有着19年的IT从业经验，现全职做IT类职业培训：运维、k8s、大模型。日常分享运维、AI、大模型相关技术以及职场相关，欢迎围观。
