Margrop
Articles243
Tags633
Categories6

Categories

1password 24GB VRAM 2K 3.6 Flash 30B dense 4-bit 量化 6-DoF SLAM AC ACP AI Agent AI Coding Assistant AI Tech AI tutor AI 安全 AI 应用 AI 日记 AI编程助手 ALTK-Evolve AMIE AP API API 定价 API 降价 ARC-AGI-3 ASR ATEM chat 模板 Agent Agent Harness Agent Memory Agent 入侵 Agent 工程 Agent 架构 Agent 检索 Agent 沙箱 Agent 系统 Agent 路由 Agentic AI Agentic tools Ai2 Alertmanager AllenAI Android 17 Antigravity AppDaemon AppWorld Aqara Astra Attention Baseten Benchmark CC-Switch CI/CD CLI Tools CLI工具 CPU 推理 Cache Hit Rate Caddy ChatGPT Claude Code Claude Sonnet ClawLoader Code Interpreter Codex ComfyUI Computer Use Cookie 认证 Cosmos-H-Dreams Cost Optimization Cron DFIR DSpark Date DeepSeek DeepSeek V4 Flash Diagrams.net Diary Diffusers Diffusion Docker Efficiency Tools Embedding English FSDP2 Fable 5 Fireworks AI FlashAttention FlashDreams GGUF GLM 5.2 GLM-5.2 GPT-4.1 GPT-5.6 GPT-Live GPT-Red GPU 加速 GPU 性能分析 Gateway Gemini Gemini 3.5 Flash Gemini API Gemini CLI Gemini Omni Flash Gemma 4 12B Gemma Translator Gemma4 GitHub Actions Google Google AI Google Research Google Sheets Grabette Gripette HA HADashboard HF Security Incident Hailuo Hermes Hexo HomeAssistant Hugging Face IBM Research Inference Providers Isaac Lab Java KV cache Kimi K3 Kubernetes LFM2.5 LFM2.5-VL LLM Router LVM‑Thin Late Interaction LeRobot Linux Liquid AI LiquidAI Live Translate LoRA Luna MCP MTP MacOS Magpie TTS Managed Agents Meta Microsoft 365 Copilot MiniMax Mistral Shieldstral Model Routing MuJoCo Warp Multi-Agent Multi-Vector Muse Glimmer MySQL NAS NIM NVIDIA NeMo Automodel Nemotron 3 Embed Newton Nginx Node.js Nunchaku OCR OOM OlmoEarth On-device AI Open Source OpenAI OpenAI 兼容 OpenClaw OpenCode OpenResty OpenWrt PII 检测 Physical AI Pollen Robotics Portainer PostgreSQL ProcessOn Project Astra Prometheus Prompt Caching Prompt Injection Proxmox VE PyTorch Qwen3-VL Qwen3.6 RAG RPC RTEB Real-Time Inference Red Teaming Responses API SNAP SOCKS5 SPED SVDQuant Scientific Computing Self-Forcing Distillation Sentence Transformers Session Sheets canvas Shell Sol Storage Buckets Strands Agents Subagent Surgical Robotics TTS Terra Think button TimeMachine TutorMoments UML Uptime Kuma V4-Pro VPS VoiceEQ WARP WebRTC WebSocket Windows World Foundation Model agent agentic aligenie aliyun annotation aop autofs backup bash bitwarden boot brew browser budget control centos cert certbot charles chat chrome classloader client clone closures cloudflare command commit commoditization container crontab cyber capability demo dependency deploy developer devtools dll dns docker domain download drafter draw drawio dsm dump dylib environment hooks exception fail2ban feign firewall-cmd flow free tier frontier hosted model frp frpc frps fuckgfw full-duplex function gfw git github gperftools gridea grub guardrail lockout gvt-g hacs havcs heap hello hexo hibernate hidpi hoisting homeassistant hosts html htmlparser https huggingface_hub iKuai iMessage image img img2kvm immortalwrt import index inference cost install intel io ios ip iptables iso java javascript jni jnilib jpa js json jsonb jupter jupyterlab jvm k8s kernel key kvm lastpass launchctl learning letsencrypt linux llama.cpp low-code lvm mac mariadb markdown maven md5 microcode mirror modules monitor mount mstsc multimodal mysql n5105 network nfs node node-red nodejs nohup notepad++ npm nssm ntp oop open weights openfeign openssl os ovz packet capture pdf pem perf pip plugin png powerbutton print pro productive struggle pve pvekclean python qcow2 qemu qemu-guest-agent rar reasoning control reasoning slider reboot reflog remote remote desktop renew repo resize retina router runtime safari sata scaffolding scheduled triggers scipy-notebook scoping scp self-play server serverless inference silent test simulated student so speculative decoding spk spring springboot springfox ssh ssl stash string support svg svn swagger sync synology systemctl systemd template terminal txt ubuntu ui undertow unlocker upgrade vLLM vhd vim vm vmdk web windows with worker xml yum zai-org/GLM-5.2 zip 上下文压缩 上下文工程 交换机 人才争夺 代理 企业 AI 优化 低延迟 供应链 健康检查 光猫 免费层 内存 内存优化 内网渗透 分布式推理 分布式训练 医疗 AI 升级 卫星影像 反向代理 反诉 向量检索 启动 告警 告警优化 地球观测 地理空间推理 复盘评测 夏令时 多 token 预测 多智能体 多模态 多模态 Agent 多语言 大厂人才战 大模型评测 天猫精灵 安全 安全事件 安装 定时任务 实时语音 客户端 SDK 容器 导入 小米 屏幕理解 工具审计 工具调用 工具调用拦截 工程团队 工程实践 工程笔记 常用软件 应用市场 延迟优化 开权重 开源权重 开源模型 异常 异步任务 异步委派 微信 心跳 性能优化 成本优化 成本控制 扩散模型 技术 抓包 按 provider 优先级 排查 推理加速 推理速度 推理预算 描述文件 提示词敏感性 故障排查 效率工具 教育数据开源 教育评测 数据工作流 数据流 数据集偏差 文本编码器 旁路由 日志分析 日记 时区 显卡虚拟化 智能家居 智能音箱 服务管理 本地 agent 机器人仿真 机器人学习 机器人数据采集 架构 模块 模型推理 模型评测 模型路由 残存访问 流式推理 流程 流程图 浏览器 漫游 火绒 电信 画图 监控 监控系统 监管 磁盘 稀疏注意力 立体声 端侧 AI 端侧推理 端口 端口冲突 端口扫描 续期 网关 网络 网络风暴 群晖 脚本 脚本优化 腾讯 自动化 自动恢复 自动攻击 自部署 苹果 虚拟机 视觉语言模型 视频生成 视频问诊 认证 证书 评测 评测基准 评测方法学 诉讼 语音 AI 语音 Agent 语音识别 超时 路由 路由器 软件管家 软路由 运维 运维监控 连接保活 连接问题 通信机制 通知 邮件漏发 部署 配置 量化 钉钉 镜像 镜像源 长上下文 长连接 门窗传感器 问题排查 防火墙 阿里云 阿里源 集客 飞书

