研究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
client = OpenAI( api_key="你的_DEEPSEEK_API_KEY", base_url="https://api.deepseek.com")
CHECK_DIR = "/data/host-check-results"
REPORT_FILE = ( f"/data/report/" f"host_check_report_{datetime.datetime.now().strftime('%Y%m%d_%H%M%S')}.md")
def build_prompt(host_check): prompt = f"""你是一名资深Linux运维专家。请分析下面的服务器巡检结果。请按照以下格式输出：# 服务器健康分析## 1. 整体状态正常 / 警告 / 严重## 2. 发现的问题列出异常指标。## 3. 判断依据引用巡检数据。## 4. 可能原因分析根因。## 5. 下一步排查建议给出具体Linux命令。## 6. 是否需要人工介入是/否，并说明原因。
服务器巡检数据：----------------{host_check}----------------""" return prompt
def call_deepseek(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(): all_report = [] files = Path(CHECK_DIR).glob("*.txt")
for file in files: print(f"正在分析: {file.name}") content = file.read_text( encoding="utf-8", errors="ignore" ) prompt = build_prompt(content) result = call_deepseek(prompt) host_report = f"""================================# 主机:{file.name}{result}""" all_report.append(host_report)
Path("/data/report").mkdir( exist_ok=True )
with open( REPORT_FILE, "w", encoding="utf-8" ) as f: f.write( "\n".join(all_report) )
print( "分析完成:" , REPORT_FILE )
if __name__ == "__main__": main()
主机：app-01
状态：严重
问题：- 磁盘 /data 使用率 96%- 系统日志中出现大量 IO error
依据：- df -h 显示 /data 96%- dmesg 中存在 blk_update_request I/O error
可能原因：- 磁盘空间不足- 磁盘或存储链路异常
建议排查：- df -h- du -sh /data/*- dmesg -T | tail -200- smartctl -a /dev/sda
是否人工介入：是
05 | 二次故障排查
不要让 LLM 直接随便执行命令。
建议做成：
LLM 只判断问题类型中心机根据问题类型调用固定排查脚本
例如：
磁盘问题 → run_disk_check.shCPU问题 → run_cpu_check.sh内存问题 → run_mem_check.sh网络问题 → run_net_check.sh进程异常 → run_process_check.sh
示例：
#!/bin/bashecho "===== df -h ====="df -h
echo "===== inode ====="df -i
echo "===== 大目录 ====="du -sh /* 2>/dev/null | sort -h | tail -20
echo "===== dmesg 磁盘错误 ====="dmesg | egrep -i "error|fail|io|disk|scsi|blk" | tail -100
流程就是：
第一次巡检 → LLM发现磁盘异常 → 执行磁盘排查脚本 → 再把结果交给 LLM → 输出最终建议
06 | 最小可用版本
可以先这样落地：
1. 每台主机部署 /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 ··············
粤ICP备14082021号
免费POC，
零成本试错
