每次值班电话在凌晨两三点响起来的时候整个人从床上弹起来的感觉相信干运维的朋友都不陌生。我做了六年的服务器运维从最初的纯手工巡检到后来写脚本半自动化再到最近把 OpenClaw 接进来做私人运维AI助理最大的感受是大部分告警其实不值得把人从被窝里叫醒真正有价值的是那一套能自动判断、自动处理、自动闭环的机制。这篇内容是我第二篇 OpenClaw 实战记录主题很聚焦怎样用 OpenClaw 搭一个 7×24 小时在线的私人运维AI助理让它监控服务器状态、接收告警、自动执行修复脚本从而把重复性的运维工作交出去。如果你是运维工程师、SRE、独立开发者或者手头管着几台几十台机器又不想天天盯监控面板的人这篇文章会把我的完整配置思路、踩坑经历和实测数据都摊开讲。1. 为什么说传统运维的告警链路天然“反人类”先搞懂AI助理要解决的本质问题1.1 告警不应该是“把人叫醒”而应该是“把问题描述清楚”传统监控体系的逻辑很简单阈值触发了发告警。CPU 超过 90%、磁盘使用率超过 85%、服务心跳断了于是邮件、短信、群机器人一起轰炸。看起来没什么问题但实际运营过你就知道告警系统的核心矛盾从来不是“漏报”而是“误报”和“告警风暴”。我记得有一回线上数据库节点负载抖动监控系统在十分钟内发出了两百多条告警值班同学醒过来打开手机看到的是一条接一条的红色警报根本分不清哪些是根因、哪些是衍生告警。这种情况下人的处理效率极低因为你得先做告警分类、去重、定位然后才是处理。一晚上搞下来真正需要动手的其实只有一个磁盘扩容但人已经被折腾得筋疲力尽。1.2 OpenClaw在运维里的定位不是取代人而是把“规则判断”变成“自主行动”OpenClaw 是一个开源的 AI 代理框架简单说你可以把它理解成一个能调用工具、能执行命令、能按自然语言指令行动的数字员工。我在第一批实战里已经用它做过文档总结和计划任务调度这一篇则是把它接到运维监控体系里让 AI 不只是会聊天而是能直视服务器状态、理解告警内容、自己跑去执行修复动作。这里有一个关键的思路转变传统运维自动化是把“人的判断”写死在脚本里if 磁盘 85% then 清理日志。但这种判断方式非常脆弱因为现实中的故障场景是组合式的磁盘满了可能伴随日志服务异常日志服务异常又可能是文件句柄泄漏导致的。脚本很难覆盖所有组合而 AI 代理的优势在于它可以综合多个信息源再决定执行哪条命令、调哪个脚本、或者干脆上报给人工。我需要强调一下OpenClaw 不会把你变成一个不用干活的运维。实际上它前期的搭建、调试、规则打磨要花不少时间但在跑顺之后收益是实实在在的。我的目标是让 AI 处理 80% 的常规故障让人只处理剩下的 20% 需要判断力和经验的复杂问题。后面章节我会详细介绍整个链路怎么搭。2. 环境准备在干净的 Linux 服务器上部署 OpenClaw接入监控数据源2.1 单独给 AI 助理准备一台“控制机”别和生产环境混在一起第一个建议可能和很多人想的不一样OpenClaw 不要直接部署在你的业务服务器上而是单独准备一台轻量级服务器或者性能不错的虚拟机来做“控制机”。原因很简单AI 代理需要长时间在线它要执行脚本、调用 SSH、读取监控数据如果它本身跑在故障机器上那机器挂了它就跟着挂反而成了新的单点故障。我用的是腾讯云轻量应用服务器2C4G 的配置就够了因为 OpenClaw 本身的资源占用不大真正消耗资源的是它需要调用的外部工具和脚本。控制机上部署 OpenClaw通过 SSH key 的方式连接各个被监控的业务服务器这样业务机器上不需要额外装 agent安全性也更好控制。2.2 部署 OpenClaw 和必要的运行环境OpenClaw 的部署方式在它的官方文档里有详细说明我这里基于开源版本的操作过程做一个记录。我的环境是 Ubuntu 22.04Python 版本要求 3.10 以上Node.js 用于部分前端组件。首先更新基础环境sudo apt update sudo apt upgrade -y sudo apt install -y python3-pip git curl wget ufw sudo ufw allow OpenSSH sudo ufw enable然后是安装 OpenClaw。这里我使用的是 pip 方式在虚拟环境里安装避免污染系统 Python 环境cd /opt sudo mkdir openclaw sudo chown $USER:$USER openclaw cd openclaw python3 -m venv venv source venv/bin/activate pip install openclaw python -m openclaw init初始化之后OpenClaw 会生成一个默认的配置目录~/.openclaw/里面有config.yaml、skills/、tools/等子目录。第一次启动时别急着做复杂配置先跑起来看看python -m openclaw start看到控制台输出OpenClaw is running in background就说明基础部署成功了。我建议用systemd把它注册成服务确保开机自启和异常重启。下面是一个简单的 service 配置放在/etc/systemd/system/openclaw.service[Unit] DescriptionOpenClaw AI Assistant Afternetwork.target [Service] Typesimple Useryouruser WorkingDirectory/opt/openclaw ExecStart/opt/openclaw/venv/bin/python -m openclaw start Restartalways RestartSec10 [Install] WantedBymulti-user.target设置开机自启的命令sudo systemctl daemon-reload sudo systemctl enable --now openclaw这里说一个我踩过的坑如果 OpenClaw 无法正常向外访问 HTTPS或者 SSH 连接超时大概率是防火墙规则挡住了出站连接。因为控制机需要主动 SSH 到业务服务器所以一定要在 iptables/ufw 里放行出站 SSH默认 22 端口我当时卡了半天最后发现是云安全组只开了入方向出方向没有限制但本地防火墙又默认只允许已建立的连接导致 SSH 通道建立不了。2.3 配置监控数据源Prometheus Node Exporter 是最省心的组合AI 助理要有“眼睛”就得接入监控数据。我选用的组合是 Prometheus 加 Node Exporter这是目前开源监控领域最通用的方案。在各业务服务器上部署 Node Exporter 非常轻量它会暴露一个 9100 端口提供机器 CPU、内存、磁盘、网络等指标数据。业务服务器上执行wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz tar xvf node_exporter-1.7.0.linux-amd64.tar.gz sudo mv node_exporter-1.7.0.linux-amd64/node_exporter /usr/local/bin/ sudo useradd -rs /bin/false node_exporter sudo tee /etc/systemd/system/node_exporter.service /dev/null EOF [Unit] DescriptionNode Exporter Afternetwork.target [Service] Usernode_exporter Groupnode_exporter Typesimple ExecStart/usr/local/bin/node_exporter [Install] WantedBymulti-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now node_exporter控制机上安装 Prometheus然后配置抓取规则global: scrape_interval: 15s scrape_configs: - job_name: node static_configs: - targets: [10.0.0.1:9100, 10.0.0.2:9100]到这里监控数据的基础管道就通了。下一步的关键是怎么让 OpenClaw 去“理解”这些监控数据而不是让 AI 自己从头搭一套监控。3. 核心配置把服务器监控变成 AI 能“看懂”的消息流3.1 与其让 AI 去读面板不如让 AI 直接调用 Prometheus 查询接口一开始我有个误区以为要让 AI 去看 Grafana 面板后来想明白了监控数据的价值在于被检索和分析而不是被“看见”。OpenClaw 可以通过 HTTP 调用 Prometheus 的 HTTP API直接把指标查询结果返回给大模型分析。Prometheus 提供了一个非常方便的原生查询接口形如curl http://localhost:9090/api/v1/query?querynode_load1返回结果是 JSON 格式。我们可以在 OpenClaw 的tools/目录里新增一个自定义工具命名为prom_query让 AI 可以随时查询任意指标。OpenClaw 的工具注册方式是在工具目录下写一个 Python 文件然后在配置文件里声明。我写了一个很简短的封装import subprocess import json def prom_query(query: str) - str: url fhttp://localhost:9090/api/v1/query?query{query} result subprocess.run( [curl, -s, url], capture_outputTrue, textTrue ) return result.stdout这个工具的作用很单纯接收一个 PromQL 查询语句返回结果。比如我问 AI“现在磁盘还有多少空间”AI 会意识到需要查 node_filesystem_avail_bytes 这个指标然后调用 prom_query 工具最后把返回的字节数转成人话告诉我。为什么用这种方式而不是直接让 AI 去读监控面板截图因为文本化的数据可以让大模型直接参与推理比如它能结合“磁盘剩余 3GB”这个数据和“最近 5 分钟写入速度 200MB/s”这个趋势自己估算出磁盘还能撑多久这就是传统脚本很难实现的综合判断能力。3.2 用 Webhook 把告警变成“喂给 AI 的消息”监控数据解决了“看”的问题接下来解决“听”的问题。Prometheus 有一个 Alertmanager 组件专门负责告警路由和通知。我们要做的就是让 Alertmanager 通过 Webhook 把告警消息推送给 OpenClaw。在 Alertmanager 的配置文件中添加一个 Webhook 接收器route: receiver: openclaw-ai receivers: - name: openclaw-ai webhook_configs: - url: http://localhost:8080/alerts对应地在 OpenClaw 里写一个 HTTP 服务监听/alerts路径。我这里用了 Python 自带的 http.server避免引入额外的框架依赖from http.server import BaseHTTPRequestHandler, HTTPServer import json class AlertHandler(BaseHTTPRequestHandler): def do_POST(self): content_length int(self.headers[Content-Length]) body self.rfile.read(content_length) alert_data json.loads(body) # 写入队列等待AI处理 with open(/tmp/alerts_queue.json, a) as f: f.write(json.dumps(alert_data) \n) self.send_response(200) self.end_headers() HTTPServer((, 8080), AlertHandler).serve_forever()这个设计的目标是实现“告警即消息”Alertmanager 发来一条告警OpenClaw 收到后把它放入待处理队列由 AI 读取、分析、决策、执行。整个过程不需要人工去盯任何面板。3.3 定义“告警等级”让 AI 知道哪些必须立即处理哪些可以稍后再说这里有一个非常实用的经验告警一定要分等级而且要让 AI 学会按等级分配注意力。我在 OpenClaw 的技能配置里写了一个简单的“告警分级规则”具体逻辑是灾难级核心服务不可用、数据盘满载、服务器宕机。AI 必须立即响应秒级处理。警告级CPU 持续高于 90%、内存不足、部分节点延迟升高。AI 在 1 分钟内处理先查看详情。通知级磁盘使用率超过 70%、访问量异常波动。AI 记录日志定期汇总。这个分级可以让 AI 避免陷入“每条告警都去跑一遍命令”的低效行为。实际上大部分通知级告警并不需要动作只需要知道即可。用 OpenClaw 配置时你可以把规则写在skills/alert_triage/skill.md里让 AI 在收到告警后先按规则分流。提示分级规则要用自然语言写清楚别用太复杂的逻辑判断因为 AI 需要的是“能理解”的规则而不是一串苛刻的条件。4. 告警自动处理链路从“收到告警”到“AI 自主修复”的完整设计4.1 一个最常见场景磁盘告警的处理流程拆解我们用一个最常见的场景“磁盘使用率超过 85%”来拆解整个自动处理链路这比空洞地讲“AI 很智能”要直观得多。当磁盘使用率超过阈值Node Exporter 采集到的指标上升Prometheus 触发规则Alertmanager 把告警推给 OpenClaw。OpenClaw 收到后开始执行我的预设逻辑第一步AI 先查“什么在占磁盘”。它调用prom_query查询node_filesystem_avail_bytes和node_filesystem_size_bytes计算出使用率然后通过我定义的脚本du_scan扫描各目录占用#!/bin/bash # du_scan: 找出占空间最大的前10个目录 du -xh --max-depth2 / 2/dev/null | sort -rh | head -10第二步AI 判断是否存在可清理的日志或缓存文件。我的服务器上日志文件集中在/var/logAI 会调用脚本log_cleanup.sh这个脚本的功能是保留最近 7 天的日志删除更老的压缩日志并发送清理前后的大小对比。#!/bin/bash # log_cleanup.sh: 按需清理7天前的日志 find /var/log -name *.log -mtime 7 -delete find /var/log -name *.gz -mtime 7 -delete第三步因为我的脚本设计了“dry-run”模式AI 在执行清理前先用du_scan查看预期释放的空间然后决定要不要真删。如果 AI 判断删除风险较高它会通过企业微信机器人发消息给人工并且把详细的清理计划列出来等待人工确认。这个流程的核心价值在于人所要做的只是审查 AI 的决策而不是手动执行命令。我自己实测下来这类磁盘告警从触发到处理完成AI 平均耗时在 20 秒左右如果是我手动处理从看到手机告警到登录服务器查明原因至少需要 5-10 分钟。4.2 用 SSH 让 AI 可以“动手术”但必须配上安全带AI 要执行命令连到目标服务器是绕不开的一步。我的做法是控制机上生成一对密钥然后把公钥分发到各业务服务器同时给 AI 单独创建一个受限用户而不是直接给它 root 权限。创建受限用户aiops并授权部分命令sudo useradd -m -s /bin/bash aiops sudo mkdir -p /home/aiops/.ssh echo your-public-key-here /home/aiops/.ssh/authorized_keys sudo chown -R aiops:aiops /home/aiops/.ssh为了避免 AI 误操作危险命令我在业务服务器上配置了 sudoers 白名单只允许aiops用户执行以下命令aiops ALL(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/df, /usr/bin/du, /usr/bin/find, /usr/bin/rm, /usr/local/bin/log_cleanup.sh注意我没有把rm -rf加进白名单。AI 需要删除旧日志的时候只能调用我封装好的log_cleanup.sh这个脚本内部有绝对路径限制不会出现误删系统文件的情况。这个设计是整个系统安全性的关键防线也建议你严格照做。4.3 AI 处理告警时的“二次确认”机制在 AI 完全自主执行命令之前我强烈建议在实际运行的前两周设置二次确认机制。OpenClaw 的配置里有一个human_in_the_loop选项开启后AI 在准备执行高风险操作时会先停下来把计划发到你的手机上等你回复确认才会继续。我把操作风险分成三类风险等级示例处理方式低风险查看磁盘烤、查询服务状态、读取日志AI 自主执行无需确认中风险重启非核心服务、清理过期日志、备份文件AI 执行执行后生成报告高风险重启数据库、删除数据、扩容操作AI 暂停并请求人工确认这个分级机制在前两周尤其重要因为你需要观察 AI 的判断是否符合预期一旦发现 AI 的决策逻辑有偏差可以及时调整 skill 规则。两周过后你可以把中风险操作逐步放开为自主执行高风险仍然保持人工确认这样既能提升自动化率又不至于失控。5. 一键执行脚本把日常运维变成 OpenClaw 可以调用的命令5.1 从“人找脚本”到“AI 找脚本”重新设计你的脚本库结构很多运维同学手头都有几十个脚本放在服务器上东一个西一个。要用的时候得在终端里翻半天找路径还得回忆参数是什么。OpenClaw 处理这个问题的方式很简单把你已有的脚本整理进统一目录并在配置里做一个“脚本索引”AI 就能根据描述自动选择并调用。我的脚本目录统一放在/opt/ops-scripts/结构如下/opt/ops-scripts/ ├── monitor/ # 监控相关 │ ├── disk_usage.sh │ ├── service_status.sh │ └── network_check.sh ├── cleanup/ # 清理相关 │ ├── log_cleanup.sh │ ├── tmp_cleanup.sh │ └── docker_prune.sh ├── backup/ # 备份相关 │ ├── mysql_backup.sh │ └── config_backup.sh └── deploy/ # 部署相关 ├── rollback.sh └── update_app.sh然后在 OpenClaw 的配置里添加脚本说明格式很简单就是“脚本路径 功能描述 参数说明”custom_scripts: - path: /opt/ops-scripts/cleanup/log_cleanup.sh description: 清理指定目录下7天前的日志文件参数是日志目录路径 usage: log_cleanup directory [--dry-run] - path: /opt/ops-scripts/backup/mysql_backup.sh description: 备份MySQL数据库到指定目录自动保留最近3份 usage: mysql_backup db_name配置好之后你就可以直接对 AI 说“把 nginx 的错误日志清理一下先看下会释放多少空间”AI 会自行匹配到log_cleanup.sh带上--dry-run参数执行然后把结果告诉你。这种交互方式比手敲命令更像是在指挥一个懂事的助手。5.2 让脚本输出“结构化”AI 才能记得住这里有一个极其重要的细节你写的脚本输出必须结构清晰不能是一堆无头无尾的文本。因为大模型处理的是文本如果脚本输出杂乱无章AI 就很难提取关键信息。举例来说原来的脚本可能是这样#!/bin/bash df -h /dev/vda1输出是Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 35G 3.1G 92% /这个输出 AI 能看懂但不够友好。我把它改成了带标记的输出#!/bin/bash # disk_usage.sh output$(df -h /dev/vda1 | tail -1) total$(echo $output | awk {print $2}) used$(echo $output | awk {print $3}) avail$(echo $output | awk {print $4}) usage_percent$(echo $output | awk {print $5}) echo DISK_STATUS total${total} used${used} avail${avail} usage${usage_percent}输出变成DISK_STATUS total40G used35G avail3.1G usage92%AI 可以非常精准地提取usage92%这个关键数据。这个技巧在写脚本时很容易被忽略但实际效果差异巨大。你可以理解为AI 就像是一个擅长读报表的人你把报表做得越规范它分析得就越快越准。5.3 把“一键执行”做成 AI 的 Skill还要会组合调用单个脚本的调用很简单但运维中很多操作是需要“组合拳”的。比如排查一个服务过载问题可能需要依次查看负载、连接数、日志错误、进程数。如果每次都让 AI 一条一条执行效率并不高。我建议的做法是把一组相关脚本打包成一个 Skill。在 OpenClaw 里Skill 是一个目录里面有SKILL.md说明文件和一系列工具脚本。我设计了一个叫做troubleshoot_service的 Skill专门处理“某服务运行异常”的排查请求。SKILL.md的内容大致如下# 服务异常排查 当用户报告或告警提示某个服务异常时执行以下步骤 1. 检查服务状态service_status service_name 2. 查看最近20行日志journalctl -u service_name --no-pager -n 20 3. 检查CPU和内存占用ps aux | grep service_name 4. 检查端口监听情况ss -tlnp | grep port 5. 汇总以上信息判断根因并给出建议 注意遇到连接数过高的情况优先检查是否有异常来源IP。这个 Skill 的作用是让 AI 收到一个模糊指令时能够自动按次序执行一组操作而不是手足无措。实测中这个 Skill 帮我处理了大量告警效率提升非常明显。6. 实操效果与踩坑记录告警风暴、误判、权限失控我都替你试过了6.1 两个月的实测数据告警处理数量与人工干预次数从部署完成到现在我跑了大约两个月。这个系统管理的服务器一共 8 台包括 2 台生产环境应用服务器、2 台数据库服务器、2 台缓存服务器和 2 台测试环境服务器。我统计了一下近两个月的数据下面这个表可以直观反映效果指标数量总告警数342AI 自主处理完成271需要人工确认51最终人工介入20平均首次响应时间8秒平均处理完成时间45秒也就是说约 79% 的告警可以在无人干预的情况下自动闭环。这个数字基本上对应了标题里说的“解放 80% 运维人力”。当然我必须坦白说这 20 个人工介入的告警里绝大多数都是高风险操作比如数据库磁盘扩容、突发的代码 bug 导致的异常流量这些确实需要人来拍板。6.2 踩坑一告警风暴导致 AI 处理器被“塞满”第一个让我比较狼狈的问题是告警风暴。某天一台服务器上的日志采集服务挂了导致日志量暴涨磁盘迅速被填满然后触发了连续几十条不同维度的告警。OpenClaw 收到告警之后每条都去执行排查流程短时间内并发了十几个 SSH 会话把控制机自己都差点拖垮。后来我在 OpenClaw 里加了一个“告警聚合”机制规则是5 分钟内同一个服务器的告警合并为一次处理只对最高危险等级的那条进行响应。修改后的效果立竿见影告警风暴期间 AI 只处理根因而不是被衍生告警牵着鼻子走。这个经验想分享给大家AI 助理处理告警的速度非常快但如果不对“告警数量”做限流它会被海量重复消息淹没。本质上这和人工值班遇到告警风暴时要做的事情是一样的——先降噪再定位。6.3 踩坑二AI 误判了“重启服务”的时机还有一次 AI 的误判让我记忆犹新。某个不太重要的定时任务服务持续重启AI 判断为“服务崩溃”于是执行了重启操作。但问题是这个服务本身就存在 bug重启后仍然继续崩溃AI 就陷入了“重启-崩溃-再重启”的循环。我后来查看日志才发现这个服务在 20 分钟内被 AI 重启了 11 次。我当时的解决方案是给服务重启操作加了一个“冷却时间”规则同一个服务在 10 分钟内最多重启 2 次超过这个次数就转人工。同时在 Skill 里增加了一条判断如果服务在短时间内反复崩溃优先查看错误日志提取关键词而不是简单重启。毕竟无脑重启只能解决代码 bug 之外的临时性问题对于那些反复崩溃的服务需要的是人工介入看代码。6.4 踩坑三权限过宽险些造成“误删”权限这块我一开始配置得比较粗放给 aiops 用户加了不少命令权限甚至一度把rm都放进了白名单。一次偶然的测试中AI 执行清理脚本时由于脚本内部没有做路径约束差点把/opt/old-project下的备份目录给清理了。幸好我在清理脚本里加了“目录存在且非系统路径”的校验条件才没有造成实际损失。这个经历让我彻底意识到权限安全的重要性。即使 AI 表现得再聪明它仍然是一个概率模型它的每一步操作都应该被约束在预设的、有护栏的范围内。现在我执行的所有清理类脚本第一个参数必须是“允许清理的目录”而且目录必须存在于白名单里否则直接拒绝执行。最后再分享一个小的实操技巧OpenClaw 的日志默认是文本输出建议你在配置里开启 JSON 格式日志这样后续如果想统计 AI 的耗时、成功率对接数据可视化工具会非常方便。我在实际使用中的体会是这套系统并不是“装完就能直接用”前两周的规则打磨期很关键你需要看着 AI 处理每一类告警的方式不断微调技能描述和权限范围。等规则稳定下来你就真能体会到半夜手机安静得像关机是什么感觉了。