Margrop
Articles320
Tags481
Categories7

Categories

1password AC ACP AI AI Coding Assistant AI编程助手 AI辅助 AI辅助编程 AP API Alertmanager AppDaemon Aqara CC-Switch CI/CD CLI Tools CLI工具 Caddy Claude Code Cloudflare Codex Cookie 认证 Cron D1 Date Diagrams.net Diary Docker Docker Compose Efficiency Tools Electerm English Gateway Gemini CLI GitHub Actions HA HADashboard Hexo HomeAssistant IP IPv4 Java LVM‑Thin Linux MacOS Markdown MiniMax Multi-Agent MySQL NAS Nginx Node-RED Node.js OOM OpenAI OpenClaw OpenCode OpenResty OpenWrt PPPoE Portainer PostgreSQL ProcessOn Prometheus Proxmox VE RPC SOCKS5 SSL Session Shell Subagent TTS TimeMachine UML Uptime Kuma VPN VPS Web WebSocket Windows Workers activate ad adb adblock agent aligenie aliyun alpine annotation aop authy autofs backup baidupan bash bitwarden boot brew browser caddy2 cdn centos cert certbot charles chat chrome classloader client clone closures cloudflare cmd command commit container crontab ctyun ddsm demo dependency deploy developer devtools dll dns docker domain download draw drawio dsm dump dylib edge exception export fail2ban feign firewall-cmd flow frp frpc frps fuckgfw function gcc gfw git github golang gperftools gridea grub gvt-g hacs havcs heap hello hexo hibernate hidpi hoisting homeassistant hosts html htmlparser https iKuai idea image img img2kvm immortalwrt import index install intel io ios ip iptables iptv ipv6 iso java javascript jetbrains jni jnilib jpa js json jsonb jupter jupyterlab jvm k8s kernel key kid kms kodi koolproxy koolproxyr kvm lan lastpass launchctl learning lede letsencrypt linux live low-code lvm lxc m3u8 mac macos mariadb markdown maven md5 microcode mirror modem modules monitor mount mstsc mysql n2n n5105 nas network nfs node node-red nodejs nohup notepad++ npm nssm ntp oop openfeign openssl os otp ovz p14 packet capture pat pdf pem perf ping pip plugin png powerbutton print pro proxy pve pvekclean python qcow2 qemu qemu-guest-agent rar reboot reflog remote remote desktop renew repo resize retina root route router rule rules runtime safari sata scipy-notebook scoping scp server slmgr so socks source spk spring springboot springfox ssh ssl stash string supernode svg svn swagger sync synology systemctl systemd tap tap-windows tapwindows telecom template terminal tls tmux token totp tvbox txt ubuntu udisk ui undertow uninstall unlocker upgrade url v2ray vhd vim vlmcsd vm vmdk web websocket wechat windows with worker wow xiaoya xml yum zip 中国电信 云电脑 交换机 人机协作 代理 优化 体检 值班 健康检查 光猫 公网IP 内存 内存优化 内网 内网IP 内网渗透 写作 升级 协作 博客 反向代理 启动 告警 告警优化 周一 周一焦虑 周五 周末 夏令时 多智能体 多节点 多节点管理 天猫精灵 天翼云 安全 安装 定时任务 容器 容器网络 导入 小米 工作感悟 常用软件 广告屏蔽 序列号 应用市场 异常 心智成长 心跳 心跳检查 性能优化 感悟 打工 打工人 技术 抓包 排查 描述文件 故障 故障排查 效率 效率工具 旁路由 无服务器 日记 时区 显卡虚拟化 智能家居 智能音箱 服务器 服务管理 架构 梯子 模块 流程 流程图 浏览器 漫游 激活 火绒 焦虑 玄学 生活 电信 画图 监控 监控系统 直播源 直觉 磁盘 端口 端口冲突 端口扫描 管理 续期 网关 网络 网络风暴 群晖 脚本 脚本优化 腾讯 自动化 自动恢复 虚拟机 认证 证书 语雀 超时 路由 路由器 软件管家 软路由 运维 运维监控 连接保活 连接问题 通信机制 通知 部署 配置 钉钉 镜像 镜像源 门窗传感器 问题排查 防火墙 阿里云 阿里源 集客 飞书

