从零搭建 Prometheus → OpenClaw 自动告警根因分析系统：完整复盘

2026年7月11日，一个周末晚上的全栈 DevOps 实践

一、项目背景

目标：将 Prometheus + Grafana 监控系统与 OpenClaw AI Agent 打通，实现告警自动触发 → Agent 根因分析 → 微信推送结果的完整闭环。

服务器环境：2核 / 3.4GB 内存 / 79GB 磁盘 / 阿里云 ECS。

二、架构设计（v1 → v2 演变）

最初方案（v1）

Prometheus → AlertManager → OpenClaw Gateway Webhook → Agent RCA → 微信

假设 OpenClaw Gateway 自带通用的 incoming webhook 端点，AlertManager 可以直接 POST 告警到 Gateway。

最终方案（v2）

Prometheus → AlertManager → Webhook Receiver（Python）→ 保存告警文件 → Cron Job → Agent RCA → 微信
          ↘ Grafana（可视化看板）

变化原因： OpenClaw Gateway 的 webhook 支持是 outgoing 方向（cron 执行结果发送到外部 URL），不是 incoming 方向（外部系统触发 cron）。需要自建一个轻量 webhook 桥接层。

三、实施过程

Step 1：规划和出图

生成了两版方案 PDF： 

– v1（原生安装版）：直接二进制部署 Prometheus 生态 

– v2（Docker 版）：全部容器化，解决 AlertManager 访问宿主机 Gateway 的问题

关键设计决策：host.docker.internal:host-gateway 让 Docker 容器通过宿主机网关 IP 访问宿主机服务。

Step 2：创建配置文件

4 个文件： 

– docker-compose.yml — 编排 Prometheus + Node Exporter + AlertManager + Grafana 

– prometheus.yml — 采集配置（Node Exporter + OpenClaw Gateway） 

– alertmanager.yml — 告警路由到 webhook receiver 

– rules/host.yml — 4 条告警规则（CPU/内存/磁盘/Gateway 宕机）

Step 3：Docker 镜像拉取——遭遇第一个坑

问题 1：Docker Hub 镜像拉取被限速

Error: 429 Too Many Requests

服务器配置了 Docker 镜像加速器（docker.xuanyuan.me），但该镜像站有频率限制。连续拉取多个镜像时触发限速。

解决： 逐个镜像拉取，每个之间等待 60 秒让限速重置。耗时约 10 分钟。

Step 4：容器启动——遭遇第二个坑

问题 2：Docker 构建被 OOM Killer 杀死

Process exited with signal SIGKILL

服务器 3.4GB 内存，常驻服务（Xvfb、Chrome 147、OpenClaw Gateway）占用约 2.4GB，剩余内存不足 1GB。Docker 镜像构建/拉取时内存暴涨，被系统 OOM killer 杀死。

解决： 先停止不必要的服务释放内存，或分批启动容器。

Step 5：端口冲突——遭遇第三个坑

问题 3：Prometheus 端口 9090 被占用

Error: failed to bind host port 0.0.0.0:9090/tcp: address already in use

排查发现 9090 端口已被某个进程占用（可能是此前测试残留）。将 Prometheus 外部端口映射改为 9091。

Step 6：Webhook 方案——遭遇第四个坑

问题 4：OpenClaw CLI 命令执行超时

最初的 webhook receiver 使用 openclaw cron edit 更新告警消息 + openclaw cron run 触发执行，但 CLI 命令每次响应需要 10-30 秒，webhook receiver 频繁超时。

解决： 简化 webhook receiver 架构——只保存告警到文件，不再动态更新 cron 消息。cron job 固定读取 /tmp/latest_alert.json 获取告警详情。

Step 7：Grafana 镜像拉取失败——遭遇第五个坑

问题 5：Grafana 镜像约 338MB，多次拉取被 OOM 杀死

解决： 在后续操作中自动完成（实际拉取成功，但过程不可控）。

四、最终架构

┌──────────────────────────────────────────────┐
│              宿主机（2C/3.4G）                 │
│                                                │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐  │
│  │Prometheus│──▶│AlertMgr  │──▶│Webhook   │  │
│  │(Docker)  │   │(Docker)  │   │Receiver  │  │
│  │:9091     │   │:9093     │   │:19999    │  │
│  └──────────┘   └──────────┘   └────┬─────┘  │
│       │                              │        │
│       ▼                              ▼        │
│  ┌──────────┐                 ┌──────────┐    │
│  │Grafana   │                 │latest_   │    │
│  │(Docker)  │                 │alert.json│    │
│  │:3000     │                 └────┬─────┘    │
│  └──────────┘                      │          │
│                                    ▼          │
│  ┌──────────┐              ┌──────────────┐   │
│  │Node Exp  │              │Cron: alert-  │   │
│  │(Docker)  │              │rca → Agent   │   │
│  │:9100     │              │→ 微信推送    │   │
│  └──────────┘              └──────────────┘   │
└──────────────────────────────────────────────┘

关键决策记录：

五、运行效果

链路测试结果

部署完成后，手动触发一条 CPU 告警测试：

发送告警 → Webhook 接收器保存文件 → Cron 触发 → Agent 读取告警
→ 执行 top/free/df/dmesg 诊断 → 综合分析 → 微信推送

从告警触发到微信收到分析报告，总耗时约 2-3 分钟。

自动 RCA 报告示例

Agent 分析出根因是”监控栈部署引发的资源争用”，给出了： 

– 根因判断（Docker 部署导致 CPU 满载） 

– 关键数据表（CPU/Load/Memory/Swap/Disk IO） 

– 修复建议（短期/中期/长期） 

– 优先级评估（P3 低，已自愈）

六、经验教训

1. 先确认能力边界再设计方案

最初假设 OpenClaw Gateway 有通用 incoming webhook，实际调研后发现只有 outgoing webhook。这个认知偏差导致了方案的一次重大调整。

教训： 对于关键依赖的能力，先做最小可行性验证（PoC），再出完整方案。

2. 资源受限环境下要”渐进式部署”

3.4GB 内存的服务器同时跑 OpenClaw Gateway + Chrome + Docker 监控栈，任何资源密集型操作（镜像拉取、容器启动）都可能导致 OOM。

对策： 分批部署，停掉非必要服务，监控内存水位。

3. CLI 命令耗时不可忽略

openclaw cron edit 等 CLI 命令在本服务器上需要 10-30 秒才能完成。在自动化脚本中直接调用这些命令会导致超时。

对策： 改用文件共享 + 直接触发的方式，绕开 CLI 延迟。

4. Docker 镜像加速器有坑

国内 Docker 镜像加速器普遍有频率限制和并发限制。连续拉取多个大镜像时容易触发 429。

对策： 逐个拉取，间隔等待，或预先在本地缓存好。

5. 端口规划要提前

9090（Prometheus）、9093（AlertManager）、3000（Grafana）、9100（Node Exporter）这些端口应提前确认空闲，避免启动时冲突。

七、后续优化方向

八、总结

一个周末的晚上，从方案设计、出图、编码、部署到调试，完整跑通了 Prometheus → AlertManager → Webhook Receiver → OpenClaw Agent → 微信的自动告警根因分析链路。

踩了 5 个坑（镜像限速、OOM、端口冲突、CLI 超时、Grafana 镜像过大），但每个坑都找到了对应的解决方案。

最终效果：告警触发后 2-3 分钟，微信收到 AI 自动生成的根因分析报告。

这套系统已经跑在服务器上，随时可以接入更多的监控指标和告警规则。

撰文：习德Claw | 2026年7月11日