Carry の Blog
Carry の Blog
2026-06-27
目录

OpenClaw 实战 09｜监控告警：7 个真正有用的信号与告警噪声治理原创

# 监控告警：7 个真正有用的信号与告警噪声治理

这一篇讲怎么给 OpenClaw 搭一套不会被忽视的告警——只盯 7 个真正有用的信号，3 级告警，一个通知渠道（Telegram）。

关键认知有两条：① 告警不被响应 = 没有告警；② "进程 RUNNING" 是 OpenClaw 监控里最骗人的信号——它能 RUNNING 着，CLI 却全挂、Agent 在死循环刷屏。下面的 7 个信号就是冲着这两条来的。

# §1 进程一直 RUNNING，Telegram 却被刷屏了

某天早上，家用 NAS 上的 OpenClaw 开始疯狂往 Telegram 发消息——几十条/分钟，全是同一段错误。我第一反应去看服务状态：

$ systemctl --user status openclaw-gateway
   Active: active (running)
1
2

RUNNING。 按"进程活着就没事"的直觉，这里该收手了。但实际上 Agent 已经卡在一个 browser endpoint blocked by policy 的死循环里，反复重试、反复发 Telegram（详见 08 故障排除）。

这件事定了本文的调子：OpenClaw 的监控不能只盯"进程在不在"，要盯它"是不是真的在正常工作"。 这是 7 个信号里最重要的取舍。

# §2 7 个核心信号（只盯这 7 个）

其他都先挂 dashboard、不进告警。告警项越少，响应率越高。

# 信号 怎么取 级别
1 Gateway 健康 curl gateway 端口（默认 18789）的健康端点 Critical
2 进程"假死"（token mismatch） 日志 grep "gateway token mismatch" Critical
3 死循环 / 工具策略抖动 日志 grep -c "tool policy removed" 频率 Critical
4 内存压力 日志 grep "memory pressure" Warning
5 磁盘可用空间 df ~/.openclaw（sqlite + media 会涨） Critical
6 Cron 作业失败 openclaw cron runs <id> 里 error 比例 Warning
7 后台自治还活着吗 DREAMS.md / MEMORY.md 的 mtime 是否在更新 Warning

逐个说几个 OpenClaw 特有的：

信号 1 — Gateway 健康

# 1 分钟一次。注意：这只证明 gateway 在听，不证明 CLI 能鉴权连上（见信号 2）
curl -sf http://localhost:18789/health >/dev/null || echo "GATEWAY DOWN"
1
2

信号 2 — 假死（token mismatch）：这是 OpenClaw 最隐蔽的故障。config 的 gateway.auth.token 和 env 的 OPENCLAW_GATEWAY_TOKEN 不一致时，CLI 报 unauthorized 全挂，但 Telegram 走降级轮询还在回消息——进程 RUNNING、Telegram 有反应，你以为没事，其实控制面已死。

# 容器看 supervisor 日志，裸机看 journal
grep -c "gateway token mismatch" /var/log/supervisor/openclaw.log    # >0 就报
1
2

信号 3 — 死循环：§1 那种刷屏，特征是 tool policy removed 在短时间内高频出现。

# 10 分钟内出现次数；正常个位数，>20 基本是在死循环
grep -c "tool policy removed" <(journalctl --user -u openclaw-gateway --since "10 min ago")
1
2

信号 4 — 内存压力：OpenClaw 自己会在日志里打 memory pressure，这比盯 RSS 数字更直接。

grep "memory pressure" /var/log/supervisor/openclaw.log | tail
1

信号 7 — 后台自治活性：dreaming（写 DREAMS.md）和 heartbeat 是"应该自己在跑"的东西。它们停更往往是 Agent 整体不健康的早期信号。

# DREAMS.md 超过 48h 没更新 → 后台反思可能没在跑
find ~/.openclaw/workspace/DREAMS.md -mtime +2 -print
1
2

复用规则：只让这 7 个进告警。CPU 曲线、QPS 这类挂 dashboard 看就行，别让它们半夜叫醒你。

# §3 告警分级（3 级够了）

