OpenClaw Watch Dog

核心用法

openclaw-watchdog 是一款专为 OpenClaw 网关设计的本地守护进程监控工具。它通过每15秒向 localhost:3117/health 发送健康检查请求，实现对网关运行状态的实时监控。当连续3次检测失败后，系统会自动尝试重启网关服务，并通过 Telegram 机器人向用户推送告警通知。

显著优点

• 自愈能力：无需人工干预即可自动恢复服务，显著降低网关宕机时间
• 本地优先：所有诊断和日志分析均在设备本地完成，敏感数据不外泄
• 用户授权机制：关键操作（如重装）需用户通过创建特定文件手动批准，避免误删风险
• 跨平台支持：原生适配 macOS LaunchAgent 和 Linux systemd 用户级服务
• 凭证加密：Telegram 凭证使用 AES-256 配合机器特定密钥加密存储
• 轻量依赖：仅需 Python 3 和 OpenSSL，无额外重量级组件

潜在缺点与局限性

• 单点监控局限：仅监控本地网关健康端点，无法检测网络层或上游依赖故障
• 重启次数限制：2次重启失败后即停止自动修复，需人工介入，可能无法应对顽固故障
• Telegram 依赖：告警通道单一，若用户未及时处理 Telegram 消息可能延误响应
• 配置门槛：需用户自行创建 Telegram Bot 并获取 Chat ID，对非技术用户有一定学习成本
• 无 Web 界面：纯命令行和日志交互，缺乏可视化监控面板

适合人群

• 运行 OpenClaw 网关的个人开发者或小型团队
• 需要基础自动化运维但不想部署复杂监控栈的用户
• 重视数据隐私、希望监控完全本地化的场景
• 已使用 Telegram 作为主要通讯工具的技术用户

常规风险

• 凭证泄露风险：Telegram Bot Token 若被截获可能导致机器人被滥用
• 误重启风险：健康端点设计不当可能导致正常服务被误判为故障
• 服务冲突：与其他系统级监控工具（如 pm2、supervisor）可能产生资源竞争
• 升级兼容性：OpenClaw 网关版本更新可能改变健康检查端点或响应格式

核心功能

openclaw-watchdog 是一款专为 OpenClaw 网关设计的自愈合监控系统，以 Python 编写，作为后台守护进程运行。其核心机制为每 15 秒向 localhost:3117/health 发送健康探测；连续 3 次失败后自动尝试重启网关服务，并将状态通过 Telegram 实时推送至用户。若两次重启仍失败，系统进入"请求用户授权"模式，需用户显式创建批准文件（~/.openclaw/watchdog/approve-reinstall）后才执行重装，避免误操作导致的服务中断。

显著优点

1. 设备绑定加密：Telegram Bot Token 与 Chat ID 采用 AES-256-CBC 加密存储，密钥派生自机器硬件 UUID 与主机名，实现"换机失效"的物理绑定保护，即使配置文件泄露也难以解密。
2. 零外部数据泄露：诊断与日志分析完全在本地执行，仅向 Telegram 发送纯文本告警，不上传任何原始日志或系统信息。
3. 用户级权限隔离：以 macOS LaunchAgent 或 Linux systemd user 服务运行，不涉及 root 提权，符合最小权限原则。
4. 透明可控：敏感操作需用户文件授权，避免自动化脚本的"越权"风险。

潜在局限

• 单一告警渠道：仅支持 Telegram，若用户未安装或网络受限则无法接收通知；无邮件、Webhook 等备选方案。
• 硬件绑定迁移成本：加密配置与机器硬件强绑定，更换设备需重新配置，对多机部署或容器化场景不够友好。
• 个人维护风险：来源为个人开发者 GitHub 仓库（T3），无企业级 SLA 保障，长期维护可持续性存疑。
• Telegram API 限流：高频监控场景下可能触发 Bot API 频率限制，大规模部署需谨慎评估。

适合人群

• 个人开发者或小型团队使用 OpenClaw 网关，需要 7×24 无人值守监控
• 偏好即时通讯告警、已习惯 Telegram 生态的技术用户
• 对数据隐私敏感，希望诊断数据完全本地化的场景

常规风险

• Token 泄露风险：虽然加密存储，但运行时仍需解密调用 API，若设备被攻破，Token 可能被内存提取。
• 误判重启风险：健康探测逻辑相对简单（HTTP 状态码），可能因瞬时网络抖动导致不必要的重启操作。
• 供应链风险：依赖 aiohttp 等 Python 库，需关注上游 CVE 漏洞更新。