Hitokoto

Archive

记一次健康检查脚本执行超时的排查与优化实践

记一次健康检查脚本执行超时的排查与优化实践

前言

健康检查是保障服务稳定性的第一道防线,但如果健康检查本身出了问题,反而会造成误报,影响对服务真实状态的判断。本文记录了一次健康检查脚本执行超时的完整排查过程,最终通过增加缓存机制从根本上解决了问题,而不是简单地调高超时时间。

问题背景

业务场景

我们的自动化运维系统依赖健康检查脚本来监控各节点的服务状态。健康检查脚本会定期执行,检查Gateway进程、端口监听、API连通性等关键指标。如果健康检查失败,系统会自动尝试重启或发送告警。

问题现象

  • 故障时间:近期某日早上
  • 故障表现:健康检查脚本执行超时,错误信息显示执行时间超过预设的30秒阈值
  • 影响范围:某VM的定时健康检查任务持续告警,但实际服务运行正常
  • 环境信息
    • 操作系统:Ubuntu 24.04
    • 健康检查脚本:自定义Bash脚本
    • 超时设置:30秒

初步分析

根据报错信息分析,可能的原因有以下几种:

  1. 网络问题:健康检查脚本需要调用外部API,网络延迟可能导致超时
  2. API响应不稳定:被调用的API响应时间波动较大
  3. 超时设置不合理:30秒的超时对于当前网络环境来说偏紧
  4. 脚本逻辑问题:脚本内部可能存在效率低下的操作

排查过程

第一步:查看健康检查日志

首先查看健康检查脚本的执行日志,确认具体的超时时间:

1
2
3
4
5
6
7
8
# 查看最近一次健康检查的详细日志
cat /var/log/health-check.log | tail -100

# 查找超时相关的日志条目
grep -i "timeout" /var/log/health-check.log

# 查看健康检查的执行时间
grep "execution time" /var/log/health-check.log

日志显示健康检查脚本的执行时间为45秒,超过了30秒的超时阈值。

第二步:分析脚本执行流程

查看健康检查脚本的内容,分析执行流程:

1
2
# 查看健康检查脚本内容
cat /usr/local/bin/health-check.sh

分析脚本逻辑后发现,健康检查包含以下几个步骤:

  1. 检查Gateway进程是否存在
  2. 检查端口18789是否在监听
  3. 调用内部API验证服务可用性
  4. 调用外部API获取额外状态信息
  5. 综合判断并输出结果

问题出在第4步:调用外部API获取额外状态信息。

第三步:测试外部API响应时间

单独测试外部API的响应时间:

1
2
3
4
# 测试API响应时间(多次)
for i in {1..10}; do
time curl -s -o /dev/null -w "%{time_total}s\n" https://api.example.com/status
done

测试结果:

测试次数 响应时间
1 5.2s
2 8.7s
3 35.1s
4 42.3s
5 6.8s

可以看到,API响应时间波动很大,从5秒到42秒不等。这说明API本身不稳定,或者网络链路存在波动。

第四步:确定根本原因

通过以上排查,确定了问题的根本原因:

根本原因:外部API响应时间不稳定,部分情况下超过30秒,而健康检查脚本没有缓存机制,每次执行都需要实时调用API。

次要原因:超时设置30秒虽然对于稳定API来说是合理的,但对于这种波动较大的API来说偏紧。

解决方案

方案对比

方案 优点 缺点 推荐程度
调高超时时间 简单,改动小 不解决根本问题,问题仍会累积 不推荐
增加重试机制 提高成功率 增加执行时间,可能加剧API压力 一般
增加缓存机制 根本解决问题,减少API调用 需要修改脚本逻辑 推荐
改用内部API 响应更稳定 需要确认内部API可用性 可选

综合考虑,我们选择了增加缓存机制作为主要方案。

实现缓存机制

修改健康检查脚本,增加缓存逻辑:

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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
#!/bin/bash

# 健康检查脚本 - 带缓存版本

# 配置
CACHE_FILE="/tmp/health-check-cache.json"
CACHE_TTL=300 # 缓存有效期:5分钟
API_URL="https://api.example.com/status"
TIMEOUT=10 # API调用超时:10秒

# 获取缓存数据
get_cache() {
if [ -f "$CACHE_FILE" ]; then
local cache_time=$(stat -c %Y "$CACHE_FILE" 2>/dev/null)
local current_time=$(date +%s)
local age=$((current_time - cache_time))

if [ $age -lt $CACHE_TTL ]; then
cat "$CACHE_FILE"
return 0
fi
fi
return 1
}

# 设置缓存数据
set_cache() {
local data="$1"
echo "$data" > "$CACHE_FILE"
}

# 检查Gateway进程
check_gateway_process() {
if pgrep -f "openclaw-gateway" > /dev/null; then
echo "Gateway进程运行中"
return 0
else
echo "Gateway进程未运行"
return 1
fi
}

# 检查端口监听
check_port_listening() {
if ss -tlnp | grep -q ":18789 "; then
echo "端口18789正常监听"
return 0
else
echo "端口18789未监听"
return 1
fi
}

# 获取API状态(带缓存)
get_api_status() {
# 尝试从缓存获取
local cached_data=$(get_cache)
if [ $? -eq 0 ] && [ -n "$cached_data" ]; then
echo "使用缓存数据"
echo "$cached_data"
return 0
fi

# 缓存不存在或已过期,调用API
echo "调用外部API获取状态..."
local response
response=$(curl -s -m $TIMEOUT "$API_URL" 2>&1)

if [ $? -eq 0 ]; then
# 保存到缓存
set_cache "$response"
echo "$response"
return 0
else
# API调用失败,尝试使用过期缓存
if [ -f "$CACHE_FILE" ]; then
echo "API调用失败,使用过期缓存"
cat "$CACHE_FILE"
return 0
else
echo "API调用失败,且无缓存可用"
return 1
fi
fi
}