Critical / Warning / Info。4 级是噪音制造机。

级别 触发 通知 响应
Critical Gateway 挂 / token mismatch / 死循环 / 磁盘满 Telegram 立即推 + 多次重试 立即
Warning 内存压力 / Cron 失败 / 后台停更 Telegram 单条 24h 内
Info 正常事件（备份完成等） 不发，只写日志 不响应

设计要点：Critical 必须配一个"已知动作"——比如死循环 → restart openclaw，token mismatch → 对齐 token 后重启。告警发出来却没人知道怎么处理，等于没发。

# §4 通知渠道：只用 Telegram

OpenClaw 本来就和 Telegram 深度绑定，告警走它最自然，也最可能被看到：

Critical ─► Telegram（实时 + 重试）
Warning  ─► Telegram（单条，可每小时汇总）
Info     ─► 写日志，不通知
1
2
3

不接 Slack（下班不看）、不接邮件（淹没在噪音里）。渠道越多，"漏看"的风险越大。

# §5 噪声治理（4 类噪音）

噪音 症状 解药
抖动 指标瞬跳触发多次 告警带持续时间（如连续 15 分钟超阈值才报）
重复 同一问题刷 50 条 每条告警带 fingerprint，30 分钟内只发一次
开发期 调试时 CPU 跑满乱报 维护窗口文件 ~/.openclaw/.maintenance 存在则静默
死循环自身 故障本身就是刷屏 限流 + 直接 restart，不要让告警跟着刷屏

去重的最小实现：

send_alert() {  # $1=level $2=msg $3=fingerprint
  local now=$(date +%s) log=~/.openclaw/monitor/last_alert.log
  local last=$(grep -F "$3" "$log" 2>/dev/null | tail -1 | cut -d'|' -f2)
  [ -n "$last" ] && [ $((now-last)) -lt 1800 ] && return   # 30 分钟内同 fingerprint 不重发
  # …发 Telegram…
  echo "$3|$now|$2" >> "$log"
}
1
2
3
4
5
6
7

复用规则：告警必须有持续时间 + fingerprint 去重，否则一次故障就能把你淹没到关通知。

# §6 最小可用监控脚本

#!/bin/bash
# ~/.openclaw/monitor/check.sh —— 挂到 cron 每 5 分钟跑一次
LOG=/var/log/supervisor/openclaw.log          # 裸机改成 journalctl

# 1. Gateway 健康
curl -sf http://localhost:18789/health >/dev/null || send_alert critical "gateway /health 失败" gw_health

# 2. 假死（token mismatch）
grep -q "gateway token mismatch" <(tail -n 500 "$LOG") && \
  send_alert critical "token mismatch：CLI 控制面可能已挂（Telegram 仍在轮询）" token_mismatch

# 3. 死循环（tool policy 抖动）
churn=$(grep -c "tool policy removed" <(tail -n 2000 "$LOG"))
[ "$churn" -gt 20 ] && send_alert critical "疑似死循环：tool policy removed x$churn" deadloop

# 4. 内存压力
grep -q "memory pressure" <(tail -n 500 "$LOG") && send_alert warning "内存压力" mem_pressure

# 5. 磁盘
use=$(df ~/.openclaw | tail -1 | awk '{print $5}' | tr -d '%')
[ "$use" -gt 90 ] && send_alert critical "磁盘 $use%" disk

# 6. 后台自治停更
find ~/.openclaw/workspace/DREAMS.md -mtime +2 -print | grep -q . && \
  send_alert warning "DREAMS.md 超 48h 未更新，后台反思可能停了" dreaming_stale
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

挂到 cron（注意 cron add 的 scope 问题见 02）：

openclaw cron add --every 5m --tz Asia/Shanghai --name monitor \
  --message "bash ~/.openclaw/monitor/check.sh" --session isolated --tools exec
1
2

# §7 复用规则（一句话带走）

7 个信号 + 3 级告警 + 1 个 Telegram + 30 分钟去重 = 能救命的监控；而其中最值钱的一条是：别信"进程 RUNNING"。

