Kora 健康监测系统详解

运行数百个独立的用户 AI 实例，每个都需要 24/7 在线——这是 Kora 面临的核心运维挑战之一。本文深入解析我们的健康监测系统。

问题背景

Kora 的每个用户实例是一个独立运行的 Docker 容器，包含 OpenClaw AI 代理进程、工作区文件系统和活跃的消息推送连接。当某个实例出现问题时，我们需要：快速检测、自动恢复、通知用户、根因分析。

架构设计

健康监测系统由三个核心组件构成：

• Heartbeat Checker — 定期检查每个实例的心跳信号
• Resource Monitor — 监控 CPU、内存、磁盘使用率
• Log Analyzer — 分析错误日志，识别异常模式

这三个组件的事件汇集到 Event Queue，由 Auto Heal（自动修复）和 Alert Manager（告警分发）处理。

心跳检测

每个用户实例每 5 分钟发送一次心跳信号，包含实例 ID、状态（healthy/degraded/error）、运行时间、队列任务数和最后活动时间。

超时判断策略：

• 10 分钟无心跳 → 触发告警，等待确认
• 15 分钟无心跳 → 自动重启实例
• 30 分钟无心跳 → 通知用户，标记为 degraded

资源监控

每 1 分钟采集一次每个实例的资源使用情况：

• CPU 使用率持续 > 90%（5 分钟）→ 警告
• 内存使用率 > 85% → 触发 GC 或重启
• 磁盘使用率 > 90% → 清理临时文件，通知用户

自动恢复策略

1. 软重启 — 重启 AI 代理进程，保留工作区文件（30 秒完成）

2. 容器重启 — 重建容器，挂载用户数据卷（2 分钟完成）

3. 实例迁移 — 将用户数据迁移到新的宿主机（5 分钟，最后手段）

恢复操作使用分布式锁，确保同一实例不会被并发恢复操作干扰。

可观测性

我们使用 Grafana + Prometheus 构建了实时监控大盘，核心指标包括：实例健康率（目标 > 99.5%）、平均恢复时间 MTTR（目标 < 3 分钟）、心跳延迟 P99（目标 < 30 秒）、自动恢复成功率（目标 > 95%）。

实测数据

过去 30 天的运行数据：整体可用性 99.87%，共发生 47 次软重启（100% 自动恢复），平均恢复时间 1.8 分钟，用户感知中断次数仅 3 次（均在 5 分钟内解决）。

未来优化方向

• 预测性维护 — 通过历史数据预测实例故障，提前迁移
• 自适应阈值 — 根据用户使用模式动态调整告警阈值
• 根因分析 AI — 用 LLM 自动分析错误日志，生成修复建议

健康监测系统是 Kora 可靠性的基石。如果你对技术细节有兴趣，欢迎查看我们的开源监控代码或在论坛提问！