生产环境中健康检查频率需匹配服务响应特征与业务容忍度：核心web/api服务推荐10–20秒，数据库代理/缓存客户端5–10秒，后台任务容器60–120秒；必须配合start_period（如spring boot设40–60秒）和timeout（须小于interval）使用，并采用轻量探测（如pg_isready、redis-cli ping），避免全链路请求加重负担。
生产环境中，健康检查频率不能只图“快”，也不能一味求“省”。核心是让检测节奏匹配服务的真实响应特征和业务容忍度，避免假死误判或故障漏检。
根据服务类型和关键性分级设定 interval
高频检测适合强实时依赖的服务，比如网关、订单中心；低频则适用于批处理、报表等边缘服务。
- 核心 Web/API 服务：推荐 10–20 秒。既能较快捕获崩溃或卡死（如线程阻塞、连接池耗尽），又不会对 Nginx 或应用本身造成明显压力
- 数据库代理/缓存客户端：用 5–10 秒，尤其当上层服务依赖其快速反馈连接状态时
- 后台任务容器（如定时 job）：可放宽至 60–120 秒，因它们本就不持续提供请求服务，健康与否更多看进程是否存活+日志输出是否活跃
必须搭配 start_period 和 timeout 使用
只调 interval 不设启动宽限期，等于在服务还没热起来时就开枪——90% 的“启动期 unhealthy”都源于此。
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- start_period 要覆盖完整初始化时间：Spring Boot 应用建议 40–60s，含类加载、DB 连接池填充、缓存预热；PostgreSQL 容器可设为 30s（pg_isready 响应快）
- timeout 必须小于 interval：若 interval=10s，timeout 就不该超过 7s，否则两次检查可能重叠，堆积子进程或连接
- 例如：interval: 15s, timeout: 5s, start_period: 45s 是一个稳定组合，兼顾启动鲁棒性和运行期敏感度
用轻量探测替代全链路请求
别让健康检查变成压测。/health 端点如果每次都要查 DB、调远程服务、渲染模板，那它自己就是故障源。
- Web 服务的 /health 应只检查本地进程状态 + 内存/线程池水位 + 关键依赖连通性（如 Redis ping、DB ping），不执行业务逻辑
- 数据库容器直接用原生命令：
pg_isready（PostgreSQL）、mysqladmin ping（MySQL）、redis-cli ping（Redis）——毫秒级完成，无 HTTP 开销 - 避免 curl -f http://localhost:8080/health 这类写法在资源受限容器中反复创建 TCP 连接；改用
test -f /tmp/app.ready或 socket 连接检查更轻量
监控 FailingStreak 和 Log 辅助调优
别凭感觉调参数。上线后盯紧实际检查日志，用数据反推是否合理：
- 运行
docker inspect <cid> | jq '.State.Health'</cid>查看最近几次检查的 timestamp、exit code、output - 如果 FailingStreak 在 1–2 波动但很快恢复 → timeout 太短或网络偶发抖动，可略增 timeout 或 retries
- 如果连续失败发生在固定时间点（如每小时整点），大概率是业务侧定时任务占满 CPU，需协同优化，而非调 interval
- Log 中出现 “connection refused” 多于 “timeout” → 检查服务是否真没起来，或 port 绑定延迟，不是检查太勤的问题
