OpenClaw监控告警：千问3.5-27B分析服务器日志

1. 为什么选择OpenClaw做日志监控？

去年我的个人博客服务器频繁出现502错误，每次都是用户先发现并留言反馈。传统监控工具如Zabbix对小型项目过于笨重，而云服务商的告警功能又需要将日志上传第三方平台。直到发现OpenClaw的SSH技能模块，配合本地部署的千问3.5-27B模型，终于实现了符合我需求的轻量级解决方案。

这套组合的核心优势在于：

• 隐私保障：所有日志分析都在本地完成，敏感信息不会外泄
• 语义理解：大模型能识别"Connection refused"和"Too many open files"等错误的业务影响差异
• 灵活定制：可以随时调整监控规则，比如将"error"关键词监控改为特定错误码模式匹配

2. 基础环境搭建

2.1 模型部署准备

我使用的是星图平台预置的千问3.5-27B镜像，主要看中其两个特性：

• 支持32k上下文长度，能分析较长的日志片段
• 提供兼容OpenAI的API接口，方便OpenClaw调用

部署完成后，通过curl测试接口可用性：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.5-27b",
    "messages": [{"role": "user", "content": "请用一句话说明你是谁"}]
  }'

2.2 OpenClaw核心配置

安装SSH技能模块是关键步骤：

clawhub install ssh-connector log-analyzer

配置文件~/.openclaw/openclaw.json需要添加SSH连接信息：

{
  "skills": {
    "ssh": {
      "servers": [
        {
          "name": "my-blog",
          "host": "192.168.1.100",
          "port": 22,
          "username": "ubuntu",
          "privateKeyPath": "~/.ssh/id_rsa"
        }
      ]
    }
  }
}

特别注意：私钥文件权限需设置为600，否则OpenClaw会拒绝使用。

3. 告警流水线设计

3.1 日志采集机制

我采用"主动拉取+事件触发"双模式：

• 定时任务：每5分钟获取/var/log/nginx/error.log最新50行
• 触发式采集：当检测到error数量突增时，自动获取完整日志文件

OpenClaw的SSH技能支持直接执行远程命令：

ssh my-blog "tail -n 50 /var/log/nginx/error.log"

3.2 分析逻辑实现

通过自定义prompt让千问3.5-27B执行结构化分析：

你是一个专业的运维工程师，请分析以下Nginx错误日志：
1. 按严重程度将错误分类（Critical/Major/Minor）
2. 判断是否需要立即人工干预
3. 给出初步解决建议

日志内容：
{{LOG_CONTENT}}

模型返回的JSON结构示例：

{
  "summary": "发现3处Critical级别错误",
  "details": [
    {
      "error": "connect() failed (111: Connection refused)",
      "level": "Critical",
      "suggestion": "检查上游服务是否崩溃"
    }
  ]
}

3.3 飞书通知集成

配置飞书机器人时遇到个坑：必须同时设置appId和appSecret才能生效。完整配置如下：

{
  "channels": {
    "feishu": {
      "enabled": true,
      "appId": "cli_xxxxxx",
      "appSecret": "xxxxxx-xxxxxx",
      "notificationWebhook": "https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxx"
    }
  }
}

告警消息模板采用飞书交互式卡片，关键字段通过Mustache语法注入：

{
  "msg_type": "interactive",
  "card": {
    "elements": [{
      "tag": "div",
      "text": {
        "content": "**{{level}}** 在{{server}}发现错误：\n\n{{error}}\n\n建议：{{suggestion}}",
        "tag": "lark_md"
      }
    }]
  }
}

4. 实际运行效果

这套系统已经稳定运行两个月，最成功的案例是提前发现了磁盘空间不足的问题。模型从大量"502 Bad Gateway"错误中识别出根本原因是inode耗尽，而传统监控只关注了磁盘剩余容量。

典型告警流程时间线：

1. 09:15:00 - OpenClaw采集到新日志
2. 09:15:03 - 千问3.5-27B完成分析
3. 09:15:05 - 飞书收到告警卡片
4. 09:15:30 - 我通过手机查看并处理

5. 踩坑与优化经验

权限问题：最初使用root账号直接采集日志，后被模型建议改为专用只读账号。实现方法是在目标服务器创建monitor用户：

sudo useradd -r -s /bin/bash -d /var/log/monitor monitor
sudo setfacl -R -m u:monitor:r /var/log/nginx

Token消耗控制：通过以下策略将日均Token消耗控制在5000以内：

• 对重复错误进行聚合
• 只在首次出现新错误类型时请求详细分析
• 对已知问题直接匹配预存解决方案

模型微调建议：当发现模型对某些专业术语理解不准时，可以在prompt中添加术语表。例如针对MySQL错误日志：

术语说明：
[Deadlock] 指两个事务互相等待对方释放锁
[Lock wait timeout] 事务等待锁超时

这套系统现在已成为我的个人项目标配组件，最近还扩展到了数据库慢查询监控。它的价值不在于替代专业监控工具，而是为开发者提供了一种可编程、可解释的轻量级方案。

---

获取更多AI镜像

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