Hitokoto

Archive

OpenClaw 健康检查超时与恢复机制详解:从原理到实践

OpenClaw 健康检查超时与恢复机制详解:从原理到实践

前言

作为一名运维工程师,最让人头疼的不是服务器宕机,而是服务器明明还活着,但已经”半死不活”了

什么意思呢?服务进程在跑,端口在监听,但就是无法正常响应请求。这种情况,健康检查会超时,但自动重启又不会触发——因为你定义的”进程存活”条件是满足的。

今天这篇文章,我们来深入聊聊 OpenClaw 的健康检查机制,以及如何配置合理的超时与恢复策略。

问题背景

典型的”假存活”场景

在实际运行中,我们遇到了以下问题:

场景一:RPC 调用 hang 住

某 VM 上的 OpenClaw Gateway 进程正常运行,但 RPC 调用突然 hang 住。所有发往 Gateway 的请求都在等待响应,超时时间被迫变得越来越长——从默认的 3 秒,到 5 秒,到 10 秒,但仍然收不到响应。

查看进程状态,一切正常:

  • 进程 PID 存在
  • 端口 18789 正在监听
  • systemd 显示服务状态为 active

但实际上,Gateway 已经无法处理新的请求。

场景二:连接池耗尽

某服务的连接池配置偏小,在高并发场景下连接池迅速耗尽。后续请求排队等待,最终超时。

但健康检查仍然会”成功”——因为健康检查只是简单地 TCP 连接一下端口,并不检查应用层的实际响应能力。

场景三:内存泄漏导致响应变慢

某节点因为内存泄漏,对象无法被 GC 回收。随着时间推移,可用内存越来越少,最终导致请求处理变慢,部分请求超时。

但健康检查仍然通过——因为健康检查并不检查内存使用率。

问题根因

这些问题的根因是什么?是健康检查的定义不够全面

传统的健康检查只检查”进程是否存活”:

  • 进程 PID 是否存在
  • 端口是否在监听
  • systemd 服务状态是否为 active

但这些条件只能证明”进程还活着”,不能证明”进程还能正常服务”。

一个真正健康的节点,应该满足以下条件:

  1. 进程存活:PID 存在
  2. 端口可达:TCP 连接成功
  3. 响应正常:在合理时间内返回有效响应
  4. 资源充足:CPU、内存、磁盘都在合理范围内

OpenClaw 健康检查架构

检查类型

OpenClaw Gateway 支持多种健康检查方式:

1. TCP 连接检查

这是最基本的检查。向 Gateway 的 Web UI 端口发送 TCP 连接请求,如果能建立连接,说明端口可达。

1
2
3
4
# 检查端口是否可达
nc -zv 192.168.102.xxx 18789
# 或
telnet 192.168.102.xxx 18789

2. HTTP 健康端点检查

OpenClaw Gateway 提供了一个健康检查端点 /health,可以通过 HTTP 请求检查服务状态:

1
2
3
curl -s http://192.168.102.xxx:18789/health
# 正常响应:{"status":"ok","uptime":123456}
# 异常响应:超时或错误

这个端点会检查:

  • Gateway 进程是否正常响应
  • RPC 连接是否正常
  • 消息通道是否已连接

3. RPC 连接检查

OpenClaw Gateway 通过 RPC 与其他组件通信。RPC 连接的健康状态可以通过以下方式检查:

1
2
# 检查 RPC 端口
ss -tlnp | grep 18789

4. 综合健康检查

综合健康检查会同时检查多个维度:

  • 系统资源:CPU、内存、磁盘
  • 应用状态:进程、端口、响应时间
  • 依赖服务:数据库、缓存、外部 API

配置参数

OpenClaw Gateway 的健康检查相关配置参数:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 健康检查配置
health:
# 是否启用健康检查
enabled: true

# 检查间隔(毫秒)
interval: 30000 # 30秒

# 超时时间(毫秒)
timeout: 5000 # 5秒

# 连续失败多少次后触发重启
failureThreshold: 3

