OpenClaw健康检查脚本：GLM-4.7-Flash监控系统资源与告警

1. 为什么需要自动化健康检查

去年夏天，我的个人开发服务器因为内存泄漏连续崩溃了三次。每次都是正在跑重要任务时突然宕机，修复后又要重新开始。这种经历让我意识到——个人开发者同样需要可靠的系统监控方案。

传统方案如Zabbix对个人项目过于笨重，而简单crontab脚本又缺乏智能分析能力。直到发现OpenClaw+GLM-4.7-Flash这个组合，才找到适合个人开发者的轻量级解决方案。这套系统最吸引我的特点是：

• 零额外成本：利用现有GLM模型资源
• 可解释性强：模型会给出负载异常的原因推测
• 无缝告警：通过飞书直接推送到手机

2. 核心组件搭建过程

2.1 基础环境准备

我的测试环境是一台4核16GB的Ubuntu云服务器，已经部署了ollama版的GLM-4.7-Flash模型服务。OpenClaw的安装采用了官方推荐的一键脚本：

curl -fsSL https://openclaw.ai/install.sh | bash

安装完成后特别需要注意权限配置。由于要监控系统指标，需要给OpenClaw服务账户添加特殊权限：

sudo usermod -aG disk,adm openclaw

2.2 模型服务对接

在~/.openclaw/openclaw.json中配置本地GLM服务地址时，遇到了第一个坑——ollama默认的11434端口需要明确指定API路径：

{
  "models": {
    "providers": {
      "local-glm": {
        "baseUrl": "http://localhost:11434/api/generate",
        "api": "openai-completions",
        "models": [
          {
            "id": "glm-4-flash",
            "name": "Local GLM-4-Flash",
            "contextWindow": 32768
          }
        ]
      }
    }
  }
}

配置完成后，用这个命令测试模型连通性：

openclaw models test glm-4-flash

3. 健康检查脚本开发

3.1 指标采集模块

核心的bash监控脚本health_check.sh主要采集五类指标：

#!/bin/bash

# CPU负载(5分钟均值)
cpu_load=$(uptime | awk -F'load average: ' '{print $2}' | cut -d, -f2 | tr -d ' ')

# 内存使用率
mem_total=$(free -m | awk '/Mem:/ {print $2}')
mem_used=$(free -m | awk '/Mem:/ {print $3}')
mem_usage=$((mem_used*100/mem_total))

# 磁盘空间(根分区)
disk_usage=$(df -h / | awk 'NR==2 {print $5}' | tr -d '%')

# 网络连接数
conn_count=$(netstat -ant | wc -l)

# 进程异常检测
zombie_procs=$(ps aux | awk '{print $8}' | grep -c Z)

3.2 智能分析模块

原始指标通过OpenClaw传递给GLM模型进行分析。这里设计了一套提示词模板：

你是一个资深Linux系统管理员。请分析以下服务器指标：
- CPU负载: {cpu_load}
- 内存使用率: {mem_usage}%
- 磁盘使用率: {disk_usage}%
- 网络连接数: {conn_count}
- 僵尸进程数: {zombie_procs}

请用中文回答：
1. 当前系统健康状态评分(0-100分)
2. 最需要关注的3个潜在问题
3. 针对每个问题的修复建议

在实际测试中发现，直接传递原始数值会导致模型理解偏差。后来改进为在传递前添加指标说明：

# 在JSON中添加指标描述
metrics_json=$(jq -n \
  --arg cpu "$cpu_load" \
  --arg mem "$mem_usage" \
  --arg disk "$disk_usage" \
  --arg conn "$conn_count" \
  --arg zombie "$zombie_procs" \
  '{metrics: [
    {name: "CPU负载(5分钟均值)", value: $cpu, note: ">1.0表示负载较高"}, 
    {name: "内存使用率", value: $mem, unit: "%", note: ">80%需要关注"},
    {name: "磁盘使用率", value: $disk, unit: "%", note: ">90%需要扩容"},
    {name: "网络连接数", value: $conn, note: "突然激增可能有问题"},
    {name: "僵尸进程数", value: $zombie, note: ">0表示有异常"}
  ]}')

4. 告警系统集成

4.1 飞书机器人配置

在飞书开放平台创建应用时，特别注意要开启"消息接收"权限。配置完成后遇到消息发送失败的问题，最终发现是IP白名单限制：

# 获取服务器公网IP
curl ifconfig.me

将IP加入飞书应用白名单后，测试消息推送：

openclaw feishu send --text "测试告警消息"

4.2 分级告警策略

根据模型输出的健康评分，实现了三级告警机制：

if [ $score -lt 60 ]; then
  # 紧急告警
  openclaw feishu send --title "[紧急] 服务器健康度: $score" --content "$analysis"
elif [ $score -lt 80 ]; then
  # 警告级别
  openclaw feishu send --title "[警告] 服务器健康度: $score" --content "$analysis"
else
  # 正常状态记录日志
  echo "$(date) - 系统健康度: $score" >> /var/log/openclaw_health.log
fi

5. 实际运行效果

这套系统已经稳定运行两个月，成功捕获到三次真实问题：

1. 内存泄漏：模型通过内存使用曲线分析出某个Python服务存在泄漏
2. 磁盘爆满：在达到90%使用率时提前发出警告
3. 异常连接：发现异常的Redis外连请求

最令我惊喜的是GLM-4-Flash的分析能力。有次它通过"CPU负载高但内存使用低"这个矛盾点，准确判断出是某个进程在频繁进行大量计算，而传统监控工具只会简单报"CPU负载高"。

6. 优化与改进方向

目前这套方案还有两个待改进点：

• 历史数据分析：计划增加定时将指标存入SQLite，实现趋势对比
• 自动修复：对已知问题(如日志文件过大)尝试自动处理

对于个人项目和小型服务器，这种轻量级智能监控方案已经足够实用。它最大的优势是不需要维护复杂的监控系统，所有组件都可以用最简方式部署和扩展。

---

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。