# 主函数
main() {
echo "=== 健康检查开始 ==="
echo "时间:$(date '+%Y-%m-%d %H:%M:%S')"
echo ""

local exit_code=0

# 检查Gateway进程
if ! check_gateway_process; then
exit_code=1
fi

# 检查端口监听
if ! check_port_listening; then
exit_code=1
fi

# 获取API状态
if ! get_api_status; then
exit_code=1
fi

echo ""
echo "=== 健康检查结束,退出码:$exit_code ==="

return $exit_code
}

# 执行主函数
main

优化效果

部署优化后的脚本,观察一周的效果:

指标 优化前 优化后
健康检查执行时间 30-50秒 1-3秒
超时错误频率 每天5-10次 0次
API调用次数/天 ~500次 ~50次
缓存命中率 0% ~90%

一键排查脚本

如果你遇到了类似的健康检查超时问题,可以使用以下脚本进行快速排查:

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
#!/bin/bash

# 健康检查超时问题快速排查脚本

echo "=== 健康检查超时问题排查 ==="
echo ""

# 1. 检查Gateway进程
echo "1. 检查Gateway进程状态:"
ps aux | grep openclaw-gateway | grep -v grep
echo ""

# 2. 检查端口监听
echo "2. 检查端口18789监听状态:"
ss -tlnp | grep 18789
echo ""

# 3. 测试网络连通性
echo "3. 测试网络连通性:"
curl -v -m 10 https://api.example.com/status 2>&1 | head -20
echo ""

# 4. 检查缓存状态
echo "5. 检查缓存文件状态:"
if [ -f /tmp/health-check-cache.json ]; then
echo "缓存文件存在,最后修改时间:"
stat /tmp/health-check-cache.json | grep Modify
echo "缓存内容:"
cat /tmp/health-check-cache.json
else
echo "缓存文件不存在"
fi

echo ""
echo "=== 排查完成 ==="

常见问题解答

Q1:为什么不直接调高超时时间?

A:调高超时时间只是让问题隐藏起来,并不能解决API响应不稳定的问题。当API响应时间超过新的阈值时,问题会再次出现。而且,过长的超时时间会影响整体检查效率。

Q2:缓存过期了怎么办?

A:我们的实现中,当缓存过期且API调用失败时,会使用过期缓存作为Fallback。虽然数据可能不是最新的,但至少能保证健康检查不会因为临时的API问题而失败。这是一种容错设计。

Q3:缓存TTL设置多少合适?

A:这取决于你的业务场景。如果状态变化比较频繁,可以设置短一点(如1-5分钟);如果状态相对稳定,可以设置长一点(如15-30分钟)。我们的场景是5分钟,实际使用效果良好。

Q4:缓存机制有什么副作用吗?

A:主要副作用是健康检查结果可能有短暂延迟(最长为TTL时间)。但这个延迟对于大多数场景来说是可以接受的,而且可以通过监控实际API状态来弥补。

Q5:还有其他优化方案吗?

A:可以考虑:1)改用更稳定的内部API代替外部API;2)实现异步健康检查,将检查结果写入队列;3)使用服务网格层的健康检查机制。不同方案适用场景不同,需要根据实际情况选择。

经验总结

  1. 不要用超时掩盖问题:调高超时时间只是让问题隐藏起来,根因仍然存在

  2. 缓存是解决API不稳定的有效手段:对于变化不频繁的状态信息,缓存可以大大减少API调用,同时提高响应稳定性

  3. Fallback机制很重要:即使有缓存,也需要考虑缓存失效的情况,设计合理的Fallback逻辑可以提高系统的容错能力

  4. 监控很重要:部署优化后,持续监控API响应时间和缓存命中率,及时发现新的问题

  5. 文档要同步更新:修改了健康检查逻辑后,记得更新相关文档,避免后续维护困难

延伸阅读

结语

健康检查是保障服务稳定性的重要手段,但如果健康检查本身设计不当,反而会造成误报。通过增加缓存机制,我们不仅解决了超时问题,还减少了不必要的API调用,提高了整体效率。这个案例也提醒我们:解决问题的最好方式不是增加限制,而是优化流程


作者:小六,一个在上海努力搬砖的程序员

本文阅读量 --
Author:Margrop
Link:https://blog.margrop.com/post/2026-04-21-troubleshooting-health-check-script-timeout/
版权声明:本文采用 CC BY-NC-SA 3.0 CN 协议进行许可