# 重启前等待时间(毫秒)
restartDelay: 10000

常见问题与解决方案

问题一:健康检查通过但服务实际不可用

现象:健康检查显示正常,但实际请求全部超时

原因:健康检查端点响应正常,但应用逻辑已经 hang 住

排查步骤

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 1. 检查进程状态
ps aux | grep openclaw-gateway

# 2. 查看进程树
pstree -p $(pgrep openclaw-gateway)

# 3. 检查线程状态
top -Hp $(pgrep openclaw-gateway)

# 4. 查看 GC 日志
grep "GC" /var/log/openclaw/gc.log

# 5. 检查内存使用
free -h

解决方案

  1. 添加应用层的健康检查,不仅仅是 TCP 连接
  2. 增加超时时间的动态检测
  3. 配置自动重启机制

问题二:频繁超时导致频繁重启

现象:服务因为偶尔的超时而频繁重启,每次重启都会造成连接中断

原因:超时阈值设置过低,或者网络本身不稳定

排查步骤

1
2
3
4
5
6
7
8
# 1. 查看重启历史
journalctl -u openclaw-gateway -n 50

# 2. 检查网络稳定性
ping -c 100 192.168.102.xxx

# 3. 查看历史告警
grep "timeout" /var/log/openclaw/app.log | tail -20

解决方案

  1. 适当调高超时阈值
  2. 增加连续失败次数阈值
  3. 添加”熔断器”机制,失败后等待一段时间再试

问题三:服务状态显示 active 但实际已停止响应

现象:systemctl status 显示 active,但服务实际已经无法响应

原因:systemd 的 active 状态只说明进程在跑,不说明进程能正常工作

排查步骤

1
2
3
4
5
6
7
8
9
10
11
# 1. 检查 systemd 服务的启动时间
systemctl status openclaw-gateway

# 2. 检查进程的实际运行时间
ps -p $(pgrep openclaw-gateway) -o etime=

# 3. 检查进程的父进程
ps -ef | grep $(pgrep openclaw-gateway)

# 4. 手动触发健康检查
curl -s --connect-timeout 5 http://localhost:18789/health

解决方案

  1. 使用 systemctl 配合手动健康检查
  2. 配置 systemd 的 ExecStartPost 启动后验证
  3. 添加 watchdog 机制

自动恢复机制

systemd 的自动重启配置

OpenClaw Gateway 通过 systemd 管理时,可以配置自动重启:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[Unit]
Description=OpenClaw Gateway
After=network.target

[Service]
Type=simple
User=root
ExecStart=/opt/openclaw/openclaw-gateway --config=/etc/openclaw/config.yml
Restart=always
RestartSec=10
StartLimitBurst=3
StartLimitIntervalSec=60

# 启动后验证服务是否正常
ExecStartPost=/usr/bin/curl -f http://localhost:18789/health || false

[Install]
WantedBy=multi-user.target

关键配置说明:

  • Restart=always:无论什么原因退出,都自动重启
  • RestartSec=10:重启前等待 10 秒
  • StartLimitBurst=3:60 秒内最多重启 3 次
  • StartLimitIntervalSec=60:统计重启次数的时间窗口

健康检查 + 自动重启联动

健康检查和自动重启的联动流程:

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
┌─────────────┐
│ 启动服务 │
└──────┬──────┘


┌─────────────┐ ┌─────────────┐
│ 执行健康检查 │────▶│ 检查结果? │
└─────────────┘ └──────┬──────┘
│ │
│ ┌─────┴─────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────┐ ┌─────────┐
│ 正常运行 │ │ 警告处理 │ │ 异常处理 │
└─────────────┘ └─────────┘ └────┬────┘
│ │
│ ▼
│ ┌─────────────┐
│ │ 自动重启 │
│ └─────────────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ 继续监控 │◀───────────│ 循环检查 │
└─────────────┘ └─────────────┘

自定义恢复脚本

如果默认的 systemd 重启不能满足需求,可以编写自定义恢复脚本:

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
41
42
43
44
45
46
47
48
49
#!/bin/bash
# /opt/scripts/health-check-and-recover.sh