展开 3 条：

  1. 盯"在不在正常工作"而非"进程在不在"——token mismatch、死循环、后台停更都是 RUNNING 状态下的故障。
  2. 只让 7 个信号进告警，其余挂 dashboard。
  3. 告警必须有持续时间 + fingerprint，Critical 要绑一个已知修复动作。

# §8 下一篇

下一篇：10｜扩展开发——57 个内置 skill、ClawHub 装新 skill 的完整流程，与链路证伪调优。

# §9 Agent 可直接解析的元数据块

{
  "_meta": {
    "doc_version": "2026-06-27",
    "article_id": "openclaw-09-monitoring",
    "profile_context": "any",
    "estimated_read_time": "10min"
  },
  "seven_signals": [
    {"id": "gateway_health", "how": "curl gateway :18789 health", "severity": "critical", "note": "只证明在听，不证明 CLI 能连"},
    {"id": "token_mismatch", "how": "grep 'gateway token mismatch'", "severity": "critical", "note": "CLI 全挂但 Telegram 降级轮询仍回消息"},
    {"id": "deadloop", "how": "grep -c 'tool policy removed' 频率", "severity": "critical"},
    {"id": "memory_pressure", "how": "grep 'memory pressure'", "severity": "warning"},
    {"id": "disk", "how": "df ~/.openclaw", "severity": "critical"},
    {"id": "cron_failures", "how": "openclaw cron runs <id> error 比例", "severity": "warning"},
    {"id": "background_liveness", "how": "DREAMS.md / MEMORY.md mtime", "severity": "warning"}
  ],
  "alert_levels": {
    "critical": "Telegram 立即推 + 重试；必须绑已知修复动作",
    "warning": "Telegram 单条，24h 内",
    "info": "写日志不通知"
  },
  "noise_policies": {
    "flapping": "持续时间（连续 15min 超阈值才报）",
    "dedup": "fingerprint，30min 内同 fingerprint 只发一次",
    "maintenance": "~/.openclaw/.maintenance 存在则静默",
    "deadloop": "限流 + 直接 restart，别跟着刷屏"
  },
  "safety_rules": [
    "别信进程 RUNNING——盯 token mismatch / 死循环 / 后台停更",
    "只让 7 个信号进告警，其余挂 dashboard",
    "Critical 绑一个已知修复动作",
    "告警必须有持续时间 + fingerprint",
    "通知只走 Telegram"
  ],
  "verification": {
    "simulate_down": "停 gateway → Critical 在 1 分钟内到 Telegram",
    "dedup_check": "重复触发 → 30 分钟内只收到一条"
  },
  "reusable_rule": "7 信号 + 3 级 + 1 Telegram + 30 分钟去重；最值钱的是别信进程 RUNNING"
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

AI Agent 使用指南：

  • 当用户说"Agent 在 Telegram 刷屏" → 信号 3 死循环，限流 + restart
  • 当用户说"进程 RUNNING 但 CLI 连不上" → 信号 2 token mismatch，对齐 token 后重启
  • 当用户说"想搭监控" → 7 信号 + 3 级 + Telegram，别上 200 指标
  • 当用户说"告警太吵" → 加持续时间 + fingerprint 去重
  • 当用户说"OpenClaw 越来越慢/卡" → 看信号 4 内存压力 + 信号 7 后台停更
#OpenClaw#AI Agent#监控告警#内存压力#死循环#Telegram#噪声治理
上次更新: 6/28/2026

← OpenClaw 实战 10｜扩展开发：Skill / Tool / Plugin 区分 + 完整安装流程 + 链路证伪调优→

最近更新
01
Hermes Agent 实战 15｜告别临时 RAG：用 Karpathy 的 LLM Wiki 给 Agent 装上可生长的长期记忆 原创
06-29
02
OpenClaw 实战 11｜最佳实践：10 条从真实翻车提炼的 SOP + 推送二次确认硬规则 原创
06-27
03
OpenClaw 实战 07｜部署指南：3 形态决策树 + OpenWebUI 接入 + FreshRSS 跨实例 原创
06-27
更多文章>
Theme by Vdoing