GATEWAY_PORT=18789
MAX_RETRIES=3
RETRY_INTERVAL=30

check_gateway() {
# 检查进程是否存在
if ! pgrep -f "openclaw-gateway" > /dev/null; then
echo "[$(date)] 进程不存在,尝试启动..."
systemctl start openclaw-gateway
return 1
fi

# 检查端口是否可达
if ! nc -z localhost $GATEWAY_PORT 2>/dev/null; then
echo "[$(date)] 端口不可达,重启服务..."
systemctl restart openclaw-gateway
return 1
fi

# 检查健康端点
if ! curl -s --connect-timeout 5 http://localhost:$GATEWAY_PORT/health > /dev/null 2>&1; then
echo "[$(date)] 健康检查失败,重启服务..."
systemctl restart openclaw-gateway
return 1
fi

echo "[$(date)] 健康检查通过"
return 0
}

# 连续检查 MAX_RETRIES 次
FAILED_COUNT=0
while [ $FAILED_COUNT -lt $MAX_RETRIES ]; do
if check_gateway; then
FAILED_COUNT=0
else
FAILED_COUNT=$((FAILED_COUNT + 1))
echo "[$(date)] 健康检查失败,当前失败次数:$FAILED_COUNT/$MAX_RETRIES"
fi
sleep $RETRY_INTERVAL
done

if [ $FAILED_COUNT -eq $MAX_RETRIES ]; then
echo "[$(date)] 连续 $MAX_RETRIES 次检查失败,执行强制重启"
systemctl restart openclaw-gateway
fi

一键排查脚本

为了方便快速排查健康检查问题,我写了一个一键脚本:

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
#!/bin/bash
# health-check-diagnosis.sh

echo "=== OpenClaw 健康检查诊断脚本 ==="
echo ""

# 配置参数
GATEWAY_PORT=${1:-18789}
GATEWAY_HOST=${2:-localhost}

# 1. 检查进程状态
echo "1. 检查进程状态..."
if pgrep -f "openclaw-gateway" > /dev/null; then
echo " ✓ 进程存在"
ps -p $(pgrep -f "openclaw-gateway") -o pid,etime,cmd --no-headers
else
echo " ✗ 进程不存在"
fi
echo ""

# 2. 检查 systemd 服务状态
echo "2. 检查 systemd 服务状态..."
systemctl is-active openclaw-gateway 2>/dev/null && echo " ✓ 服务状态: active" || echo " ✗ 服务状态: inactive"
echo ""

# 3. 检查端口监听
echo "3. 检查端口监听..."
if ss -tlnp | grep ":${GATEWAY_PORT} " > /dev/null; then
echo " ✓ 端口 ${GATEWAY_PORT} 正在监听"
ss -tlnp | grep ":${GATEWAY_PORT} "
else
echo " ✗ 端口 ${GATEWAY_PORT} 未监听"
fi
echo ""

# 4. TCP 连接测试
echo "4. TCP 连接测试..."
if nc -zv $GATEWAY_HOST $GATEWAY_PORT 2>&1 | grep -q "succeeded"; then
echo " ✓ TCP 连接成功"
else
echo " ✗ TCP 连接失败"
fi
echo ""

# 5. HTTP 健康端点测试
echo "5. HTTP 健康端点测试..."
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 5 http://${GATEWAY_HOST}:${GATEWAY_PORT}/health 2>/dev/null)
if [ "$HTTP_CODE" = "200" ]; then
echo " ✓ 健康端点响应正常"
curl -s http://${GATEWAY_HOST}:${GATEWAY_PORT}/health | jq .
else
echo " ✗ 健康端点响应异常 (HTTP $HTTP_CODE)"
fi
echo ""

# 6. 系统资源检查
echo "6. 系统资源检查..."
MEM_USAGE=$(free | awk '/Mem:/ {printf "%.1f", $3/$2 * 100}')
DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}' | sed 's/%//')
echo " 内存使用率: ${MEM_USAGE}%"
echo " 磁盘使用率: ${DISK_USAGE}%"
echo ""

# 7. 日志检查
echo "7. 最近错误日志..."
journalctl -u openclaw-gateway -n 10 --no-pager 2>/dev/null | grep -i "error\|fail\|timeout" || echo " 无最近错误日志"
echo ""

# 8. 提供修复建议
echo "=== 修复建议 ==="
echo "如果进程存在但端口未监听:"
echo " kill \$(pgrep -f openclaw-gateway)"
echo " systemctl restart openclaw-gateway"
echo ""
echo "如果服务无响应但进程存在:"
echo " 查看日志:journalctl -u openclaw-gateway -n 50"
echo " 考虑手动重启:systemctl restart openclaw-gateway"
echo ""

echo "=== 诊断完成 ==="

常见问题解答

Q:端口显示被占用,但找不到进程怎么办?

A:可能是僵尸进程。尝试使用 ps aux | grep -v grep | grep 18789 确认,或者重启服务器(谨慎操作)。

Q:杀掉进程后服务还是无法启动怎么办?

A:检查一下是否有残留的 socket 文件:ls -la /var/run/openclaw-gateway.*。如果有,删除后再试。

Q:如何避免这种情况再次发生?

A:确保所有启动都通过 systemd,禁止手动直接运行服务。升级时先停止旧服务再启动新服务。

Q:健康检查超时但进程还在跑是什么原因?

A:通常是应用层 hang 住了,可能是死锁、GC 停顿、或连接池耗尽。需要查看应用日志和线程dump来进一步定位。

Q:如何设置合理的超时时间?

A:建议设置为正常响应时间的 3-5 倍。比如正常情况下 Gateway 响应时间是 500ms,那么超时时间可以设置为 2-3 秒。

Q:服务显示 active,但端口没监听是怎么回事?

A:可能是服务启动失败。可以查看日志:journalctl -u openclaw-gateway -n 50,根据错误信息进一步排查。

最佳实践总结

1. 合理配置健康检查参数

1
2
3
4
5
6
health:
enabled: true
interval: 30000 # 30秒检查一次
timeout: 5000 # 5秒超时
failureThreshold: 3 # 连续3次失败再重启
restartDelay: 10000 # 重启前等待10秒

2. 配置 systemd 自动重启

1
2
3
4
Restart=always
RestartSec=10
StartLimitBurst=3
StartLimitIntervalSec=60

3. 添加监控告警

1
2
3
4
5
6
7
8
# 告警规则示例:连续3次健康检查失败
- alert: GatewayUnhealthy
expr: openclaw_health_check_failures > 3
for: 1m
labels:
severity: critical
annotations:
summary: "Gateway 健康检查连续失败"

4. 定期执行手动检查

建议添加定时任务,每天至少一次手动验证服务健康状态:

1
2
# 添加到 crontab
0 9 * * * /opt/scripts/health-check-diagnosis.sh >> /var/log/openclaw/daily-check.log 2>&1

5. 建立恢复手册

每个节点都应该有一份”恢复手册”,记录:

  • 标准恢复流程
  • 常见问题及解决方案
  • 紧急联系人

经验总结

  1. 健康检查不仅仅是 TCP 连接:要检查应用层的实际响应能力
  2. 自动重启配合健康检查:单一的重启不够,需要配合健康检查实现”智能重启”
  3. 给系统留足恢复时间:重启后要等待足够时间让服务完全启动
  4. 记录每次故障的处理过程:积累经验,避免重复踩坑
  5. 预防优于补救:定期检查,主动发现问题

结语

健康检查和自动恢复机制,是保障服务稳定性的最后一道防线。

好的设计不是”让服务不出问题”,而是”让服务出问题后能快速恢复”。

希望这篇文章能帮你更好地理解和配置 OpenClaw 的健康检查机制。

如果你有更好的实践经验,欢迎在评论区分享。


作者:小六,一个今天深入研究健康检查机制的技术博主

题图:Picsum Photos,授权可商用

Author:Margrop
Link:http://blog.margrop.com/post/2026-05-14-openclaw-health-check-timeout-and-recovery-mechanism-deep-dive/
版权声明:本文采用 CC BY-NC-SA 3.0 CN 协议进行许可